SWE-Chain: Benchmarking Coding Agents on Chained Release-Level Package Upgrades¶

会议: NeurIPS 2026
arXiv: 2605.14415
OpenReview: https://openreview.net/forum?id=pQ3yrw2J9j
代码: https://github.com/mh-lam/SWE-Chain
领域: 代码智能
关键词: 编码智能体, 连续软件演化, 软件包升级, 基准评测, 规范合成

一句话总结¶

提出了首个针对真实 Python 软件包连续跨版本升级的基准评测 SWE-Chain，通过分而治之的 DecompSynth 流程对齐发布说明与代码补丁合成可靠规范，揭示前沿模型在跨版本功能继承与防退化上面临的严峻瓶颈。

研究背景与动机¶

随着大语言模型驱动的编码智能体（如 Claude Code 与 Codex）在代码仓库导航、终端交互及工具调用方面的演进，软件工程评估已从孤立的代码生成与单一 issue 修复（如 SWE-bench）逐步转向真实的长期代码演化。然而，现有的长程维护评测往往依赖人工选定的基线到目标 commit 对（如 SWE-CI）、合成检查点（如 SlopCodeBench）或重建的里程碑（如 EvoClaw），这些切分点均无法反映开源维护者实际打包并发布软件版本的真实场景；而少数探索发布级演化的工作（如 SWE-EVO）仅通过机械拼接 release notes 与 GitHub issue/PR 作为粗粒度需求，不仅充斥大量终端报错片段、环境配置噪声与图像引用，更将版本迁移拆解为孤立的端到端单步任务，未曾考察代码修改在多个连续版本间的累积与继承效应。

这种评测设定的核心矛盾在于：真实的软件包维护具有强烈的「连续累积性」与「版本边界约束」——每一次版本迭代都打包了多项新特性与修复，且维护者必须在保留已有历史功能不被破坏的前提下向前推进；智能体在上一版本留下的潜在缺陷与兼容性妥协，会直接带入下一版本的基准代码中。现有基于隔离单步任务的评测由于频繁重置干净环境，彻底掩盖了智能体在连续版本迭代中代码逐步劣化（code degradation）与回归破坏的深层隐患。

为了系统探究智能体是否能在自身持续修改的代码库上长期维护真实软件包，本文的核心 idea 是构建首个链式发布级软件包升级基准 SWE-Chain，设计「分而治之」的 DecompSynth 规范合成流水线将 release notes 与代码 diff 精确对齐，并在版本链条中强制智能体在上一轮自身产出的代码库上继续升级与回归测试。

方法详解¶

整体框架¶

SWE-Chain 的整体评测框架涵盖基准构建、环境封装、规范合成以及链式版本升级执行四大阶段。首先从真实 Python 软件包中筛选出具备完备测试集与规范发布记录的版本序列，为每条版本链定制跨版本统一的基础 Docker 环境；随后，针对每一对相邻版本，利用分治合成管线 DecompSynth 将发布说明任务项与代码级变更对齐并合成结构化升级规范；最后，编码智能体以初始版本的真实源码为起点，严格按照版本链顺序依次应用规范进行升级，且上一阶段产出的代码库直接作为下一阶段的升级输入，配合 Build+Fix 正则化机制全面评测升级解决率与回归控制能力。

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    A["历史版本元数据与代码提取<br/>PyPI/GitHub 发布说明 + Git Diff"] --> B["跨版本 Docker 环境容器化<br/>固定解释器与共用依赖"]
    B --> C["跨版本验证与测试集划分<br/>识别 FAIL_TO_PASS 升级相关测试"]
    C --> D["DecompSynth 分治规范合成<br/>Hunk 多标签匹配与结构化规约"]
    D --> E["链式升级执行与代码继承<br/>前一版本产物作为后一版本基线"]
    E -->|环境/导入报错| F["Build+Fix 单次受控修复<br/>提供执行报错反馈修正环境阻断"]
    E -->|正常退出| G["隔离容器隐藏测试集评测<br/>统计 Resolving / Precision / F1"]
    F --> G

关键设计¶

1. 跨版本 Docker 环境设计与升级测试集判定：兼顾环境复用与行为隔离 真实开源项目跨版本迭代过程中，Python 版本与底层依赖常常发生漂移，若为每个微小版本单独构建镜像会导致评测极度笨重且无法模拟连续演化。本文为每条升级链设计定制 Dockerfile，显式锁死 Python 解释器和跨版本核心依赖，同时允许各软件包解析自身特定依赖，确保单一容器即可平滑运行整条链上的所有版本测试套件，并通过健全性检查确保初始测试失败率低于 0.25%。对于相邻版本 \(v_{i-1}\) 到 \(v_i\) 的升级，系统在真实金标旧代码 \(c_{v_{i-1}}\) 与新代码 \(c_{v_i}\) 上分别执行新版本测试套件 \(\mathcal{Q}_{v_i}\)，严格提取出升级相关测试集 \(\mathcal{U}_i=\{q \in \mathcal{Q}_{v_i} \mid r(q, c_{v_{i-1}}) \in \{\text{fail}, \text{error}\} \land r(q, c_{v_i}) = \text{pass}\}\)，将真正的升级功能验证与既有存量功能测试解耦。

