SWE Refactor Bench：编码智能体能否完成长时程、全仓库级技术栈迁移

用迁移审计+行为测试+智能体验证三阶段协议评估编码智能体的全仓库迁移能力

前置知识

SWE-bench 范式（红变绿）

SWE-bench 及其后续工作确立了仓库级编码评测的主流范式：给定一个真实仓库和真实 issue，仓库中至少有一个测试在补丁之前失败、补丁之后通过。这个从失败到通过的跳变本身就是任务完成的证据，评测只需运行固定的测试套件统计通过率。后续工作如 SWE-EVO（仓库演化）、SWE-CI（CI 历史）、Terminal-Bench（终端长时程任务）都沿用这一'红变绿'判据。

本文的核心洞察是：行为保持型迁移任务的初始状态测试本来就是绿的，不存在'红变绿'信号，因此整个 SWE-bench 范式的评测手段在此完全失效，这正是论文提出三阶段协议的出发点。

盲视（Blindness）失效模式

指仅依赖行为测试的评测器无法判断迁移是否真正发生：由于行为保持型任务的原始仓库本来就通过全部测试，智能体完全可以原样交回仓库（空 diff）或只包一层转发 shim，就能在任何固定行为测试上拿满分。论文形式化地指出：行为测试套件 $T \subseteq O$ 对原仓库有 $\mathrm{rate}(R_A; T)=1$，令 $R_S=R_A$ 即可零工作量获得满分。

盲视是论文命名并要解决的核心问题——它不是奖励黑客钻空子，而是评测规则本身的结构性缺陷：新增再多行为测试也无法闭合这个漏洞，必须引入行为之外的第二类证据。

差分测试（Differential Testing）

一种没有独立规格说明时的正确性验证方法：利用参照实现作为'另一侧'，对同一输入分别运行参照版和被测版，比较输出是否一致。编译器测试长期用它在规模化场景下交叉验证不同编译器，也被用于差分符号执行等场合。它不要求写出'应该是什么'，只要求'两边必须一样'。

本文第三阶段的智能体验证就是差分测试的智能体形态：六个编码智能体拿着原仓库和迁移后的源码树主动搜索行为差异，且只接受可执行的反例——在参照系统上通过、在提交版本上失败且能复现三次。

LLM-as-Judge 与多数投票

当判据无法写成评分脚本时，用大模型充当裁判是标准做法。其已知失效模式包括位置偏差、冗长偏差和自我偏好。缓解手段是让裁判回答窄问题（逐条判据）而非给出一个总体打分，要求每个不通过判定引用可复查的证据，并对每条判据独立采样多次后取多数。

本文第一阶段迁移审计的裁判是 gpt-5.6-sol，每条判据三次独立判定取多数。论文用数据证明多数投票是承重结构而非仪式：340 个通过第一阶段的运行中有 35 个（10.3%）存在 2:1 分歧的判据，若不取多数、任何一票反对即判零，则通过数会从 340 降到 305。

技术栈迁移与四类技术债

软件系统经年累月积累技术债，其技术栈可归结为四个维度：用什么语言编写、围绕什么框架组织、假设什么宿主平台、用什么构建工具链。全仓库迁移就是把其中某一个维度整体替换（如 C 重写为 Rust、Maven 换成 Gradle），同时保持可观测行为不变。成功的迁移必须同时满足迁移条件和保持条件，且两者性质不同。

本文把 20 个任务按这四类技术债组织：语言重写 7 个、框架重写 7 个、平台移植 3 个、构建工具链重写 3 个。实验显示智能体在四类任务上能力剖面截然不同（构建工具链 31.4 分 vs 语言重写 5.6 分），且瓶颈阶段各异。

研究动机

