SWE-Bench ProMax：大尺度多语言重构基准上线，前沿模型最高仅达41.2%
SWE-Bench ProMax: Benchmarking Agents on Large-Scale Multilingual Code Refactoring
在过去一年多的时间里，以大语言模型驱动的自主软件工程 Agent（AI Coding Agents）迎来了爆发式增长。从自动化修 Bug 到端到端交付功能，各种在公开基准测试上刷榜的战报屡见不鲜。以业界最为知名的 SWE-bench Verified 为例，前沿模型的解决率（Resolve Rate）已经迅速突破 75%，各家头部闭源模型之间的差距被压缩到了极小的区间内。这种看似繁荣的现象给学术界和工业界带来了一种错觉：AI 程序员似乎很快就能接管真实的软件工程工作流。
ArXiv URL：https://arxiv.org/abs/2608.09802v1
然而，真实的软件开发远比目前的基准测试所呈现的要复杂。最近针对 SWE-bench Verified 的一项严肃审计暴露出了惊人的事实：在其所有未解决的测试任务中，近 60% 存在严重的测试套件缺陷。其中 35.5% 的测试用例过于严苛（Overly narrow），把完全正确的实现方式判定为失败；另有 18.8% 的测试用例要求过宽（Overly broad），暗中检验了任务描述中根本没有提到的外部需求。更致命的是，由于测试数据源自公开 GitHub 仓库，前沿模型甚至可以直接从预训练语料中原封不动地“背出”官方修复补丁（Gold Patch）。这一系列问题直接导致部分头部机构宣布弃用 SWE-bench Verified。当前的软件工程评估陷入了一个困境：现有基准正在迅速饱和，却无法真实衡量 Agent 在复杂、长程（Long-horizon）真实项目中的工程能力。
为了打破这种“虚假饱和”与评测质量低下的困境，来自清华大学、北京大学、上海交通大学、香港科技大学、新加坡国立大学、莫纳什大学、中国科学院大学以及抖音集团的研究团队，联合推出了全新的专家精选基准——SWE-Bench ProMax。该基准将目光锁定在更具工程挑战、却长期被评测领域忽视的领域：跨文件、大规模的代码重构（Code Refactoring）。全套基准涵盖 Python、Java、TypeScript、Go、C、C++、Rust 共 7 种主流编程语言，由真实开发提交精炼出 170 个高难度任务。实验表明，即便是在最强的 Agent 支架与最顶级的前沿模型加持下，目前最高的解决率也仅有 41.2%。这一结果清楚地证明：一旦脱离单文件小修小补的舒适区，当前的 AI 编码系统离真正的工程自主还差得远。
为什么代码重构是检验 Agent 的真正试金石
代码重构是指在不改变代码外部行为的前提下，对其内部结构进行调整与优化的工程过程。在工业级软件工程实践中，重构不仅是日常技术债务治理的核心手段，也是耗费资深工程师大量精力的工作。与孤立的漏洞修复（Bug Fixing）不同，代码重构具有极高的全局性与协调性要求。OpenAI 曾将“项目级重构”定义为检验长程、多上下文窗口 Agent 能力的关键场景；现代代码编辑器团队 Cursor 也在开发者洞察中指出，真实开发者的复杂工作流往往贯穿整个工程的数十个文件。
然而，现存的代码评测集严重偏离了这种工业现状。在 SWE-bench Verified 中，高达 86% 的实例仅仅修改了单一文件；整个补丁的修改规模往往只有寥寥数行。这种评测本质上更接近“局部代码填空”，模型只要准确定位报错点并做语法级替换即可得分。相比之下，SWE-Bench ProMax 的任务平均需要修改 11.4 个源码文件，代码修改量平均达到 261.6 行（对应超过 8,000 个 Token）。在任务分布上，有 30% 的任务涉及超过 10 个源码文件，32% 的任务修改量超过 200 行代码；若算上对应的测试文件，每个实例平均触碰 15.9 个文件。
论文中举出了一个极具代表性的案例：在 NASA 的 F’Prime 飞行软件框架中，一项将单体头文件拆分为全新统一定义入口的重构任务，要求 Agent 同时协同修改跨越自动化代码生成器、设备驱动、操作系统适配层、核心系统服务和构建配置的共计 244 个文件，并且在运行时必须维持完全一致的行为。面对如此庞大的工程图谱与级联影响，哪怕模型漏改一个宏定义或类型别名，整个构建流程就会彻底中断。这种对跨文件上下文追踪、长程依赖管理以及全局不变式保持（Behavioral Invariants）的严苛要求，正是当前单文件测试集完全无法模拟的硬核能力。
此外，现有评估长期存在语言生态单一的问题。绝大多数软件工程基准几乎完全由 Python 垄断，掩盖了不同编程语言范式下的特殊难题。SWE-Bench ProMax 覆盖了 7 大编程语言，不仅囊括了弱类型和动态类型的 Python，还深入到采用所有权与生命周期机制的 Rust、依赖显式内存管理的 C/C++、具备强类型系统与垃圾回收的 Java 和 Go，以及具备渐进类型的 TypeScript。不同的类型系统与构建工具链，直接把模型推向了真实世界中迥异的工程生态。
三阶段严格清洗：从 2.9 万个候选到 170 个黄金实例
基准测试的公信力不在于题目数量的堆砌，而在于评测机制的严密性与确定性。以往很多基准在从 GitHub 爬取数据后，仅依赖简单的自动化脚本进行筛选，导致了海量存在歧义的 Issue、过窄的断言用例以及环境配置断裂流入评测集。SWE-Bench ProMax 建立了一套严密的三阶段数据筛选与重写流程，从初始挖掘的 29,782 个提交候选池中，层层淘汰，最终仅仅保留了 170 个高质量实例。
构建管线的第一阶段聚焦于真实开源社区的数据挖掘。研究团队针对 GitHub 上超过 500 颗 Star、采用宽松开源协议、且目标语言代码占比超 80% 的活跃仓库，提取 2025 年 1 月之后提交的 Commit。这一时间截断点的设计非常关键，它在最大程度上规避了当前前沿模型预训练语料的数据污染问题。同时，规则要求提交信息中必须明确包含重构关键词且剔除单纯的修 Bug 记录，且提交内容必须同时包含代码变动与测试变动。
第二阶段是全隔离环境的容器化验证。团队借助自动化构建工具与 Docker 沙箱，将每个任务的前置依赖完整固化，并在应用人类开发者的原始修改补丁后执行自动化测试。那些无法稳定复现编译环境、缺少依赖包、或者应用了原作者补丁依然无法通过自身测试套件的不稳定用例被全数丢弃。
第三阶段也是整个基准质量控制的核心：人机协作的高强度专家清洗。由于原始提交记录中的 Commit Message 往往是开发者写给团队同事的备忘，充斥着上下文简写与模糊表达，根本不能直接作为给 AI Agent 的精确任务说明。为此，领域专家结合原始补丁和测试套件，使用辅助模型从零开始重写了所有的任务描述（Issue Description）。每一个任务说明都力求成为解决方案的充分必要条件：既完整定义重构目标与范围，又绝不泄漏实现细节。与此同时，专家对每一个用例的测试套件进行了人工逐行审查，全面剔除对特定内部私有变量、代码格式强绑定的“过窄测试”，以及测试了未指定外部特性的“过宽测试”。最后，所有任务必须剔除改动过小、无跨文件依赖的简单用例，确保最终入选的 170 个任务全部具备真正的复杂性。
评测结果：前沿闭源模型止步 41%，开源生态性价比显著
为了全面评估现有技术水平，研究团队选用了当下的六款代表性前沿模型，包括闭源的顶级梯队 GPT-5.2、Claude Sonnet 4.6、Gemini-3-Pro，以及具备代表性的开源权重模型 GLM-5、Qwen3.5 和 Kimi-K2.5。所有模型均在两种主流的自主软件工程 Agent 架构下进行评测：一种是轻量经典、基于循环交互的 mini-swe-agent，另一种则是提供丰富文件编辑和沙箱交互运行时的 OpenHands 框架。评测设定了每个实例最高 300 步交互和 10 美元的开销上限，严格采用 Pass@1 作为衡量标准。
整体评测结果不仅彻底打破了“代码大模型即将全面解决工程任务”的乐观预期，还呈现出若干反直觉的现象。在综合解决率方面，表现最佳的模型为 GPT-5.2，在 OpenHands 框架下取得了 41.2% 的成绩；Claude Sonnet 4.6 紧随其后，解决率为 38.8%。然而，其他模型的表现则出现大幅滑坡，例如 Gemini-3-Pro 仅取得了 19.4% 的解决率。即使是能力最强的系统，在面对真实的大规模重构时，失败率依然接近六成，说明 SWE-Bench ProMax 远未饱和。
细分到具体编程语言的维度，各家模型的擅长领域展现出极大的结构性方差。通常被认为语法极为繁复、包含严格所有权检查的 Rust，以及类型系统复杂的 TypeScript，在部分模型手中反而取得了较高的解决率。例如 Claude Sonnet 4.6 在 TypeScript 和 Rust 上分别达到了 53.6% 和 63.6%，GPT-5.2 在 Rust 上也取得了 54.5%；但在另一些模型上，这两门语言却成了噩梦，Gemini-3-Pro 在 TypeScript 上甚至颗粒无收（0.0% 解决率），Kimi-K2.5 在 Rust 上的解决率也只有 18.2%。这种两极分化清晰地反映出，不同模型在代码预训练阶段对特定语言生态语料的覆盖度与偏向性存在巨大鸿沟，而并非单纯由语言本身的抽象难度决定。
更为引人深思的是成本与性能的非线性关系。在传统的基准测试中，往往是单次调用成本越高的模型性能越强，但在 SWE-Bench ProMax 的长程调用中，高昂的开销并不等于更高的产出。在 OpenHands 架构下，Claude Sonnet 4.6 单个实例的平均消耗高达 4.77 美元，交互步数平均达到 117.9 步，其解决率却不及单次平均耗费 3.60 美元的 GPT-5.2。相比之下，国产开源权重模型展现出了极强的性价比：GLM-5 取得了 36.5% 的解决率，与闭源第一梯队仅差不到 5 个百分点，但其单次调用成本仅有 0.24 美元，相当于 Claude Sonnet 4.6 的二十分之一；Kimi-K2.5 也以 0.72 美元的低成本拿下了 32.9% 的解决率。这一现象表明，在合理的 Agent 架构支撑下，优质的开源模型完全有能力在真实重构任务中逼近顶级商业闭源模型的效果。
行为轨迹剖析：Agent 究竟在何处溃败？
为了深入探究模型未能解决剩余任务的底层机制，作者对 Agent 运行过程中的轨迹（Trajectories）展开了细致的统计与比对。结果发现，绝大部分失败并非源自深奥的代码算法错误，而是卡在了两大关键行为缺陷上。
第一大缺陷是“跨文件协同断层与不完全重构”。统计数据显示，Agent 最终提交的修改文件数量，普遍显著低于官方黄金补丁所涉及的文件数。当重构任务涉及的文件数量逐渐上升时，这种改动范围上的脱节愈发严峻。在许多失败案例中，Agent 能够准确理解需要将某个模块的接口迁移，并成功修改了核心定义文件及其直接调用的两三个模块，但对于分布在项目各个角落的宏定义、配置文件、次级依赖模块，Agent 往往缺乏足够的全局搜索与耐力来维持完整的修改链条。这就导致代码在构建编译或者集成测试阶段，因局部依赖未同步而全盘崩溃。模型展现出的注意力视野和规划广度，在应对大尺度工程时依然十分有限。
第二大缺陷是所谓的“无效探索循环（Unproductive Exploration）”。研究人员对比了成功解决与未能解决的任务在交互轮数（Interaction Rounds）上的分布特征。在成功的任务轨迹中，模型通常表现出高度集中且线性的特征：迅速定位关键文件，有条不紊地铺开改动，在相对较少的交互步数内便能通过所有测试并主动结束任务。然而在失败的任务轨迹中，模型往往陷入了无休止的“尝试修改—编译报错—盲目回滚—重复阅读同一批文件”的死循环。
Qwen3.5 在评测中就暴露出了这一典型症状：它在两套 Agent 框架下消耗的平均交互步数均为全场最高（分别达到 155.4 步和 141.2 步），但最终的解决率在 mini-swe-agent 框架下却垫底（仅 20.6%）。轨迹检查显示，当模型缺乏长程工作记忆和高阶全局规划时，给予它更多的交互步数配额不仅无法帮助它修正错误，反而会导致它在巨大的上下文噪音中迷失方向，在同一个错误点上反复做无用功。
总结与展望
SWE-Bench ProMax 的出现，及时刺破了由单一文件修改和受污染评测集堆叠出来的“代码大模型神话”。这项工作通过严谨的三阶段清洗，为社区树立了一个具备极高工程纯度、覆盖多语言生态的大尺度基准。
这项研究所揭示的核心事实非常明确：构建一个能够真正承担生产级工程任务的 AI Agent，其瓶颈已经不再仅仅是语言模型的代码生成准确度，而是更深层次的软件工程综合能力：
-
长程上下文中的全局规划能力：如何让模型在跨越数十个源文件时，建立清晰的级联修改蓝图，而不是改了前头忘了后头。
-
跳出无效循环的自省与纠错机制：当面对复杂的测试报错时，Agent 需要识别出自己是否已经进入低效的死循环，并具备主动重置策略、从架构层面重新审视问题的元认知能力。
当工业界的代码助手从单纯的代码补全走向全自动工程治理，SWE-Bench ProMax 设立的这道 41.2% 的天花板，无疑为下一代软件工程大模型与长程 Agent 架构的研究指明了清晰的方向。