对抗性评审（Adversarial Review）：基于结构化分歧的实证智能代理代码评审

# 对抗性审查：面向具身化智能体代码审查的结构化分歧
来源：https://arxiv.org/html/2608.18167

###### 摘要
早期多智能体大型语言模型系统常采用角色分离的团队模式，但在仓库级编程任务中，随着智能体数量增加，其收益呈递减趋势。近期替代方案将智能体视为被动工具（子智能体），但这完全消除了智能体交互的优势。我们研究子智能体范式是否能支持一种折中方案：在避免大型多智能体团队开销的前提下实现最小化的智能体协作。我们提出对抗性审查（AR），这是一种最小化的协作代码审查协议，其中主编码智能体与审查者和批评者智能体协同工作。审查者评估代码，而批评者通过结构化分歧对审查进行审计，之后主智能体才进行编辑。在LiveCodeBench基准测试中，AR在测试方法中达到了最高通过率，仅使用三个智能体就超越了五个智能体的基线方案。在SWE-PRBench上，朴素的AR暴露出虚假共识失效模式——智能体在缺乏充分证据时就趋向一致，但通过一次添加明确分歧的提示迭代，在测试方法中实现了最高的F1分数。在SWE-bench Verified上，AR在仓库级编码任务中同样展现出优于基线的表现。综上所述，AR表明协作代码审查无需大量智能体或复杂通信结构：关键在于分歧必须是最小化的、结构化的，并且基于证据。

###### 关键词
大型语言模型代码审查，智能体编码，多智能体，结构化分歧，以人为中心的智能体

††附属说明：同等贡献  
参见图例：图1：对抗性审查（AR）工作流。主智能体首先生成制品版本N（代码或方案）。协议随后进入内部循环，此时制品被冻结：审查者R生成Review_k，批评者C评估并可能修改该审查，R回应直至达成一致审查意见。若审查首次即达成一致且未识别出缺陷，则制品立即被接受。否则，主智能体编辑制品以生成版本N+1，更新变更日志，流程重复进行。关键分离在于：内部循环仅交换审查文本，而制品编辑仅发生在外层循环中。

## 1 引言
基于大型语言模型的编码智能体正日益用于解决实际软件工程任务，从处理GitHub问题到审查拉取请求（Jimenez et al. 2024）。随着这些智能体能力增强，一个关键设计问题浮现：多个智能体应如何组织以可靠地协同完成编码任务？该问题在自动化代码审查中尤为重要，因为智能体不仅需生成正确修复，还需提出恰当关切。早期多智能体系统通过在角色分离的团队中增加更多智能体来提升质量，模仿人类分工，将智能体分配用于生成、审查、辩论或聚合输出（Islam et al. 2024; Huang et al. 2023; Pan et al. 2025; Islam et al. 2025）。然而近期研究表明，在复杂仓库级编程任务中扩展对等智能体数量可能导致收益递减甚至负面效果，部分原因在于无约束通信引入协调开销及新的失效模式（Smit et al. 2023; Kim et al. 2025）。相比之下，许多生产级编码智能体已趋同于“主智能体与子智能体”范式，其中子智能体通过工具调用被唤起，而非作为独立协作者（Anthropic 2024）。我们探究这两种范式之间是否存在高效折中：主智能体与子智能体系统能否支持轻量级协作，同时避免大型角色分离团队的开销？我们的目标是设计一个最小化协议，在保留智能体交互优势的同时，通过约束通信使其在实际编码任务中保持实用。

我们提出*对抗性审查（AR）*，这是一种基于朴素零样本代码生成逐步构建的协作编码协议。每一步都通过上一步骤的可量化失败来驱动设计选择。我们首先在LiveCodeBench（LCB）（Jain et al. 2024）上评估此构建过程，随后从两个方向探究所得协议：在SWE-PRBench（Kumar 2026）上的审查质量，以及在SWE-bench Verified（Jimenez et al. 2024）上的仓库级修复能力。我们采用两种执行模式：在LCB和SWE-PRBench上，使用Python编排器实施严格的跨方法对照比较；在SWE-bench Verified上，我们将每种方法表达为可移植的纯文本SKILL.md协议，供Claude Code等自主智能体执行。

