多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 框架 在大多数情况下宣称“平局”的原因：证据间没有可测量的差异。

具体来说，当两个候选代码的 嵌入空间距离 或 静态特征 接近时，Agent 无法判断哪个更优，因为它们“看”的实际上是同一套上下文。这种情况下，强制输出胜负只会引入噪声，而非提升准确性。

如何利用内部信号替代人工标签

传统评测器准确性评估需依赖人工标注的正确答案，但代码任务的开放性使得这种方法成本过高。论文提出的两个指标完全依赖内部信号，无需外部标签：

1. 差异性指标：量化两个候选代码在特征空间中的距离。如果距离低于阈值，说明证据无法区分两者，评审结果可信度极低。
2. 独立性指标：确保验证用的证据（如代码片段或 AST 节点）不包含被评代码的逻辑细节。例如，如果证据直接来自候选代码的某一行，那么它显然无法作为“独立”证据。

通过过滤掉差异性低的比较样本，准确率从 20.7% 提升至 36.9%——尽管覆盖率减半，但这一策略避免了模型在缺乏证据时胡乱猜测。这意味着，代码评审系统不应追求“全能裁判”，而是应学会在无法确定时“放弃”。

实际应用中的三点建议

如果你正在构建代码评审流水线，以下策略可参考：

1. 预先计算差异度：在输出最终裁决前，计算两个候选代码在 嵌入空间 或 静态特征（如 AST 差异）上的距离。如果距离低于设定阈值，直接标记为“难分”，而非强行选择。
2. 接受部分覆盖：不必对所有样本强制输出排序。能准确回答一半样本即可，其余交由人工或更昂贵的模型处理，整体效率可能更高。
3. 确保证据独立：验证 Agent 的上下文应避免包含待测代码的逻辑细节。例如，可以使用 AST 差异 作为初步证据，而不是直接比对代码全文。

这种“拒绝猜测”的策略在其他领域已广泛应用，但在代码评审中，我们常因追求自动化而强制模型输出确定性结论。结果却是，这种强制带来的噪声远大于信号。与其让模型编造理由支持随机选择，不如让它明确表示“我看不出区别”。