SWE-Bench ProMax：面向大规模多语言代码重构的智能体基准 SWE-Bench ProMax: Benchmarking Agents on Large-Scale Multilingual Code Refactoring
专家策展的七语言大规模重构基准，最佳模型通过率仅41.2%，跨文件协同是智能体瓶颈
前置知识
SWE-bench 与仓库级基准评测
SWE-bench 把真实 GitHub issue 变成仓库级考题：给出 Docker 化的仓库快照与问题描述，智能体自主修改代码，以全部测试通过判定“解决”，指标为解决率 $\text{Pass@1} = \frac{N_{\text{resolved}}}{N_{\text{total}}} \times 100\%$。其衍生版本沿多语言（Multi-SWE-bench）、更长时程（SWE-bench Pro）、防污染（SWE-bench Live）等方向演进。
本文是对 SWE-bench 系统性缺陷（饱和、测试缺陷、单文件为主、数据污染）的回应，不熟悉原版设定就无法理解 ProMax 的设计取舍与结果对比基线。
代码重构
在不改变程序外部行为的前提下重组内部结构，是工业界最高频的开发活动之一，也是管理技术债务的关键手段。与修 bug 不同，重构的正确性由“行为保持”定义，改动常跨越调用点、配置、文档、测试夹具等大量文件，考察跨文件一致性与对行为不变量的理解。
本文论证重构是比孤立 bug 修复更真实的长时程试金石，任务域选择与“行为保持”这一定义直接决定了基准的构建流程与评测协议。
Agent Scaffold（智能体脚手架）
脚手架是包裹底层模型的运行时框架，决定模型如何与仓库交互。mini-swe-agent 提供极简的观察-思考-行动循环（文件查看/编辑、搜索、bash 执行）；OpenHands 提供更丰富的运行时（沙箱命令执行、结构化文件编辑工具）。本文统一设每实例 300 步、$10 成本上限。
同一模型在不同脚手架下表现差异巨大（GPT-5.2 从 21.8% 到 41.2%），这是正确解读主结果表与“脚手架消融”结论的前提。
过窄/过宽测试与基准缺陷
过窄测试把实现细节（而非行为结果）写成断言，会拒绝功能正确的解法；过宽测试检查问题描述中未声明的行为，使“按规格完成”也可能不过测。对 SWE-bench Verified 的审计发现近 60% 未解决实例存在此类缺陷（35.5% 过窄、18.8% 过宽）。
测试质量治理是本文的核心贡献之一：每条实例的测试都经人工审查剔除这两类用例，理解该概念才能读懂其策展流程的动机与价值。
研究动机
现有仓库级基准正同时遭遇饱和与质量双重危机。难度上，前沿智能体在 SWE-bench Verified 上的解决率已超过 75%，头部系统差距持续收窄，而 86% 的 Verified 实例只需修改单个文件，与真实工程中动辄跨数十个文件的任务严重脱节；OpenAI 与 Cursor 都指出“项目级重构”才是智能体的核心长时程场景，但现有基准几乎不覆盖它——RefactorBench 仅 100 条手工任务、只限 Python 且平均仅 4.3 个修改文件，SWE-Refactor 的 1,099 条实例只覆盖 Java 且测试无人工验证。质量上，近期审计发现近 60% 的未解决实例存在测试缺陷：35.5% 过窄（拒绝正确解法）、18.8% 过宽（检查未声明需求），促使 OpenAI 弃用该基准；问题描述含糊、公共仓库来源导致的数据污染（前沿模型能逐字复现训练数据中的金补丁）进一步侵蚀分数与真实能力的关联。此外，多语言扩展仍以 Python 为中心，Rust 所有权模型、C 手动内存管理等范式差异下的泛化能力无从考察。
本文的目标是本文要构建一个专家策展、多语言、大规模的代码重构基准 SWE-Bench ProMax，系统性地回应上述三重缺口。具体目标有三：其一，通过逐条人工策展根治质量缺陷——问题描述从零重写为精确、无歧义、自洽的规格说明，测试套件经人工审查剔除过窄与过宽用例，并验证描述构成金补丁的充要条件；其二，通过复杂度过滤（剔除单文件、行数过少、模式过简的任务）保证难度，使保留的 170 条实例平均需修改 11.4 个文件、261.6 行代码，覆盖 Python、Java、TypeScript、Go、C、C++、Rust 七种语言和 70 个仓库；其三，在统一协议（每实例 300 步、$10 成本上限）与两种脚手架下评测 6 个前沿模型，量化当前智能体在大规模重构上的真实水平、成本效率与失败模式，确认基准的区分度与未饱和性。
与已有工作不同的是，本文的独特切入是把“评测质量”而非“数据规模”当作一等公民，并把代码重构确立为独立的基准任务域。已有的基准要么全自动挖掘、策展有限（SWE-bench），要么规模可观但单语言或无人工验证（RefactorBench、SWE-Refactor）；Table 1 显示此前没有任何基准同时具备执行评测、仓库级、多语言、重构、平均修改超 5 文件、专家策展六个属性。ProMax 对每条实例执行四步人工流程（提交分析、质量过滤、问题重写、人工终审），并把“充要条件”作为可检查标准：正确解法应满足描述，描述也不应容忍偏离规格的解法。同时它把规模本身变成难度来源（30% 实例修改超 10 个文件、32% 超 200 行），从 29,782 个候选中仅保留 170 条（约 0.57%）的极高淘汰率本身就是对“基准价值在可靠性而非数量”这一立场的宣示。
核心方法
直觉上，一个可靠且难的重构基准要同时回答两个问题：任务是否“真”（描述、测试、金补丁三方对齐）且“难”（需要跨文件大规模协同、行为保持）。技术路线是一条三阶段流水线。阶段一数据收集：用 GitHub API 筛选 star 不低于 500、有开源许可证、主语言占比不低于 80% 的活跃仓库，抽取 2025 年 1 月之后、提交信息含 refactor 且不含 bug fix、同时改动测试与非测试文件的提交，得到 29,782 个候选。阶段二环境构建：为每个候选提交自动构建 Docker 环境（借助 SWE-Factory 等工具），把仓库克隆到重构前状态并安装全部依赖，应用金补丁后运行完整测试套件，环境无法建立或测试不通过的实例被丢弃。阶段三过滤与重写：专家在 LLM 辅助下分析提交 diff，剔除复杂度不足的任务，审查并移除过窄/过宽测试，把简略的提交信息从零重写为精确规格，最后人工终审。最终仅 170 条实例入选，评测协议为结果驱动的 $\text{Pass@1}$：只看最终仓库状态能否通过全部测试。
核心创新有三层。其一，充要条件验证：每条问题描述都被验证为金标准补丁的必要且充分条件——正确解法应满足描述，描述也不应纵容偏离规格的解法。这直接回应了过窄测试拒绝正确解、过宽测试纵容错误解两类缺陷，使“描述-测试-补丁”三方对齐从口号变成可检查的流程。其二，把复杂度作为筛选维度：与多数基准“多多益善”相反，本文主动剔除单文件、低行数、模式简单的任务，让规模（平均 11.4 个文件、261.6 行、最大 182 个文件）成为难度来源，从而测到智能体的跨文件协同与长时程规划能力。其三，结果驱动的评测协议：只验收最终仓库状态是否通过全部测试，不约束中间命令与步骤，忠实模拟真实工程验收。与 RefactorBench（手工构造、单语言）和 SWE-Refactor（自动验证、无人工测试审查）相比，ProMax 首次把真实提交、环境验证与逐条专家策展三者结合。
方法步骤详情
第一步（提交分析）：输入是通过环境验证的候选提交及其完整 diff，专家借助 LLM 总结变更、识别受影响组件，理解重构的范围、意图与结构影响。第二步（质量过滤）：剔除单文件、修改行数过少或模式过简的任务；逐条审查测试套件，移除强制实现细节的过窄测试和检查重构范围之外行为的过宽测试。第三步（问题重写）：输入是原始提交信息（通常简略含糊，如“refactor auth module”，且引用智能体不可得的内部上下文），专家借助 LLM 从零重写为自洽规格，明确哪些组件要改、预期变换是什么、必须保持哪些行为不变量，并验证其为金补丁的充要条件。第四步（人工终审）：确认描述完整规定重构、测试当且仅当重构正确时通过、无未声明需求。最终数据构成：29,782 候选中保留 170 条，来自 70 个仓库；语言分布 Python 29、TypeScript 28、Java 26、Go 23、C++ 22、Rust 22、C 20；金补丁平均 11.4 个文件/261.6 行/8,179.5 token，测试补丁平均 4.5 个文件/185.5 行，合计平均 15.9 个文件（最大 244）。
技术新颖性
技术新颖性体现在基准工程而非模型侧。首先，“专家策展 × 大规模”的范式组合：对照 Table 1，多语言基准（如 68 名标注者的 Multi-SWE-bench）与重构基准（RefactorBench、SWE-Refactor）此前从未同时具备人工审查与大规模跨文件复杂度，ProMax 是六维度全占的首个基准。其次，把对既有基准的失败模式审计（35.5% 过窄、18.8% 过宽）转化为可操作的过滤标准与充要条件验证流程，使质量改进可复现、可迁移到其他基准。再次，用行为保持性统一定义重构正确性，终结了以往重构评估各说各话（代码坏味计数、可编译性、对齐分数）无法横向比较的局面，提供标准化、执行驱动的评测；此前实证研究显示智能体自主发现所需重构的对齐率仅 7.7%，恰恰需要这样的统一标尺。最后，轨迹级失败分析（修改文件数 CDF 对比金补丁、成功/失败实例交互轮数对比）为“跨文件协同是瓶颈”提供了量化证据链，比单一解决率数字更具诊断价值。
实验结果
基准远未饱和：最佳模型 GPT-5.2（OpenHands）仅解决 41.2%，远低于前沿智能体在 SWE-bench Verified 上 75%+ 的水平。成本与性能不成正比：最贵的 Claude Sonnet 4.6（$4.77/实例）仅 38.8%，开源 GLM-5 以 $0.24 达 36.5%，Qwen3.5 36.5%、Kimi-K2.5 32.9%，与旗舰差距在 5 个百分点内。脚手架影响显著：除 Gemini-3-Pro 外所有模型换用 OpenHands 后大幅提升，GPT-5.2 从 21.8% 翻倍至 41.2%。分语言无模型全面领先：GPT-5.2 最佳于 Python（48.3%）与 C（75.0%），Claude Sonnet 4.6 最佳于 TypeScript（53.6%）与 Rust（63.6%），GLM-5 领先 Java（34.6%），Kimi-K2.5 最佳 Go（43.5%），Qwen3.5 最佳 C++（54.5%）。失败分析最具洞察：智能体修改文件数的 CDF 在约 10 个文件处达 90%，金补丁要到约 20 个文件——主导失败模式是不完整重构，即核心文件改了却未传播到外围调用点、配置与测试夹具；Qwen3.5 步数最多却垫底，印证无产出的探索循环适得其反。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 大规模多语言代码重构（170 实例，7 语言，70 仓库） | Pass@1 解决率（最高成本上限 $10/实例） | 基准本身；最佳模型 GPT-5.2（OpenHands）41.2% | 同一批前沿智能体在 SWE-bench Verified 上超过 75% | 领先模型在 ProMax 上低 30+ 个百分点，确认基准难度显著更高且未饱和 |
| 开源权重 vs 闭源模型的成本效益 | 解决率 / 每实例平均成本（OpenHands） | GLM-5 36.5% @ $0.24；Qwen3.5 36.5% @ $0.78；Kimi-K2.5 32.9% @ $0.72 | Claude Sonnet 4.6 38.8% @ $4.77；GPT-5.2 41.2% @ $3.60 | 以约 1/20 的成本逼近闭源旗舰，解决率差距不超过 5 个百分点 |
| 脚手架消融：mini-swe-agent vs OpenHands | Pass@1 解决率 | GPT-5.2 在 OpenHands 下 41.2% | GPT-5.2 在 mini-swe-agent 下 21.8% | 换用更丰富运行时近乎翻倍；除 Gemini-3-Pro 外全部模型均明显提升 |
| 分语言表现（以 C 语言子集为例，20 实例） | Pass@1 解决率 | GPT-5.2 达 75.0%（OpenHands） | 同模型在 Java 子集上仅 19.2%（Java 为最难语言，全场最高 34.6%） | 语言间方差显著，无单一模型全面领先，提示语言特化的互补性 |
局限与改进
作者未专设局限章节，但从文中可推断出几点：其一，规模仅 170 条，远小于 SWE-bench 系列的数千条，分语言后每类只有 20-29 条样本，一两个实例的波动即可改变语言排名（TypeScript 上 0.0% 对 53.6% 的巨大方差部分源于此）；其二，只评测 6 个模型与 2 个脚手架，且每实例 $10 成本与 300 步上限可能截断 244 文件级任务的求解空间；其三，Pass@1 是二值指标，“改对 200/244 个文件”与完全未动同记 0 分，掩盖了跨文件协同的渐进能力；其四，虽然重写了问题描述并审查了测试，实例仍源自公开 GitHub 提交，模型可能在预训练中见过重构后的最终代码库状态，污染只能缓解难以根除；其五，人工策展成本高昂（29,782 淘汰至 170），论文未披露标注人数与工时（对比 Multi-SWE-bench 的 68 人），持续扩充的成本结构不明；其六，测试套件只覆盖行为正确性，对代码质量、可维护性等重构的内在目标没有评价维度。
独立分析的弱点
弱点一：样本量与语言平衡。170 条实例分到七种语言每类仅 20-29 条，语言级结论（谁最强于 Rust/Java）统计置信度低，改进方向是分层扩充每语言样本并报告置信区间。弱点二：二值 Pass@1 忽略部分进度。一个修改了 200/244 个文件的方案与完全未动同样记 0 分，而轨迹分析恰恰表明智能体具备部分跨文件能力，改进方向是引入部分得分（如修改文件相对金补丁的召回率、测试通过比例）。弱点三：金补丁中心化。充要条件验证以人类金补丁为锚，可能系统性惩罚合法但路径不同的重构方案，且测试通过与否无法衡量重构是否真的改善了设计质量——这正是重构的初衷。弱点四：预算截断与敏感性缺失。$10/300 步上限对超大规模实例可能不够（Claude Sonnet 4.6 平均已花 $4.77、117.9 步），论文未做上限敏感性分析。弱点五：污染缓解不彻底。重写描述不改变仓库与 diff 本身，模型仍可能记住提交后的代码；改进方向是只收录晚于模型训练截止的提交并做逐字记忆检测。弱点六：静态快照无更新机制，饱和问题会随时间重演。
未来方向
作者方向：结论把“持续跨文件协同是根本瓶颈”作为核心发现，自然延伸是针对性能力建设——仓库级长期记忆、跨文件依赖追踪与全局规划机制，以及能显式枚举受影响外围文件（调用点、配置、文档、测试夹具）的智能体架构；失败轨迹分析还提示应抑制“编辑-回滚”式无产出探索循环。可延伸方向：其一，把充要条件验证流程半自动化，降低策展成本，实现基准滚动更新（类似 SWE-bench Live）以对抗饱和与污染；其二，引入过程感知指标，用修改文件集合与金补丁的重叠度给出部分得分，并研究其与人类评审的相关性；其三，扩展到更多语言（Kotlin、C#、Swift）与更多重构类型（架构级迁移、API 演进、依赖升级）；其四，利用“无单一模型全面领先”的语言互补性研究模型路由或集成策略，用低成本开源模型覆盖其优势语言；其五，把失败模式分类（不完整重构、无产出探索）转化为训练时的过程奖励信号，用于改进智能体本身。
复现评估
复现条件总体较好。数据集已在 HuggingFace 开源（swe-bench-promax/SWE-Bench-ProMax），每条实例自带预构建且经人工验证的 Docker 容器（重构前仓库状态 + 全部依赖），评测无需额外环境配置；两个脚手架 mini-swe-agent 与 OpenHands 均开源，论文发表于 COLM 2026，三阶段流程与评测协议描述较细。主要门槛在费用：完整复现主表需 6 个模型 × 2 个脚手架 × 170 实例，按每实例 $0.10-$4.77 的平均成本估算约需数千美元 API 费用，且论文未说明 Pass@1 的重复采样次数，随机性控制需自行设定。最不可复现的是策展环节本身：质量过滤、测试审查、问题重写与终审都依赖领域专家判断，标注团队规模与工时未披露，第三方难以复现出同等质量的扩展版。总结：对普通研究者，复现评测表格容易（数据+容器+开源脚手架），复现或扩建基准本身则难。
论文图表
双柱状图对比 SWE-Bench ProMax、SWE-bench Pro 与 SWE-bench Verified 的每实例修改文件数（≤1/2-3/4-5/6-10/>10）与代码行数（≤20/21-50/51-100/101-200/>200）分布：ProMax 有 30% 的实例修改超过 10 个文件、32% 超过 200 行代码；而 SWE-bench Verified 86% 的实例只修改单个文件。
这是动机部分的定量核心：一张图证明现有基准的“小修小补”与真实生产级重构的规模鸿沟，直接解释了 ProMax 为何更难、为何能区分前沿模型。
展示实例 nasa/fprime#3422（C++，244 个文件，+591/−514 行）的修改文件摘录，涉及 Autocoders、Drv、Fw、Os、Svc 等子系统：任务是把 244 个文件从单体头文件 BasicTypes.h 迁移到新的统一入口 FPrimeBasicTypes，同时保持运行时行为完全一致。
把“平均 11.4 个文件”的抽象统计具体化为可感知的真实案例，直观呈现大规模重构任务的形态与跨文件依赖的广度，是理解任务难度的最佳入口。