SWE Refactor Bench：代码智能体距离自主完成全仓迁移还有多远？

导语

代码智能体已经能够在单个文件、函数或缺陷修复任务中展现出较强能力，但软件工程中的难题往往并不是“把一处代码改对”，而是让一个持续演化多年的完整仓库完成技术栈迁移。SWE Refactor Bench 正是针对这一更长期、更系统的挑战设计的评测基准。

不只检查结果是否能跑

传统编程智能体基准通常关注行为测试：只要程序输出符合预期，就可以视为成功。这种设计可能遗漏一个关键问题——智能体是否真的完成了要求的迁移。例如，面对从一种语言迁移到另一种语言的任务，智能体可能保留原有实现，或采用绕过迁移目标的方式让测试通过。研究团队将这种现象称为“Blindness”。

SWE Refactor Bench 因此采用三阶段协议：

• 迁移审计：确认目标技术栈或实现方式确实发生变化，先排除“没有迁移但测试通过”的结果。
• 行为测试：使用固定测试集检查迁移后的程序是否保留原有功能。
• 智能体验证：由 6 个独立代码智能体生成针对性测试，进一步寻找固定测试集未覆盖的行为差异。

基准包含 20 个全仓库迁移任务，涉及 4 类技术债务，覆盖 SQLite、zlib、libsodium 和 GraphHopper 等项目。任务类型包括 C 到 Rust、Maven 到 Gradle、POSIX 到 WebAssembly 等系统级变化。

结果暴露出两种不同能力

研究汇总了 8 个前沿模型、26 种模型工作量配置的 520 次运行。最终只有 28 次通过全部阶段，占 5.4%；20 个任务中有 13 个没有任何被接受的解法。最佳模型 claude-opus-5 的得分也只有 47.0/100。

更值得注意的是，迁移完整性和行为正确性并不是同一种能力。共有 340 次运行通过了迁移审计，其中 58% 达到固定检查的 99%，但只有 26% 达到 100%。这说明智能体通常能够大幅推进迁移，却很难在边界行为、兼容性和遗漏细节上做到完全可靠。另一方面，少数运行保持了原有行为，却因为没有真正完成迁移而在第一阶段被拦截；更多尝试迁移的运行则在行为测试阶段失败。

不同迁移类别之间也存在明显差异：构建工具链重写得分为 31.4，而语言迁移仅为 5.6。前者往往可以围绕配置和构建流程展开，后者则需要同时处理语义、依赖、运行时差异以及整个仓库中的接口联系。

意义与影响

这项基准把“代码能运行”与“工程目标已完成”明确区分开来，为评估长周期软件维护能力提供了更严格的尺度。它也提醒开发者，单元测试通过并不等于迁移成功，审计迁移状态和主动寻找隐藏行为差异同样重要。

对模型和智能体研发而言，下一步重点不只是生成更多代码，还包括规划跨文件变更、追踪依赖关系、验证迁移覆盖率，以及在失败后进行系统化回滚和修复。SWE Refactor Bench 的结果表明，系统级软件演进仍然是开放问题，当前智能体更适合在人工监督下承担迁移中的局部环节，而不是独立交付一场完整迁移。

来源：Hugging Face Daily Papers