现代软件系统在数十年的开发中不断积累技术债，长期运行的仓库被锁定在团队已不愿维护的技术栈上。替换一门语言、一个框架、一个宿主平台或一套构建工具链依然昂贵且基本靠手工，因为工程师必须协调源代码、依赖、接口和构建逻辑之间的改动。随着编码智能体在局部缺陷修复上越来越可靠（SWE-bench 等基准驱动的进展），一个更难的问题自然浮现：它们能否自主完成长时程、全仓库级的迁移并保持行为不变？现有基准无法回答这个问题，因为它们只评测行为正确性、不评测迁移是否真的发生：迁移任务从测试全绿的仓库出发，正确的迁移和原封不动的仓库会得到同样的满分测试分数。这制造了一个极易的作弊捷径——智能体可以保留或复制原始实现让测试通过。论文将这种失效模式命名为盲视（Blindness）：仅行为的评测器在不确认目标栈已替换原实现的情况下就授予满分。值得注意的是，作者强调这不是通常意义上的奖励黑客——原样交回的仓库没有绕过任何检查，它是按规则赢得满分的，规则本身看不见迁移是否发生，因此加再多的行为测试也无济于事。

本文的目标是本文的目标是构建一个能同时度量'迁移完成度'和'行为正确性'的严谨基准，回答编码智能体当前能否可靠地完成全仓库行为保持型迁移。具体而言：其一，从真实开源基础设施（如 SQLite、zlib、libsodium、GraphHopper）中精选 20 个整仓库迁移任务，覆盖语言、框架、平台、构建工具链四类技术债，每个任务给智能体 6 到 30 小时的自主工作时间；其二，设计三阶段评估协议，分证据类型分别检验迁移条件与保持条件——迁移审计确认旧栈确实从仓库和构建闭包中消失，行为测试用从原始系统录制下来的 130,118 条固定检查确认行为逐条不变，智能体验证则派六个独立编码智能体在提交之后主动搜索固定测试覆盖不到的行为差异；其三，在 8 个前沿模型、26 个模型-推理力度配置上运行全部 20 个任务共 520 次评分运行，量化当前智能体与可靠全仓库迁移之间的能力差距，并分析失败在哪个阶段、以何种模式发生。

与已有工作不同的是，论文的独特切入角度在于指出'迁移是否发生'与'行为是否保持'是两种性质不同的命题，需要分开的证据：前者是关于仓库文本和构建产物的命题，后者是关于制品行为的命题。已有工作（TransCoder、MigrationBench、C-to-Rust 专项基准等）虽然把迁移单元从函数扩展到了整个仓库，但打分方式雷同——运行测试套件统计通过率，这在换栈场景下结构性失效。论文的分析证明了一个关键事实：由于保持条件是相对原仓库定义的，$\mathrm{rate}(R_A;T)=1$ 对任何测试套件成立，奖励的最大值恰好落在一个零工作量的提交上，扩大测试集毫无帮助。此外，已有基于模型的评判和差分测试这两条成熟技术路线分别位于本文两端的工具箱里：迁移审计借鉴前者但用窄问题加证据引用加三次采样的方式规避裁判偏差，智能体验证则把后者的参照系差分测试改造成智能体形态——只接受能运行的反例而非报告。表 7 的定位对比显示，同时具备'栈变更、迁移判据、智能体验证'三个维度的基准，本文是第一个。

核心方法

SWE Refactor Bench 度量一种能力：给定一个构建于某技术栈之上、可正常工作的仓库，智能体能否交付同一个仓库在另一技术栈上的版本，且可观测行为完好、旧栈彻底消失。直觉上，评估必须同时回答两个问题：迁移真的发生了吗？行为还和原来一样吗？技术路线是把任务形式化为元组 $\tau=(R_A, \Sigma_A \to \Sigma_B, O, I, E, B)$，其中 $R_A$ 是取自某一提交、可构建可运行的真实开源仓库（状态 A），$\Sigma_A \to \Sigma_B$ 是源栈到目标栈的变更，$O$ 是制品的可观测接口（进程输出与退出码、库导出符号、安装树清单、HTTP 端点响应等），$I$ 是给智能体的指令，$E$ 是离线镜像，$B$ 是时间预算。提交的解决方案 $R_S$ 当且仅当满足迁移条件（$\Sigma_B$ 能构建交付物，且 $\Sigma_A$ 从仓库和构建闭包中消失）和保持条件（$O(R_S)=O(R_A)$）时才算解出。评估端用三阶段协议分别收集这两类证据，共 136 条迁移判据、264 个独立测试模块、130,118 条固定行为检查。

