18Three-Agent Harness
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 解开验证)
场景:用户对 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 一关,虚假完成无处藏。
何时用 Three-Agent
- 任务可拆分为可验证的 acceptance criteria——code、feature、bug fix 都适合
- 产出需要被信任——直接进生产、对用户负责
- 用户付出了高成本(长时间、大算力)等结果——不能虚假完成
- 愿意用 ~2-3× token 成本换准确率——Evaluator 跑一次接近 Generator 的 token 量