1
2
3
4
5
6
7
8

用户："帮我写一个 HTTP server"
Alice 委派给 Bob
Bob 回复："写好了，编译通过，在 /tmp/server/main.go"

问题：
  - Bob 真的跑了 go build 吗？还是只是"觉得"能编译？
  - Alice 怎么判断这个回复可信？
  - 用户怎么知道这个结果经过了验证？

1
2
3
4
5

mesh_send_message(
  to_agent_id: "bob-coder@example",
  text: "重构 task 模块的状态机逻辑，抽到独立文件",
  complexity: "high"
)

1
2
3
4
5
6

function inferComplexity(text: string): 'low' | 'medium' | 'high' {
  const highSignals = ['重构', '架构', '设计', '迁移', '从零', '全面', '系统性', '多模块']
  if (highSignals.some(s => text.includes(s))) return 'high'
  if (text.length > 200 || text.includes('步骤') || text.includes('然后')) return 'medium'
  return 'low'
}

1
2
3
4

parts: [
  { kind: 'text', text: '重构 task 模块...' },
  { kind: 'metadata', key: 'complexity', value: 'high' }
]

1
2
3
4
5
6

语义握手（收到任务时的自主判断）：
  收到一个新任务时，先评估是否需要确认理解再执行：
  - 任务有歧义（"优化这个服务"——优化什么？延迟？内存？吞吐？）→ 先确认
  - 任务涉及多步骤或多文件 → 先确认方案
  - 任务有隐含假设（"部署到生产"——要不要先跑测试？）→ 先列出假设让对方确认
  - 任务很简单明确（"查一下版本号"）→ 直接执行，不需要确认

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

