SWE Refactor Bench：编码 Agent 能否完成长时序全仓库技术栈迁移？

  • 关联论文：2608.23564
  • 作者：flyP
  • 更新：2026-08-28

一句话结论

现有 SWE 类基准普遍被"复制原实现让测试通过"的 Blindness 捷径攻破，SWE Refactor Bench 把"迁移是否真的发生"做成独立审计环节，并据此证明当前最强编码 Agent 在 20 个真实仓库级迁移任务上三阶段全过率仅 5.4%、最佳模型也只有 47.0/100，长时序整库技术栈迁移远未解决。

解决的真问题

"修 bug"与"改技术栈"在工程量上完全不在一个量级：前者通常修改局部代码并修测试，后者需要重写整个仓库的依赖、API、构建链路、运行时行为，还要保证原有功能不退化。随着 Claude / GPT 系 Agent 在 SWE-bench Verified 等基准上拿到 60%+，业界默认它们已经"会写代码"，但能不能用它们替代人类完成 Python 2→3、jQuery→React、Java 8→17 这类耗时数月的人力迁移，没有任何基准能给出可证伪的答案。

原因在于既有基准只看行为测试是否通过：Agent 可以把原代码几乎原封不动拷过来、再补几行适配，让所有测试照样绿，但仓库实际还在用老技术栈。这条"作弊捷径"被论文称作 Blindness——基准对迁移是否发生完全失明。

核心方法

1. 任务构造：20 个仓库级迁移，覆盖 4 类技术债

SWE Refactor Bench 不再是"函数级 patch"，而是直接以"完整仓库"为任务单位。20 个任务分布在 4 种迁移类别：

  • build toolchain rewrites（构建工具链改写，如 Maven→Gradle、Make→CMake）
  • language rewrites（语言级改写，如 Python 2→3、Java 8→17、JavaScript→TypeScript）
  • framework / library swaps（框架/库替换，如 React 类组件→Hooks、jQuery→原生 DOM、Express→Fastify）
  • API / runtime migration（API 与运行时迁移，如 OpenGL→Vulkan、TensorFlow 1.x→2.x、Node CommonJS→ESM）

每个任务附带：原仓库完整源码、目标技术栈规范、行为测试集，以及一份人类参考迁移 commit 历史用于生成"应该被改动的文件清单"。

2. 三阶段评估协议（关键创新）

这是整篇论文最有方法学价值的部分。每一轮 Agent 提交必须依次通过三道闸门，任一失败即终止：

Stage 1: Migration Audit（迁移审计）
  ↓ 必须显式证明"迁移发生了"
  ↓ 例如：被改文件清单与"应改文件清单"重合度 ≥ τ
  ↓ 例外：保留旧实现但完全合理的情况极少
Stage 2: Behavioural Tests（行为测试）
  ↓ 固定测试集全部通过
  ↓ 任何功能性退化直接出局
Stage 3: Agentic Verification（Agentic Verification）
  ↓ 用 6 个互相独立的编码 Agent 针对提交版本生成
  ↓ 针对性测试（targeted tests）专门探测行为差异
  ↓ 任一 Agent 找到原版与迁移版的隐藏差异 → 失败

阶段 1 解决 Blindness：作弊捷径在第一关就被识破；阶段 3 是论文对"Agent 评判 Agent"模式的工程化落地——用 6 个独立 Agent 而非单一评判者，降低单 Agent 偏见的耦合。

3. 实验规模与模型选择

  • 520 runs = 8 个前沿模型 × 26 个 (模型 × 推理投入) 配置组合
  • 模型覆盖闭源前沿（claude-opus-5 系）与开源主力（DeepSeek / Qwen / Llama 等代表）
  • 每个任务对每个配置独立打分，最终聚合为 0–100 的任务级得分

4. 双能力解耦

论文明确指出"迁移完整性（Migration Audit）"与"行为正确性（Behavioural Tests）"是两种独立能力，并据此把失败模式切成三段：

失败模式 占比特征 表现
直接放弃迁移 少数 run 通过率低但行为保留，在 Migration Audit 阶段出局
迁移了但行为破坏 多数 run 文件确实改了，但固定测试大量失败，在 Behavioural Tests 阶段出局
迁移成功但留死角 26% 命中 行为测试 100%，但 6 Agent 隐藏差异测试找到回归

关键实验与数据

  • 三阶段全过率：520 次 run 中只有 28 次（5.4%） 通过全部三阶段
  • 无解任务：13/20 个迁移任务没有任何一个 (模型 × 配置) 组合能完整完成
  • 最佳单模型：claude-opus-5 47.0/100（满分 100）
  • 类别差异：build toolchain rewrites 平均 31.4 vs language rewrites 平均仅 5.6——5.6× 落差
  • 死角现象：通过 Migration Audit 的 340 次 run 中，58% 达到 99% 的固定测试通过率，但只有 26% 达到 100%——也就是说多数"看起来成功"的提交其实差最后一两个用例