我们做出三项贡献：第一，我们表明最小化的审查者-批评者循环可在主智能体与子智能体范式内改进智能体编码与程序修复；第二，我们识别出协作智能体系统的核心失效模式——智能体可能为追求一致性而非正确性进行优化；第三，我们展示结构化分歧能可靠修复虚假共识，在三个基准测试中同时提升代码生成与审查质量。

## 2 相关工作
##### 代码的自我改进与外部验证
测试时改进方法通过添加批评、反馈或修订来优化初始模型输出。Self-Refine使用同一模型作为生成器、反馈提供者和改进者，将修订保持在单个模型的判断循环内（Madaan et al. 2023）。然而后续研究表明，语言模型在没有外部反馈的情况下无法可靠地自我纠正推理错误（Huang et al. 2024）。AR建立于测试时改进但进行两项改动：分离审查者与批评者角色，并使分歧成为协议的显式组成部分而非可选自检。

##### 多智能体辩论与结构化分歧
多智能体辩论通过允许智能体交换论据后再由裁判或最终答案选择来提升推理、事实性或决策质量（Du et al. 2024; Liang et al. 2024）。然而辩论式系统可能对提示和协议选择敏感，且可能无法超越成本更低的非辩论基线（Smit et al. 2023）。多智能体审查系统（MARS）通过用独立审查者替代圆桌辩论，并由元审查者聚合评论来减少开销（Wang et al. 2025）。AR采取中间立场：保留交互但将通信限制为具有明确分歧类型的单一通道。目标并非开放式辩论，而是在主智能体编辑或提交前进行基于证据的质疑。

##### 用于代码生成与审查的多智能体系统
多个编码系统使用角色分离智能体将编程分解为专门子任务。MapCoder将竞赛编程任务分解为示例回忆、规划、代码生成和调试（Islam et al. 2024）。AgentCoder分离实现、测试设计和测试执行（Huang et al. 2023）。CodeSim使用仿真驱动的规划和调试指导代码生成（Islam et al. 2025）。CodeCoR采用自反思多智能体框架对生成的代码进行修剪、改进和修复（Pan et al. 2025）。在代码审查方面，CodeAgent研究用于自动审查的通信智能体，并添加QA检查器确保生成的审查贡献与原始问题保持一致（Zhang et al. 2024）。AR有意比这些系统更精简：它不添加多个专门编码角色，而是探究最小化的审查者-批评者对能否在主智能体与子智能体工作流中提供可靠、基于证据的审查。

##### 智能体编码系统与可移植协议
生产级智能体系统日益依赖调用工具、子智能体或可复用指令包的主智能体（Anthropic 2024）。在此设定中，子智能体是为聚焦子任务生成的独立智能体实例，而技能是通过SKILL.md文件激活的可移植指令包（Anthropic 2026; Anthropic 2025）。这促使我们以两种形式评估AR：用于严格对照比较的Python编排器，以及测试同一协作审查协议能否在无外部强制情况下由自主编码智能体遵循的纯文本技能形式。

##### 编码工作流中的人机协作
日益增多的研究探索编码智能体应如何沟通进展、处理歧义并整合用户反馈（Li et al. 2022; Kumar 2026）。代码审查是人机协作的自然接口：审查智能体不仅要发现缺陷，还需产出开发者能行动、接受或重新定向的发现。AR通过显式化子智能体间的分歧为此议程做出贡献，使到达任何监控工作流开发者的审查信号基于具体代码证据而非未加检验的推测。