核心创新是把'评测器看不见迁移是否发生'这一结构性盲区，转化为三道性质不同、互不可替代的关卡。与已有方法的本质区别有三点。第一，引入硬否决式的迁移审计：判据写成关于该仓库的提示词问题，由裁判模型（gpt-5.6-sol）逐条阅读两棵源码树作答，每个不通过判定必须引用可复查的证据，每条判据独立判定三次取多数，任何一条失败即整个提交判零——这堵住了行为评测给原样交回的仓库打满分的漏洞。第二，行为测试不是凭空编写而是从状态 A 录制：同样的调用先在原仓库上运行、输出被记录为期望答案，全部 130,118 条检查要求全过，一条错即零分——论文论证这种全有全无是合理的，因为失败测试背后站着真实的下游消费者。第三，智能体验证把差分测试变成智能体形态：六个编码智能体各持两棵源码树、各有一小时，五个各探测一个指定方向（C ABI、一组路由、安装树等），第六个不受限；它们提交的不能是报告，只能是可执行测试用例——先在参照实现上变绿、再在提交上失败、且复现三次，从而'没人想到的问题'变成了可复查的事实。这彻底超越了固定测试'只能问出题人想到过的问题'的局限。

方法步骤详情

流水线分三步。任务构造：先定技术债再选仓库，要求旧栈承重（如 cmark 的手写 C 解析器移到 Rust 意味着重新设计所有权而非加一层 FFI）、接口有真实下游依赖、存在可反复运行的参照实现；20 个任务共 867,062 行源码。任务执行：智能体在容器内获得状态 A、两套工具链、指令和 6-30 小时预算，全程断网，自行读仓库、定计划、重写、构建、对照原版自查；结束后工作树被收集为提交。评估阶段一（迁移审计）：裁判逐条回答 136 条关于旧栈是否消失的问题，三次采样多数决。阶段二（行为测试）：重建制品后运行 264 个模块共 130,118 条检查，全过才放行。阶段三（智能体验证）：六个智能体各 88 轮，只接受可执行反例，需先在状态 A 上通过、再在提交上失败并复现三次。打分公式为 $S(\tau)=\mathbf{1}[g]\cdot\mathbf{1}[r_i=1\ \forall i]\cdot(0.4+0.6\cdot\frac{s}{6})$：$g$ 为审计判定（乘法否决），$r_i$ 为模块通过率（全有全无），$s$ 为无反例验证器数（线性计分）。

技术新颖性

新颖性有四层。其一，问题命名与形式化：把行为评测对迁移盲视形式化为奖励最大值落在空 diff 上的数学事实（$\mathrm{rate}(R_A;T)=1$ 恒成立），并区分它与奖励黑客——这里没有漏洞可钻，是规则结构看不见迁移，修复必然是行为之外的第二证据源加否决权。其二，三阶段漏斗的证据设计：三个阶段在 520 次运行上过滤的群体几乎不相交——30 次靠跳过迁移保住行为（仅第一阶段拦住），252 次完成迁移却破坏行为（仅第二阶段拦住），88 个双过提交中 60 个被验证器击破（仅第三阶段拦住），证明每道关卡都在度量不同的东西。其三，智能体验证的对抗架构：验证器在提交后运行、对迁移智能体不可见、只认可执行反例、复现三次排除 flaky，消融数据（撤掉两个 opus 验证器后接受数从 28 升到 46）证明面板强度本身就是评分的组成部分。其四，对评测器自身的元评测：裁判三次采样一致性（96.3% 全票）、与人类标注对比（89.7% 一致，$\kappa=0.795$）、裁判是否偏袒同家族的反向检验，都属基准论文中少见的严格度。

**Figure 2**: On the left, what the agent sees: ... On the right, the three-stage evaluation it never touches

**Figure 4**: The four kinds of submission Stage I has to tell apart

实验结果

