Anthropic Generator+Critic 测试用例可靠性验收

许多开发者在让 Agent 撰写测试用例后，要求它自我检查质量，却常得到“写得很好，覆盖全面”的反馈，而自己一眼就能发现明显漏洞。此时不必急于质疑模型能力，问题往往出在架构设计上。

在 Agent 工程实践中，生成结果仅仅是起点，真正的稳定性隐患通常来自验收环节。若验收与生成处于同一上下文，系统看似增设了一道检查，实则仅让同一套判断逻辑重复确认自身结论。对于测试用例、代码审查、需求拆解等任务，这一缺陷尤为突出——错误往往非语法问题，而是场景遗漏、边界误解、默认假设未被挑战。

自我审查的局限性

让同一个 Agent 同时担任选手和裁判，本质上是让它在同一上下文里扮演两个角色。问题在于，这两个角色共享同一段记忆。

Agent 在生成输出时已构建一套自洽的推理链条。当其回头审查自身输出时，看到的并非“这份输出是否正确”，而是“这份输出是否与我推理一致”。这是两个截然不同的问题。

类比于学生写完卷子立即检查，往往会漏掉同样的错误——思维仍停留在刚建立的解题框架内。Agent 同理。

这也是诸多自检提示词效果不稳定的根本原因。即使要求 Agent 更严格、更仔细、从反方视角检查，但只要上下文未隔离，它仍会沿用生成阶段的解释框架。并非它有意放水，而是它未获得足够独立的信息位置。

Anthropic 的解决方案：物理隔离

Anthropic 在其托管 Agent 平台中引入了 Outcomes 结果评估机制，核心设计仅一条：评分模型在独立的上下文窗口内运行，完全不接触主 Agent 的推理过程。

它仅关注两件事：用户提供的评分标准（Rubric），以及主 Agent 的最终输出。仅此而已。

这种物理隔离确保评审者不带先入为主的偏见。它不知道主 Agent 的思考过程，只知最终结果和评判标准。

这即是 Generator + Critic 双模式。

该设计的关键不在于更换模型或让评审模型显得更聪明，而在于将执行者与评审者置于不同的信息环境中。Generator 负责完成任务，Critic 负责按标准验收结果。二者之间仅传递最终产物，不传递推理过程、中间草稿、自我解释——如此 Critic 才能从外部视角发现缺口。

两个角色，两个上下文

┌──────────┐
│ 任务输入 │
└────┬─────┘
     │
     ▼
┌─────────────────────┐
│     Generator       │
│ 执行任务，生成输出   │
│ （独立上下文）       │
└──────────┬──────────┘
           │ 输出结果
           ▼
┌─────────────────────┐   ┌──────────────┐
│       Critic        │──│    Rubric    │
│ 独立评分            │   │ 评分标准     │
│ （不看推理过程）    │   └──────────────┘
└──────┬──────┬───────┘
       │      │
   达标     不达标
       │      │
       ▼      │
┌──────────────────────┐ │
│ 附上问题说明，交回重试 │ │
└──────────┬───────────┘ │
           │              │
           └────── 回到 Generator
                      ▼
               ┌──────────────┐
               │  最终输出    │
               └──────────────┘

整个流程的核心在于：Generator 与 Critic 之间仅传递输出结果，而非推理过程。Critic 获得一份输出加一份评分标准，它无需知道 Generator 的思考方式。这种信息隔离才是该模式真正的价值所在。

落地到工程系统中，可将其理解为三条边界：执行上下文与评审上下文分离；评分标准在执行前明确；评审失败后仅将问题清单交回 Generator。如此，重试时针对具体问题修复，而非让 Agent 重新运行一次碰运气。

Rubric 是模式的核心

许多人理解 Generator + Critic 时，将重点放在是否拥有 Critic，但真正决定效果的是 Rubric 的编写质量。

模糊的 Rubric，例如“检查质量是否足够好”，等于没有 Rubric，因为 Critic 缺乏实质性依据。优秀的 Rubric 应具体且可判断，例如：

• 是否覆盖了正向、逆向、边界三类场景？
• 每条用例是否有明确的预期结果？
• 是否避免了重复的测试逻辑？

每一条都能被独立判断“有”或“没有”，而不依赖主观感受。

若评审测试用例，Rubric 还应明确不通过的条件：缺少边界值视为不通过，预期结果含糊视为不通过，步骤无法复现视为不通过。只有将失败条件写清楚，Critic 才能输出可执行的反馈，而非一段看似专业却无法落地的评价。

换言之，Generator + Critic 的质量上限往往不取决于 Critic 的态度，而取决于 Rubric 的颗粒度。标准越具体，评审越接近验收；标准越抽象，评审越像是复述。

重试机制并非万能

该模式引入重试后，许多人误以为多跑几遍就能获得好结果。实际上，若 Rubric 本身有误，重试只会强化错误方向的执行。

另一个常被忽略的问题是重试次数上限。无上限的重试，在极端情况下可能导致 Agent 陷入死循环——每次输出都被 Critic 打回，而 Generator 无法改进，因为问题出在任务本身的定义上，而非执行质量。通常建议设定最大重试次数，超出后转交人工处理，而非继续重复运行。

更稳妥的做法是将重试设计为有限闭环：首次失败，要求 Generator 根据问题清单定向修复；第二次仍失败，则判断是 Rubric 过严、任务定义不清，还是输入信息不足。此时继续重试的收益很低，应接入上下文、标准或人工确认。

总结

Generator + Critic 本质上是一种关注点分离的设计：执行与评审不应混合在同一个上下文中。这一思路并不复杂，但若不显式设计，Agent 默认会同时扮演运动员和裁判。

因此，在设计 Agent 流程时，不应只问它能否自我检查，而应提出三个更具体的问题：评审者是否独立，Rubric 是否可判断，失败后是否有明确的重试上限。将这三点设计清楚，Generator + Critic 就不再是一个提示词技巧，而是一个真正可控的工程结构。