---
title: "让 Agent 自己审查代码，为什么经常越审越烂？ | 行开心的颠倒世界"
description: "在封闭上下文中让 Agent 自审代码，把正确答案改错的概率远高于纠错率。多 Agent 协作生效的判据在于引入外部新信息。拆解 Proposer-Reviewer 架构、“模型无权批准完成”铁律，以及如何用上下文隔离防止 Token 爆炸。"
canonical: "https://xingkaixin.me/posts/agent-proposer-reviewer/"
language: "zh-CN"
---

# 让 Agent 自己审查代码，为什么经常越审越烂？

在封闭上下文中让 Agent 自审代码，把正确答案改错的概率远高于纠错率。多 Agent 协作生效的判据在于引入外部新信息。拆解 Proposer-Reviewer 架构、“模型无权批准完成”铁律，以及如何用上下文隔离防止 Token 爆炸。

2026年9月11日·1,794 字·5 分钟

[AI Agent](https://xingkaixin.me/tags/AI%20Agent/)[代码审查](https://xingkaixin.me/tags/%E4%BB%A3%E7%A0%81%E5%AE%A1%E6%9F%A5/)[多智能体](https://xingkaixin.me/tags/%E5%A4%9A%E6%99%BA%E8%83%BD%E4%BD%93/)[工程实践](https://xingkaixin.me/tags/%E5%B7%A5%E7%A8%8B%E5%AE%9E%E8%B7%B5/)

![Agent 自审通过后仍被外部证据发现两个新报错](https://xingkaixin.me/cover/agent-proposer-reviewer.webp)

上个月我给内部重构 Agent 补了一道“保险”。

为了防止它漏改边界，我在提示词末尾加了一行：“请仔细审查刚刚生成的代码，检查潜在逻辑漏洞；如果有，请直接修正。”

逻辑看起来很顺理成章：写完代码复查一遍，是人类工程师的基本习惯。

但跑到第六个处理并发 Map 的文件时，离奇的一幕出现了：原本跑通的单测，被它这道“自我审查”硬生生改出了两个新的类型报错，甚至顺手把正确的读写锁替换成了一个早已废弃的全局 Mutex。

这种自我审查极少能抓住深层 Bug。相反，它经常把原本写对的代码改得面目全非，或者把一个能跑通的逻辑改出全新的语法错误。

这并不是提示词写得不够严厉。

ICLR 2024 的一项研究在测试 GPT-4 时发现：在没有任何外部环境反馈的情况下，让大语言模型自我审查并修正代码，**它把正确答案改错的概率，远远高于把错误答案改对的概率。**

审查如果不引入新信息，本质上只是强迫模型就着上一轮的幻觉再猜一遍。

## 审查生效的唯一物理判据

多 Agent 协作或审查机制在什么情况下才能真正起效？

判断标准其实只有一条：**审查过程是否引入了单个 Agent 在生成时无法获得的外部新信息？**

| 审查模式 | 是否引入新信息 | 实际效果 |
| --- | --- | --- |
| 同一模型自我审查（重读自己的输出） | 否 | **通常无效甚至有害**（把对改错） |
| 两个 Agent 共享上下文互相辩论 | 否 | 消耗双倍 Token，能力几乎零提升 |
| 审查者读取**单元测试与编译器报错** | 是（执行反馈） | **显著提升** |
| 审查者读取**界面渲染截图** | 是（视觉反馈） | **显著提升** |
| 审查者调用**外部工具核验事实** | 是（工具反馈） | **显著提升** |

注意第二行：**单纯把一个模型拆成两个角色互相辩论，根本无法突破单模型的推理上限。**

学术界经常有研究指出“多 Agent 辩论用处不大”，而工业界的一线工程却普遍推崇多 Agent 架构。两者的结论之所以看似矛盾，根源就在于评测对象的不同：

学术界测试的大多是封闭上下文内的文字互评，信息熵并没有增加；而工业界真正跑通的多 Agent，无一例外都在审查环节挂载了外部环境通道——运行真实的测试用例、执行静态类型检查、抓取渲染后的 DOM 截图。

这些来自外部世界的客观反馈，在模型最初生成代码时并不存在。有了这层新信息的注入，审查才具备了物理上的纠偏能力。

![封闭互评没有新信息，测试、编译器和截图提供外部证据](https://xingkaixin.me/posts/images/agent-proposer-reviewer/agent-proposer-reviewer-01.webp)

## 模型可以提议完成，但无权批准自己的完成

在没有外部硬反馈的情况下让 Agent 自查，最容易诱发三类经典的系统失效形态：

1.  **偷懒式假完成**：代码刚写完，单测没跑、构建没试，模型便自信满满地在末尾输出“任务已圆满完成”；
2.  **过早放弃**：在解决复杂依赖时调了一个工具失败，就直接判定“该方案不可行”并退回给人类；
3.  **假成功**：环境返回了 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），防止无限空转。

![产出、测试、审核与修复通过隔离边界完成交接](https://xingkaixin.me/posts/images/agent-proposer-reviewer/agent-proposer-reviewer-02.webp)

## 附带收益：彻底斩断长会话的上下文爆炸

将审查独立拆分，在工程上还有一个极其巨大的隐蔽收益：**保护主链路的上下文纯净度。**

以生成复杂的 PPT 或前端界面为例：

如果使用单 Agent 模式，每一轮修改后都需要把 1080p 的高清渲染截图塞进上下文供模型复查。两三轮下来，海量的图像 Token 就会直接撑爆上下文窗口，带来昂贵的计费和严重的注意力衰减。

而在 Proposer-Reviewer 架构中：

Reviewer 独立加载截图并在视觉模型中完成评估，产出一份仅有几十个 Token 的轻量结构化文本（如“第 3 页内容过密、第 7 页按钮遮挡”）。Proposer 只需消费这份极简的文本反馈进行定向修补。

海量的多模态中间证据被物理隔离在 Reviewer 的临时生命周期内，主任务链路的上下文始终保持极高的信噪比。

* * *

多 Agent 协作的底线，是让代码在真正的编译器、测试集与浏览器截图里接受核验。

别再花双倍 Token 让模型在封闭的文本框里分饰两角辩论。**把审查链路建立在客观执行证据上。**

没有外部真实反馈注入的自我审查，本质上只是对上一次幻觉的重复确认。

## 版权声明

作者

XingKaiXin

标题

让 Agent 自己审查代码，为什么经常越审越烂？

发布时间

2026年9月11日

文章链接

[https://xingkaixin.me/posts/agent-proposer-reviewer/](https://xingkaixin.me/posts/agent-proposer-reviewer/)

本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。

导览

展开导览