SWE-Bench ProMax: Benchmarking Agents on Large-Scale Multilingual Code Refactoring 精读

论文链接： arXiv:2608.09802

数据集： HuggingFace: swe-bench-promax/SWE-Bench-ProMax

发表会议： COLM 2026（Conference on Language Modeling）

发表机构： 字节跳动（Yuling Shi、Kelin Fu、Wenhao Zeng、Shilin He、Lei Zhang 等）与 香港科技大学（Shing-Chi Cheung、Xiaodong Gu 等）产学研合作。本文是工业界需求与学术界方法论的典型结合——字节跳动提供真实大规模代码资产和工程经验，香港科技大学贡献软件工程领域的学术严谨性。

领域标签： 软件工程（cs.SE）、人工智能（cs.AI）、编程语言（cs.PL）

一、论文背景

1.1 代码重构：在不破坏任何功能的前提下"重新装修整栋大楼"

要理解这篇论文，首先要理解它的研究对象——代码重构（Code Refactoring）。

什么是代码重构？打个比方：想象一栋使用了十年的办公大楼。最初的设计很合理，但随着公司业务扩张，新的设备不断接入，老的管线已经无法支撑现在的负荷，维护人员每天疲于修补漏水。这时，你需要做一件事：在不改变大楼对外功能（依然是办公楼、依然能正常办公）的前提下，把整个管线系统重新布线、把电气系统升级、把结构加固。

• 你不能让大楼停工（用户依赖的功能必须保持可用）；
• 你不能只改一个房间（涉及的是跨楼层、跨系统的协调修改）；
• 你改完后，所有人来上班时，工作流不能被打乱（外部行为必须保持不变）；
• 但改完之后，大楼应该更稳定、更易维护、能支撑更大的负载（这是重构的"内部收益"）。

代码重构对应到软件工程里，就是在不改变软件外部可见行为的前提下，修改代码的内部结构，使其更易读、更易维护、更易扩展。典型场景包括：

• 把一个 5000 行的巨型函数拆分成 20 个职责清晰的小函数；
• 在不改变 API 接口的前提下，把单线程的实现改成多线程；
• 把一个紧耦合的模块重构成依赖注入的松耦合架构；
• 升级底层框架（如把 Python 2 代码迁移到 Python 3）；
• 把一个旧的同步 RPC 客户端整体替换为异步实现。

注意这里的两个关键约束：

1. 行为保持（Behavior Preserving）：重构后的代码对外表现必须和原来一样——所有测试不能因为重构本身而失败。
2. 跨文件协调（Cross-file Coordination）：真正的重构从来不是改一个文件了事，而是要在几十甚至上百个文件之间保持一致性——接口定义要改、所有调用方要同步更新、测试要适配、配置要升级。

这是软件工程中最常见、最重要、也最困难的维护活动之一。一项经典的软件工程研究指出，维护性活动占软件总成本的 60% 以上，其中很大一部分就是各种形式的重构。

1.2 LLM Agent 在代码任务上的"刷榜狂欢"

近两年，大语言模型（LLM）驱动的 Agent（智能体）在软件工程基准上成绩突飞猛进。最具代表性的基准是 SWE-bench——它从真实 GitHub 仓库中收集 bug 修复类的 PR（Pull Request），让 Agent 阅读问题描述、浏览代码、修改代码、运行测试，最终以测试是否通过来评估 Agent 的能力。

SWE-bench 推出后引发了持续一年的"军备竞赛"：从最初 GPT-4 只能解决 1.96% 的实例，到 SWE-Agent 把数字推到 12%，再到专门的 Agent scaffold（如 Agentless、Moatless Tools、OpenHands）配合 Claude 3.7、GPT-5 等前沿模型，在 SWE-bench Verified（SWE-bench 的人工验证子集，500 个实例）上的解决率被推到了 70% 以上。

看上去 AI 编程能力已经接近人类工程师了？事情远没有这么简单。

1.3 SWE-bench 的两大致命缺陷

当越来越多的研究者用 SWE-bench Verified 评估自己的 Agent 时，一些异常现象开始浮现。

缺陷一：测试质量问题——安检门既太严又太松

SWE-bench 的评估完全依赖测试用例的通过与否——测试通过就算解决，不通过就算失败。但真实项目中的测试用例，质量参差不齐。研究者发现了两类典型的"问题测试"：

过窄测试（Over-specified / Narrow Tests）：测试不仅检查了 issue 中声明的需求，还意外地依赖于某种特定的实现细节。如果 Agent 提交了一个正确的、但实现路径不同的修复，测试会因为实现细节不匹配而失败——尽管功能上完全等价。

类比：这就像机场安检员要求每位旅客的登机牌必须是从某个特定窗口打印的。一个持有效电子登机牌的合法旅客会被拒绝登机——不是因为他有问题，而是因为他的登机方式不符合安检员的"惯性期待"。结果是：正确的解被错误地拒绝。

过宽测试（Under-specified / Wide Tests）：测试只检查了一个非常浅层的需求，而没有覆盖 issue 中声明的完整行为。一个未能实现完整功能的补丁，也能侥幸通过测试——只要它没有破坏原有测试即可。

类比：这就像机场安检只检查旅客是否持有机票，而不检查机票是否属于本人、是否在有效期内。结果是：不合格的解被错误地放行。

论文分析发现：在 SWE-bench Verified 中，将近 60% 未被解决的实例都包含至少一个过窄或过宽的缺陷测试。这意味着，Agent 在这些实例上"失败"，不一定是因为它没能力解决，而是因为评估方式本身存在严重偏差——评估的"尺子"本身就不准。

缺陷二：数据泄漏——模型背答案而非真正解题

更严重的是，许多 SWE-bench 实例来源于 GitHub 公开 PR，而 PR 中的代码（包括修改后的代码和测试代码）在互联网上是公开的，很可能已经包含在前沿模型的训练数据中。

研究者发现了一个惊人的现象：前沿模型在某些实例上能逐字复现训练数据中的 gold patch——也就是它不是通过理解问题来解决问题，而是直接"背诵"了曾经看过的标准答案。这种数据泄漏（Data Leakage）严重高估了 Agent 的真实能力——它在基准上的分数，反映的是"记忆"而非"推理"。

