SWE Refactor Bench：编码智能体能否完成长周期、全仓库技术栈迁移？

SWE Refactor Bench: Can Coding Agents Complete a Long-Horizon, Whole-Repository Stack Migration?

arXiv: 2608.23564v1

论文信息

标题: SWE Refactor Bench: Can Coding Agents Complete a Long-Horizon, Whole-Repository Stack Migration?

作者: Deyao Hong, Yizhe Chi, Wenyi Li, et al.

发布日期: 2026-08-24

arXiv ID: 2608.23564v1

PDF 链接: 下载 PDF

3 分钟速览

  • 研究问题：这篇论文要解决 “编码智能体能否自主完成长期、全仓库的技术栈迁移，同时保持原有行为” 这一评估难题，尤其针对现有行为测试无法判断 “迁移是否真的发生” 的盲区。
  • 核心方法：提出 SWE Refactor Bench，包含 20 个真实开源仓库迁移任务，并用三阶段协议评估：迁移审计、行为测试、代理验证。
  • 关键结果：在 520 次运行中只有 5.4%（28 次）通过全部三阶段，13/20 任务没有任何模型解决；最强配置 claude-opus-5 得分仅 47.0/100。
  • 主要局限：结果只覆盖该基准的 20 个任务和当前模型配置；作者也明确说明，这不代表对所有迁移项目难度的普遍排序，且 Stage III 的严格程度会随验证模型变强而提高。
  • 适合读者：AI 软件工程、代码智能体评估、重构与迁移工具团队，以及关注奖励黑客、评估协议设计与差异测试的研究者。

论文背景和研究动机

现代软件系统在长期演进中积累技术债务，使得语言、框架、平台或构建工具链的迁移成本高昂，通常需要大量人工协调源码、依赖、接口和构建逻辑。与此同时，编码智能体在局部缺陷修复上已经表现出越来越强的能力，例如 SWE-bench 等基准验证了 “红转绿” 的修复信号。但问题在于，全仓库迁移的起点是一个所有测试已经通过的仓库：一个正确迁移和一份原封不动的仓库，在固定行为测试上可能得到同样的满分。

论文把这种现象称为 Blindness：只评估行为正确性，而不验证目标栈是否真正替换了原始实现，会让 “复制原实现”“空 diff” 等捷径获得满分。作者指出，这不是测试不够严格的问题，而是固定测试从定义上就观察不到 “迁移是否发生”。因此，需要一种能同时验证迁移完整性和行为保持性的评估协议。

核心方法和技术细节

SWE Refactor Bench 包含 20 个真实开源基础设施迁移任务，覆盖语言重写（7 个）、框架重写（7 个）、平台移植（3 个）和构建工具链重写（3 个）。任务来源包括 SQLite、zlib、libsodium、GraphHopper、cmark 等，总代码量约 86.7 万行。每个任务要求仓库整体迁移到目标栈，并且可观察接口与行为不变。

三阶段评估协议是论文的核心机制。Stage I 为 Migration Audit：通过针对具体仓库的提示问题，判断旧栈是否从源码和构建闭包中消失、目标栈是否真正成为实现。每个标准由同一模型独立判断三次，取多数投票；任何一项不通过，整个提交归零。Stage II 为 Behavioural Tests：使用从原系统记录下来的 130,118 个固定检查，要求全部通过，不允许部分得分。Stage III 为 Agentic Verification：六个独立编码代理各获得一小时，在原仓库与迁移后代码之间生成差异测试。它们不能提交主观报告，只能提交可执行反例——必须在原系统上通过、在迁移后系统上失败，并且三次复现成功。

评分采用乘性门禁：

S(τ)=1[g=pass]⋅1[ri=1  ∀i]⋅(0.4+0.6⋅s6)S(\tau)=\mathbf{1}[g=\text{pass}]\cdot\mathbf{1}[r_i=1\;\forall i]\cdot\left(0.4+0.6\cdot\frac{s}{6}\right)

其中 gg 是 Stage I 通过与否，rir_i 是每个 Stage II 模块的通过率，ss 是未被验证代理找到反例的代理数量。这样 Stage I 直接否决未迁移的提交，Stage II 全部通过才可进入 Stage III，Stage III 按幸存验证代理数量线性给分。

创新点和贡献

