为什么重要
所有现有的 SWE 基准（SWE-bench、SWE-bench Pro、Terminal-Bench 等）都采用相同的评测协议：每次重置仓库、重读代码库、修复一个独立 Bug——将连续维护工作流折叠为独立会话。但在真实软件开发中，工程师需要在一个不断演进的仓库上连续修复相关缺陷，每次修复都可能引入下游依赖问题。
ChainSWE 是首个评估 Agent 在共享代码库中顺序修复相关 Bug 能力的基准。它揭示了两种传统评测无法捕获的失败模式：
- 过修（Overshoot）：Agent 修复早期 Bug 时修改了多余的代码，导致后续 Bug 的补丁应用在污染后的代码基上失败
- 欠修（Undershoot）：Agent 只修复了 Issue 描述中提到的文件，遗漏了多个配套重构，导致下游测试因前置条件未建立而失败
构建方式
- 从 6 个 SWE-bench 系列数据集中挖掘同一仓库中存在文件/函数/类重叠的 Bug 修复历史
- 按时间排序构建 Bug 链，验证每步的金标准补丁和测试套件
- 评估时：Agent 在步骤 k 仅收到第 k 个 Issue 的描述，操作在前 k-1 步累积的代码状态上进行
- 100 条链 × 304 个实例 × 54 个 Python 仓库
评估配置
- Oracle 模式：每个 Bug 单独接收完整 Issue 描述（最优条件）
- Seq 模式：连续修复，不做任何上下文管理（最接近真实场景）
- Seq+Mem 模式：连续修复 + 保留对话历史记忆
- 上下文管理策略：Baseline（保留原始历史）/ Summarize（总结）/ Sub-Agent（子代理编辑）
关键发现
- 性能随链长度急剧下降：从 Oracle 到 Seq 模式，per-bug 准确率平均从 58.9% 降至 36.5%（-38%）
- 最深位置降幅高达 70%：在链的第三个 Bug 位置，Summarize 和 Sub-Agent 在 Seq 模式下降幅分别达 70% 和 70%
- GPT-5.5 鲁棒性最佳：Oracle→Seq 降幅最小（69.1% → 49.0%，-29%），且是唯一从对话记忆中获益的模型（Seq+Mem 46.8% vs Seq 42.2%）
- DeepSeek V4 Pro 鲁棒性最差：Sub-Agent 下 Oracle→Seq 降幅最大（48.4% → 25.0%，-48%）
- Full-Chain 通过率极低：Oracle 平均仅 20.0%，Seq 仅 17.0%——任一 Bug 失误即导致全链失败
- Baseline 上下文管理最优：保留原始历史比 Summarize（-40%）和 Sub-Agent（-41%）更鲁棒
最新进展
- 2026-07-01：ChainSWE 论文在 arXiv 发布（arXiv:2607.02606），7 个前沿模型在 3 种上下文管理配置下评估，揭示链式修复的严重性能退化
- 2026-07：发现 GPT-5.5 在连续修复场景下鲁棒性超预期——即使在 Seq 模式下 per-bug 仍达 49.0%，而 DeepSeek V4 Pro 跌至 25.0%，反映模型间”依赖感知”能力差异远超单次修复能力差异
- 2026-07：ChainSWE 的”过修/欠修”双重失败模式框架被社区广泛引用，为构建更好的依赖追踪和仓库状态管理提供了明确的改进方向
关联基准
- SWE-bench Pro：静态单次评测标准
- SWE-Together：多轮交互编程评测
- SWE-Lancer：真实付费任务
- Terminal-Bench 2.0：终端 Agent 评测
不足与展望
- 100 条链规模有限，54 个仓库的覆盖面不广
- 仅覆盖 Python 项目，未扩展到多语言
- Oracle 模式假设每个 Bug 都有完整 Issue 描述，但实际排查过程中 Bug 描述往往不全
- Full-Chain 通过率极低（~20%）使评分分布偏向极值，细粒度区分度有限
- 依赖链挖掘算法可能遗漏某些跨链依赖关系