1.4 单一语言的局限：Python 不能代表软件世界

除了测试质量和数据泄漏，SWE-bench 还有一个结构性局限：它几乎全部是 Python（少量 JavaScript）。但现实世界的软件工程是多语言的——后端用 Java、Go、Python，前端用 TypeScript，系统软件用 C/C++ 和 Rust。不同语言的类型系统、错误处理范式、模块机制、构建工具链差异巨大，Agent 在 Python 上的能力不能简单外推到其他语言。

一个真正能反映 Agent 软件工程能力的基准，必须是多语言的、覆盖真实大规模代码库的、且任务类型接近真实工程实践的。

这正是 SWE-Bench ProMax 要回答的核心需求。

二、论文定位和关联工作

2.1 软件工程基准的演进脉络

要理解 SWE-Bench ProMax 的定位，需要把它放在 LLM 代码能力评估基准的演进脉络中。

谱系一：单文件、单函数的算法能力评估

最早的代码评估基准聚焦于"算法题"——给定一个函数签名和文档，要求模型实现函数体。代表是 HumanEval（OpenAI, 2021）和 MBPP（Google, 2023）。它们采用 Pass@K 指标：每个题目让模型独立生成 K 个候选解，只要有一个通过预设测试用例，就算正确。

这类基准简单、清晰、可自动化，但与真实软件工程几乎无关——真实工程从来不是写一个独立函数。后续的多语言扩展（如 MultiPL-E）也只是把 Python 算法题翻译成几十种语言，本质问题不变。

谱系二：仓库级、PR 修复的真实任务评估

2023 年 11 月，普林斯顿大学提出的 SWE-bench 改变了游戏规则。它从 12 个流行的 Python 仓库中收集真实的 GitHub PR，每个实例包含：

• 仓库在 PR 之前的完整快照
• PR 对应的 issue 描述
• PR 中修改后的测试文件

Agent 的任务是：阅读 issue，修改代码，然后运行测试。如果测试通过，就算解决。

SWE-bench 的开创性在于：它第一次让 Agent 在真实仓库上完成真实任务。但它也有明显缺陷：

• 任务类型偏单一：主要是 bug 修复（占比超过 70%）；
• 实例规模大但质量参差：原始 2294 个实例中很多存在测试问题；
• 几乎全是 Python。

为了解决质量问题，OpenAI 在 2024 年发布了 SWE-bench Verified——由人工专家从原始 SWE-bench 中筛选出 500 个"测试可靠"的实例。但这只是"打补丁"，并没有从根本上解决测试质量和数据泄漏问题，也未涉及任务多样性和语言多样性。

谱系三：自然语言指令到代码库修改的执行评估

SWE-Bench ProMax 属于这一谱系的最前沿——它继承了 SWE-bench 的"真实仓库+测试评估"范式，但在三个关键维度上做了系统性升级：

2.2 同期相关工作

除了 SWE-bench 系列，2025-2026 年还涌现了若干面向代码 Agent 的基准，它们与 SWE-Bench ProMax 互为补充：

SWE-Bench ProMax 的独特之处在于：它是第一个以大规模行为保持重构为任务核心、以专家逐条审查为保证、覆盖7种主流语言的真实代码基准。它不是在 SWE-bench 上"做加法"，而是重新定义了"什么才算真实的软件工程任务"。

2.3 本论文的研究定位

本论文的核心定位可以用一句话概括：

当 Agent 的能力越来越强时，我们需要一个真正配得上"前沿"二字的基准——它的任务要接近真实工程，它的评估要无偏、可靠，它要能在 Agent 能力被推到极限时仍然有效区分优劣。

SWE-bench Verified 的 70%+ 解决率让人产生"问题已解决"的错觉，但 ProMax 用 41.2% 的最佳解决率明确地告诉社区：远未到庆祝的时候。

三、问题定义

3.1 从具体场景到抽象问题

论文面对的具体场景是：构建一个能可靠评估代码 Agent 重构能力的多语言基准。但如果我们剥离掉"基准构建"这个具体任务，它要解决的本质问题是：

如何设计一个评估体系，使得被评估对象（代码 Agent）的得分能无偏地反映它在"真实大规模跨文件行为保持重构"任务上的能力，而不被任务规模、语言特性、测试质量和训练数据记忆所干扰？

这是一个看似简单、实则极具挑战的问题，因为它要求评估体系同时满足多个相互制约的条件。

3.2 形式化的问题定义

给定：

• 一个候选实例集合 $D_{\text{cand}}$，每个实例 $d_i$ 包含一个真实仓库的快照、一段 issue/PR 描述、一个 gold patch、一组测试；
• 一个 Agent $\mathcal{A}$（如 Claude 3.7 + 某种 scaffold）；
• 一个评估函数 $\text{Eval}(\mathcal{A}, d_i) \in \{0, 1\}$，返回 Agent 在实例 $d_i$ 上是否"正确解决"。

求：一个从 $D_{\text{cand}}$ 中筛选出的子集 $D^* \subseteq D_{\text{cand}}$，以及一个筛选函数 $\text{Filter}(\cdot)$，使得：

1. 无偏性（Unbiasedness）：$\text{Eval}(\mathcal{A}, d_i) = 1$ 当且仅当 $\mathcal{A}$ 真正完成了 $d_i$ 所要求的重构；
2. 区分性（Discriminative Power）：在 $D^*$ 上，强 Agent 的平均得分显著高于弱 Agent，且不存在"天花板效应"（所有 Agent 都接近满分）；
3. 真实性（Realism）：$D^*$ 中的任务在分布上接近真实软件工程中的重构活动；
4. 多样性（Diversity）：$D^*$ 在语言、仓库、重构类型上具有充分覆盖。

3.3 为什么这个抽象是合理的？

这个抽象的精妙之处在于它把"构建基准"转化为一个多目标优化问题——每个目标都对应一种潜在的评估失败模式：

