为什么大型多智能体团队会陷入困境
当LLM智能体开始在开发中大规模使用时，许多团队走上了一条看似合理但并非总是有效的道路：招募尽可能多的算法“专家”并给他们分配角色。一个写代码，一个找漏洞，一个检查场景。问题在于，每增加一个智能体带来的收益越来越少：在仓库级别的任务上，协调成本很快超过了“额外帮手”带来的收益。
对此的反应是走向另一个极端：智能体被变成了子智能体——听话的工具，按需调用，不参与对话。这种方法消除了混乱，但也同时摧毁了集体工作的核心资源：再也没有人质疑他人的决定，错误也因此悄悄溜过而无人察觉。
平衡点：最小化协作
Eric S. Qiu 和 Joyce Gill 在论文 「Adversarial Review: Structured Disagreement for Grounded Agentic Code Review」（arXiv:2608.18167，类别 cs.AI 和 cs.SE；提交于2026年8月16日，被 ICML 2026 Workshop on DL4C 接收）中致力于寻找黄金平衡点。他们的假设很简单：可以保留子智能体架构的简洁性，但加入最小化的协作——一个节点，让智能体的意见在此有意碰撞。
由此产生了 Adversarial Review（AR）协议。作者有意不构建复杂的层级结构，也不制造大量角色。取而代之的是三个参与者：
- 编码智能体 准备代码变更；
- 审查者 评估这些变更的正确性；
- 批评者 审计的不是代码，而是审查本身，找出其中的薄弱环节。
批评者不只是说“我不同意”——他提出结构化的分歧：指出代码中那些无法支持审查者结论的具体片段。只有当这个循环完成后，主智能体才被允许进行修改。
测试结果显示了什么
分歧的效果在基准测试结果中清晰可见。
在 LiveCodeBench 上，AR 在所有测试方法中展现了最高的成功通过率。一个重要细节：这只需要三个智能体，而 AR 超越的基线版本使用了五个。
在 SWE-PRBench 上，情况更有趣。协议的朴素版本意外暴露了一种失败模式，作者称之为虚假共识：智能体在没有足够证据的情况下就达成了共同意见。也就是说，即使是特意构建的分歧也可能退化为形式上的“同意所有人”。解决办法只需一次提示迭代，在其中明确写出要求争论并论证分歧的指令——经过这样的改进后，该方法在 F1 指标上取得了第一名。
最后，在 SWE-bench Verified 上，AR 再次提升了基线方法的结果。这很重要，因为仓库级别的任务与孤立的函数是完全不同的复杂度规模：一个模块的改动可能破坏数十个相邻模块。
结论：力量不来自票数，而来自反对的权利
作者得出了一个反直觉但经实验验证的结论：有效的代码审查既不需要庞大的团队，也不需要复杂的沟通方案。只需让分歧具备以下特点：
- 最小化——一个冲突点，而不是无休止的聊天；
- 结构化——每个参与者都有自己明确的功能；
- 有据可依——反对意见基于代码中的事实，而非个人偏好。
对所有构建智能体流水线的人来说，实践教训是：不要试图通过增加角色来解决问题。更好的做法是在流程中嵌入一个强制性的质疑阶段——让一个智能体可以正式质疑另一个智能体的结论。审查的价值不取决于票数的多少，而在于是否有人能够就实质性问题提出反对意见。