总榜：520 次评分运行（8 模型、26 配置）中仅 28 次（5.4%）通过全部三阶段，13/20 个任务无模型解出；均值仅 13.44/100，而到达第三阶段的 88 次均分 79.43，难在第三阶段。最强配置 claude-opus-5（xhigh）47.0 分、5 次接受居首，其后 gpt-5.6-sol 28.5。漏斗：340 次（65.4%）过第一阶段，118 次（22.7%）全过固定检查，都过者仅 88 次。两种能力反向失配：30 次靠不迁移守住行为检查（盲视），252 次完成迁移却破坏行为，为前者八倍多。最后 1% 的鸿沟：过审计的 340 次中 58% 达 99%，但仅 26% 全对，140 次中位差 12.5 条检查。第三阶段杀伤力：88 个全过提交中 60 个（68.2%）被找到反例，平均只顶住 3.94/6 个验证器，反例中位 17.0 分钟。分类：构建工具链 31.4 分、平台移植 17.2、框架重写 12.0、语言重写 5.6；工具链类前两阶段通过率最高（80.8%/54.0%）但第三阶段存活率最低（17.6%），框架类正相反（18.9% 对 56.0%）。

**Table 1**: Composition of the SWE Refactor Bench task set

**Table 2**: The three-stage funnel: where each of the 520 runs stops

**Table 3**: Behavioural pass rate, score and cost for the same runs

**Table 4**: Summary by debt class, pooling all 26 configurations

**Table 5**: Agent success varies across stages and migration categories

**Table 6**: Task-by-Task Comparison of Migration Audit and Independent Human Annotation

**Table 7**: Positioning against related benchmarks

**Figure 3**: (a) Where each model sits on two axes ... (b) The same two axes, per task, with marker area the number of accepted submissions

**Figure 5**: (a) Reaching 99% is common; reaching 100% is not ... (b) 100% on the tests is still not enough

**Figure 6**: Break rate of each of the six verifiers

查看结构化数据

任务	指标	本文	基线	提升
全仓库行为保持型迁移（20 个任务，覆盖语言/框架/平台/构建工具链四类）	三阶段综合得分（0-100，公式见方法）	最佳配置 claude-opus-5（xhigh）47.0 分，5/20 次接受；全部 520 次运行均值 13.44 分	无直接可比基准（表 7 显示 SWE-bench/MigrationBench 等均无迁移判据与智能体验证）	首个同时具备栈变更、迁移判据、智能体验证三维度的基础设施迁移基准
迁移完成度（Stage I 迁移审计）	通过率	340/520 = 65.4%	仅行为测试评测下该维度不设防（118 个满分提交中含从未迁移者）	拦截全部 30 个盲视提交，避免行为评测给空 diff 满分
行为保持（Stage II 固定行为测试）	全部 130,118 条检查通过的比例	88/340 = 25.9%（在通过审计的运行中）；行为通过率均值为 22.7%	58% 的运行能到 99%，36% 能到 99.9%	暴露 35 个已达 99.9% 的运行在最后一步失败
隐藏行为差异（Stage III 智能体验证）	六个验证器均未找到反例的比例	28/88 = 31.8%	仅固定测试评测下该维度不存在	60 个提交（68.2%）在一小时内被找到可执行反例，中位耗时 17.0 分钟

局限与改进

作者承认的局限有四点。第一，实验建立的是这 20 个任务上的能力缺口，并不对一切迁移项目的内在难度排序——任务选择本身有偏。第二，评分是评测面板的属性而非提交的内在属性：撤掉两个最强的 claude-opus-5 验证器，接受数会从 28 升到 46，因此接受只意味着挺过当前能调集的最强对手；随模型进步，同一套任务会被打得更严，跨时间分数不可比。第三，智能体验证是形式化验证的近似：跨语言整仓库重写不提供两侧可关联的语义，翻译验证、差分符号执行和经验证的编译器都做不了，反例是证据的下限而非等价性证明。第四，迁移审计裁判有方向性误差——与人类标注对比显示 16 个分歧中 14 个是裁判过严，可能把至多 2 个真迁移误判为零。我的补充观察：130,118 条固定检查全部录制自原系统，本质上只能覆盖想到过的行为，而第三阶段验证器自身水平（两个 opus 占击破率大头）会直接抬高或压低全榜分数；此外每任务平均六千多条检查的录制成本和 262 小时总预算的评估成本都相当高，社区复现和扩容门槛不低。

