技术摘要：CHAINSWE —— 在多缺陷软件维护任务上对编码智能体进行基准测试

问题陈述

当前的大型语言模型（LM）智能体正越来越多地被部署于软件工程（SWE）任务中，包括代码修复和仓库维护。然而，现有的基准测试（如 SWE-bench、SWE-bench Live、SWE-rebench）都在评估这些智能体处理孤立的、单项问题任务的能力。在这些协议中，仓库在每次评估时都会重置为干净的基础提交（base commit），智能体在一个全新的容器中解决一个自包含的缺陷。

这种评估模式无法捕捉到持续软件维护的现实情况，即工程师会在刚刚修改过的代码库上连续修复一系列相关的缺陷。论文指出，当缺陷被顺序评估且仓库状态在会话间发生传递时，会出现两种关键的失效模式：

1. 过度修复（Overshoot）： 智能体在修复早期缺陷时，修改了超出预期范围的文件。当后续缺陷针对这些相同文件时，智能体的修改会被应用到一个“受污染”的基准之上，导致正确的变更失败。
2. 修复不足（Undershoot）： 智能体未能应用前一个缺陷所要求的必要的多文件重构（仅交付了 issue 标题中提到的子集）。下游测试失败并非因为当前缺陷处理不当，而是因为前序重构建立的先决条件缺失。

核心问题在于，当前的基准测试忽略了累积依赖和状态漂移，从而高估了智能体在现实世界长程维护场景中的能力。

方法论

为了填补这一空白，作者引入了 CHAINSWE，这是首个旨在评估智能体在共享代码库中进行顺序、依赖性缺陷修复任务的基准测试。

数据构建流水线

该数据集通过挖掘并验证来自六个现有 SWE-bench 系列数据集（SWE-bench、SWE-bench Live、SWE-rebench、SWE-rebench-v2、SWE-Gym 和 SWE-bench Pro）的链条来构建。

1. 挖掘： 按提交日期对实例进行时间排序。如果满足以下条件，则使用滑动窗口将连续的实例分组为链条：
   • 后者的基础提交是前者的直接继任者，或者
   • 后者的金标准（gold）/测试补丁可以干净地应用在前者的已解决状态之上。
2. 过滤：
   • 代码重叠启发式算法： 丢弃那些修改的文件、函数或类完全不重叠的窗口。
   • 测试重执行： 使用容器化过滤器按顺序应用金标准补丁，以验证所有 FAIL_TO_PASS 测试均通过，且没有 PASS_TO_PASS 测试出现回归。
   • 难度选择： 丢弃那些单个缺陷本身过于困难（即使在“Oracle”模式下也导致超过 50% 的缺陷无法解决）的链条，以确保基准测试测试的是状态管理而非纯粹的缺陷解决能力。
3. 最终数据集： 最终数据集包含 100 个缺陷链，跨越 54 个 Python 仓库，共计 304 个实例，平均链条长度为 3.04。

评估协议

作者使用固定的智能体脚手架（SWE-EDIT），在三种上下文管理配置下评估了七种最先进的语言模型（包括 GPT-5.5、Claude-Opus-4.7 和 DeepSeek-V4-Pro）：

• BASELINE（基准）： 保留完整的交互历史。
• SUMMARIZE（总结）： 当上下文超过 50k token 时，用结构化摘要替换旧的历史记录。
• SUB-AGENT（子智能体）： 将文件查看/编辑任务交给专门的子智能体，以保持主上下文窗口的整洁。

评估分为三种模式，以隔离特定的失效维度：

• ORACLE（先知模式）： 容器重置为基础提交，并在智能体开始前应用之前所有缺陷的金标准补丁。这衡量的是不考虑状态漂移时的单项缺陷处理能力。
• SEQ (Sequential，顺序模式)： 智能体在单个容器中按顺序处理缺陷 1 到 $n$，且不进行重置。仓库保留智能体自身生成的补丁。智能体控制台会重启，但代码库状态持续存在。
• SEQ+MEM（顺序+记忆模式）： 与 SEQ 相同，但智能体的对话历史也会在不同缺陷之间得以保留。

关键结果

评估显示，从孤立评估转向顺序评估时，性能出现了持续且严重的下降：

1. 性能跌幅： 在所有模型和配置中，从 ORACLE 转向 SEQ 时，单项缺陷准确率下降了约 38%（从 ~59% 降至 ~36.5%）。在链条的最深处，性能下降幅度高达 70%。
2. 链条错误： 在顺序模式下的失败案例（位置 2 和 3）中，48% 是“链条错误”——即由智能体自身累积的状态而非当前缺陷的内在难度所导致的失败。
   • 过度修复（破坏了正常工作的代码）占这些错误的约 40%。
   • 修复不足（未修复缺陷或未满足先决条件）占约 25%。
3. 上下文管理策略：
   • 总结和子智能体策略降低了性能： 出人意料的是，旨在管理长上下文的策略（SUMMARIZE 和 SUB-AGENT）表现竟然比原始历史记录基准（BASELINE）更差。从 ORACLE 到 SEQ 的相对跌幅从 33%（BASELINE）增加到了 40-41%（SUMMARIZE/SUB-AGENT），这表明在重写上下文时造成的信息丢失或不一致性，比保留原始历史记录更具危害性。
   • 记忆收益有限： 对于大多数模型而言，保留对话历史（SEQ+MEM）带来的收益微乎其微。只有 GPT-5.5 在特定配置下显示出小幅提升（+7 到 +8 个百分点），这可能是因为它能有效地对更长的历史进行推理。对于其他模型，增加的 token 并未转化为更好的状态追踪能力。
4. 位置分析： 在 ORACLE 模式下，后期的缺陷本质上并不更难；成功率往往随位置增加而上升。而在 SEQ 模式下，随着链条加深，成功率骤降，这证实了难度是由累积的状态漂移驱动的，而非任务本身的复杂度。

意义与贡献

本论文做出了三个主要贡献：

1. CHAINSWE 基准测试： 它提供了第一个显式评估语言模型在真实世界仓库上进行顺序、多缺陷发布能力的基准测试，揭示了在单项问题基准测试中无法察觉的失效模式。
2. 可扩展流水线： 它引入了一个用于构建和验证链式 SWE 任务的流水线，实现了在任意长缺陷修复序列上的持续评估。
3. 实证洞察： 研究表明，当前的 SWE 智能体缺乏鲁棒的依赖追踪和长程推理能力。结果表明，未来的进展需要专注于管理仓库状态和理解跨任务依赖关系，而非仅仅提高孤立问题的解决能力。

作者得出结论，当前的“重置并解决”范式掩盖了关键的失效模式。现实世界的软件维护要求智能体不仅要使当前缺陷得到修复，还要能将代码库维持在一个不仅对当前问题正确，而且可以作为未来工作的起始点的状态。CHAINSWE 中观察到的显著性能下降表明，目前的智能体尚未准备好进行持续的、自主的软件维护。