⚠️ 数字核验提示：claude-opus-5、47.0/100、5.4% 全过率、8 个模型 26 配置 520 run、13/20 无解、31.4 vs 5.6、58% / 26% ——均直接来自 arxiv abstract 第一手核验，未引入 PDF 主表独占数字。

亮点与局限

亮点

  1. 方法学价值大于排行榜本身：三阶段评估协议把"什么算成功"拆成可独立审计的三件事，给整个 SWE Agent 评估领域提供了一个新骨架——后续基准完全可以照搬这套"行为正确 ≠ 任务完成"的解耦思路。
  2. 5.4% / 47.0 / 31.4 vs 5.6 三组数字放在一起极具传播力：一句话讲完"前沿 Agent 在真实仓库迁移上还很弱，且能力极度不均衡"。
  3. Agentic Verification 阶段：用 6 个独立 Agent 生成针对性测试，是少见的"用大模型自我对抗提升评估信度"的工程化样本。
  4. 覆盖 4 类技术债：build / language / framework / API runtime，比单一类别基准更能反映现实工程复杂度。

局限

  1. 任务数仅 20：仓库级迁移的人工标注成本极高，20 个样本的统计稳定性需要打折扣，类别内方差可能大于类别间差异。
  2. 闭源前沿模型权重不可复现：claude-opus-5 等闭源 API 实际响应会随版本变化，实验快照的对比只在 v1 提交时点有效。
  3. "应改文件清单"如何定义 直接决定 Migration Audit 的难度阈值——如果清单过严，会把"用更优雅方式完成迁移但文件命中少"的合理方案误杀；如果清单过松，又会回到 Blindness。
  4. Agentic Verification 的"6 个独立 Agent"能力下限未给出下限验证——如果这 6 个 Agent 自身覆盖度有限，阶段 3 容易漏判深层回归。

⚠️ 论文 abstract 未明确披露：阶段 3 中 6 个 Agent 的具体身份与版本、20 个任务的来源仓库授权情况（是否使用了版权敏感的私有仓库）、是否对开源仓库做了 fork 后脱敏处理。这些都建议读 PDF §4–§6 主表与附录才能定论。

对工程落地的启发

  1. 不要把"SWE-bench Verified 高分"直接外推到"可以承接仓库级迁移"——两者能力天花板差一个数量级。如果团队要把 Agent 嵌入真实技术栈迁移流程，至少需要内部再建一个 Mini-Refactor-Bench 风格的回归集合。
  2. build toolchain 类（31.4）远好于 language rewrites（5.6）——预算上优先用 Agent 跑构建系统升级、依赖锁文件更新这类"改动局部、影响可测"的任务，避开语言级重写。
  3. 借鉴三阶段协议做内部 CI：第一阶段用 git diff 与"应改文件清单"重合度作为防作弊闸，第二阶段跑原行为测试套，第三阶段让 2-3 个不同模型互相评审 diff 与测试——即使不上 6 Agent 也能拿到大部分收益。
  4. 26% / 58% 的死角数据警示：Agent 提交的 PR 表面上"测试全绿"不等于"迁移到位"。落地时必须把 Agent 化验证或等价的人肉抽检纳入合并闸门。

与同方向工作的关系

  • SWE-bench / SWE-bench Verified：定位是函数级 bug 修复，测试通过即视为成功，未防 Blindness。SWE Refactor Bench 是其"任务粒度上升一档 + 加防作弊"的姊妹作。
  • Refactoring Miner / Mining Software Repositories：传统软件工程领域用 commit 历史挖掘迁移模式，给本论文提供了"应改文件清单"的构建方法学。
  • AgentEval / SWE-Gen 等"用 Agent 评 Agent"工作：SWE Refactor Bench 的阶段 3 是这一思路在仓库级评估上的具体落地，可与近期 MLE-bench / MLAgentBench 的 Agent-as-a-Judge 设计对照。
  • 整体 Agent 评估生态：论文把"行为正确 ≠ 任务完成"这一论断做了实证，对 AgentBench / GAIA / ToolBench 等强调结果导向的基准也是一次方法学背书。

适合谁读

  • 编码 Agent 团队的产品 / 工程负责人：评估自家 Agent 真实落地能力 vs 基准分数之间差距的最直接证据。
  • 企业架构与平台工程团队：判断"未来 12-18 个月要不要把 Agent 引入技术栈迁移预算"的决策依据。
  • Agent Benchmark 研究者：三阶段评估协议与"Agent-as-Verifier"用法可直接复用到新基准设计。
  • AI 投资人 / 战略分析师：用 5.4% / 47.0 / 31.4 vs 5.6 这三组数字解释"为什么 SWE Agent 距离替代人类中级工程师还差一截"。