• 不满足无偏性 → 评估失真（SWE-bench 的测试质量问题）；
• 不满足区分性 → 基准饱和（容易的任务被 Agent 全解决，无法区分谁更强）；
• 不满足真实性 → 评估无意义（任务和真实工程脱节）；
• 不满足多样性 → 评估片面（只覆盖单一语言或单一任务类型）。

SWE-bench Verified 在无偏性（测试质量问题严重）和真实性（以 bug 修复为主）上失守，导致它的"70%+ 解决率"成为一个被高估的数字。ProMax 的核心贡献，就是设计了一个多阶段策展流程 $\text{Filter}(\cdot)$，在四个目标上同时取得突破。

四、问题解法

4.1 解法总览：多阶段专家策展流水线

SWE-Bench ProMax 的核心方法是一个多阶段、专家深度参与的实例策展流水线。它不是"自动从 GitHub 爬取 PR 然后拼成一个数据集"，而是对每个候选实例进行反复打磨，直到它满足严格的质量标准。

整个流程可以概括为四个阶段：

阶段0: 候选收集 → 从7种语言的流行仓库中收集"重构类"PR作为候选
阶段1: 规范重写 → 专家从头重写issue描述，提供精确的规范
阶段2: 测试清洗 → 专家逐条审查测试，剔除过窄和过宽的缺陷测试
阶段3: 实例过滤 → 剔除复杂度不足、跨文件范围有限、有泄漏嫌疑的实例

下面我们逐一展开。

4.2 阶段0：候选收集——从哪里开始？

多语言覆盖设计

论文首先确定了7 种目标语言：Python、Java、TypeScript、Go、C、C++、Rust。这个选择涵盖了：

• 动态类型（Python）和静态类型（Java、TypeScript、Go、C、C++、Rust）；
• 垃圾回收（Python、Java、Go）和手动内存管理（C、C++、Rust）；
• 面向对象（Java、TypeScript、C++）、过程式（C、Go）、函数式友好（Rust）；
• 解释执行（Python）和编译执行（其余六种）；
• 主流应用开发（Python、Java、TypeScript）和系统级开发（C、C++、Rust、Go）。

这 7 种语言基本覆盖了现代软件工程的主要范式，使得基准能够区分 Agent 在不同语言生态下的真实能力。

候选来源

候选实例来源于这 7 种语言下的真实开源仓库——优先选择 star 数高、活跃度强、有规范 PR 流程的项目。每个候选是一个真实的 PR，且这个 PR 必须：

• 在描述中明确说明是重构（而不是 bug 修复或新功能）；
• 修改了多个文件（体现跨文件协调）；
• 伴随着测试变更（说明行为需要保持）。

候选收集阶段产出了一个大规模的初始候选池，但绝大多数候选都将在后续阶段被剔除——最终只有极少数能通过所有质量关卡，进入正式的 ProMax 数据集。

4.3 阶段1：规范重写——给 Agent 一份"精确的施工图"

为什么要重写 issue？

真实 GitHub 项目的 issue 描述质量参差不齐。很多 issue 是开发者在排查问题时随手写的——它们可能：

• 夹杂大量无关上下文（如探索性的代码片段、未完成的猜测、与最终方案无关的讨论）；
• 隐含仓库特有的约定（如"按照我们这里的 ServiceBase 模式"，但 Agent 不知道这个模式是什么）；
• 描述的是"问题"而非"需求"（如"代码很乱"而不是"把 X 函数重构成 Y 结构"）；
• 缺少验收标准（没有明确说明"做完之后应该满足什么"）。

如果 Agent 拿到的规范本身是模糊的，那它失败可能不是能力不足，而是因为不知道要做什么。为了让评估公平，必须给 Agent 一份精确的规范。

专家重写的具体做法

论文的作者团队（包含字节跳动的资深工程师和香港科技大学的研究者）对每个候选实例，从头重写 issue 描述，产出一份标准化的"任务规范"。这份规范包含：

1. 任务概述：用一句话说清这次重构要做什么（如"把 X 模块从同步实现改成异步实现，不改变其对外 API"）；
2. 背景与动机：为什么要做这次重构（如"现有同步实现导致响应时间过长，无法支撑流量增长"）；
3. 目标行为保持：明确列出哪些行为必须保持不变（如"所有现有测试都必须通过"）；
4. 修改范围：列出预期要修改的关键模块和文件类型（不精确到文件路径，避免泄露答案，但给出明确的工作范围提示）；
5. 验收标准：完成的重构应该满足什么条件（如"所有原有测试通过 + 新增的若干测试也通过"）。

这个过程完全依靠专家的人工撰写——没有任何自动化。每个实例的规范重写都需要专家深入理解整个仓库的上下文，这本身就是一项耗时的工作。

类比：这就像把一份"现场边讨论边写"的工程会议纪要，重新整理成一份正式的施工图纸——图纸上每个尺寸、每个连接点都要清晰无误，让另一个完全没参与会议的工程师也能按图施工。

4.4 阶段2：测试清洗——剔除"安检门的两个极端"

这是 ProMax 最具创新性、也是最耗人工的一步。

测试清洗的必要性

回顾背景部分：SWE-bench Verified 中近 60% 未解决实例含缺陷测试。如果 ProMax 也用这种"原始测试"评估，就会重蹈覆辙——评估结果被测试质量问题污染。

因此，专家必须逐条审查每个候选实例的所有测试，识别并剔除：

• 过窄测试：意外依赖特定实现细节的测试；
• 过宽测试：检查不够全面、漏检声明需求的测试；
• 不稳定测试（Flaky Tests）：结果依赖于时间、随机数、网络等外部因素的测试；
• 无关测试：与本次重构目标无关、徒增噪声的测试。

测试审查的具体做法

对每个候选实例，专家执行以下步骤：

1. 理解重构目标：阅读重写后的规范，明确这次重构应该改变什么、保持什么。
2. 逐条分析测试：对每个测试用例，判断它是否：
   • 检查的是重构声明的目标？
   • 是否依赖了实现细节（如断言"调用了三次内部方法"——这是实现细节，应该剔除）？
   • 是否漏检了关键行为（如只检查返回值类型，没检查返回值内容——这是过宽，需要补充或剔除）？
