18Three-Agent Harness

L3P0五步章 · 概念章
Why · 为什么要学
你的 agent 报告"任务完成 ✅"——结果用户一看,测试根本没跑通,文档也没写,只是模型"觉得做完了"。这是 LLM 的 self-validation bias——对自己产出偏向正面评估。Three-Agent Harness 借鉴 GAN 的对抗思想把"做事"和"评判"分开,是当下生产级 agent 解决"虚假完成"的核心架构。这一节决定你能不能让 agent 输出"被验证过的成果",而不是"自吹自擂的报告"。
1 ·核心要点

Anthropic 2026-03 提出的 Planner / Generator / Evaluator 三 agent 架构:

┌─────────────────────────────────────────────┐
│  Planner    把任务拆成验收标准              │
│             acceptance criteria 列表        │
│             每条默认 = FALSE                │
└─────────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────────┐
│  Generator  拿一条标准 → 生成代码/改动      │
│             产出代码 + 工作过程日志         │
└─────────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────────┐
│  Evaluator  用 fresh context 评分:         │
│             这条标准真的 met 了吗?         │
│             需要打开证据(测试输出/文件)   │
│             才能标 TRUE                     │
└─────────────────────────────────────────────┘
       ↑________ loop ________│

Claude Code 的 /goal 命令就是 generator-evaluator loop 的产品化。

关键设计 1:Default-FAIL Evaluator。每个验收标准默认 FALSE,Generator 不打开证据(运行测试看输出、cat 文件检查内容、grep 特定字符串)就不能标记 met。这一条直接对抗 LLM 的 self-validation bias。

关键设计 2:Fresh-Context Evaluator。Evaluator agent 必须用全新 context——没看过 Generator 怎么写的、没看过 Planner 怎么拆的。它只看 acceptance criteria + Generator 的最终产出。同 context 评判 self-validation bias 严重(Anthropic 实测准确率低 15~30%)。

关键设计 3:对抗 vs 协作。Three-Agent 是对抗式架构(Generator 想 pass、Evaluator 想 fail),Multi-Agent(见 #23)是协作式(都为同一目标)。GAN 启发 vs 分布式系统启发,不是同一类问题。

验收标准的写法(影响整套架构能否工作):

# 差的(模糊,Evaluator 会随便 pass)
- 实现登录功能

# 好的(可验证,Evaluator 必须打开证据)
- POST /login 接口存在,接受 {email, password}
- 正确密码返回 200 + jwt_token 字段
- 错误密码返回 401
- 单元测试 test_login_success 和 test_login_wrong_password 都通过
- jwt token 过期时间 24h(用 jwt.decode 解开验证)
2 ·真实系统拆解
概念章——用 Claude Code /goal 命令做案例

场景:用户对 Claude Code 说 "/goal 给项目加 OAuth2 登录"

Step 1 — Planner
  输出 acceptance.md:
    - [ ] 1. 新增 /auth/oauth/login 接口
    - [ ] 2. 新增 /auth/oauth/callback 接口
    - [ ] 3. 集成 Google OAuth provider
    - [ ] 4. 实现 token 刷新
    - [ ] 5. 单元测试覆盖率 ≥ 80%
    - [ ] 6. 文档更新(README + API.md)

Step 2-N — Generator (Loop)
  每次取一条 unchecked criterion:
    - 写代码、改文件
    - run 测试、看输出
    - 自己标 [ ] → [x]?不行,要 Evaluator 来确认

Step N+1 — Evaluator (Fresh Context)
  收到 acceptance.md(全部 unchecked)+ 代码 diff
  对每条标准:
    - 打开证据(运行测试、grep 文件、看输出)
    - 真满足 → 标 [x]
    - 不满足 → 留 [ ]、给 Generator 反馈

Step ↻ — 回到 Step 2 直到全 [x]

对比"单 agent 自评"模式:Generator 会快速"自宣布完成"——8 个未实现的细节被一句"已实现 OAuth2"概括。Three-Agent 强制每条标准都过 Evaluator 一关,虚假完成无处藏。

3 ·工程权衡

何时用 Three-Agent

  1. 任务可拆分为可验证的 acceptance criteria——code、feature、bug fix 都适合
  2. 产出需要被信任——直接进生产、对用户负责
  3. 用户付出了高成本(长时间、大算力)等结果——不能虚假完成
  4. 愿意用 ~2-3× token 成本换准确率——Evaluator 跑一次接近 Generator 的 token 量