多Agent代码评审经常是在瞎猜，两个无标签指标让它学会放弃

我们在用一个大模型去评判另一个大模型写的代码对不对时，通常得到的只是一个带着推理过程的自信结论。这种结论和它真正有据可依时发出的判断没有任何区别，因为它根本不会报告“我没证据”。多Agent验证（Multi-agent verification）看起来是个好办法，它把判断拆解成一个个可以检查的主张，然后逐一核对证据。这在检索文档的场景下很有效，但放到代码评审里，逻辑就断了。

这篇刚上线 arXiv 的论文（2609.30328v1）指出了核心问题：多Agent评审的证据必须满足两个条件。第一，证据得独立于正在审查的答案；第二，证据在两个候选方案之间必须有差异。对于检索来的文档，第二个条件是自动成立的，但在代码评审里，这两个候选代码往往共享大量相似上下文，导致证据没有区分度。

作者直接用现有的 MARCH 框架做了测试，没改任何代码，跑了两个代码评审基准上的 80 个逐单元测量。结果挺打击人。在对比两个解法时，MARCH 在 78% 到 95% 的情况下都宣称两者一样好。在这种强制二选一的设定下，它的准确率只有 4.4%。作为参照，直接问同一个大模型哪个更好，准确率能达到 43.7%。也就是说，搞了一套复杂的多Agent流程，效果反而比直接问还要差得多，而且增加题目难度或者换更大的裁判模型都没用。

最有用的是他们提出了两个不需要标签（Label-Free）的测量指标，直接从流水线日志里就能算出来。如果你利用其中一个指标给评审过程做个闸门（Gating），让系统对那些拿不准的比较直接说“我不猜”，准确率能从 20.7% 提升到 36.9%。虽然这也只覆盖了所有比较的一半，但这比胡乱给出一个虚假的自信结论要有价值得多。这篇工作的贡献不在于造出了一个更准的裁判，而是提供了一种方法，让裁判知道自己什么时候在瞎蒙。

代码评审里的证据陷阱

多Agent评审的核心假设是分解和验证。比如判断代码 A 是否正确，Agent 会提出“变量 x 在第 5 行被定义”这样的主张，然后去证据里找。如果证据是检索回来的文档片段，只要文档和答案独立，且不同答案对应的文档不同，这招就灵。

但在代码评审里，我们要比较代码 A 和代码 B。这两个代码很可能解决的是同一个问题，结构相似，甚至包含相同的库导入或注释。如果证据是从代码本身提取的，那 A 和 B 的证据重叠度极高。这时候，无论 Agent 怎么“验证”，它都在看同样的东西，自然得不出区分性的结论。论文指出，这就是为什么 MARCH 框架在大多数情况下会宣布平局——因为证据里找不到差异。

用日志信号代替人工标签

我们通常评估评测器准不准，得先有一堆人工标注好的正确答案。但这太贵了，尤其是对于开放性的代码任务。这篇论文提出的两个测量指标完全基于内部信号，不需要任何外部标签。

第一个测量关注的是证据的差异性。既然平局是因为证据没区别，那我们可以量化两个候选代码提取出的特征向量之间的距离。如果距离太小，说明证据没法定性区分两者。第二个测量关注的是独立性，确保用于验证主张的证据没有受到被评审代码本身的污染。

作者发现，只要把那些证据差异性低的比较过滤掉，剩下的比较虽然数量减半，但准确率明显提升。从 20.7% 到 36.9% 的提升看似不多，但在没有额外训练数据的情况下，这是一个干净的信号筛选结果。这意味着我们不需要追求一个全能且永远正确的裁判，我们需要的是一个知道何时沉默的裁判。

实际落地的建议

如果你也在搭建代码评审流水线，不要盲目堆砌 Agent 数量。这篇论文提示了几个实操方向。

• 先算差异度：在做最终裁决前，计算两个候选代码在嵌入空间或静态特征上的距离。如果距离低于某个阈值，直接标记为“难分”，而不是强行输出一个胜负。
• 接受部分覆盖：不要强求对所有样本都给出排序。如果能准确回答一半样本，剩下的让给人工或更贵的模型，整体效率可能更高。
• 检查证据独立性：确保你的验证 Agent 使用的上下文没有混入待测代码的逻辑细节。可以用简单的代码抽象语法树（AST）差异作为初步证据，而不是全文比对。

这种“拒绝猜测”的策略在其他领域也很常见，但在代码评审里，我们往往为了自动化而强迫模型给出一个确定性的输出。结果显示，这种强迫带来的噪声远大于信号。与其让模型编造理由来支持一个随机的选择，不如让它承认“我看不出来”。