你是否遇到过这样的情况：让 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 就不再仅仅是一个提示词技巧，而是一个真正可落地、可控的工程化结构。
