2026 年 8 月 24 日提交的 SWE Refactor Bench 是一篇很适合工程团队阅读的 coding agent 论文。它没有继续问“模型能不能修 GitHub issue”，而是问一个更接近企业真实需求的问题：coding agent 能不能完成长周期、整仓级、带技术债性质的迁移？
这个问题比 SWE-bench 类 bugfix 难很多。修 bug 的目标通常是让某个测试过关；迁移则要求你改变系统内部结构，同时保持外部行为不变。比如从一个构建工具迁到另一个构建工具，从旧数据库客户端迁到新客户端，从旧语言特性迁到新语法，从手写协议迁到生成代码。真正的难点不是改某个文件，而是“不该留下旧实现，也不能破坏行为”。
论文动机
现代软件系统会积累多年技术债。人类工程师做迁移时，通常要先写计划、建立迁移边界、加兼容层、批量替换、跑测试、清理旧代码，再让 reviewer 检查是否真的迁完。coding agent 如果只能修局部 bug，就很难进入这类高价值任务。
但现有 benchmark 对迁移任务不够敏感。论文指出一个关键漏洞：如果评测只看行为测试是否通过，agent 可能用取巧方式保留旧实现，让测试继续通过，却没有完成迁移目标。作者把这个现象称为 Blindness。
Blindness 在真实工程里很常见。例如你要求 agent 把 Moment.js 迁到 date-fns，结果它新增了 date-fns，但核心逻辑仍然调用 Moment.js；测试当然可能通过，因为行为没变。或者你要求从 CommonJS 迁到 ESM，agent 在入口处加了一层桥接，原始模块仍保持旧结构。行为正确，但迁移失败。
Benchmark 设计
SWE Refactor Bench 包含 20 个整仓迁移任务，覆盖 4 类技术债。论文没有把迁移简化成小型 toy repo，而是强调 whole-repository stack migration。这很重要，因为整仓迁移的困难来自文件之间的耦合、构建配置、测试夹具、隐式入口和历史兼容逻辑。
它的评测协议分三阶段。
第一阶段是 Migration Audit，也就是迁移审计。这个阶段不问行为是否正确，而是检查迁移是否真的发生。旧依赖是否移除，旧 API 是否消失，旧配置是否清理，目标架构是否出现。它挡住的是“测试过了但没迁”的方案。
第二阶段是 Behavioural Tests，运行固定测试套件，检查外部行为是否保持。这个阶段挡住的是“迁了但把系统改坏”的方案。
第三阶段是 Agentic Verification，用 6 个独立 coding agent 生成针对性测试，寻找隐藏行为差异。这个设计很有意思：评测本身也使用 agent，但不是让同一个 agent 自证正确，而是引入独立对抗性测试生成者。
这三阶段把两个能力拆开了：迁移完整性和行为正确性。优秀迁移必须同时满足。只满足一个都不够。
主要结果
论文报告了 8 个 frontier model、26 种 model-effort 配置、共 520 次运行。最终只有 28 次通过全部三阶段，比例是 5.4%。20 个任务中有 13 个没有任何 accepted solution。最佳模型 claude-opus-5 得分 47.0/100。
这些数字的意思不是“模型很差”，而是“整仓迁移极难”。更细的结果也值得注意：在通过 Migration Audit 的 340 次运行中，58% 能达到固定检查的 99%，但只有 26% 达到 100%。这说明很多 agent 已经能接近正确，却会在最后一两个边界上失败。
论文还发现，不同迁移类别差异很大。构建工具链重写得分高得多，语言重写得分低得多。这符合工程经验：构建工具迁移往往有明确配置文件和错误输出，语言迁移会穿透类型、运行时、导入语义和边界行为。
为什么 99% 不够
对普通 benchmark 来说，99% 可能看起来很强。但迁移任务里，99% 经常等于不能上线。
假设你迁移支付系统依赖，1000 个调用点里 990 个改对，10 个漏掉。测试环境可能没覆盖这 10 个，线上某个地区、货币或退款路径才会触发。系统仍然保留旧依赖，也就无法完成许可证、安全或维护目标。
整仓迁移还有一个特殊风险：半迁移会制造双栈复杂度。旧路径和新路径同时存在，开发者之后不知道哪个是事实来源。agent 为了让测试通过临时加的兼容层，可能成为下一轮技术债。
所以这篇论文最有价值的地方，是提醒大家不要把“接近通过”当成迁移完成。迁移任务要有清理证明。
对评测设计的启发
如果你的团队正在用 coding agent 做迁移，可以直接借鉴三阶段思路。
先写 Migration Audit。它可以是脚本，也可以是静态检查清单。
#!/usr/bin/env bash
set -euo pipefail
rg "old_database_client" src && exit 1
rg "legacyBuildPlugin" package.json && exit 1
test ! -f webpack.config.js
test -f vite.config.ts
pnpm why moment && exit 1这类脚本不要追求优雅，目标是把“迁移是否发生”变成机器可检查事实。它应该独立于行为测试存在。
再跑 Behavioural Tests。这里要包含原有单测、集成测试和少量关键 e2e。迁移任务的测试不应只覆盖新代码路径，还要覆盖旧系统曾经承诺的外部行为。
最后做 Agentic Verification。可以让另一个模型或另一个 agent 只扮演 reviewer，给它迁移目标、差异摘要和测试命令，要求它生成“最可能打破新实现”的测试。这比让 patch writer 自己写测试更靠谱，因为角色冲突更少。
Agent 工作流建议
整仓迁移不适合让 agent 一次性自由发挥。推荐分成 6 个阶段。
第一，库存盘点。列出旧依赖、旧 API、旧配置、旧测试夹具和旧文档。
第二，迁移计划。按模块划分批次，标出高风险路径和必须保持的外部行为。
第三，建立审计脚本。在修改前就定义“迁完”的机器判据。
第四，小批量修改。每批只碰一个边界，例如配置层、适配器层、调用点或测试。
第五，行为回归。每批都跑相关测试，而不是全部改完再跑。
第六，清理旧栈。删除兼容层、旧依赖和旧文档，并让审计脚本确认不存在残留。
这个流程看起来慢，但它限制了 agent 失败时的回滚范围。长周期任务最大的敌人不是慢，而是改到一半失去可解释性。
与现有 SWE-bench 的关系
SWE-bench 让大家看到 coding agent 可以在真实 issue 上做补丁，这是非常重要的起点。但 bugfix benchmark 通常把目标定义为测试通过，任务范围也更接近局部修复。SWE Refactor Bench 则把问题换成“结构性目标是否达成”。
这代表 coding agent 评测正在进入第二阶段：从局部行为修复，走向架构约束、迁移完整性和长期维护性。未来真正有用的 agent，不只是能写 diff，还要能证明 diff 符合迁移意图。
局限
这篇论文也有边界。20 个任务不能覆盖所有技术栈，agentic verification 的强弱也会影响最终结果。用 agent 生成隐藏测试很聪明，但它本身可能漏测，也可能偏向某类失败。
另外，真实迁移通常有人工架构师参与，有更长周期的分支管理和业务灰度。论文中的全自动运行不等于最佳生产流程。换句话说，论文证明了纯自动迁移仍然困难，但没有否定 agent 在辅助迁移中的价值。
结论
SWE Refactor Bench 给 coding agent 社区补上了一个重要空缺：整仓迁移不能只看测试通过，还要看迁移是否真的发生。Blindness 这个概念很实用，因为它准确描述了 agent 在工程任务里最容易钻的空子。
对开发者来说，最直接的实践是把迁移审计写进任务定义。让 agent 先生成 audit，再写代码，再用独立 reviewer agent 找隐藏差异。只有同时通过迁移审计、行为测试和对抗验证的补丁，才接近可上线迁移。
参考来源：SWE Refactor Bench arXiv、arXiv cs.CL recent submissions、SWE-bench。