上个月我给内部重构 Agent 补了一道“保险”。
为了防止它漏改边界，我在提示词末尾加了一行：“请仔细审查刚刚生成的代码，检查潜在逻辑漏洞；如果有，请直接修正。”
逻辑看起来很顺理成章：写完代码复查一遍，是人类工程师的基本习惯。
但跑到第六个处理并发 Map 的文件时，离奇的一幕出现了：原本跑通的单测，被它这道“自我审查”硬生生改出了两个新的类型报错，甚至顺手把正确的读写锁替换成了一个早已废弃的全局 Mutex。
这种自我审查极少能抓住深层 Bug。相反，它经常把原本写对的代码改得面目全非，或者把一个能跑通的逻辑改出全新的语法错误。
这并不是提示词写得不够严厉。
ICLR 2024 的一项研究在测试 GPT-4 时发现：在没有任何外部环境反馈的情况下，让大语言模型自我审查并修正代码，它把正确答案改错的概率，远远高于把错误答案改对的概率。
审查如果不引入新信息，本质上只是强迫模型就着上一轮的幻觉再猜一遍。
审查生效的唯一物理判据
多 Agent 协作或审查机制在什么情况下才能真正起效？
判断标准其实只有一条：审查过程是否引入了单个 Agent 在生成时无法获得的外部新信息？
| 审查模式 | 是否引入新信息 | 实际效果 |
|---|---|---|
| 同一模型自我审查（重读自己的输出） | 否 | 通常无效甚至有害（把对改错） |
| 两个 Agent 共享上下文互相辩论 | 否 | 消耗双倍 Token，能力几乎零提升 |
| 审查者读取单元测试与编译器报错 | 是（执行反馈） | 显著提升 |
| 审查者读取界面渲染截图 | 是（视觉反馈） | 显著提升 |
| 审查者调用外部工具核验事实 | 是（工具反馈） | 显著提升 |
注意第二行：单纯把一个模型拆成两个角色互相辩论，根本无法突破单模型的推理上限。
学术界经常有研究指出“多 Agent 辩论用处不大”，而工业界的一线工程却普遍推崇多 Agent 架构。两者的结论之所以看似矛盾，根源就在于评测对象的不同：
学术界测试的大多是封闭上下文内的文字互评，信息熵并没有增加；而工业界真正跑通的多 Agent，无一例外都在审查环节挂载了外部环境通道——运行真实的测试用例、执行静态类型检查、抓取渲染后的 DOM 截图。
这些来自外部世界的客观反馈，在模型最初生成代码时并不存在。有了这层新信息的注入，审查才具备了物理上的纠偏能力。
模型可以提议完成，但无权批准自己的完成
在没有外部硬反馈的情况下让 Agent 自查，最容易诱发三类经典的系统失效形态：
- 偷懒式假完成：代码刚写完，单测没跑、构建没试，模型便自信满满地在末尾输出“任务已圆满完成”；
- 过早放弃：在解决复杂依赖时调了一个工具失败，就直接判定“该方案不可行”并退回给人类；
- 假成功：环境返回了 500 报错，但因为返回的 JSON 结构里带了 success 字段，模型误判为成功并关单。
这三种形态的本质完全一致：在独立验证介入之前，“完成”只是模型的一句主观宣称，绝不是客观证明。
生产级 Harness 必须确立一条铁律般的系统不变量：
模型可以提议“完成”，但绝不能批准自己的“完成”。
一个 Agent 循环的真正瓶颈永远在验证器（Verifier），而不在生成模型。如果验证器无法提供确定性的对错信号，循环转得再快，也只是以更高的并发把劣质产出标记为通过。
提议者—审核者（Proposer-Reviewer）的架构边界
要把这套机制落到工程代码中，标准的解法是采用 提议者—审核者（Proposer-Reviewer） 架构。
它包含三条硬性的工程纪律：
1. 产出方与评判方的上下文必须物理隔离
Reviewer 的上下文里，绝对不能包含 Proposer 刚才长达数千字的思考过程（Thinking Block）。
如果让 Reviewer 带着 Proposer 的推理路径去审查，Reviewer 会不可避免地被同一套推理所诱导。Reviewer 应该只接收两样东西：最终生成的产物本身，以及外部环境给出的执行证据（测试输出、Linter 报告、渲染截图）。
2. 审查必须消费可执行的客观证据
在 Coding 场景中，让 Reviewer 去“肉眼看代码”依然是低效的。
正确的链路是：Proposer 生成代码 -> Harness 自动运行测试套件 -> 失败的堆栈与报错作为执行证据传给 Reviewer -> Reviewer 根据客观报错向 Proposer 下发修改意见。
3. 驳回时必须提供结构化、可定位的修复条件
Reviewer 不能只抛出一句空洞的“逻辑不严谨”，而必须输出机器可解析的结构化结论（如问题类型、出错行号、期望的边界输出），并且整个重试循环必须设置严格的预算上限（Budget），防止无限空转。
附带收益：彻底斩断长会话的上下文爆炸
将审查独立拆分，在工程上还有一个极其巨大的隐蔽收益：保护主链路的上下文纯净度。
以生成复杂的 PPT 或前端界面为例：
如果使用单 Agent 模式，每一轮修改后都需要把 1080p 的高清渲染截图塞进上下文供模型复查。两三轮下来，海量的图像 Token 就会直接撑爆上下文窗口，带来昂贵的计费和严重的注意力衰减。
而在 Proposer-Reviewer 架构中：
Reviewer 独立加载截图并在视觉模型中完成评估，产出一份仅有几十个 Token 的轻量结构化文本（如“第 3 页内容过密、第 7 页按钮遮挡”）。Proposer 只需消费这份极简的文本反馈进行定向修补。
海量的多模态中间证据被物理隔离在 Reviewer 的临时生命周期内，主任务链路的上下文始终保持极高的信噪比。
多 Agent 协作的底线，是让代码在真正的编译器、测试集与浏览器截图里接受核验。
别再花双倍 Token 让模型在封闭的文本框里分饰两角辩论。把审查链路建立在客观执行证据上。
没有外部真实反馈注入的自我审查，本质上只是对上一次幻觉的重复确认。