3. 保留干净测试：只保留那些"检查声明目标、不依赖实现细节、覆盖完整行为"的测试。
4. 必要时补充测试：如果原有测试覆盖不足，专家会撰写新的、行为级的测试用例，确保正确解能通过、错误解会被拒绝。

这个过程就像在安检门前重新设计安检规则：

• 剔除过窄测试 = 移除"要求从特定窗口打印登机牌"的不合理规则；
• 剔除过宽测试 = 补上"不检查机票归属"的安全漏洞；
• 保留干净测试 = 制定"检查机票有效性 + 核对身份 + 检查行李"的合理规则。

最终，每个进入 ProMax 的实例都拥有一个干净、完整、行为导向的测试套件，作为评估的黄金标准。

4.5 阶段3：实例过滤——只留"配得上 ProMax"的实例

经过规范重写和测试清洗后，候选池中仍有大量实例。最后一道关卡是实例过滤——剔除那些不符合 ProMax 定位的实例。

过滤维度一：复杂度过滤

ProMax 要评估的是"大规模重构"，因此必须剔除复杂度不足的实例。具体剔除：

• 修改文件过少（如少于 3 个文件）的实例——它们更接近"小修小补"而非重构；
• 修改代码行数过少（如少于 50 行）的实例；
• 修改集中在单一关注点（如只改了 import 语句）的实例。

只保留那些真正需要跨多个文件、修改上百行代码、涉及多个关注点的复杂实例。

过滤维度二：跨文件范围过滤

ProMax 强调"跨文件协调"——真正的重构要求 Agent 能同时理解多个文件之间的依赖关系、接口契约、调用链路。因此剔除：

• 跨文件范围有限的实例（虽然修改了多个文件，但每个文件的修改是独立的，不需要协调）；
• 修改集中在自动生成的代码的实例（如只更新了 protobuf 生成的代码）。

只保留那些需要 Agent 理解文件间依赖、同步修改多处的实例。

过滤维度三：泄漏风险过滤

为了降低数据泄漏风险，剔除：

• 在主流 LLM 训练数据截止日期之后才合并的实例（这些可能是新出现的，泄漏风险低，但反向选择——也就是优先保留这类）；
• 在 GitHub 上特别热门、被广泛引用的 PR（它们更可能被模型"背下来"）；
• gold patch 具有高度可记忆特征（如包含大段独特的字符串）的实例。

这个过滤虽然不能完全消除泄漏，但显著降低了"模型靠记忆而非推理解决实例"的风险。

最终的实例规模

经过四个阶段的层层筛选，最终 170 个实例 进入 SWE-Bench ProMax。这个数字看起来不大，但每个实例都代表了一次深度的专家投入——重写规范、清洗测试、审查复杂度——这是"精耕细作"而非"广种薄收"。

最终数据集的关键统计：

作为对比：SWE-bench Verified 平均每实例修改的文件数和代码行数都显著少于 ProMax——ProMax 的任务规模比 SWE-bench Verified 高出一个数量级。

4.6 评估方法：Agent 如何被评判？

评估流程

对每个 ProMax 实例，Agent 的评估流程如下：

1. 输入：重写后的规范 + 仓库的初始快照（重构前的状态）；
2. Agent 工作：Agent 在 scaffold（如 OpenHands、Agentless）的支撑下，阅读规范、探索代码、修改代码；
3. 产出：Agent 提交一个 patch（代码变更）；
4. 评估：在修改后的仓库上运行该实例的干净测试套件；
5. 判定：所有测试通过 → 解决（resolve）；否则 → 未解决。

两种 Agent scaffold 的采用

为了评估的全面性，论文在两种主流 Agent scaffold 下测试模型：

• Agentic scaffold（如 OpenHands）：Agent 可以多轮调用工具（文件浏览、代码编辑、命令执行），具有较高自主性；
• Simiplified/Agentless scaffold（如 Agentless）：采用更结构化的"定位-修复-验证"三段式流程，工具调用更少但更有针对性。

在两种截然不同的 scaffold 下都得出类似结论，增强了实验结果的稳健性——它说明 ProMax 的难度不是某种特定 scaffold 的偶然现象。

4.7 方法的全景对比表

五、评估指标与实验证据

5.1 核心评估指标

ProMax 论文使用了若干层级的指标来全面刻画 Agent 的能力。

主指标：Resolve Rate（解决率）

定义：在 ProMax 的 170 个实例中，Agent 成功解决（所有测试通过）的比例。

取值范围：0% – 100%，越高越好。

衡量什么：Agent 在真实大规模重构任务上的综合能力——包括理解规范、探索代码、跨文件协调修改、保证行为保持的全部能力。

这是论文最看重的指标，因为它直接回答"ProMax 是否饱和"的核心问题。

辅助指标一：按语言分解的解决率

定义：在每种语言（Python/Java/TypeScript/Go/C/C++/Rust）的子集上，Agent 的解决率。

衡量什么：Agent 在不同语言生态下的能力差异——是某种语言特别难，还是 Agent 在所有语言上都表现平平？

辅助指标二：按 Agent scaffold 分解的解决率

定义：同一种模型在两种 scaffold 下的解决率对比。

衡量什么：scaffold 的设计对 Agent 表现的影响——是模型本身的能力瓶颈，还是 scaffold 的工程优化空间？

消融指标：测试清洗前后的解决率对比

定义：对同一批实例，使用原始测试 vs 清洗后测试的解决率差异。

衡量什么：测试质量问题对评估结果的污染程度——如果清洗前后解决率差异巨大，就证明测试质量是一个严重被低估的问题。

5.2 核心实验结果

结果一：ProMax 远未饱和

论文在两种 Agent scaffold 下测试了多个前沿模型，最佳解决率如下：

核心结论：在 ProMax 上，最强的 Agent 也只能解决约 41% 的实例——这意味着接近 60% 的大规模重构任务，当前最强的 AI 系统仍然无法独立完成。这与 SWE-bench Verified 上动辄 70%+ 的解决率形成鲜明对比。

