SWE-Bench ProMax：当 AI 编程基准被"刷爆"之后，用大规模多语言重构给 Agent 来一记狠的
上周看到一个挺扎眼的数据：OpenAI 自己审计了 SWE-bench Verified 里那些一直没被解决的实例，发现近 60% 都是坏题——不是模型不行，是题本身有毛病。要么测试写得过于刁钻，功能完全正确的解法也被拒；要么测试检查的是任务描述里根本没提的要求。OpenAI 干脆直接弃用了这个基准。
这就很尴尬了。一边是所有榜单都在刷 SWE-bench，前沿 Agent 的 resolve rate 已经冲到 75% 以上，眼看着就要"满分毕业"；另一边是审计告诉你，这考试本身漏题、错题一大堆，而且模型还能从训练数据里把标准答案逐字背出来。
那怎么办？今天聊的这篇 SWE-Bench ProMax（arXiv: 2608.09802，COLM 2026 录用）给了一个很硬核的答案：换赛道，考大规模代码重构。
核心摘要
现有 AI 编程基准面临双重危机：题目质量堪忧（SWE-bench Verified 未解决实例中 35.5% 存在过窄测试、18.8% 存在过宽测试），难度也严重饱和（86% 的实例只改一个文件，前沿模型 resolve rate 超 75%）。SWE-Bench ProMax 从 29,782 个候选 commit 中筛出 170 个专家级重构任务，覆盖 Python、Java、TypeScript、Go、C、C++、Rust 七种语言，每个实例平均要改 11.4 个文件、261.6 行代码——规模远超现有基准。结果是最强的 GPT-5.2 也只拿到 41.2% 的 resolve rate。我的判断：这不是一篇"又一个 benchmark"的水文，它真正值钱的地方在于把"评估质量"当成一等公民来做（专家重写 issue、人工清洗测试），而且揭示了 Agent 一个此前没被量化的软肋——跨文件级联修改做不完整。
📖 论文信息
- 标题：SWE-Bench ProMax: Benchmarking Agents on Large-Scale Multilingual Code Refactoring
- 作者：Yuling Shi, Jinghan Xu, Kelin Fu, Wenhao Zeng, Shilin He, Lei Zhang, Yue Liu, Zelin Zhao, Terry Yue Zhuo, Jialun Cao, Siyu Ye, Tianyu Liu, Kai Cai, Shing-Chi Cheung, Xiaodong Gu
- 发表：COLM 2026（arXiv: 2608.09802，2026 年 8 月 10 日提交）
- 数据集：https://huggingface.co/datasets/swe-bench-promax/SWE-Bench-ProMax
🎯 为什么偏偏是"重构"？
你可能觉得，SWE-bench 不行了，再造一个更难的 bug fixing 基准不就行了？
作者的选择是重构，这个切入点我觉得选得很准。三个理由层层递进。
重构是真实开发里最高频的活动之一。 OpenAI 自己把 "project-scale refactors" 列为多上下文窗口 Agent 的主要用例。天天写新功能的是少数，天天在存量代码里挪模块、改接口、清理依赖的才是多数工程师的日常。
重构天然是"行为保持"的，可以严格验证。 改完前后测试必须全绿，没有模糊空间——这比"实现一个新功能"的评判要干净得多。
重构天然是跨文件、长程的。 把一个接口从旧抽象迁到新抽象，调用点、文档、配置、测试装置全得跟着动。这恰好打在现有基准的软肋上——SWE-bench Verified 里 86% 的实例只改单文件，而真实重构动辄横跨几十个文件。
那已有的重构基准呢？说实话都不够用。RefactorBench 只有 100 个手工任务、9 个 Python 仓库、平均改 4.3 个文件，还是单语言；SWE-Refactor 有 1,099 个实例但只覆盖 Java 的 18 个仓库，且测试质量没经过人工验证。更重要的是，几乎所有基准都以 Python 为中心——可 Rust 的所有权模型、C 的手动内存管理、Java 的类型层次，这些才是检验 Agent 泛化能力的试金石。
顺带说个背景：OpenAI 那次审计（论文引用来源）的细节值得记住。未解决实例里 35.5% 是 overly narrow tests——测试强制了某种具体实现细节，换个等价写法就挂；18.8% 是 overly broad tests——检查了任务描述里没说的行为。再加上前沿模型能逐字复现 gold patch 的数据污染问题，这个基准的可信度确实是崩了。
🏗️ 怎么造出来的：29,782 进，170 出
这个淘汰率（0.57%）本身就说明了策展的狠劲。整个 pipeline 分三个阶段，每个实例最终包含四样东西：预配置 Docker 环境、精确的自然语言 issue description、验证测试套件、gold patch。判定 resolved 的标准很干脆——Agent 的修改必须通过套件里所有测试。
三阶段策展流程：从 GitHub 海选重构 commit，到 Docker 环境构建与测试验证，再到专家过滤与 issue 重写——注意右侧每个环节都标注了 Human 参与的位置
Stage 1：数据收集。 用 GitHub API 筛仓库，三个硬门槛：至少 500 stars、有批准的开源许可证、主要语言占比超 80% 且属于七种目标语言之一。然后提取 2025 年 1 月之后的 commit——这个时间截断是故意用来缓解数据污染的——要求 commit message 含 "refactor" 但不含 "bug fix"，且必须同时改了测试文件和非测试文件。
Stage 2：环境构建。 借助 SWE-Factory 这类自动化工具为每个候选 commit 搭隔离 Docker 环境：仓库克隆到重构前的状态，打上 gold patch（源码加测试变更），跑完整测试套件。环境起不来或者 gold patch 过不了测试的，直接扔。
Stage 3：过滤与问题重写。 这是全文最有分量的部分，专家加 LLM 辅助走四步：
- Commit 分析：专家分析 diff，LLM 帮着总结变更、识别受影响组件，搞清楚重构的范围、意图和结构影响。
- 质量过滤：删掉只改单文件、改动行数太少、模式太简单的任务；审查测试套件，把 overly narrow 和 overly broad 的测试清掉——这两类正是前面审计发现的重灾区，这里是直接对着病灶下刀。
- 问题陈述重写：原始 commit message 往往就一句 "refactor auth module"，要么含糊要么引用了 Agent 拿不到的内部上下文。专家在 LLM 辅助下从头重写 issue description，产出精确、自包含的规范，并验证它是 gold patch 的必要且充分条件。
- 人工验证：最后一道人工审查确保三者一致——描述完整指定重构；测试当且仅当重构正确时通过；没有未说明的要求。
说实话，这个"issue 重写 + 测试清洗"的双保险是我认为整个工作里工程价值最高的部分。之前太多基准是"爬下来洗洗就上"，测试质量全靠运气，最后大家刷的其实是噪声。
📊 这个基准长什么样
先看体量。平均每个实例：
| 组件 | 指标 | 平均值 | 最大值 |
|---|---|---|---|
| Issue Description | Tokens | 685.3 | 2,092 |
| Gold Patch（源码） | 文件数 | 11.4 | 182 |
| 代码行数 | 261.6 | 4,503 | |
| Test Patch | 文件数 | 4.5 | 66 |
| 代码行数 | 185.5 | 1,959 | |
| 合计 | 文件数 | 15.9 | 244 |
30% 的实例要改超过 10 个文件，32% 需要超过 200 行代码变更。对比一下：SWE-bench Verified 里 86% 的实例只改一个文件。这不是量变，是任务性质变了。
语言分布上，170 个实例来自 70 个仓库：
| 语言 | 仓库数 | 实例数 | 平均文件数 | 平均 LOC |
|---|---|---|---|---|
| C | 9 | 20 | 17.9 | 424.1 |
| C++ | 9 | 22 | 21.4 | 196.3 |
| Go | 16 | 23 | 16.0 | 227.4 |
| Java | 11 | 26 | 20.8 | 309.8 |
| Python | 18 | 29 | 10.6 | 299.8 |
| Rust | 5 | 22 | 14.5 | 284.8 |
| TypeScript | 2 | 28 | 11.9 | 122.6 |
有个细节值得注意：Java 和 C++ 的补丁最大（平均 20.8 和 21.4 个文件），这很符合直觉——类型层次深、头文件依赖链长，动一处牵一片。而 C 的平均改动行数最高（424.1 行）。
论文 Table 6 给了每语言一个代表性实例，挑两个最震撼的：C++ 侧是 NASA 的 F'Prime 飞行软件框架（nasa/fprime#3422），一次重构要协调 244 个文件、+591/−514 行，从单一头文件迁移到新的统一入口点，涉及 autocoders、驱动、OS 层、服务和构建配置，同时运行时行为一个字节都不能变；Java 侧是 plantuml 给甘特图引擎加小时级时间分辨率，改了 94 个文件、1,629 行。这种任务给人做都得分期，对 Agent 来说是真正的长程大考。
任务类别也挺有意思（多标签标注，由 Claude Sonnet 4.6 辅助分类）：Refactoring Cleanup 占 66.5%，API Interface Change 占 65.3%，但同时 New Feature 占 43.5%、Bug Fix 占 41.2%。46.5% 的实例同时涉及三个以上类别，没有一个实例少于两个类别。 这很真实——实际工程里哪有"纯粹的重构"，改着改着顺手修个 bug、加个字段才是常态。
任务类别共现热力图：对角线是各类别自身频次（Refactoring Cleanup 113 次、API Interface Change 111 次），非对角线上 API 变更与重构清理共现 79 次、Bug Fix 与重构共现 48 次——印证了"重构过程中常会暴露潜在缺陷"这个老经验
所需技能分布更能说明这个基准在考什么：跨文件推理 99.4%、API 语义理解 98.8%、接口契约推理 97.1%、模式匹配 91.8%、数据流 88.8%、领域知识 79.4%、类型系统推理 50.6%。几乎每一题都要求跨文件推理，这跟"单文件打补丁"完全是两种能力。
🧪 实验：六个模型、两种脚手架
实验设置很克制：两种 agent scaffold——mini-swe-agent（SWE-agent 的最小重实现，observe-think-act 循环）和 OpenHands（带沙盒执行和结构化编辑工具的通用平台）；统一 300 步上限、每实例 10 美元成本上限。六个模型里三个专有（Gemini-3-Pro、Claude Sonnet 4.6、GPT-5.2），三个开源权重（GLM-5、Kimi-K2.5、Qwen3.5）。指标就是 Pass@1 的 resolve rate。
主结果（Table 3）：
| 模型 | mini-swe-agent Resolve | 步数 | 成本 | OpenHands Resolve | 步数 | 成本 |
|---|---|---|---|---|---|---|
| Gemini-3-Pro | 26.5% | 58.0 | $0.60 | 19.4% | 51.2 | $1.49 |
| Claude Sonnet 4.6 | 30.6% | 99.5 | $2.32 | 38.8% | 117.9 | $4.77 |
| GPT-5.2 | 21.8% | 25.2 | $0.19 | 41.2% | 115.1 | $3.60 |
| GLM-5 | 22.9% | 108.9 | $0.10 | 36.5% | 114.2 | $0.24 |
| Kimi-K2.5 | 26.5% | 85.3 | $0.37 | 32.9% | 99.6 | $0.72 |
| Qwen3.5 | 20.6% | 155.4 | $0.93 | 36.5% | 141.2 | $0.78 |
几个发现挨个说。
基准确实没饱和。 最好的 GPT-5.2 在 OpenHands 下也只有 41.2%，跟 SWE-bench Verified 上 75%+ 的分数比，直接被砍半。而且别忘了这个基准的题是清洗过的，分数的含金量比老基准高。
开源模型追得非常凶，而且便宜得离谱。 OpenHands 下 GLM-5 和 Qwen3.5 都是 36.5%，Kimi-K2.5 32.9%，跟 GPT-5.2 的 41.2% 只差几个点。看成本：GLM-5 每实例 0.24 美元，是 Claude Sonnet 4.6（4.77 美元）的二十分之一。看到这个数的时候我愣了一下——如果你在做编程 Agent 的产品化，这个性价比表比 resolve rate 本身更有信息量。
脚手架的选择影响巨大。 除 Gemini-3-Pro 外（26.5% 掉到 19.4%，是唯一反着走的），所有模型从 mini-swe-agent 换到 OpenHands 都明显涨分，GPT-5.2 直接从 21.8% 蹦到 41.2%。大规模重构这种任务，光靠最小编辑循环不够，沙盒执行、结构化编辑这些"重装备"是真的有用。反过来也说明一件事：报 Agent 分数不报脚手架，基本等于报一半。
没有任何模型在所有语言上称霸。 每语言 resolve rate（OpenHands 下）的分布很碎：Claude Sonnet 4.6 领先 TypeScript（53.6%）和 Rust（63.6%），GPT-5.2 领先 Python（48.3%）和 C（75.0%），GLM-5 领先 Java（34.6%），Kimi-K2.5 在 Go 上最好（43.5%），Qwen3.5 在 C++ 上最好（54.5%）。最夸张的是方差——Gemini-3-Pro 在 TypeScript 上是 0.0%，而 Claude 能拿 53.6%。这大概率不是语言本身的难度差异，而是各家训练数据构成的差异被照妖镜照出来了。
🔬 失败在哪：不是找不到，是做不完
这是全文我最喜欢的分析。作者追踪了 Agent 的行为轨迹（Figure 5），得出主导失败模式：不完整重构（incomplete refactoring）。
证据很硬。从修改文件数的累积分布看，Claude Sonnet 4.6 和 Kimi-K2.5 在小改动（5 个文件以内）上跟 gold patch 的分布咬得很紧，但补丁一大就急剧分化——gold patch 要改到约 20 个文件才覆盖 90% 的实例，而两个 Agent 改到约 10 个文件就覆盖了它们 90% 的产出。
关键点在于：Agent 不是找不到正确的文件。 它们通常能准确定位并编辑核心文件，但改完核心就停手了——同样的转换没有传播到外围调用点、文档、配置文件和测试装置，留下一堆不一致的下游依赖，测试自然就红了。
从交互轮次看也很说明问题：成功解决的实例消耗的轮次明显更少，曲线早早平台化；失败的尝试则陷入"无效循环"——反复读文件、试编辑、测试失败、回退，轮次烧了不少，修改范围却一点不扩大。作者管这个叫 unproductive exploration（非生产性探索）。
这个结论我想展开说一句。很多人默认 Agent 的瓶颈是"推理不够强"，但这篇论文的行为分析指向另一个地方：瓶颈是在大跨度上维持连贯计划、并把级联后果坚持执行到底的能力。 这更像"项目管理能力"而不是"智商"。Qwen3.5 是个极端佐证：两种脚手架下步数最多（155.4 和 141.2 步），mini-swe-agent 下 resolve rate 反而垫底（20.6%）——瞎忙不代表能干。
成本维度也有反直觉的点：花钱多不等于做得好。Claude Sonnet 4.6 最贵（4.77 美元/实例、117.9 步）却落后 GPT-5.2；Gemini-3-Pro 花 1.49 美元只换回 19.4%。给更多步数预算并不能保证进步，无效的"编辑–回退"循环烧的都是冤枉钱。
🤔 我的判断
先说这篇论文做得漂亮的地方。
它把"评估质量"从口号变成了流程。 针对审计发现的过窄/过宽测试，直接在建库流程里设了专家清洗环节；issue description 从头重写并验证"必要且充分"——这是拿做数据集当软件工程做，不是爬虫加正则。
任务规模是真的上了一个台阶。 平均 15.9 个文件、244 文件的天花板实例，加上七种语言覆盖，这个基准短期内不太可能被刷爆。41.2% 的头部分数给社区留出了足够的爬坡空间。
行为分析比分数本身更有价值。 "不完整重构"这个失败模式的量化（Agent 在 10 个文件处封顶 vs gold patch 需要 20 个），为后续研究指了条明路：提升跨文件计划的持久性，可能比继续堆推理能力更划算。
再说几个让我皱眉的地方。
语言–仓库分布不均衡是个实打实的软肋。 TypeScript 的 28 个实例只来自 2 个仓库，Angular 一家独占 25 个。论文解释这是"选大型活跃项目的自然结果"，道理我认，但这让 per-language 的结论打折扣——Claude 在 TypeScript 上的 53.6% 到底是"擅长 TypeScript"还是"擅长 Angular 的代码风格"？这两个解释区分不开。C 语言只有 20 个实例，单实例就占 5 个点，GPT-5.2 那个 75.0% 的领先多少有小样本波动的成分。
LLM 深度参与策展引入了循环依赖的风险。 Stage 3 用 LLM 辅助重写 issue 和审测试，任务分类用 Claude Sonnet 4.6——而被评测的模型里恰好就有 Claude Sonnet 4.6。作者声明 LLM 是"人工指导下的交互工具"，但客观上说，当出题过程和被测模型来自同一技术族时，微妙的风格偏向很难完全排除。这是我自己的担忧，原文没有讨论这一点。
Pass@1 加 10 美元上限的协议有点紧。 对动辄要改 200 个文件的任务，300 步和 10 美元可能截断了某些模型的发挥。当然这个限制有现实的复现成本考量，可以理解，但结论应该带着这个前提读。
跟同期工作摆在一起看：SWE-bench 系（Verified、Multimodal、Multilingual）在修修补补，RefactorBench 和 SWE-Refactor 做了重构但规模或质量不够。这篇的定位很清晰——不追求实例数量（170 个远少于 SWE-Refactor 的 1,099），而是用专家策展换质量、用大规模换难度。在"benchmark 通胀"的当下，这个取舍我觉得是对的。
💡 工程启发
如果你在做编程 Agent，这篇论文至少有三个可直接用的洞察。
其一，调试 Agent 的失败时先查"传播完整性"：核心文件改对了但外围没跟上，是最可能的死因。给 Agent 加"变更影响面检查"之类的显式步骤，可能比换更强的模型见效快。
其二，脚手架投入有杠杆：同样的模型换更重的运行时工具能涨近 20 个点（GPT-5.2 案例），别只盯着模型侧优化。
其三，开源模型的成本曲线已经越过甜点区：GLM-5 用二十分之一的成本拿到九成水准的分数，大规模批处理场景（比如仓库级自动重构流水线）闭源 API 的账已经很难算了。
最后一个更本质的问题这篇没解决：当 Agent 学会了"坚持把级联修改做完"，怎么防止它走向另一个极端——过度修改、把不该动的也动了？行为保持这条钢丝，两边都是悬崖。下一个基准也许该考考这个。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我