你有没有遇到过这种情况：让 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 才不是一个提示词技巧，而是一个真正可控的工程结构。