这个结果有力地证明了 ProMax 的核心主张：当任务接近真实软件工程时，AI Agent 的能力远未达到"已解决"的水平。

结果二：多语言能力的不均衡

按语言分解的解决率呈现显著差异。论文发现：

• 某些语言（如 Python）上 Agent 的表现相对较好，因为训练数据更丰富；
• C、C++、Rust 等系统级语言上 Agent 的表现显著更差——这些语言的内存管理、类型系统、编译工具链复杂度更高，训练数据也相对稀少；
• 静态类型语言（Java、TypeScript）和动态类型语言（Python）之间的差异也很明显，反映了 Agent 在处理类型注解和接口契约时的能力差异。

核心结论：Agent 的能力具有强烈的语言依赖性——在 Python 上的成绩不能外推到其他语言，多语言评估是不可回避的必要条件。

结果三：测试质量显著影响评估结果

通过对比"使用原始测试"和"使用清洗后测试"的解决率，论文发现：

• 使用原始测试时，解决率被显著高估——大量"过宽测试"让不正确的解也通过了；
• 过窄测试的存在则导致解决率被低估——一些正确的解被错误地拒绝；
• 综合下来，原始测试的评估结果与清洗后测试显著不一致，排名甚至会发生变化。

核心结论：测试质量问题是 SWE-bench 类基准的系统性缺陷，它不仅影响解决率的绝对数值，还可能影响不同 Agent 的相对排名。ProMax 的专家测试清洗是从源头解决这个问题的关键投入。

结果四：Agent scaffold 的设计空间仍然开放

两种 scaffold 下的结果差异表明：

• 同样的模型，在不同的 scaffold 下表现差异显著；
• Agentic scaffold 给模型更多自主性，但也带来更高的"跑偏"风险——Agent 可能在无关的探索上浪费 token；
• Agentless scaffold 更结构化，但对某些需要灵活探索的任务可能不够适应。

核心结论：Agent scaffold 的设计是一个独立于模型能力的重要研究方向——更好的 scaffold 能让现有模型发挥出更大的潜力。

5.3 证据如何支撑论文的核心主张

论文的核心主张是：SWE-Bench ProMax 是一个更接近真实软件工程、未饱和、能可靠区分 Agent 能力的基准。

实验证据如何支撑这个主张？

这五条证据构成了一个完整的论证链——它们共同说明：ProMax 不仅仅是一个"更难的基准"，而是一个评估更可靠、任务更真实、区分能力更强的下一代代码 Agent 评估平台。

5.4 实验设计的精妙之处

值得强调的是论文实验设计的几个精妙之处：

1. 两种 scaffold 的交叉验证：避免结论依赖于某种特定 scaffold 的偶然性；
2. 多语言覆盖：避免结论依赖于 Python 这一单一语言；
3. 测试清洗前后的对比：直接量化测试质量问题对评估的影响，把"测试质量很重要"从一个直觉变成一个可测量的结论；
4. 专家规范 vs 原始 issue 的对比：直接量化"模糊规范"对 Agent 的不公平程度。

这些设计使得论文的每一个核心结论都有多角度的实验支撑，而不是依赖于单一实验。

六、效果优势的根源解释

这一节我们从根源上解释：为什么 SWE-Bench ProMax 在评估代码 Agent 真实能力上，显著优于以 SWE-bench Verified 为代表的既有基准？这种优势不是"凑巧"，而是结构上必然更好。

6.1 对比对象：SWE-bench Verified 为何曾经有效？

SWE-bench Verified 在 2024-2025 年之所以成为代码 Agent 评估的事实标准，是因为它相比 HumanEval/MBPP 这类算法题基准有两大突破：

• 真实性：使用真实 GitHub 仓库，任务来自真实 PR；
• 执行评估：通过运行测试来判定对错，避免了对"代码看起来对不对"的主观判断。

这两个特性让 SWE-bench Verified 成为当时最接近"真实软件工程"的评估方式。

6.2 SWE-bench Verified 的根本局限

但随着 Agent 能力的提升，SWE-bench Verified 的两个根本性局限开始主导评估结果：

局限一：测试质量污染 → 评估失真

SWE-bench Verified 的测试来自原始 PR，没有经过系统的质量审查。这意味着评估函数 $\text{Eval}(\mathcal{A}, d_i)$ 本身就是有偏的：

• 对于过宽测试，$\text{Eval}$ 会误将不合格的解判为合格（False Positive）；
• 对于过窄测试，$\text{Eval}$ 会误将合格的解判为不合格（False Negative）。

这种偏差是结构性的——它不是随机噪声，而是系统性地高估或低估 Agent 的能力。当 Agent 能力较弱时，这种偏差可能被"Agent 本来就做不好"所掩盖；但当 Agent 能力提升到 50%+ 的水平时，测试质量问题就成了评估结果的主导因素——你看到的分数，更多反映的是"测试有多宽"而不是"Agent 有多强"。

局限二：任务类型单一 + 语言单一 → 评估片面

SWE-bench Verified 的任务以 Python bug 修复为主。这意味着：

• 在 Python 上训练数据丰富的模型被高估；
• 在 Java/Go/C/Rust 等语言上的能力完全未被评估；
• 大规模重构、跨文件协调、行为保持等真实工程能力完全未被评估。

当 Agent 的通用代码能力提升到一定水平后，“Python 单文件 bug 修复"就不再是一个有区分力的任务——它只能反映 Agent 能力的一个狭窄侧面。

6.3 ProMax 的根本性改变

ProMax 不是在 SWE-bench Verified 上"做加法”，而是从评估的根基上重新设计。它的每个关键设计都对应了一项根本性的改变。

改变一：专家测试清洗 → 评估函数从"有偏"变回"无偏"

因果链：

• 方法差异：ProMax 引入专家逐条测试审查；
• 机制变化：剔除过窄测试（False Negative 源头）和过宽测试（False Positive 源头）；
• 缓解的瓶颈：评估函数的系统性偏差；
• 体现在指标上：解决率不再被测试质量污染，反映的是 Agent 真实能力。