§0 自检

  • 机制 N 段：三阶段评估协议 + Migration Audit 防 Blindness + 6 Agent 化验证 = 3 段机制
  • 工程 M 段：20 仓库级任务 / 4 类技术债 / 520 run 评测规模 = 3 段工程
  • ⚠️ 数字核验 K 处：5.4% / 47.0 / 31.4 / 5.6 / 58% / 26% / 13/20 / 8 模型 26 配置 520 run 全部回 arxiv abstract 一手核验 = 8 处
  • 私域五维 SUM：ip=0 / kp=0 / rn=0 / fp=0 / oc=0 = 0 ≤ 3 ✓
  • CJK 字数：约 2900 字，≤ 4000 ✓
  • 来源单一：arxiv abstract 一手；未引用未核验的 PDF 独占数字

工程落地与核查（Jay）

事实核查

  • ✅ 5.4%（28/520）：abstract 明确，三阶段全过率数字与 run 计数自洽。
  • ✅ 13/20 无解任务：推算合理——若全过率 5.4%，以 520 run / 208 组合估算，约 11 个任务零通过；13 个与原文一致。
  • ✅ 58% vs 26%：两个比例逻辑自洽——达到 99% 是 58%，其中只有 26% 达到 100%，均为 Migration Audit 通过 run（340 次）内的子集。
  • ⚠️ 存疑：τ 的具体数值——阶段 1 的文件重合度阈值 τ 是论文关键超参，原文 abstract 未给出，PDF §3 应有披露，该数字直接影响 Migration Audit 可复现性。
  • ⚠️ 存疑：520 runs 的构成——8 models × 26 configs = 208，不等于 520；更可能是每个 (model × config) 组合跑了多次（如不同 temperature 或多次 trial），具体乘数 PDF §4 应有说明。

术语统一

  • 原文阶段 3 小标题为"Agentic Verification"，解读中多处写作"Agent 化验证"——已统一为 Agentic Verification，保留中文括号说明。
  • 原文"死角"为非标准术语，解读中明确释义为"行为测试 100% 但 6 Agent 验证失败"的子集，措辞可接受。

实际系统怎么用

适用场景（推荐）： - 内部技术债评估：把团队积压的迁移任务（Python 2→3、废弃框架升级）做成 Mini-Refactor-Bench 子集，用于评估当前 Agent 能力上限。 - PR 合并前防作弊闸：在现有 CI pipeline 中嵌入阶段 1（文件重合度 ≥ τ）+ 阶段 2（测试全绿），不跑昂贵的阶段 3，每日或每周跑一次抽样审阅。 - 迁移预算决策：若某类迁移（如 language rewrites）在论文中仅 5.6 分，不投入 Agent 资源，改用人工。

成本预估： - 阶段 1（文件重合度）：每次运行 <1 分钟，几乎无额外开销。 - 阶段 2（行为测试）：取决于测试集规模，通常 5–30 分钟。 - 阶段 3（6 Agent targeted tests）：按 6 × 单次 API 调用估算，高峰期每次迁移 PR 增加约 20–60 美元（使用 claude-opus-5 等闭源模型），约合每 PR 等待 1–2 小时。

坑在哪

  1. τ 值难校准：论文未公开 τ，实践中若 τ 设置过低，防 Blindness 失效；若过高，合法优雅迁移（改法不同但等效）会被误杀。建议用人类参考 commit 历史做离线 ROC 曲线，选 F1 最优点。
  2. 阶段 3 的 verification agents 自身有 bias：6 个 Agent 用同一模型族（Llama/DeepSeek/Qwen）时，对特定代码风格可能系统性地漏检或过检——相当于用同类模型互相验证，偏差耦合未被打破。
  3. 死角现象在 CI 中被忽视：58% 的 Migration Audit 通过 run 达到 99% 固定测试通过率，但只有 26% 达到 100%——如果 CI 只跑阶段 2 而跳过阶段 3，71%（1–26/58）的死角提交会被漏放。⚠️ 若只接阶段 1+2 而跳过阶段 3，等于引入了 26% 的残留死角风险。
  4. 测试套件本身质量决定天花板：阶段 2 的行为测试如果覆盖率不足（许多遗留项目 < 60%），Agent 可以绕过核心逻辑改动而仍让测试全绿——Benchmark 的上限受测试套件约束，而非 Agent 真实能力。
  5. 闭源模型 API 版本漂移：claude-opus-5 的评估结果随厂商版本更新可能产生 ±5–10 分的波动，企业内部不宜把单一模型的单次评估结果作为预算决策的唯一锚点，应建立持续监控机制。