2. DecompSynth 分而治之规范合成：对齐发布说明与代码差异以消除噪声 直接使用开源 release notes 会因表述模糊导致智能体无法明确修改意图，而拼接 issue/PR 则会引入冗长且不可靠的上下文噪声。DecompSynth 将规范合成拆解为「分（Divide）」与「治（Conquer）」两步：在分块阶段，先将文件级代码 diff 按行数降序拆分为受控批次（每批最多 20 个文件、150 个 hunk、3000 行 diff），交由大模型智能体 \(\pi_{\theta}^{\text{map}}\) 对每个 hunk 进行多标签标注，映射到 release notes 提取出的任务标签 \(\mathcal{L}=\{1,\dots,n\} \cup \{\text{doc}, \text{others}\}\)；在合成阶段，针对每个聚合了相关 hunks 的任务，利用合成智能体 \(\pi_{\theta}^{\text{syn}}\) 生成包含问题陈述、概念与落地约束、具体预期行为及验收准则四要素的高质量升级规范。针对标注为 others 的剩余变更，智能体还会判定是否隐含了未列于发布说明的行为变更并补充新任务规范。

3. 链式连续演化协议与 Build+Fix 正则化：真实代码继承与非功能性错误容错 在链式演化协议下，版本升级链表示为连续步骤序列 \([\mathcal{V}_1, \dots, \mathcal{V}_N]\)。智能体初始从纯净版本 \(c_{v_0}\) 启动，在第 \(i\) 步接收合成规范 \(\mathcal{S}_i\) 后对上一轮代码 \(\hat{c}_{v_{i-1}}\) 进行修改生成 \(\hat{c}_{v_i} = \pi_{\theta}(\mathcal{S}_i, \hat{c}_{v_{i-1}})\)。由于黑盒评测中非语义性的环境兼容性阻断（如缺少顶层包导入、pytest 收集阶段报错）会误伤原本功能正确的补丁，评测引入了 Build+Fix 正则化机制：当智能体产出的代码在执行层面抛出导入或收集异常时，系统提供单次反馈报告错误堆栈，允许智能体执行一次针对性修复。这既避免了智能体因琐碎的配置阻断而满盘皆输，又严格限制了调试次数以保持基准区分度。

一个完整示例¶

以 attrs 软件包从版本 21.3.0 向 26.1.0 连续升级为例： 1. 环境准备与基线加载：评测框架在统一容器 /app 目录下放置 21.3.0 版本的纯净代码，并初始化无状态智能体会话； 2. 规范下发与版本升级：系统下发 21.3.0 \(\rightarrow\) 21.4.0 的 DecompSynth 规范文件，包含该版本识别出的多个细分任务（如新增 evolve() 的参数校验机制与弃用警告迁移）； 3. 首轮实现与 Build+Fix：智能体通过编辑工具修改源码；若在测试收集阶段由于遗漏新常量的 __all__ 导出抛出 ImportError，系统捕获该执行错误并提供堆栈，智能体在单次 Fix 机会中补齐导出； 4. 历史冻结与链式继承：通过该版本测试后，框架将当前工作区代码整体打包归档，并将其作为升级 22.1.0 的起始基线 \(\hat{c}_{v_1}\)。若智能体在 21.4.0 中引入了未暴露的隐蔽类型破坏，该破坏将直接在后续 22.1.0 的新老测试中被持续放大，最终引发级联回归。

实验关键数据¶

主实验¶

在 12 条升级链（涵盖 attrs, conan, Flask, Jinja2, poetry, PyJWT, pytest, urllib3, xarray 等 9 个流行开源项目，共 155 次版本跃迁、1660 个细分升级任务）上，评测了覆盖 Anthropic、OpenAI、Z.AI 及 MiniMax 的 8 款前沿大模型与 3 款主流智能体框架（Claude Code, Codex CLI, OpenCode）。

智能体 CLI	厂商	模型	Resolving (Build)	Resolving (Build+Fix)	Precision (Build)	Precision (Build+Fix)	F1-score (Build+Fix)	Final Passing
Claude Code	Anthropic	Claude-Opus-4.7	58.3%	60.8%	67.4%	80.6%	68.5%	91.9%
Claude Code	Anthropic	Claude-Opus-4.6	38.8%	44.3%	51.3%	64.9%	50.8%	85.8%
Claude Code	Anthropic	Claude-Sonnet-4.6	34.4%	39.8%	53.4%	66.5%	45.9%	84.5%
Codex CLI	OpenAI	GPT-5.5	52.2%	57.5%	72.0%	80.1%	64.8%	92.2%
Codex CLI	OpenAI	GPT-5.4	45.3%	47.5%	59.2%	72.2%	54.9%	90.4%
Codex CLI	OpenAI	GPT-5.3-Codex	47.1%	51.8%	70.5%	76.3%	59.2%	90.9%
OpenCode	OpenAI	GPT-5.4	39.3%	43.4%	54.7%	63.8%	46.5%	89.7%
OpenCode	Z.AI	GLM-5.1	27.5%	38.1%	31.8%	49.9%	40.1%	84.1%
OpenCode	MiniMax	MiniMax-M2.7-HS	14.5%	20.2%	25.8%	34.2%	21.2%	70.3%
平均	-	-	39.7%	44.8%	54.0%	65.4%	50.2%	86.6%