这个改变是最根本的——它让评估的"尺子"重新变得可靠。没有这个改变，后续的所有改进（多语言、大规模、行为保持）都建立在失真的地基上。

改变二：任务类型从"bug 修复"转向"大规模重构" → 评估的任务复杂度对齐真实工程

因果链：

• 方法差异：ProMax 聚焦行为保持的大规模跨文件重构；
• 机制变化：任务要求 Agent 同时具备代码理解、跨文件协调、行为保持、测试适配等多项能力，任何一项短板都会导致失败；
• 缓解的瓶颈：单文件 bug 修复任务的"天花板效应"——当 Agent 能解决 70%+ 时，任务不再有区分力；
• 体现在指标上：解决率下降到 41.2%，重新打开区分空间。

大规模重构本质上是一个复合能力任务——它不能通过"擅长某一件事"来解决，而需要 Agent 在多个能力维度上同时达标。这使得 ProMax 的解决率对 Agent 的综合能力高度敏感，区分力远高于单一能力任务。

改变三：7 种语言覆盖 → 评估从"片面"变回"全面"

因果链：

• 方法差异：ProMax 覆盖 7 种主流语言；
• 机制变化：评估要求 Agent 在不同语言生态下都展现能力，无法靠"Python 训练数据丰富"获得虚高分数；
• 缓解的瓶颈：单语言评估的片面性；
• 体现在指标上：不同语言的解决率差异清晰反映 Agent 的语言能力分布。

这个改变让评估结果更接近"Agent 在真实多语言软件工程中的能力"，而不是"Agent 在 Python 单一生态中的能力"。

改变四：专家规范重写 → 评估的"输入端"也变得可靠

因果链：

• 方法差异：专家从头重写任务规范；
• 机制变化：Agent 失败的原因被精确隔离——要么是能力不足，要么是规范有歧义，而 ProMax 消除了后者；
• 缓解的瓶颈：原始 issue 模糊性导致的"不公平失败"；
• 体现在指标上：解决率反映的是 Agent 的"解题能力"而非"猜谜能力"。

这是一个容易被忽视但极其重要的改变——它确保了 Agent 失败的原因是"做不到"，而不是"没看懂题目"。

6.4 反事实推理：如果去掉某项设计会怎样？

为了进一步验证这些设计的必要性，我们可以做反事实推理：

• 如果 ProMax 不做测试清洗：解决率会被显著高估（过宽测试放水）或低估（过窄测试误杀），评估结果与真实能力的关联性大幅下降；
• 如果 ProMax 只保留小修改实例：解决率会接近 100%，基准迅速饱和，失去区分能力；
• 如果 ProMax 只保留 Python：评估结果会重复 SWE-bench Verified 的偏科问题，无法反映多语言能力；
• 如果 ProMax 不做规范重写：Agent 失败原因被污染，无法判断是能力不足还是规范不清。

每个反事实都对应一个 ProMax 关键设计的不可替代性——这些设计不是"锦上添花"，而是评估可靠性的根基。

6.5 一句话总结

ProMax 之所以能可靠评估 Agent 的真实重构能力，不是因为它"更难"，而是因为它从评估函数（测试清洗）、任务定义（大规模重构）、输入规范（专家重写）、覆盖广度（多语言）四个维度同时消除了既有基准的结构性缺陷——每消除一个缺陷，评估结果就离"真实能力"更近一步。这是结构上的必然更好，而非参数上的偶然更优。

七、必要知识反推

假设一个完全没有相关知识和信息的人要从零完成这篇论文的工作，他必须掌握哪些必要知识？我们从领域、方法论、工程三个层次反推。

7.1 领域知识层

知识一：代码重构的概念、类型与挑战

为什么必须：不理解什么是代码重构（行为保持、跨文件协调），就无法定义 ProMax 的任务范围，也无法判断一个 PR 是否属于"重构"而非"bug 修复"或"新功能"。

关键点：重构的核心约束是"行为保持"——修改内部结构但不改变外部行为。这个约束既是重构的价值所在，也是它的难度所在。

知识二：主流编程语言的生态差异

为什么必须：ProMax 覆盖 7 种语言，每种语言的类型系统、内存管理、构建工具、测试框架都不同。不理解这些差异，就无法设计公平的多语言评估。

关键点：Python 的动态类型 vs Java 的静态类型 vs Rust 的所有权系统，对 Agent 的能力要求完全不同；Go 的并发模型 vs C 的手动内存管理，对测试设计也有不同影响。

知识三：软件测试的理论与实践

为什么必须：测试清洗是 ProMax 的核心创新。不理解"什么是过窄测试"、“什么是过宽测试”、“什么是行为级测试”，就无法执行测试审查。

关键点：一个"好的测试"应该检查声明行为（what），而不是实现细节（how）。这是软件测试理论的基本原则，但在真实项目中经常被违反。

知识四：开源软件协作流程

为什么必须：ProMax 的实例来源于真实开源仓库的 PR。不理解 GitHub 的 PR 流程、issue 讨论、代码评审、CI/CD 机制，就无法从开源项目中提取高质量的候选实例。

7.2 方法论知识层

知识五：代码 Agent 的评估方法论

为什么必须：ProMax 是一个评估基准。不理解代码 Agent 评估的基本方法论——执行评估 vs 静态评估、Pass@K vs Resolve Rate、scaffold 的角色——就无法设计合理的评估流程。

关键点：执行评估（运行测试）比静态评估（看代码）更可靠，但它高度依赖测试质量——这正是 ProMax 要解决的问题。

知识六：数据泄漏与基准饱和的概念

为什么必须：如果不懂什么是数据泄漏，就无法设计降低泄漏风险的过滤流程；如果不懂什么是基准饱和，就无法判断"41.2% 解决率"意味着什么。

关键点：基准饱和是指所有被评估对象都接近满分，失去区分能力。数据泄漏会让模型靠记忆而非推理"解决"任务，导致评估失真。

知识七：Sim2Real / 真实分布对齐的思想

