SWE Refactor Bench 精读
论文链接：arXiv:2608.23564 项目主页：lab.einsia.ai/swe-refactor-bench 发表时间：2026年8月 机构：Naver’s Lab（韩国）+ Einsia.AI + 清华大学——跨国产学研合作：Naver 出研究问题与评测方法学，Einsia.AI 出工程构建（86.7 万行代码的容器化迁移环境），清华参与任务设计与分析 领域标签：cs.SE（软件工程 Agent 评测）
一、论文背景
技术栈迁移是什么？ 把一个项目从旧技术栈搬到新的——C 改写为 Rust、Flask 换成 Starlette、POSIX 移植到 wasm32-wasi、Maven 切换 Gradle。这是真实软件工程中代价最高的一类工作：全仓库、长周期、且必须保持行为不变（迁移后的程序要和原来一样正确）。它恰恰也是"高级工程师才敢碰"的任务——完美对应"AI 能否承担资深工程工作"的考题。
现有基准的盲区在哪？ SWE-bench 系评测（含 Verified、Senior、Multilingual 等）测的都是"局部修 bug"：给一个 issue，改几行代码让测试通过。但迁移任务的结构完全不同——起点的测试套件本来就是全绿的。这意味着一个空 diff 提交（什么都不改）在任何行为测试下都是满分。论文把这个漏洞命名为 Blindness（盲区）：行为测试只能证明"没改坏"，永远无法证明"改了该改的"。这不是测试不够多的问题，而是评分维度缺失的问题——数学上，加多少行为测试都无法弥补。
为什么现在？ 编码 Agent 在 SWE-bench Verified 上已进入 70%+ 时代，头部模型逼近饱和，行业急需能区分"高级能力"的下一代表基准。同期出现的 SWE Atlas Refactoring（Scale Labs）、Senior SWE-bench（Snorkel）说明"重构/迁移"正是公认的下一个战场，但它们仍未正面处理 Blindness。
二、论文定位和关联工作
| 基准 | 任务形态 | Blindness 防御 |
|---|---|---|
| SWE-bench Verified | 单点修 bug（起点测试有红） | 不需要（失败测试天然区分改没改） |
| SWE Atlas Refactoring | 行为保持的重构 | 部分（任务构造上避免空 diff 得分，但无对抗验证） |
| SWE Refactor Bench | 全仓库迁移（起点测试全绿） | 三阶段协议：审计门 + 固定检查 + 对抗验证 |
本基准的差异化不仅在"更难"，而在于协议设计：三个阶段各拦截一种独立失败模式（见第六节），使 520 个 run 的失败可以被归因——这是"评测科学"与"任务难度堆叠"的本质区别。
三、问题定义
具体场景：判断一个编码 Agent 完成的迁移提交是否既"完成了迁移"（旧栈确实被替换）又"保持了行为"（原功能全部可用）。
抽象问题：当行为测试对两种假设（“完成了迁移"与"原样交回”）都返回通过时，如何构造能区分它们的验收函数？ 形式化：迁移任务起点 R_A 上任意行为套件 T⊆O 恒有 rate(R_A;T)=1，故空 diff 在任何 T 下得分 1 而迁移条件满足度为 0——唯一的解是在行为维度之外增加持否决权的第二检查维度。
四、问题解法
三阶段协议，每阶段针对一种失败模式：
4.1 Stage I：Migration Audit（迁移审计否决门）
LLM judge（gpt-5.6-sol）按仓库专属 criteria（262 条共 136 模块，如"构建脚本中不得再出现 Maven 坐标"）对提交逐一提问，每条独立判 3 次取多数；任一条失败则整个 run 记 0 分。这直接封死"跳过迁移保行为"的漏洞。为防止 judge 不稳定：三采样 96.3% 全一致；与两名人类评委一致率 89.7%（κ=0.795），16 个分歧中 14 个是 judge 过严。
4.2 Stage II：Behavioural Tests（固定检查）
从原状态录制 130,118 条检查（平均每任务 6000+ 条，覆盖 API 响应、文件安装树、构建产物等），all-or-nothing：全对才过。录制式检查比"移植测试文件"更完备——它不依赖原仓库测试作者想到了什么。
4.3 Stage III：Agentic Verification（对抗验证）
6 个独立编码 Agent 各获 1 小时：5 个各攻一个指定方向（C ABI 兼容/路由集/安装树等），1 个不限方向。规则：只能提交"原版通过、迁移版失败"的可执行反例，且须先对参考实现转绿、再复现 3 次。这补足固定套件"作者没想到"的盲区——实例：Gin 在空格或分号处截断 Content-Type 而 chi 只在分号截断；SQLite WAL checkpoint 后 native 删 -wal+-shm 而 WASI 版只删 -wal。
计分：S = 1(审计过) × 1(检查全过) × (0.4+0.6·s/6)。任务全部离线容器化（无网络），每任务 6-30 小时自主预算。
五、评估指标与实验证据
规模：8 前沿模型 × 26 模型-努力配置 × 20 任务 = 520 runs。
| 关卡 | 通过率 |
|---|---|
| Stage I 迁移审计 | 340/520（65.4%） |
| Stage II 固定检查（130,118 条） | 118/520（22.7%） |
| 达到 Stage III（双过） | 88/520 |
| 全部三阶段通过 | 28/520（5.4%） |
模型排名：claude-opus-5(xhigh) 47.0 > gpt-5.6-sol 28.5 > kimi-k3 19.5 > sonnet-5 15.0 > qwen3.8-max 10.5 = luna 10.5 > glm-5.2 6.5 ≈ dsv4-flash 7.0。
三类失败几乎不重叠：30 个 run 靠跳过迁移保行为、252 个完成迁移但破坏行为、60 个被反例攻破——证明三门槛各测一种独立能力。
关键反差案例：dsv4-flash 行为通过率 90.7%（仅次于 opus）但最终得分仅 7.0、零接受——仅看行为测试会严重高估；三个零接受的模型分别有 3-4 个全过固定检查的 run，仅按固定套件它们会以"满分"并列第一。
“最后 1% 鸿沟”：140 个 run 落在 [99%,100%) 区间，中位缺 12.5 条检查、18 个恰好缺 1 条——如 fw03 四个模型同止于 21768/21769（hash 路由 /#/ 差异）、build03 五个模型同止于 380/381（wheel METADATA 空描述）。长尾完美主义是当前 Agent 的共性短板。
为什么这套设计有证明力：三阶段漏斗 + 失败模式互斥性 + judge/人类一致率 + 无同家族偏袒验证（opus 验证器破 opus 稿 40.8% vs 他稿 65.0%，系稿质量差异而非偏袒）——每个数字都能被独立复核。
六、效果优势的根源解释
本基准的"效果"是失败归因能力，其根源在三阶段的结构设计：
- Blindness 的形式化（Stage I 必要性）：行为套件对空 diff 恒满分 ⇒ 评分维度缺失无法靠加测试弥补 ⇒ 必须有行为外的否决门。30 个 Blindness run 被审计门拦截。
- “迁移完成"与"行为保持"是反向能力：前者要求大规模改动（252 个 run 迁移成功但破坏行为），后者要求克制改动（30 个 run 克制过头没改）——单一阶段无法同时度量，双门漏斗（65.4%→22.7%）正是两能力的联合分布。
- 对抗验证补盲：88 个双过 run 中 60 个被 6-Agent 反例攻破——固定套件覆盖不到的语义边界（截断规则、文件系统副作用）只有"以 Agent 攻 Agent"能暴露；且反例出现中位时间 17 分钟，成本可控。
七、必要知识反推
- 领域知识层：四大类迁移（语言/框架/平台/构建工具链）的语义边界陷阱——不知道"Gin 与 chi 的 Content-Type 截断差异"这类领域细节，写不出 262 条仓库专属审计 criteria；测试录制技术（从运行态录制 6000+ 条检查而非手工编写）。
- 方法论知识层：基准有效性方法学（构造性偏置检测、judge 稳定性协议、对抗评估）；漏斗式评分设计。
- 工程知识层：86.7 万行代码的容器化离线环境构建；跨语言构建闭包验证（迁移后依赖树中不得残留旧栈）。
知识融合的关键节点：把"程序分析中的等价性检查"思想迁移到"Agent 评测”——迁移正确性本质是程序等价问题（行为等价 + 结构非等价），而程序等价不可判定，于是用"审计（结构）+ 测试（行为）+ 反例（对抗）“三面逼近——这是把理论不可判定性转化为工程可操作协议的漂亮示范。
八、论文中可以提取的通用性灵感
当验收函数对两种假设都返回"通过"时，必须增加第二维度（机制类）
- 证据：空 diff 骗过任何行为测试；三阶段协议使三类失败互斥可归因。
- 推广：任何"验收无法区分合格与不合格提交"的场景——审计（合规报告是否真实执行了整改 vs 只改了措辞）、教育（作业是否真理解 vs 抄袭改写）、安全（系统是否真修复 vs 绕过检测）——都需构造否决性第二检查。
“完成改动"与"保持不变"是两种独立能力，需分开度量（机制类）
- 证据：252 个 run 改了却改坏、30 个 run 没改却保真——两种失败几乎不重叠。
- 推广：组织变革管理（推动变化的能力 vs 保护存量的能力）、产品迭代（加功能 vs 不破坏存量用户流程）都应分设考核线，混在一起会让"什么都不做的人"与"什么都敢改的人"同分。
对抗性验证暴露固定检查的盲区（信号利用类）
- 证据：60/88 个双过 run 被 6-Agent 反例攻破，反例命中固定套件覆盖不到的语义边界。
- 推广：红队安全测试、论文审稿中的"试图推翻结论"式审阅、质检中的"恶意用户模拟”——投入少量对抗性资源，收益远高于等量增加固定检查。
最后 1% 的鸿沟是共性短板（现象类）
- 证据：140 个 run 卡在 [99%,100%)，18 个恰好差 1 条检查。
- 推广：自动化系统在"接近完成"阶段的边际成本急剧上升是普遍规律（自动驾驶边缘案例、数据清洗长尾），规划时应对最后 1% 预留不成比例的资源。