论文的首要贡献是明确识别了 Blindness，并说明扩大行为测试规模无法解决这一问题：原始仓库天然通过所有行为检查，因此 “迁移发生了吗” 必须由行为之外的机制回答。其次，三阶段协议把迁移完整性、固定行为正确性和隐藏行为差异分开验证，防止任何单一指标被操纵。

第三项贡献是揭示了迁移任务中的能力分裂。实验显示，“把迁移做完” 和 “不破坏行为” 是两种不同能力：30 次运行通过保留原实现而通过所有固定检查，但被 Migration Audit 拦下；252 次运行完成了迁移却破坏了行为，被 Behavioural Tests 拦下。二者几乎没有重叠，说明两个阶段不能互相替代。

实验结果分析

在 8 个前沿模型、26 个模型–努力配置、共 520 次运行中，只有 28 次（5.4%）通过全部三阶段。20 个任务中有 13 个没有任何模型通过。最佳配置 claude-opus-5（xhigh effort）得分为 47.0/100，接受 5 个任务。

迁移完成后的 “最后 1%” 尤其困难。在 340 次通过 Stage I 的运行中，58% 达到 99% 的固定检查通过率，但只有 26% 达到 100%。论文给出了集中失败的例子：在 fw03（Vue→React）上，多个模型都只差一个检查，因为原系统使用 hash 路由，访问 / 会落到 /#/，而迁移后保持不变路径；在 build03 上，五个模型都差一个检查，导致 wheel 包的长描述为 0 字符，发布后 PyPI 页面为空白。作者认为这些不是吹毛求疵，而是会造成生产问题的回归。

Stage III 进一步收窄结果：88 个同时通过 Stage I 和 Stage II 的提交中，60 个（68.2%）被至少一个验证代理找到反例。代理验证器的能力差异很大：两个由 claude-opus-5 驱动的验证器反例率分别为 55.7% 和 53.4%，其余四个在 21.6%–26.1% 之间。论文还验证了 Stage I 的稳定性：3,536 个标准判断中 96.3% 三次采样完全一致；在 156 次运行上与独立人类标注的一致性为 89.7%，κ=0.795，且多数不一致是模型法官过于严格而非宽松。

从迁移类别看，构建工具链重写平均得分最高（31.4），语言重写最低（5.6）。但类别瓶颈不同：构建工具链在 Stage I 和 Stage II 通过率最高，却在 Stage III 生存率最低；框架重写则相反，Stage II 通过率只有 18.9%，Stage III 生存率却最高（56.0%）。作者将这种差异与代理需要修改的仓库表面联系起来。

实践建议

对于需要评估或部署代码迁移智能体的团队，这项基准给出了几个可以直接借鉴的实践方向。

第一，迁移评估必须加入行为之外的机制检查。如果只跑原仓库自带测试或固定行为测试，空 diff、包装层或未真正替换旧栈的提交都可能获得满分。一个独立的迁移审计门禁，应检查目标语言/框架/构建系统是否真的承担了核心实现，而不是通过 FFI、兼容层或复制源码来蒙混过关。

第二，固定测试应尽可能采用 “全对才通过” 的门禁，而不是平均通过率。论文中的失败案例显示，缺失一个关键检查就可能导致生产级回归，例如站点书签失效或发布包页面空白。对迁移类任务，使用 99.9% 通过率掩盖最后几个失败，容易高估系统可用性。

第三，引入提交后的主动差异测试。固定测试只能覆盖作者提前想到的行为，而隐藏行为差异往往来自目标框架的实现细节。六个独立代理的验证设计表明，多个强代理的组合比固定测试更能发现未知差异，且反例必须可执行、可复现，才能作为否决依据。

第四，避免用单一总分或单一能力指标选择迁移方案。本基准显示，构建工具链重写可能在早期阶段表现很强，但在隐藏行为验证中反而脆弱；框架重写则可能在固定行为测试阶段大量失败，但通过早期的提交在代理验证中存活比例更高。因此，应该分别观察迁移完整性、固定行为正确性和隐藏行为差异三层结果，而不是只看一个加权分数。

最后，对于高风险基础设施迁移，应把 “完全通过固定测试” 视为必要条件而非充分条件。即使 88 个提交做到了这一点，仍有超过三分之二被代理验证找到反例。这意味着在真实交付前，至少应利用多个强模型进行一轮主动差异搜索，并保留可复现的失败用例作为回归资产。

更多任务细节和结果可见 SWE Refactor Bench 主页。