SWE-Chain | 评测

为什么重要

SWE-Chain 是首个评估编码 Agent 在链式版本迁移场景下表现的基准。现有 SWE 类基准（SWE-bench、SWE-bench Pro）聚焦于孤立的 issue 修复，但真实软件维护是一个持续过程——每次上游发布新版本，维护者必须将修改延续到新版本而不破坏既有功能。SWE-Chain 填补了这一关键评测空白：

链式依赖：每次版本迁移都基于 Agent 上一次修改过的代码库，错误会累积传播
发布粒度：在包的实际发布单位（而非单次 commit）上评估持续维护能力
真实复杂度：Release notes 常模糊、不完整，Agent 需要从代码 diff 中推断实际变更

构建方式

DecompSynth 流水线

SWE-Chain 的核心创新是 DecompSynth（分而治之合成流水线），将 release notes 与代码 diff 对齐，生成有依据的升级规格：

分段：将 release notes 拆解为多个子任务
文件级匹配：将每个子任务与 diff 中的文件级变更关联
Hunk 级匹配：进一步精确定位到代码块级别
噪音过滤：去除终端输出、片段示例、图像引用等非操作性内容

升级链设计

12 条升级链，覆盖 9 个真实 Python 包
155 次版本迁移（如 v1.0→v1.1→v1.2→…）
1660 条有代码依据的升级需求
每条链使用独立 Docker 映像，固定 Python 解释器和跨版本依赖

评估流程

两阶段设计：

Build：Agent 单次提交，一次性通过所有测试
Build+Fix：允许 Agent 基于执行错误做一次修正提交

关键发现

Agent 在链式升级中挣扎

9 种前沿 Agent-Model 配置在 Build+Fix 下平均仅 44.8% resolving
即使最佳配置（Claude Opus 4.7 + Claude Code），也仅 60.8% resolving
精确度（65.4%）明显高于召回率（44.8%），说明 Agent 倾向于保守——宁可不做也不做错

版本链越长，越难维护

链式升级中的错误会累积传播：第 N 个版本的错误可能源自第 N-2 个版本的遗漏
Agent 在处理多版本连续升级时，往往忘记前面版本已做的修改

Claude Code 领先但差距不大

Claude Opus 4.7 (Claude Code) 在 Build+Fix 下达 60.8% resolving、80.6% precision、68.5% F1
GPT-5.1 Codex 紧随其后（52.3%），差距仅 8.5pp
开源模型（DeepSeek V3）也有不错表现（45.2%）

Build vs Build+Fix 差距

Build+Fix 机制比纯 Build 提升约 10-15pp
说明 Agent 在获得测试反馈后能有效修正，但首次提交质量仍需提高

关联基准

SWE-bench Pro：孤立 issue 修复的行业标准
SWE-bench-Live：微软出品的可实时更新 SWE 基准
DeepSWE：零污染 SWE 基准，揭示验证器缺陷
BeyondSWE：跨仓库修复和依赖迁移评测

不足与展望

仅覆盖 Python 语言和 9 个包，多样性有限
评估环境依赖 Docker，启动和执行时间较长
Release notes 质量参差不齐，部分包的 release notes 过于简略
尚未测试 Claude Opus 4.8 等最新模型
未来需扩展到多语言（TypeScript、Go 等）和更多包

SWE-Chain 1.0

考察能力

构建信息

资源链接

模型效果排行