消融实验：规范粒度级别对升级能力的影响（pytest 8.0 链）¶

研究对比了 5 种不同细化程度的升级规范对模型维护行为的影响：L1 为 SWE-EVO 式原始 release notes 混杂 issue/PR；L2 仅含问题陈述；L3 为默认配置（含问题陈述、概念性预期与防退化约束）；L4 包含代码级具象约束；L5 包含完整验收准则与行为描述。

模型	指标	L1 (原始拼接)	L2 (仅问题陈述)	L3 (默认: 约束与边界)	L4 (代码具象约束)	L5 (完整验收规约)
Claude-Opus-4.7	Resolving	44.5%	62.6%	66.1%	66.7%	73.9%
Claude-Opus-4.7	Precision	8.9%	7.8%	88.1%	89.2%	93.5%
Claude-Opus-4.7	F1-score	14.8%	13.9%	75.5%	76.3%	82.5%
GPT-5.5	Resolving	47.4%	44.5%	53.4%	68.1%	67.8%
GPT-5.5	Precision	9.9%	9.5%	92.1%	93.3%	89.7%
GPT-5.5	F1-score	16.3%	15.7%	67.6%	78.7%	77.3%

关键发现¶

跨版本链式维护极其严苛：在 Build+Fix 机制下，前沿智能体全链平均升级解决率仅为 44.8%，F1 仅为 50.2%，超过半数的新版本特性无法被完整正确实现，暴露了当前模型在长程版本迭代中的明显能力短板。
防退化约束对安全性产生质的飞跃：从 L2 到 L3 的消融表明，缺少明确边界约束时模型的 Precision 暴跌至 7.8%~9.5%（F1 低于 16%），引入负向与概念边界后 Precision 瞬间回升至 88%~92%，说明模型若未被明确告诫「哪些现有行为不得破坏」，极易肆意重构引发大面积回归。
Build+Fix 机制有效挽救脆性阻断：Build+Fix 将平均 Precision 从 54.0% 提升至 65.4%，主要修复了 import 与 collection 级别的脆性错误，证明该机制合理惩罚了逻辑语义缺陷，避免了构建配置层面的过度惩罚。
原生 CLI 与模型适配协同显著：GPT-5.4 在 Codex CLI 下的 F1 表现（54.9%）明显高于在 OpenCode CLI 下的表现（46.5%），证实官方生态内工具提示词和调用协议的高度对齐对长程软件工程任务至关重要。

亮点与洞察¶

真实连续链式演化评估视角：跳出了传统「单步独立 issue 修复」的静态范式，首创基于真实发布周期的多步级联维护评测，将前期修改的代码作为后续演化的载体，真实重现了代码异味积累与技术债雪崩。
基于分治对齐的 DecompSynth 合成设计：巧妙利用 diff 行数贪心打包和多标签 hunk 映射，将上万行 diff 的复杂版本升级精准拆解为高内聚、有依据的原子规范，成功解决了以往自动构建测试规范要么过于含糊、要么严重信息泄漏的顽疾。
可复用的跨版本多阶段测试稳健插件：在评测中针对 pytest 设计了导入桩补全与阶段性断点写入机制，使处于半损坏状态的升级中间态代码仍能产出有效的覆盖率与错误报告，避免评测框架自身崩溃。

局限与展望¶

作者承认的局限：目前评测语言严格局限于 Python 生态，且升级链全部基于 Git 提交与已发布的开源包，未能涵盖私有闭源项目或多语言混合微服务架构的升级动态。
实际观察到的局限：Build+Fix 仅提供了一次单轮执行修复，而真实工程师在面对大版本迁移时会经历多轮渐进式单元测试调试；此外由于防作弊限制禁用了外网包下载，智能体无法根据升级规范自主更新 pyproject.toml 中的第三方依赖。
未来改进方向：可进一步引入多智能体协作机制（如拆分架构分析师、代码实现者与回归测试员），并在仿真沙箱中支持依赖树同步更新与跨包级联协同升级。

评分¶

新颖性: ⭐⭐⭐⭐⭐ 首次建立基于真实软件包连续版本发布链的演化评估基准，填补了长程代码继承评测的空白。
实验充分度: ⭐⭐⭐⭐⭐ 覆盖 9 大流行 Python 库、155 次版本跃迁与 1660 个任务，全面横评主流前沿模型与三大智能体 CLI。
写作质量: ⭐⭐⭐⭐⭐ 体系完备，公式与算法描述严密，对规范粒度、防作弊与评测稳健性的论述十分详实。
价值: ⭐⭐⭐⭐⭐ 对代码智能体从「玩具级单点修 bug」走向「企业级长程代码库运维」提供了极具鉴别力与指导性的评测工具。