if (complexity === 'high' || complexity === 'medium') {
  lines.push(`⚠️ 这是一个${complexity === 'high' ? '高' : '中等'}复杂度任务，请先确认你的理解再执行：`)
  lines.push(`1. 用 mesh_reply 回复你理解的范围、方法和假设`)
  lines.push(`2. 等对方确认后再动手执行`)
  lines.push(`3. 如果有疑问，在回复中列出`)
  lines.push(``)
  lines.push(`回复格式参考：`)
  lines.push(`  范围：...`)
  lines.push(`  方法：...`)
  lines.push(`  假设：...`)
  lines.push(`  疑问：...`)
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

Alice → Bob（complexity=high）：
  "重构 task 模块，把状态机逻辑从 service.go 抽到独立的 fsm.go"

Bob 收到的 prompt：
  ⚠️ 这是一个高复杂度任务，请先确认你的理解再执行...

Bob 回复：
  范围：把 Transition()、IsAllowedTransition()、allowedTransitions map 抽到 fsm.go
  方法：新建 fsm.go，移动函数，service.go 改为调用 fsm 包
  假设：不改 Service 的公开 API，只是内部重组
  疑问：状态常量（StateSubmitted 等）也移过去吗？

Alice 确认：
  确认。状态常量也移过去，fsm.go 包含完整的状态机定义。

Bob 开始执行。

1
2
3
4
5

验证清单（完成编码任务后必须执行）：
  □ 文件已创建/修改 → 用 Read 确认文件内容正确
  □ 编译通过 → 用 Bash 跑 go build 或 bun build
  □ 基本功能正确 → 用 Bash 跑 go test 或 go run
  注意：系统会自动检测你是否执行了验证，并在回复末尾追加标注。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

hooks: {
  PostToolUse: [{
    hooks: [async (event) => {
      const toolName = event?.tool_name || ''
      const exitCode = event?.tool_result?.exit_code
      const cmd = event?.tool_input?.command || ''
      if (toolName === 'Bash' && exitCode === 0) {
        if (cmd.includes('go build')) turnCtx.verifications.push('编译通过(exit 0)')
        else if (cmd.includes('go test')) turnCtx.verifications.push('测试通过(exit 0)')
      } else if (toolName === 'Bash' && exitCode !== undefined && exitCode !== 0) {
        turnCtx.verifications.push(`命令失败(exit ${exitCode}): ${cmd.slice(0, 50)}`)
      }
      return { continue: true }
    }],
  }],
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

async function runIndependentVerification(replyText: string, cwd: string): Promise<string[]> {
  const results: string[] = []

  // 检测"创建了 xxx.go" → stat 确认文件存在
  const filePathPattern = /(?:创建|写入|生成).*?([/\w.\-@]+\.\w{1,5})/g
  // ... 对每个匹配的路径执行 stat

  // 检测"编译通过" → 跑 go build 确认
  if (replyText.includes('编译通过')) {
    await execAsync('go build ./...', { cwd, timeout: 15000 })
    results.push('编译通过')
  }

  // 检测"测试通过" → 跑 go test 确认
  if (replyText.includes('测试通过')) {
    await execAsync('go test ./...', { cwd, timeout: 30000 })
    results.push('测试通过')
  }

  return results
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

const independentResults = await runIndependentVerification(args.text, turnCtx.cwd)
const agentVerified = turnCtx.verifications.length > 0

if (independentResults.length > 0) {
  annotations.push(`[独立验证 ✓] ${independentResults.join('、')}`)
}
if (agentVerified) {
  annotations.push(`[agent 已验证] ${remaining.join('、')}`)
}
if (annotations.length === 0) {
  annotations.push('[未验证] 以上结论基于推理，未执行验证命令')
}

1
2
3
4

hello.go 已创建，编译通过，可以直接 go run。

[独立验证 ✓] 文件存在: hello.go、编译通过
[agent 已验证] 编译通过(exit 0)、运行成功(exit 0)

1
2
3

代码写好了，但编译有个小问题，我来修一下。

[agent 已验证] 命令失败(exit 1): go build ./...

1
2
3

建议把查询改成批量接口，预计能降低 60% 的延迟。

[未验证] 以上结论基于推理，未执行验证命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

用户发任务给 Alice
    │
    ▼
Alice 评估复杂度（显式指定或启发式推断）
    │
    ├── low → effort=low, thinking=disabled
    │         直接委派 Bob，Bob 执行后回复带行为标注
    │
    ├── medium → effort=medium, thinking=adaptive
    │            语义握手（Bob 先确认理解）→ 执行 → 行为标注
    │
    └── high → effort=high, thinking=adaptive
               语义握手 → 执行 → 行为标注 → Alice 自己也验证
                                                → 双重标注

全程硬性防护：maxTurns=30, maxBudgetUsd=$5
PostToolUse hook 实时记录每个工具调用的成功/失败

1
2
3
4
5
6
7
8

// low complexity → 快速响应，省 token
effort: 'low', thinking: { type: 'disabled' }

// medium complexity → 适度推理
effort: 'medium', thinking: { type: 'adaptive' }

// high complexity → 深度推理，质量优先
effort: 'high', thinking: { type: 'adaptive' }

1
2

maxTurns: 30,      // 单次事件最多 30 轮对话
maxBudgetUsd: 5.0, // 单次事件最多花 $5

1
2
3

1. 范围偏差：A 说"优化这个服务"，B 理解为"优化延迟"，A 其实想"优化内存"
2. 粒度偏差：A 说"简单分析一下"，B 写了 2000 字深度报告
3. 隐含假设偏差：A 说"部署到生产"，A 假设 B 知道要先跑测试，B 直接部署了

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

Layer 1: 信息查询（RPC）
  → Agent A 问 Agent B 一个问题，B 返回答案
  → 本质：同步函数调用
  → 示例：A 问 B "这个函数在哪个文件"

Layer 2: 任务委托（异步）
  → Agent A 把一个完整任务交给 B，B 独立完成后返回结果
  → 本质：异步任务队列
  → 示例：A 让 B "分析这个服务的性能瓶颈"

Layer 3: 方案对弈（迭代）
  → Agent A 和 B 就一个问题来回讨论，互相挑战对方的方案
  → 本质：多轮协商
  → 示例：A 和 B 讨论"这个系统应该用什么架构"

Layer 4: 共创涌现（真协作）
  → 多个 Agent 共享上下文，持续演化一个方案，产出超越任何单个 Agent 的结果
  → 本质：集体智能
  → 示例：多个 Agent 共同设计一个复杂系统，各自贡献不同视角

1
2
3
4
5
6
7
8

用户请求："帮我重构这个函数"

过度拆分后的调用链：
User → Planner → CodeReader → Analyzer → Refactorer → CodeWriter → Tester → Reporter
                    ↕              ↕            ↕           ↕
              (语义分区风险)  (语义分区风险) (语义分区风险) (语义分区风险)

每多一跳，语义偏差累积一次。7 跳之后，最终输出可能已经偏离原始意图。

1
2
3
4
5
6
7
8

实际生成过程：
  模型倾向 → 结论方向已定 → 生成支撑该结论的推理步骤

看起来像：
  前提 → 推理步骤 1 → 推理步骤 2 → 结论

本质区别：
  推理链是结论的"事后合理化"，不是结论的"推导来源"

1
2
3
4
5

可信度 = f(锚点密度)

其中：
  锚点 = 可被独立验证的事实声明
  密度 = 锚点数量 / 推理步骤总数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

低密度（不可信）：
  "这个服务延迟高是因为 DB 慢查询导致的"
  → 纯推理，无锚点，密度 = 0

中密度（部分可信）：
  "这个服务 P99 延迟 = 500ms [L2: 监控数据]，
   其中 DB 查询占 400ms [L2: trace 数据]，
   所以瓶颈在 DB"
  → 2 个锚点 / 3 步推理，密度 ≈ 0.67

高密度（可信）：
  "这个服务 P99 延迟 = 500ms [L2: 监控数据]，
   DB 查询占 400ms [L2: trace 数据]，
   该查询缺少索引 [L1: EXPLAIN 输出]，
   加索引后延迟降至 50ms [L1: 测试环境验证]"
  → 4 个锚点 / 5 步推理，密度 = 0.8

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

message:
  content: "服务延迟瓶颈在 DB 层"
  assertions:
    - claim: "P99 延迟 500ms"
      confidence: verified
      evidence: "grafana 监控面板 2024-01-15 14:00-15:00"
      verify_command: "curl 'http://grafana/api/query?...' "

    - claim: "DB 查询占 80% 耗时"
      confidence: verified
      evidence: "trace_id=abc123 的 span 分析"
      verify_command: "python mlog_log.py trace abc123 live.service.name"

    - claim: "根因是缺少联合索引"
      confidence: inferred
      reasoning: "查询条件涉及 user_id + created_at，当前只有单列索引"
      verify_command: "EXPLAIN SELECT ... FROM table WHERE user_id=? AND created_at>?"

    - claim: "加索引后预计延迟降至 50ms"
      confidence: uncertain
      reasoning: "基于类似场景的经验估算，未实际验证"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

                    ┌─────────────────────────────┐
                    │     Agent 输出（可能有错）     │
                    └──────────────┬──────────────┘
                                   ▼
                 ┌─────────────────────────────────┐
  Layer 1:       │  格式检查：输出结构是否完整？      │  ← 成本最低
                 └──────────────┬──────────────────┘
                                ▼
                 ┌─────────────────────────────────┐
  Layer 2:       │  逻辑检查：前后是否自洽？          │  ← 低成本
                 └──────────────┬──────────────────┘
                                ▼
                 ┌─────────────────────────────────┐
  Layer 3:       │  锚点验证：verified 声明是否属实？ │  ← 中等成本
                 └──────────────┬──────────────────┘
                                ▼
                 ┌─────────────────────────────────┐
  Layer 4:       │  交叉验证：独立 Agent 是否同意？   │  ← 较高成本
                 └──────────────┬──────────────────┘
                                ▼
                 ┌─────────────────────────────────┐
  Layer 5:       │  人类审查：关键决策人工确认        │  ← 最高成本
                 └─────────────────────────────────┘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# 阶段 1：任务下发
message:
  type: task_request
  from: alice
  to: bob
  content: "分析 user-service 的性能瓶颈并给出优化建议"
  complexity_hint: medium

# 阶段 2：意图确认（接收方返回理解）
message:
  type: intent_confirmation
  from: bob
  to: alice
  understanding:
    scope: "user-service 的 API 延迟问题"
    approach: "查看监控 → 定位慢接口 → 分析 trace → 给出优化建议"
    output_format: "根因分析 + 优化建议列表（按优先级排序）"
    assumptions:
      - "重点关注 P99 延迟，不是吞吐量"
      - "优化建议限于代码层面，不涉及基础设施变更"
    questions:
      - "需要关注特定时间段吗？还是看整体趋势？"

# 阶段 3：确认/修正
message:
  type: intent_ack
  from: alice
  to: bob
  status: confirmed_with_correction
  corrections:
    - "也要看吞吐量，最近有用户反馈 QPS 上不去"

# 阶段 4：执行确认
message:
  type: execution_start
  from: bob
  to: alice
  content: "收到，开始分析。预计输出：延迟+吞吐量双维度分析，覆盖最近 7 天。"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

class Assertion:
    claim: str           # 声明内容
    confidence: str      # verified | inferred | uncertain
    evidence: str        # 证据来源（verified 必填）
    verify_cmd: str      # 验证命令（可选）
    reasoning: str       # 推理过程（inferred/uncertain 必填）

class AgentOutput:
    summary: str
    assertions: List[Assertion]

    @property
    def trust_score(self) -> float:
        """锚点密度 = verified 数量 / 总声明数量"""
        total = len(self.assertions)
        verified = sum(1 for a in self.assertions if a.confidence == "verified")
        return verified / total if total > 0 else 0

# 接收方处理逻辑
def handle_output(output: AgentOutput, risk_level: str):
    if risk_level == "low":
        return accept(output)
    elif risk_level == "medium":
        for a in output.assertions:
            if a.confidence == "inferred" and a.verify_cmd:
                validate(a)
        return accept_with_caveats(output)
    elif risk_level == "high":
        for a in output.assertions:
            if a.confidence != "verified":
                require_validation(a)
        return accept_after_validation(output)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

def assess_complexity(task: str) -> str:
    signals = {
        "scope_ambiguity": check_ambiguity(task),
        "step_count": estimate_steps(task),
        "domain_count": count_domains(task),
        "reversibility": assess_reversibility(task),
        "blast_radius": assess_impact(task),
    }

    if signals["blast_radius"] == "high" or not signals["reversibility"]:
        return "high"
    if signals["step_count"] > 5 or signals["domain_count"] > 2:
        return "medium"
    if signals["scope_ambiguity"] == "low" and signals["step_count"] <= 3:
        return "low"
    return "medium"

# 复杂度 → 协作模式映射
COMPLEXITY_TO_MODE = {
    "low":    {"handshake": False, "annotation": "minimal", "verification": "L1-2"},
    "medium": {"handshake": True,  "annotation": "full",    "verification": "L1-3"},
    "high":   {"handshake": True,  "annotation": "full",    "verification": "L1-4"},
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

Week 1-2: 复杂度评估（方案 3）
  → 先有分类能力，为后续方案提供触发条件

Week 3-4: 语义握手（方案 1）
  → 对 medium/high 任务启用
  → 观察：握手后的返工率 vs 不握手的返工率

Week 5-8: 三级标注（方案 2）
  → 对所有输出启用标注
  → 观察：trust_score 与实际准确率的相关性

持续迭代：
  → 收集"语义偏差"案例，优化复杂度评估规则
  → 收集"锚点验证失败"案例，优化标注策略
  → 数据足够后，考虑引入对抗性验证