##### 编码与审查基准测试
LiveCodeBench使用随时间更新的抗污染基准评估代码生成（Jain et al. 2024）。SWE-PRBench根据拉取请求反馈评估AI代码审查质量（Kumar 2026）。SWE-bench评估智能体能否通过编辑仓库并通过测试来解决真实GitHub问题（Jimenez et al. 2024）。这些基准测试分离了常被混淆的三个主张：方法是否解决独立编程问题，是否有助于仓库级修复，以及是否产生有用的审查评论。我们利用这种分离将AR评估为编码协议与协作监督协议。

## 3 在LiveCodeBench上构建AR
本节逐步构建对抗性审查协议。每个子节添加一个设计选择。每项结果在LCB上报告两个指标：全部105项stdin式任务的通过率（pass/105），以及57项困难标签子集的通过率（pass-on-hard/57）。完整结果见表1。困难层级是方法表现分化的关键。后续所有智能体与子智能体调用均使用Claude Sonnet 4.5 Medium Reasoning模型。

### 3.1 零样本→自精炼：添加验证
零样本生成无验证步骤。因此我们添加一个验证。自精炼（Madaan et al. 2023）让同一智能体自我批评其代码然后修订。在LCB上改进几乎不可察觉：零样本通过率为77%，自精炼通过率同为77%。原因是批评者和生成者是同一模型，犯同样错误，因此批评者难以捕获生成者遗漏的问题（Olausson et al. 2024）。这促使我们为批评者使用独立模型调用。

### 3.2 自精炼→单审查者：外部验证
单审查者采用独立模型调用。具体地，主智能体M编写代码，审查者R审查M的代码，M编辑一次。在LCB上通过率为77%，困难任务通过数为36/57。性能与零样本处于同一集群。问题可能在于单个外部审查者具有高方差：可能不加检查就批准一切，或关注许多细小问题而未针对真正缺陷。这促使我们运行多个独立审查者。

### 3.3 单审查者→双审查者：独立性降低方差
两个独立样本应降低方差。具体地，R1和R2独立审查M的代码，然后M基于两者并集编辑一次。在LCB上通过率为75%，困难任务通过数为34/57。这仍在单审查者、自精炼和零样本的噪声范围内。四种方法在同一水平聚集，朴素验证无法突破该水平。这促使我们追求智能体多样性而非更多独立样本。

### 3.4 双审查者→MARS：多样性但有极限
多智能体辩论（MAD）是多智能体系统中增加多样性的标准方式（Du et al. 2024）。然而MAD的两项成本随智能体和轮次增加而增长：一是通信开销，因为每个智能体必须读取其他所有智能体的消息；二是随着系统扩展，通过率可能下降（Smit et al. 2023; Kim et al. 2025）。MARS（Wang et al. 2025）通过移除审查者间的消息传递来降低MAD式通信成本。具体地，作者智能体生成初始方案。三个并行审查者各自输出包含二元决策（接受/拒绝）、自报置信分数、理由及（拒绝时）明确错误识别的结构化输出。单独的元审查者子智能体阅读三份审查和候选方案，发布包含最终决策、理由、拒绝时修改建议和推荐答案的综合输出。若元审查者拒绝，作者根据建议修改方案，并在修改后方案上进行新一轮审查。循环在元审查者接受或达到固定上限K=2轮时终止。在LCB上，MARS是首个通过率明显高于零样本、自精炼、单审查者和双审查者的方法：在pass/105上比四方法集群提升+5个百分点（达85%），在困难任务上比单审查者多解决+3项（43/57）。但MARS存在两个问题：一是增益相对于每任务使用五个智能体（一个作者、三个审查者、一个元审查者）的token成本较小；二是虽然MARS避免了MAD的通信开销，但完全移除了所有智能体交互。这引发一个自然问题：能否通过智能体交互提升编码性能，同时避免MAD的开销且使用更少智能体？

### 3.5 MARS→AR：双智能体交互
一个仍能实现有意义协作的紧凑交互结构可能是单个审查者加单个批评者……