TL;DR

本文核心观点：

  1. false-consensus 是多 agent 评审的主要失败模式 — 无证据约束的多数投票，本质是共识压缩而非智能汇聚，agent 互相平滑掉异议
  2. Adversarial Review 只用 3 个角色（coder/reviewer/critic） — critic 对 review 做结构化异议审计后再让 coder 改，不是让 agent 吵架，而是让 disagreement 有结构、绑定证据
  3. 关键设计：disagreement 最小化、有结构、绑定证据 — 一句显式 disagreement 指令即拉回 F1，说明这个失败模式被修复的门槛极低
  4. 可直接抄进 PR review bot 和 agent 自检环 — 协议级方案，不依赖特定模型，3 个 prompt 即可实验

多 agent 评审的一个被忽视的失败模式

多 agent 评审（multi-agent review）背后的逻辑很直观：多个视角比单个视角好，不同 agent 看到不同问题，大家讨论之后取最优。

但这条路有一个隐蔽的失败模式，在 Adversarial Review（arXiv:2608.18167）之前，没有人在基准测试里明确把它分离出来：

false-consensus：没有证据约束的多数投票，实际上是在拟合彼此的噪声，而不是汇聚真实的判断。

具体来说：当三个 agent 对同一个代码片段做评审，它们各自产生了初始判断。如果没有任何机制强制它们绑定证据，最终结果会向「最容易被语言化的观点」收敛——不是因为这个观点最正确，而是因为它最容易在文本层面达成一致。

这在人类评审里也会发生，叫「groupthink」。在 agent 评审里更严重，因为 agent 没有 ego，不会坚持己见。

Adversarial Review 的核心设计

Adversarial Review 的设计目标是：让 disagreement 最小化、有结构、绑定证据。

它只用了 3 个角色：

Coder

写代码的一方。接收 reviewer 和 critic 的反馈，进行修改。

Reviewer

对代码做标准评审。发现 bug、提出改进建议、与 coder 交互。

Critic（核心创新）

Critic 不评审代码，而是评审 review 本身。

Critic 的职责：对 reviewer 的每一条评审意见，提出以下问题：

  • 这个评审意见绑定了什么证据？
  • 证据是否足以支持这个结论？
  • 如果没有证据，这个评审意见是否只是在复述 coder 的实现，而非真正的问题发现？

Critic 产生的是结构化异议——不是「我觉得这个不对」，而是「reviewer 的第 N 条意见依赖的证据是 X，但 X 不能推出结论 Y」。

为什么这个结构有效

关键在于 disagreement 的质量而非数量。

传统多 agent 评审想的是：多几个 agent 能覆盖更多问题角度。但这假设了每个 agent 的判断是独立的。现实中 agent 共享训练数据、共享预训练知识，某些 bug 模式是大家同时容易忽略的。

Adversarial Review 换了一个角度：与其增加 agent 数量（边际收益递减），不如让已有的评审绑定证据。

Evidence-based review 的核心好处：

  • 防止共识漂移：没有证据的结论不会被平滑掉
  • 强制推理外显化：reviewer 必须说出「因为什么，所以什么」，不能只说「这里有问题」
  • 让真正的异议浮现：有证据支撑的 disagreement 才有价值，没有证据的共识只是噪音

实验结果：关键发现

Adversarial Review 在两个基准上验证：

LiveCodeBench：超 5-agent 基线。说明少体多轮胜过多体单轮。

SWE-PRBench：揭示了 false-consensus 失败模式的具体表现——在无证据约束的评审中，agent 的判断趋同率很高，但 F1 分数反而下降（因为趋同的是噪声，不是信号）。

更有意思的是：只需加一句显式的 disagreement 指令，即可拉回 F1。

这说明 false-consensus 这个失败模式被修复的门槛极低——不需要改模型架构，不需要改训练方式，只需要在 prompt 里说清楚「你需要绑定证据」。

可直接抄的协议级方案

Adversarial Review 最大的价值不是提出了新架构，而是证明了现有的 agent 评审协议有系统性的设计缺陷，且修复门槛极低。

对于想改善 PR review bot 或 agent 自检环的团队，Adversarial Review 提供的是：

协议层规范：

  1. 角色分离：coder / reviewer / critic，三者职责不同
  2. 审查对象：reviewer 的评审，而非代码本身
  3. 审查标准：每条评审意见必须绑定证据，证据必须能推出结论
  4. 争议解决：没有证据的评审意见，在没有新证据之前不能作为修改依据

这套协议不依赖特定模型、不需要额外训练、不需要改变现有代码生成流程。3 个 prompt 即可实验。

与其他方案的对比

维度 多 agent 堆人头 Risa（路由仲裁） Adversarial Review
核心思路 更多 agent 更多视角 模型内部信号仲裁 结构化异议 + 证据绑定
失败模式 false-consensus 依赖 MoE 路由器质量 critic prompt 质量
落地门槛 低 中（需要 MoE 模型） 极低（3 个 prompt）
修复成本 加更多 agent（边际递减） 改模型架构 改协议 prompt

三条路并不互斥。Risa 解决的是「轨迹间的 patch 选哪个」，Adversarial Review 解决的是「评审过程如何不丢失异议」。未来可能出现结合两者的方案。

写在最后

多 agent 协作领域有一个隐含的假设：agent 越多，视角越丰富，结论越可靠。

Adversarial Review 用实验数据反驳了这个假设——在没有结构约束的情况下，agent 越多，共识压缩越严重，F1 反而下降。

真正重要的不是「有多少个 agent」，而是「agent 之间的交互有没有结构」。

这个洞察不限于 code review。任何多 agent 协作系统——包括策略生成、架构评审、安全审计——都面临同样的风险：看起来热闹，实际上是在互相拟合噪声。

Adversarial Review 提供的解决思路：强制证据绑定，让异议变成有质量的东西，而不是数量的堆砌。

论文链接：https://arxiv.org/abs/2608.18167

AI-Native Engineering 系列 深度阅读时间：约 10 分钟