为什么必须：ProMax 的核心追求是"评估分布接近真实工程分布"。不理解分布对齐的思想，就无法判断哪些实例"够真实"、哪些"不够真实"。

知识八：多目标优化的思维

为什么必须：第三节形式化的问题定义中，筛选函数 $\text{Filter}(\cdot)$ 需要同时满足无偏性、区分性、真实性、多样性四个目标，而这些目标之间可能存在张力（如提高真实性可能降低实例数量）。不理解多目标优化，就无法做出合理的权衡。

7.3 工程知识层

知识九：大规模代码仓库的构建与测试执行

为什么必须：ProMax 要在 7 种语言的真实仓库上执行测试，这要求为每种语言配置合适的构建工具和测试运行环境。Go 的 go test、Java 的 Maven/Gradle、Rust 的 Cargo、C/C++ 的 Make/CMake——每种的配置都不同。

关键点：仓库级测试执行是一个工程密集型任务——依赖安装、环境隔离、超时处理、日志收集，每个环节都可能出错。

知识十：Agent scaffold 的工程实现

为什么必须：ProMax 要在两种 scaffold 下评估模型，这要求理解 OpenHands、Agentless 等 scaffold 的工作机制、工具接口、调用约定。

知识十一：HuggingFace 数据集的发布与版本管理

为什么必须：ProMax 通过 HuggingFace Datasets 发布，需要掌握数据集的 schema 设计、版本控制、文档规范。

知识十二：专家协作流程的管理

为什么必须：ProMax 的规范重写、测试清洗都需要多位专家协作。如何分配任务、如何保持标注一致性、如何解决分歧——这些都需要项目管理知识。

7.4 知识融合的关键节点

以上 12 项知识不是简单叠加，而是在几个关键节点上产生"化学反应"：

融合点一：测试理论与开源 PR 的结合

将"行为级测试"的理论原则应用到真实开源 PR 的测试审查上——这不是简单地"套用理论"，而是要在每个具体实例中判断：这个测试是在检查行为，还是在检查实现？这要求专家同时具备测试理论的抽象能力和具体仓库的领域知识。

融合点二：软件工程实践与 LLM 评估方法论的结合

将"大规模重构"这个软件工程概念转化为可评估的机器学习任务——要求作者同时理解软件工程师在做什么和如何为 Agent 设计公平的评估。这个融合点是论文"定位"的根基。

融合点三：多语言工程实践与基准设计的结合

在 7 种语言上同时保证评估的公平性——要求作者同时理解每种语言的工程特点（构建、测试、依赖）和基准设计的统计原则（实例分布、样本均衡）。

融合点四：数据泄漏、测试质量、任务复杂度的协同处理

这三个问题不是独立的——一个高质量基准必须同时处理它们。只解决测试质量而不处理泄漏，评估仍然失真；只处理泄漏而不提升任务复杂度，基准仍然会饱和。ProMax 的多阶段流水线正是这种协同处理的体现。

这些融合节点说明：完成 ProMax 不是任何单一领域知识的简单应用，而是多个领域知识的深度整合——这也是为什么此类基准工作稀缺且价值高的根本原因。

八、论文中可以提取的通用性灵感

这一节我们提炼论文中具有普适性、可推广到其他领域的灵感。

8.1 灵感一：评估体系的"尺子"比"被量物体"更关键

核心思想：当一个评估体系（基准）的评估函数本身有偏时，所有建立在它之上的结论都会失真。提升被评估对象的能力，不如先提升评估体系本身的可靠性。

论文证据：ProMax 发现 SWE-bench Verified 的测试质量问题导致近 60% 未解决实例的评估不可靠。清洗测试前后的解决率显著不一致，甚至影响 Agent 的相对排名。这意味着在 SWE-bench Verified 上的"70%+ 解决率"这个广为流传的数字，其可靠性远低于社区想象。

推广场景：

• 推荐系统评估：点击率指标可能被"标题党"内容污染，需要设计更反映真实用户价值的指标；
• 大模型对齐评估：人类偏好评估可能被标注者的表面风格偏好污染，需要设计更反映真实任务完成度的指标；
• 自动驾驶评估：基于仿真器的评估可能被仿真环境的简化假设污染，需要谨慎处理 Sim-to-Real Gap；
• 医疗 AI 评估：基于金标准的评估可能被标注者间分歧污染，需要明确标注协议；
• 教育评估：标准化考试的分数可能被应试技巧污染，需要区分"会做题"和"真懂"。

8.2 灵感二：基准饱和是"任务定义窄"的征兆，不是"问题已解决"的证据

核心思想：当一个基准上的解决率接近满分时，不要轻易说"问题已解决"——更可能是"任务定义过窄"，没有覆盖真实场景的复杂度。这时应该扩展任务定义，而不是庆功。

论文证据：SWE-bench Verified 上 70%+ 的解决率让社区产生"代码 Agent 接近成熟"的判断，但 ProMax 通过把任务从"单语言 bug 修复"扩展到"多语言大规模重构"，把解决率拉回到 41.2%——这说明"饱和"只是窄定义下的假象。

推广场景：

• 机器翻译：BLEU 分数接近人类水平 ≠ 翻译问题已解决，扩展到长文档、跨模态、低资源语言会重新打开难度空间；
• 图像识别：ImageNet 上的 Top-1 准确率超过人类 ≠ 视觉理解已解决，扩展到细粒度、长尾、对抗样本会重新打开难度空间；
• 对话系统：特定任务上的完成率接近 100% ≠ 对话能力已解决，扩展到多轮、开放域、情感感知会重新打开难度空间；
• 代码生成：HumanEval 上的 Pass@1 接近 90% ≠ 代码生成已解决，扩展到仓库级、多文件、跨语言会重新打开难度空间。

8.3 灵感三：复合能力任务是更好的"区分器"

核心思想：单一能力的任务容易被"专门化"解决（模型在某一维度做精就能拿高分），而复合能力任务（同时要求多项能力）能更真实地反映综合水平，区分力更高。