独立分析的弱点

独立分析出四个弱点。第一，验证器面板强度决定分数线：两个 claude-opus-5 验证器击破率（55.7%/53.4%）是其余四个（21.6%-26.1%）的两倍多，论文自己承认撤掉它们接受数会从 28 涨到 46——榜单一半的信号来自两个特定模型，评测结果与验证器供应商强耦合。改进方向：报告跨验证器面板的得分区间，或定期用当时最强模型重跑历史提交做时间校准。第二，评分对接近完成完全不敏感：340 个过审计的运行中 58% 达到 99% 却拿零分，只按 0.4 门槛一刀切。改进方向：在主榜之外提供连续分数带供诊断。第三，迁移审计依赖单个裁判模型（gpt-5.6-sol），虽然三次采样把 2:1 分歧压到 3.7%，但 10.3% 的过线运行存在险胜判据，且裁判过严的系统性偏差（16 个分歧中 14 个）未被校准。改进方向：引入第二个异构裁判交叉验证，对险胜判据设人工复核通道。第四，20 个任务规模太小，每任务仅 26 次运行，单个任务噪声即可显著移动均分，且 13/20 无解说明难度过度集中在当前模型能力之外。改进方向：扩充任务池并按难度分层报告，或引入任务内自适应时间预算。

未来方向

作者在结论中指出：进展的度量不在于智能体写了多少代码，而在于做完之后系统是否还是同一个系统。基于论文成果可延伸的方向：其一，把第三阶段的对抗验证闭环回训练侧——六个验证器产出的可执行反例是天然的奖励信号或拒绝采样数据，可用来微调出迁移完成度与行为保持双优的编码智能体。其二，把三阶段协议推广到其他初始即绿的任务族，如依赖升级、API 弃用替换、许可证合规重写，这些场景同样存在盲视问题。其三，研究 99% 到 100% 的最后一步——140 次运行中位差 12.5 条检查、18 次只差一条，让智能体在提交前用录制式差分检查自验证自修复，可能以低成本显著提升通过率。其四，探索比智能体验证更强的语义级证据，例如对纯函数核心做受限的等价性定理证明，或在任务构造时即生成可差分的属性规约。其五，建立随模型演进自动更新验证器面板、并追溯校准历史分数的机制——既然验证器强度决定分数，这是基准长期可用的关键。

复现评估

复现评估如下。有利因素：论文信息密度高，表 1 列出 20 个任务的源仓库、行数区间、预算与判据/模块/检查数量，表 2 和表 3 给出全部 26 个配置逐运行分解，主页为 https://lab.einsia.ai/swe-refactor-bench；任务全部基于真实开源仓库（SQLite、zlib、libsodium、GraphHopper、cmark 等）。不利因素：其一，评估基础设施复杂——任务镜像（含两套工具链的离线环境）、独立评估镜像（130,118 条录制检查、136 条判据）、六验证器面板，缺一则三阶段协议不完整。其二，成本可观：总预算 262 小时智能体时间，opus-5 xhigh 每任务平均 74.9 美元、gpt-5.6-sol max 高达 143.5 美元，完整复现需数千美元级推理开销。其三，验证器模型会随时间失效，严格复现需冻结模型版本与提示词。其四，论文未明确说明代码与数据集的开源许可。综合判断：单任务缩小复现（验证盲视与漏斗形态）难度中等且性价比高；完整复现 520 次运行的三阶段评估难度高，依赖官方发布镜像。

SWE Refactor Bench：编码智能体能否完成长时程、全仓库级技术栈迁移 SWE Refactor Bench: Can Coding Agents Complete a Long-Horizon, Whole-Repository Stack Migration?