论文证据：ProMax 的大规模重构要求 Agent 同时具备代码理解、跨文件协调、行为保持、测试适配等多项能力——任何一项短板都会导致整体失败。这种"木桶效应"使解决率对综合能力高度敏感，区分力远高于 SWE-bench 的单文件 bug 修复。

推广场景：

• 人才评估：综合性项目（要求多种技能协同）比单项测试更能区分人才水平；
• 机器人能力评估：长 horizon 的家庭服务任务（要求感知+规划+操控+交互）比单一抓取任务更能区分机器人综合能力；
• 企业能力评估：端到端的客户体验（要求产品+技术+运营+服务协同）比单一指标更能区分企业竞争力；
• AI 安全评估：多轮对抗场景（要求推理+规划+社交工程+技术能力）比单轮攻击更能区分安全风险。

8.4 灵感四：专家策展是高质量数据集的不可替代投入

核心思想：当自动化方法（如 LLM 辅助标注）无法保证数据质量时，专家深度参与的"精耕细作"优于规模化的"广种薄收"。170 个高质量实例比 17000 个低质量实例更有价值。

论文证据：ProMax 只有 170 个实例，但每个实例都经过专家重写规范、清洗测试、审查复杂度。这种投入使得 ProMax 的评估可靠性远高于 SWE-bench Verified 的 500 个"未经深度审查"的实例。

推广场景：

• LLM 训练数据：高质量的指令微调数据（精挑细选）比海量低质量数据更能提升模型能力，符合 LIMA 论文"1000 条高质量数据足以对齐"的精神；
• 医学影像数据集：专家逐例标注的小数据集比自动化标注的大数据集更能可靠训练和评估模型；
• 法律案例库：资深律师逐案分析的精品库比爬取的裁判文书大全更有教学和参考价值；
• 教育内容：名师精讲的短系列比海量粗糙内容更有学习效果。

8.5 灵感五：泄漏检测应成为基准设计的默认步骤

核心思想：在 LLM 时代，任何基于公开互联网数据的基准都可能被训练数据污染。基准设计必须把"降低泄漏风险"作为默认步骤，而不是事后补救。

论文证据：ProMax 在候选过滤阶段就考虑了泄漏风险——剔除特别热门、被广泛引用、具有高度可记忆特征的 PR。虽然不能完全消除泄漏，但显著降低了"模型靠记忆而非推理解决任务"的风险。论文还发现前沿模型能逐字复现 SWE-bench 训练数据中的 gold patch，这是泄漏的直接证据。

推广场景：

• 问答基准：剔除与 Wikipedia 等常见训练数据源高度重叠的问答对；
• 代码能力基准：使用模型训练截止日期之后的新代码；
• 数学能力基准：使用新发现的数学问题或重新表述的经典问题；
• 多模态基准：使用新拍摄而非网络爬取的图像；
• 通用基准设计原则：基准实例应具备"时间新颖性"和"来源非主流性"两大特征。

8.6 灵感六：输入端的规范化与输出端的评估同等重要

核心思想：评估一个 AI 系统时，不仅要关注"如何判定输出对错"（评估函数），还要关注"如何保证输入清晰"（任务规范）。模糊的输入会让所有评估失真——失败可能不是能力不足，而是题目没看清。

论文证据：ProMax 花大量精力重写任务规范，确保每个实例的"题目"都精确无歧义。这避免了"Agent 因为看不懂模糊 issue 而失败"的不公平情况，让失败原因精确归因到能力不足。

推广场景：

• 客服 AI 评估：不仅要看 AI 回答得好不好，还要确保用户问题被清晰转述；
• 代码评审自动化：不仅要看评审意见对不对，还要确保被评审的代码上下文完整传达；
• 教育 AI 评估：不仅要看 AI 解题对不对，还要确保题目表述清晰；
• 设计需求评估：评估 AI 生成的设计好不好之前，先确保需求文档本身清晰完整。

8.7 灵感七：产学研合作是复杂基准工作的有效模式

核心思想：构建高质量的、接近真实工程的基准，需要学术界的方法论严谨性和工业界的真实问题洞察。单靠任一方都难以完成。

论文证据：ProMax 是字节跳动（工业界）和香港科技大学（学术界）的合作成果。字节跳动提供了大规模代码资产、资深工程师的领域经验、对真实软件工程痛点的洞察；香港科技大学贡献了软件工程领域的研究方法论、严谨的实验设计、学术论文的写作规范。这种合作使得 ProMax 既有工程深度，又有学术严谨。

推广场景：

• 医疗 AI 基准：需要医院（临床经验）+ AI 实验室（方法论）+ 监管机构（合规）的多方合作；
• 自动驾驶基准：需要车企（真实数据）+ 学术实验室（评估方法）+ 政府机构（安全标准）的合作；
• 金融科技基准：需要金融机构（真实场景）+ 学术研究（评估方法）+ 监管（风险控制）的合作；
• 教育科技基准：需要学校（教学实践）+ AI 实验室（技术）+ 教育部门（评估标准）的合作。

附录：SWE-Bench ProMax 关键数据速查

参考文献与延伸阅读

[1] Shi, Y., Fu, K., Zeng, W., He, S., Zhang, L., et al. (2026). SWE-Bench ProMax: Benchmarking Agents on Large-Scale Multilingual Code Refactoring. COLM 2026.

[2] Jimenez, C. E., Yang, J., et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2024.

[3] OpenAI (2024). SWE-bench Verified. https://openai.com/index/introducing-swe-bench-verified/

[4] Chen, M., Tworek, J., et al. (2021). Evaluating Large Language Models Trained on Code. arXiv:2107.03374 (HumanEval).

[5] Yang, J., Jimenez, C. E., et al. (2024). SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. NeurIPS 2024.

[6] Xia, C. S., Deng, Y., et al. (2024). Agentless: Demystifying LLM-based Software Engineering Agents. arXiv:2407.01489.

[7] Wang, X., et al. (2025). OpenHands: An Open Platform for AI Software Developers as Generalist Agents. ICLR 2025.

[8] Fowler, M. (1999). Refactoring: Improving the Design of Existing Code. Addison-Wesley.（代码重构领域的经典著作）