SWE-Bench Pro V2：更干净、更难被刷的编码基准

SWE-Bench Pro V2：更干净、更难被刷的编码基准

\contact{soham.dan, ying.liu, yue.zhang}@scale.com

Soham Dan，Jeff Da，Sanyam Bhutani（单位：Reflection AI），Miguel Romero Calvo（单位：Scale AI），Ivan Guevara（单位：Scale AI），Fernando Carabedo（单位：Scale AI），Jose Bernal（单位：Scale AI），Julio Reyna（单位：Scale AI），Luis Leandro Monsalve Mendez（单位：Scale AI），Ying Liu（单位：Scale AI），Daniel Yue Zhang（单位：Scale AI）。原文把单位标在作者姓名之后：Sanyam Bhutani 任职于 Reflection AI，自 Miguel Romero Calvo 起的各位作者任职于 Scale AI。联系方式写在文首命令中，收件人为 soham.dan、ying.liu 与 yue.zhang。

摘要

SWE-Bench Pro 是一项被广泛使用的基准，用来评测编码智能体在长程软件工程任务上的表现。随着智能体变强，它们会碰到更早的智能体从未触及的任务问题，也会以原始评测框架没有预料到的方式与评测环境交互。我们提出 SWE-Bench Pro V2，这是一份修订后的公开划分，目的是在能力继续前进时仍让基准保持准确。智能体审计、专家裁决和盲法重实现修复或退役了 731 项任务中的 480 项：23 名签约工程师花了 404 小时，每人使用自己职业中书写的语言，每一条修订后的说明都由第二名工程师仅凭文本完成该任务来核验。加固后的协议把网络访问限制在模型端点，并在干净容器里重新给每个补丁打分，因此智能体不能取回上游修复，也不能因为补丁之外的改动得分。在 642 项 V2 任务上，前沿智能体的解决率最高到 99.4%，其他系统仍被清楚地分开；51 项任务的 Hard 划分把系统从 52.9% 拉开到 98.0%。我们发布该基准，并提炼出随时间维护智能体基准的经验。

1 引言

用真实 GitHub issue 建成的基准，已经成为评测编码智能体的一种标准。SWE-bench [1] 要求智能体在真实仓库里解决一个 issue，并用原始修复所带的测试给得到的补丁打分。在前沿系统饱和了它经过人工筛选的子集 SWE-bench Verified [2]，而且其较老 issue 的污染变得难以排除之后（如 OpenAI [3] 所述，它已不能再用来度量前沿能力），SWE-Bench Pro [4] 被设计成它的后继。其公开划分包含来自 11 个仍在积极维护的仓库的 731 项任务，语言为 Python、Go 和 JavaScript/TypeScript。参考解常常跨多个文件，每项任务把一份人工撰写的规格（问题陈述、需求与接口）与隐藏测试配在一起。SWE-Bench Pro 的分数被广泛写进模型发布和排行榜，从业者用它们来选择模型和智能体支架，因此让基准随时间保持准确至关重要。

随着智能体改进，它们剩余失败中越来越大的一份可以追溯到任务本身的问题 [5]。我们审阅了全部 731 项公开任务，发现两类问题。数据缺陷使一项任务的分数与解的正确性不一致：测试检查说明从未陈述的行为，说明与测试矛盾或泄漏测试，测试太弱，以及验证器或环境缺陷（表 1）；修复或退役它们触及 480 项任务（66%）。评测漏洞让智能体可以不解决任务、靠作弊通过。

我们处理这两类问题，并发布 SWE-Bench Pro V2。[^1] 两轮智能体审计标出 731 项任务中的 200 项，23 名专家软件工程师裁决每一条标记，并且所有任务的验证器都被加固（图 2）。发布集有 642 项任务，其中 391 项被修复，89 项被丢弃。

在 V2 上，Claude Opus 5（在 Claude Code 中运行）解决 99% 的任务，而 Gemini 3.8 Flash 解决 94.9%，Inkling 解决 89.9%（图 1）。全集仍然分开前沿之下的系统，51 项任务的 Hard 划分把系统从 52.9% 拉开到 98.0%。我们的贡献是：

• SWE-Bench Pro V2：经过多轮自动与专家修复之后的 642 项任务清洁集，以及配套的 51 项任务 Hard 划分：23 名工程师裁决每一条智能体审计标记（超过 404 小时），用盲法重实现核验每一次修复，并加固且门控每一个验证器（§3）。
• 一套面向基于 issue 的编码基准的修复流水线与缺陷分类：以智能体审计做分诊，再经工程师裁决、盲法重实现和验证器加固（§3.1–3.4）。
• 来自运行该基准的证据：沙箱内打分会放行、而锁定协议会拒绝的那些利用（§4.4）；一项研究表明，对开源权重模型，智能体框架改变成本但不改变准确率（§4.5）；以及一个对前沿模型接近饱和的基准为何仍然有用（§5）。

图 1：在 SWE-Bench Pro V2（实心点）及其 Hard 划分（空心点）上解决的任务百分比。全集把这些系统分开大约 12 个点（87.2–99.4%），而 Hard 划分从 52.9% 跨到 98.0%。

2 相关工作

#### 仓库级编码基准。

SWE-bench [1] 为编码智能体基准确立了一种共同格式，即解决 git issue；后续工作沿若干方向扩展了这一格式：SWE-bench Verified [2] 让标注者筛掉 issue 不清或测试不公平的任务，Multi-SWE-bench [6] 增加语言，SWE-bench-Live [7] 和 SWE-rebench [8] 持续收集新 issue 以限制污染，SWE-Lancer [9] 从付费自由职业工作中抽取任务。同一种容器加测试的格式支撑着 Harbor [10] 这类智能体框架、更广的终端基准 [11]，以及编码智能体的训练环境 [12, 13]。SWE-Bench Pro [4] 针对仍在积极维护的仓库中的长程改动，并为每个 issue 增加人工撰写的需求与接口。我们研究的是，当智能体接近其天花板时，如何维护这样一项基准。

#### SWE 基准中的质量缺口。

若干研究表明，基于 issue 的基准里的测试比通常假定的更弱。补丁可以通过，是因为 issue 文本已经包含解，或者因为测试太弱 [14]；许多被判为正确的补丁，其行为与参考修复不同 [15, 16]。Zhu 等人 [17] 把这类失败提炼成一份构建严格智能体基准的检查清单。Nadgir 等人 [5] 认为，这类缺陷往往要到智能体强到能够触及它们时才浮现，因此基准在饱和之后需要维护。我们把这类审计变成一条可重复的流水线，对每一条标记决定是修复还是丢弃该任务。

#### 奖励破解与答案泄漏。

已知智能体会利用评测中的弱点。专门的基准度量模型把测试特例化或改写测试的频率 [18, 19, 20, 21]，训练期间也观察到奖励篡改及其隐瞒 [22, 23]。在基于 issue 的基准里，容器中随附的仓库状态泄漏了含有修复的未来提交，先是在 SWE-bench [24]，后来在 SWE-Bench Pro [25, 26]。模型也可能已经记住了流行仓库及其修复 [27, 28]。我们还识别出一条由沙箱内打分产生的额外通道：当验证器在智能体自己的沙箱里运行时，补丁之外的状态，例如伪造的模块版本或被改过的依赖缓存，会影响分数。

#### 同期对 SWE-Bench Pro 的修复。

在同时期的工作中，SWE-Bench Pro Verified [29] 封锁代码托管站点，隐藏测试产物，并精修从公开报告收集来的 102 项任务 [30]，用模型试跑来检查这些精修。作者表明，堵住泄漏把一个模型的 186 次通过变成了失败。我们的做法在四点上不同。我们用专家审计检查每一项任务，而 SWE-Bench Pro Verified 从已报告的问题出发。我们从不修改隐藏测试去迁就说明，并且丢弃缺陷位于测试之中的任务。我们用盲法的人工重实现来核验每一次说明修复，而他们依赖模型试跑。最后，在智能体阶段我们只允许访问模型端点的网络，他们则封锁一份域名清单；并且我们在干净容器里重新给每个补丁打分。

3 方法

我们从 SWE-Bench Pro Public v1.0 的 731 项任务出发。一项任务由下列部分组成：一份说明（问题陈述、需求、新接口），一个仓库停在基线提交的容器镜像，一个参考补丁，一个隐藏测试补丁，列出被打分测试的 fail-to-pass 与 pass-to-pass 名单，以及一个验证器，它应用测试补丁、运行测试并解析输出。一项任务有效，当且仅当每一个满足说明的解都通过，每一个不满足说明的解都失败。图 2 追踪这些任务经过三轮修复、一次工程师审阅和一次终审。第 1 轮修复了 40 个容器镜像，它们的参考补丁携带了测试和夹具文件，或者说明缺少标准模板。第 2 轮对难度标定、说明与测试的对齐以及奖励破解做自动审计；它标出 387 项任务（53%），发现 326 项干净，并在 18 项上出错。工程师修订被标出的任务，使说明与被打分的测试对齐，并覆盖已陈述的需求，每一批都重新审计，直到大约 700 项通过；大约 30 项无法只靠编辑任务来通过。有三项改动应用到每一项任务：「不要编辑测试」这条约束离开了说明模板，验证器现在会在应用测试补丁之前还原与测试相关的改动；镜像中的 git 历史被清除，使智能体无法恢复修复；智能体阶段禁用网络。此前一个前沿模型在 351 项已解决任务上从 GitHub 逐字复制了参考解，其中只有 237 项在封锁 GitHub 之后仍然成立。这一轮的结果保留了全部 731 项任务。第 3 轮运行两次智能体审计（§3.1），标出 200 项任务（27%）。工程师裁决每一条标记（§3.3）：68 项被修复，43 项保持不变，89 项被丢弃。终审把针对具体任务的编辑扩展到整个集合，并且共享验证器对每一项任务都被加固（§3.4）。发布集有 642 项任务，其中 391 项带有针对该任务的修复（表 1）：731 项任务中的 480 项（66%）被修复或移除，另外 251 项只通过验证器加固发生变化，没有任何参考解被改动。

图 2：731 项任务从 SWE-Bench Pro v1.0 流向发布集；条和带的高度与任务数量成比例。第 1 轮修复 40 个容器镜像（泄漏的测试和夹具文件、非标准说明）。第 2 轮的自动审计标出 387 项任务（全部由人类专家修好）。在第 3 轮，产物审计（一个 LLM 智能体和一名人类审计员比较说明与测试及参考补丁）和失败审计（一个 LLM 评判者把四种智能体设置的失败运行归因）标出 200 项任务。工程师裁决每一条标记，一次修复只有在对编辑后说明做盲法重实现并通过隐藏测试之后才发布。

3.1 智能体审计

#### 产物审计。

一个 LLM 智能体把每项任务的说明与其测试名单和参考补丁比较，不执行任何东西。它标出六种模式：说明中缺少测试要求，说明中的陈述被测试否定，测试或解的细节被抄进说明，已改变的行为没有任何被打分的测试去检验，测试会读取但从未被创建的夹具，以及被打分名单点名整个测试文件。过于冗长的需求章节是一种泄漏信号，因为它们常常逐字转录参考补丁。一名人类审计员审阅这些标记并标出高优先级情形；共标出 161 项任务。

#### 失败审计。

我们在每一项任务上运行四种智能体配置：Claude Code 配 Claude Opus 5，Codex 配 GPT-5.6，以及 mini-SWE-agent 分别配这两个模型。对每次运行，一个 LLM 评判者阅读轨迹、补丁、验证器日志和被打分的测试，并把每次失败归因于模型或归因于任务。当一个与对说明的合理阅读相一致的补丁被拒绝时，该任务被标出。例如，在一项 vuls 任务中，两种配置按说明退回到包目录名并报告 Sample.app，而被打分的测试期望 Sample，因为参考补丁去掉了后缀，说明却没有这么说。对每一条这样的标记，我们记录缺陷类型、修复位置、工作量估计、建议的编辑，以及通过和失败的配置。失败审计标出 54 项任务，其中 39 项是新的，全部被标任务合计 200 项。

3.2 缺陷分类

我们把各次审计的标签和终审的编辑类型合并成表 1 的六类；每项任务只计一次，归在它的主要编辑之下（说明，否则是测试补丁，否则是打分文件）。未陈述的要求、矛盾，以及验证器或环境缺陷，会使正确的解失败；泄漏和测试不足会使任务比预期更容易，或让不完整的解通过。

表 1：在 SWE-Bench Pro Public v1.0 的 731 项任务与最终 642 项之间，被修复并保留（Rep.）和被丢弃（Disc.）的任务的缺陷类别。合计起来，731 项任务中的 480 项（66%）被修复或移除。每项任务只计一次，归在其主要编辑所针对的缺陷之下。每项任务也都得到了加固后的验证器，并且没有任何参考解被改动。

#### 未写明的测试要求（修复 119，丢弃 22）。

测试依赖于说明没有提到的行为、名称或文件；上面的 vuls 任务通过写明 .app 后缀会被去掉而得到修复。119 次修复中的大多数（25 次来自被确认的标记，94 次来自终审）是短的增补，写明被打分测试已经强制的东西：一个精确的值、字符串、顺序或签名。当测试检查的是参考补丁碰巧如何写成时，该任务被丢弃，因为把这一点写出来就会把解送出去。

#### 规格与测试矛盾（修复 10，丢弃 5）。

说明说的是一件事，被打分的测试检查的是另一件事。错误的说明被改正（8 项来自标记，2 项在终审中）；其修复位于测试之中的矛盾被丢弃，例如一项 webclients 任务，其接口声明一个 Element 参数，而被打分的测试传入的是 Document。

#### 答案泄漏（修复 18，丢弃 4）。

有泄漏的说明逐个文件走一遍参考补丁，或者从测试中复制期望值。一份 tutanota 说明告诉智能体去更新 decrypt 里 aes256Decrypt 周围的 try-catch 块；修复后的版本只规定行为：加密库抛出的 CryptoError 必须作为应用程序自己的 CryptoError 浮出，凭据层再把它转换成 KeyPermanentlyInvalidatedError。修复删掉泄漏的文本，并且在测试依赖它的地方，把要求重述为行为。四项丢弃是先被修复、然后在发布前移除的（§3.3）。

#### 测试不足（修复 1，丢弃 33）。

被打分的测试留下改动的一部分不检查：在一项 flipt 任务中，它们只覆盖新缓存层的错误路径，因此一个总是返回 false 的 getJSON 和一个空操作的 setJSON 都能通过。工程师不编写新测试，所以这些任务被丢弃；那一次修复是给一个 teleport 测试增加一条断言。

#### 验证器或环境缺陷（修复 228，丢弃 19）。

在 16 项被丢弃的任务中，fail-to-pass 名单点名整个文件（例如 test/tests/calendar/CalendarUtilsTest.js | test suite），因此该文件里任何无关或易波动的失败都会使一个正确补丁失败；在 3 项中，镜像使打分无法进行，例如一个 teleport 测试因为缺少 SoftHSM 而被跳过，验证器把这记为失败。228 项被修复的任务，是那些唯一针对该任务的改动发生在打分文件上的任务（223）：在四个 Go 仓库中，运行脚本从整个仓库收窄到含有被打分测试的包，还有解析器，以及 20 项 element-web 任务的被打分测试名称；另有 5 份说明增加了一项环境事实，例如没有网络，或一个精确的依赖版本。共享验证器的缺陷对所有任务都做了修复（§3.4）。

#### 其他（修复 15，丢弃 6）。

十五份说明被改写，或被给予并不修复任何缺陷的实现细节。六项被丢弃的任务没有一条成立的标记：两项 ansible 任务在一条泄漏标记被拒绝后被隔离，四项被修复后又被丢掉，尽管它们所记录的标记并不成立。

3.3 工程师审阅

工程师采用一条标准：如果参考补丁增加了一种被隐藏测试检查的行为，说明必须陈述该行为，但不陈述参考补丁如何实现它。测试不被编辑去迎合说明，说明也从不被改写去迁就错误的测试。

23 名签约工程师用 404 小时裁决每一条标记。对每一条主张，他们记录它成立、部分成立或不成立，并引用产物和行号（例如 test_patch_before:178）；高优先级标记接受第二次独立审阅，以及项目组的第三遍。不成立的标记使任务保持不变（45 项任务；其中 26 条被拒绝的标记声称答案泄漏，这是最常不成立的类型）。缺口在说明之中的标记，导致一次仅限于标记成立之处的编辑（69 项任务，其中 53 项进入发布集）。补救位于测试、夹具、验证器或镜像之中的标记导致隔离（73 项任务，主要是测试不足 32 项，以及验证器或环境缺陷 19 项）。工程师一共改正了 55 项任务：51 项针对完全或部分成立的标记（18 项答案泄漏，8 项规格与测试矛盾，25 项未陈述的要求），4 项针对后来的审阅所拒绝的标记，它们通过其他编辑仍留在发布集中。加上终审对被标任务的编辑，200 项被标任务中有 68 项带有编辑，43 项不变，89 项被丢弃（图 2）。

修复以盲法核验：第二名工程师既没有看过原始任务，也没有看过参考补丁，去实现编辑后的说明，只有该实现通过隐藏测试，这次编辑才发布。十六项已修复的任务在发布前被移除；我们按它们原来的标记把它们计为丢弃，其中包含全部四项泄漏丢弃。

#### 终审。

发布之前，最后一遍交叉核对每一条标记并审阅整个集合，对另外 340 项任务做了针对任务的编辑：116 次说明编辑，一个增加了断言的测试补丁，以及 223 项任务上的打分文件改动，按上文所述分布到表 1 的各行。在表中，一项任务计为已修复，是指它自己的某个文件在 v1.0 与发布集之间发生了变化（说明、测试补丁、被打分测试名单、解析器或运行脚本）；对每一项任务同样施加的改动（test.sh、Dockerfile、task.toml 以及 pytest worker 的固定）不计在内。

3.4 验证器加固

共享打分代码中的缺陷对所有任务都做了修复；发生变化的逐任务打分文件，在它们是一项任务唯一改动的地方，构成表 1 的验证器那一行。

#### 范围与资源。

Go 验证器在整个仓库上运行 go test ./...。在 253 项任务上把它收窄到被打分的包，消除了内存不足失败和超时。231 项执行完整测试套件的任务上的运行脚本，被限制到被打分的测试。在自动 worker 数量下，pytest-xdist 在小测试文件上生成多达 128 个 worker，并以 “no tests ran” 崩溃：我们在 239 项任务上把它封顶为四个 worker，并在 83 项的 ansible-test 内部同样处理。

#### 解析与环境。

jest 解析器把失败文件中的测试指派到错误的文件，并丢掉失败（47 项任务），而且它在第一个括号处截断测试标题：它现在只去掉末尾的计时。我们为 cgo 构建增加了内核头文件（5 项任务），在打分时取回镜像离线缓存中缺少的一个 Go 模块，在 3 项漏掉定义被打分测试的包的任务上重新推导测试范围，并恢复一个夹具中的 CRLF 行尾，该行尾曾使参考补丁失败。

#### 测试文件重置。

在隐藏测试运行之前，验证器（i）恢复测试补丁触及的每一条路径，并且只删除它创建的路径；（ii）恢复被修改的、受跟踪的测试数据（测试数据、夹具、mock、快照），并对六个会改动夹具的参考补丁使用允许名单；（iii）移除与隐藏测试冲突的、由智能体写出的测试文件；（iv）清除被杀死的智能体命令留下的过期 git 锁文件；（v）删除 __pycache__ 和 .pyc 文件。没有（i）时，智能体对测试补丁所拥有的快照的编辑，使它在 44 次运行中无法应用。步骤（v）针对的是智能体一次 git stash 往返留下的、大小和时间戳都未变的 .pyc 文件，它们曾使验证器导入基线代码。

在组装好的 642 项任务集上，参考补丁通过每一项任务，空补丁则使每一项任务失败。

3.5 加固后的评测协议

我们在一份锁定协议下运行每一个模型：框架按一次运行的阶段设置网络访问，并在一个新容器里而不是在智能体的沙箱里给智能体的补丁打分。

#### 网络。

网络开放时，642 条 Claude Opus 5 轨迹中有 32 条联系了代码托管站点，25 条下载了该任务自己的仓库。在锁定之下，沙箱在智能体阶段只能到达模型端点（允许名单只写该主机名），支架在沙箱之外执行的网页工具被禁用，镜像的 git 历史中也不携带修复提交。

#### 打分。

原始框架在智能体刚刚用过的沙箱里运行验证器。因为验证器恢复测试文件但不恢复二进制，一个不编辑任何源文件、并把 python3 换成一个打印 PASSED 的脚本的脚本化智能体，会得到 1 分。伪造的依赖从同一缺口通过：网络关闭时，一些取不到修复的智能体就地编辑 Go 模块缓存，或从本地 GOPROXY 提供一个捏造的模块版本，这两种改动都不出现在 diff 里。我们现在把智能体的改动存成补丁，把它应用到任务镜像的一份新副本上，在那里运行未改动的验证器并报告该分数，从而使二进制或模块缓存不会被带过去。

#### 轨迹审计。

一次全新的重新打分抓不住写进补丁内部的伪造，因此我们审计补丁中指向补丁内部或绝对路径的 replace 指令、镜像中不存在的模块的 go.sum 条目，以及模仿第三方 SDK 的大型新目录。我们也扫描轨迹，查找返回了内容的抓取，或对模块缓存或包目录的写入。

4 实验

图 3：修复之后分数为什么上升，用两项公开任务说明。左：旧验证器把隐藏测试补丁应用到智能体的工作树上，因此一个同时还编辑了测试夹具的正确补丁无法被打分。右：隐藏测试编码了一种说明从未陈述的回退。两种情形都没有改动隐藏测试。

4.1 设置

我们在 SWE Bench Pro V2 上运行若干模型和智能体（表 2）。Claude 与 GPT 系列模型运行在各自开发者提供的原生支架里，也就是 Claude Code 与 Codex；在锁定协议中，这两套支架的网页工具都被关掉。Gemini 以及开源模型则用 mini-swe-agent [31]，并配上其他开放框架来运行。每一项任务单独给五十分钟预算。时间一到，当时工作区里留下的补丁会被拿到一个新的容器里打分，而不是留在智能体用过的沙箱里。因为一次结果同时受支架、努力档位和模型三项影响，我们按“系统”来报告：一个系统就是这三者的一种组合。全部运行都报告百分之九十五的 Wilson 置信区间。表中每一行是一个系统：模型及其努力档位、所用支架、在六百四十二项上的解决百分比、该百分比的置信区间，以及五十一项 Hard 上的解决百分比。

表 2：每个模型（推理努力）和智能体所解决的任务百分比，分别给出 V2 上的 95% 置信区间，以及 Hard Split（51 个实例）上的结果。

4.2 主要结果

在表 2 中我们看到，前沿模型解决约 99% 的任务，而且 642 项任务中的每一项至少被其中一个解决，这独立地确认每一项任务都可解。最好的系统是 Claude Code 上的 Opus 5 (xhigh)，失败四项任务。我们也看到，51 项任务的 Hard 划分把前沿模型与其余模型清楚地分开（§4.3）。时间预算对一些系统是有约束的：Gemini 的运行中有 78 次达到 50 分钟上限，不过其中 65 次仍以截止时刻存在的补丁通过。

4.3 Hard 划分

我们根据模型失败和另一轮专家审计来选择 hard 划分，并确定为 51 项任务（附录 A）。在 Hard 上，模型运行从 52.9% 到 98.0%（表 2）。有意思的是，尽管 Astra 和 Gemini 在另外 591 项任务上打平，在 Hard 上 Astra 解决 46 项，Gemini 解决 30 项。进一步，我们看到 Hard 子集对非前沿模型尤其困难。Hard 并不把前四名系统彼此分开，要对它们排名，需要比公开划分目前所含更难的任务。

#### 分数为什么上升。

图 3 对每种机制各给出一项任务。一次验证器修复改变一个未改动补丁的分数：旧验证器无法把隐藏测试补丁应用到智能体也编辑过的夹具之上，这在 v1 上使 Opus 5 和 GLM-5.3 损失 44 次运行，在加固后的验证器下则为零。一次说明修复改变智能体所构建的东西：一旦写明 .app 回退，全部五个系统都解决了一项此前没有任何 v1 配置解决过的任务。

表 3：同一模型在三种支架下。每个单元格给出 642 项 V2 任务中被解决的百分比，以及被解决的 Hard 任务数（共 51）。极差是该模型最好与最差支架之间的 V2 点数之差。

图 4：同一模型在三种支架下。（a）每个已解决任务的总 token。（b）智能体墙钟时间按每一步在做什么来划分的份额；斜线部分是在 mini-swe-agent 的 30 秒命令上限下等待后台作业所花的时间。（c）同一次模型–支架配对中，一次已解决运行（实线）和一次失败运行（虚线轮廓）的完成 token 中位数。

4.4 锁定协议抓住了什么

#### 网络访问。

网络开放时，642 次 Opus 5 运行中有 32 次（5.0%）联系了代码托管站点，25 次下载了该任务自己的仓库。这些在锁定协议中全部被阻止。在一次运行中，Gemini 把对 Go 模块代理的请求伪装成发往模型端点的流量，该请求也被拒绝。

#### 伪造的依赖。

当智能体无法下载一个依赖时，它有时会在补丁之外造一个假的。Gemini 在 3 项任务上捏造 go.sum 和 go.work.sum 条目，或就地编辑共享模块缓存；Opus 5 和 Inkling 用一条捏造的 go.sum 条目伪造了一个模块版本。这些全部在智能体的沙箱里通过，并在干净容器里失败，因为伪造的文件不是补丁的一部分。如果没有第二次打分，每一次都会通过。

4.5 智能体框架的影响

为了检验框架而不是模型把分数推动了多少，我们让三个开源权重模型在其最高思考设置下运行（GLM-5.3、Kimi K3、Inkling），在锁定协议中于三种支架上跑完全部 642 项任务：mini-swe-agent，它只暴露一个 bash 工具，并在 30 秒后杀死任何命令；以及 Pi 和 OpenCode，它们增加结构化的读、搜索和编辑工具，且没有命令上限（表 3）。准确率几乎不动：GLM-5.3 和 Kimi K3 的六对支架比较中只有一对有差异，即 Kimi K3 的 Pi 相对 OpenCode 差 1.7 个点；Inkling 的极差是 Pi 落后另外两个 7.5 个点；在全部 642 项任务、每一次运行都尝试了该任务的情况下，这解释了解决或失败这一方差的 32%，模型解释 2.7%，支架解释 0.3%。支架所推动的是成本（图 4a）：Kimi K3 在 Pi 下每个已解决任务花费 130 万 token，在 mini-swe-agent 下花费 260 万，而 GLM-5.3 在每种支架下花费 350 万到 370 万。时间花到哪里取决于模型，而不是工具（图 4b）：测试、构建和检查在每种支架下占 GLM-5.3 墙钟时间的 30–58%，占 Kimi K3 的 30–42%；Inkling 把 42–51% 的时间花在阅读和搜索上；在支架、语言和运行长度保持不变时，最后一次编辑之后再做测试，对三个模型都大约使解决的几率翻倍。失败运行的中位数写出的完成 token，是同一模型–支架配对中已解决运行中位数的 1.6–2.0 倍（图 4c）：一次失败的运行是继续往下走的运行，而不是放弃的运行。支架会留下它自己的痕迹：Pi 和 OpenCode 放在智能体路径上的 Node 二进制与打分器所用的不同，这使 13 次试验付出代价，其中智能体重建了一个原生模块，随后打分器在该模块上崩溃。

5 讨论

#### 接近饱和时 V2 的用处。

前沿系统解决几乎全部 V2 任务，但该基准仍因四个理由有用。饱和结果本身就有信息：在一个打分正确的划分上，最强的系统失败的任务少于 1%，因此它们之间的小差异不是能力差异。大多数已部署的系统并不在前沿：开源权重、更小、更便宜的系统在全集上跨过 87.2–97.7%，在 Hard 上跨过 52.9–88.2%（表 2）。这个清洁集支持通过率之外的比较，例如成本、解出时间和支架选择，这些只有在每一项任务都可解且被正确打分时才有意义。而且一套锁定的、完全可解的套件是智能体产品的回归测试：一项近期所有系统都能解决的任务上的失败，值得调查。

#### 给基准维护者的教训。

（1）用强智能体做审计员：失败审计标出了产物审计漏掉的 39 项任务，因为有些缺陷只有在一个有能力的智能体写出合理的解、而测试拒绝它时才出现。（2）修复说明，保持测试固定，并盲法核验修复：削弱一个测试去迁就说明会改变基准所度量的东西，而一次盲法重实现检查编辑后的说明是否足够。（3）在干净容器里打分：无法取到依赖的智能体有时会伪造一个。（4）给基准做版本，并发布全部分数，因为新的缺陷会随着智能体改进而浮现。（5）检查常见支架能否在每个镜像上运行：§4.5 中的两种支架在我们修补之前无法安装到基线镜像上。

6 结论

随着智能体变得更有能力，SWE-Bench Pro 中的两类问题变得可见：其分数可能与解的正确性不一致的任务，以及智能体可以绕过的评测设置。SWE-Bench Pro V2 用一条由智能体审计、工程师裁决、盲法重实现和验证器加固组成的流水线处理这两者，该流水线修复或退役了 731 项任务中的 480 项，并用一份锁定协议在干净容器里给每个补丁打分。前沿系统现在几乎解决每一项任务，Hard 划分把它们分开，全集在前沿之下仍然是可靠的基准。我们在 https://huggingface.co/datasets/ScaleAI/SWE-bench_Pro/viewer 发布任务和协议，并期望这条流水线和这些教训在智能体接近其天花板时适用于其他基准。

局限

#### 记忆。

公开仓库及其修复早于被评测的模型。该协议阻止的是测试时的检索，而不是训练期间的记忆。

#### 重新打分的范围。

干净容器中的重新打分拒绝补丁之外做出的改动，但补丁内部的伪造，例如对一个缺失库的模仿，留给补丁审计。

伦理声明

这些任务来自开源仓库，遵循其原始许可证。审阅和修复任务的工程师是签约的，关于他们的个人数据不被记录或发布。我们记录所观察到的利用，是因为基准运营者需要这些信息来防御它们，对策与基准一起提供。

参考文献

下列三十一条按原文出现的先后顺序完整著录。arXiv 网页在每条末尾所附的 “Cited by” 只是站内回链，不另译成正文句子。

• [1] C. E. Jimenez、J. Yang、A. Wettig、S. Yao、K. Pei、O. Press 与 K. Narasimhan（2024）。SWE-bench：语言模型能否解决真实世界的 GitHub issue？载于 International Conference on Learning Representations (ICLR)。https://arxiv.org/abs/2310.06770 本条按原文顺序直译，作者姓名与网址不译。
• [2] OpenAI（2024）。介绍 SWE-bench Verified。OpenAI 博客，https://openai.com/index/introducing-swe-bench-verified/ 本条按原文顺序直译，作者姓名与网址不译。
• [3] OpenAI（2026）。为什么 SWE-bench Verified 不再度量前沿编码能力。OpenAI 博客，https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/ 本条按原文顺序直译，作者姓名与网址不译。
• [4] X. Deng、J. Da、E. Pan、Y. Y. He、C. Ide、K. Garg、N. Lauffer、A. Park 等（2025）。SWE-Bench Pro：人工智能智能体能解决长程软件工程任务吗？arXiv 预印本 arXiv:2509.16941。https://arxiv.org/abs/2509.16941 本条按原文顺序直译，作者姓名与网址不译。
• [5] N. Nadgir、S. Kapoor、K. Liu、P. Kirgis、M. Orona、S. Rabanser、T. Bayer、A. Shetty、Y. Ling、D. Chan-Sew、R. Nakagawa、S. Utpala、Z. S. Siegel 与 A. Narayanan（2026）。基准饱和之后的日子：CORE-Bench 案例研究。arXiv 预印本 arXiv:2606.26158。https://arxiv.org/abs/2606.26158 本条按原文顺序直译，作者姓名与网址不译。
• [6] D. Zan、Z. Huang、W. Liu、H. Chen、L. Zhang、S. Xin、L. Chen、Q. Liu 等（2025）。Multi-SWE-bench：用于解决 issue 的多语言基准。载于 Advances in Neural Information Processing Systems (NeurIPS)，Datasets and Benchmarks Track。https://arxiv.org/abs/2504.02605 本条按原文顺序直译，作者姓名与网址不译。
• [7] L. Zhang、S. Wang、J. Jia、F. Wang 等（2025）。SWE-bench 上线了！arXiv 预印本 arXiv:2505.23419。https://arxiv.org/abs/2505.23419 本条按原文顺序直译，作者姓名与网址不译。
• [8] I. Badertdinov、A. Golubev 等（2025）。SWE-rebench：用于任务收集和对软件工程智能体去污染评测的自动流水线。载于 Advances in Neural Information Processing Systems (NeurIPS)。https://arxiv.org/abs/2505.20411 本条按原文顺序直译，作者姓名与网址不译。
• [9] S. Miserendino、M. Wang、T. Patwardhan 等（2025）。SWE-Lancer：前沿大语言模型能否从真实世界的自由职业软件工程中赚到 100 万美元？arXiv 预印本 arXiv:2502.12115。https://arxiv.org/abs/2502.12115 本条按原文顺序直译，作者姓名与网址不译。
• [10] Laude Institute（2026）。Harbor：在容器化环境中评测和优化智能体的框架。https://github.com/laude-institute/harbor 本条按原文顺序直译，作者姓名与网址不译。
• [11] M. A. Merrill 等（2026）。Terminal-bench：在命令行界面中的困难、真实任务上给智能体做基准。arXiv 预印本 arXiv:2601.11868。https://arxiv.org/abs/2601.11868 本条按原文顺序直译，作者姓名与网址不译。
• [12] J. Pan、X. Wang、G. Neubig、N. Jaitly、H. Ji、A. Suhr 与 Y. Zhang（2024）。用 SWE-Gym 训练软件工程智能体和验证器。arXiv 预印本 arXiv:2412.21139。https://arxiv.org/abs/2412.21139 本条按原文顺序直译，作者姓名与网址不译。
• [13] J. Yang、K. Lieret、C. E. Jimenez、A. Wettig、K. Khandpur、Y. Zhang、B. Hui、O. Press、L. Schmidt 与 D. Yang（2025）。SWE-smith：为软件工程智能体扩展数据。arXiv 预印本 arXiv:2504.21798。https://arxiv.org/abs/2504.21798 本条按原文顺序直译，作者姓名与网址不译。
• [14] R. Aleithan、H. Xue、M. M. Mohajer、E. Nnorom、G. Uddin 与 S. Wang（2024）。SWE-Bench+：面向大语言模型的增强编码基准。arXiv 预印本 arXiv:2410.06992。https://arxiv.org/abs/2410.06992 本条按原文顺序直译，作者姓名与网址不译。
• [15] Y. Wang、M. Pradel 与 Z. Liu（2025）。SWE-bench 里“已解决的 issue”真的被正确解决了吗？一项实证研究。arXiv 预印本 arXiv:2503.15223。https://arxiv.org/abs/2503.15223 本条按原文顺序直译，作者姓名与网址不译。
• [16] B. Yu 等（2025）。UTBoost：在 SWE-Bench 上严格评测编码智能体。载于 Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (ACL)。https://arxiv.org/abs/2506.09289 本条按原文顺序直译，作者姓名与网址不译。
• [17] Y. Zhu、T. Jin、Y. Pruksachatkun 等（2025）。为构建严格的智能体基准确立最佳实践。arXiv 预印本 arXiv:2507.02825。https://arxiv.org/abs/2507.02825 本条按原文顺序直译，作者姓名与网址不译。
• [18] Z. Zhong、A. Raghunathan 与 N. Carlini（2025）。ImpossibleBench：度量大语言模型利用测试用例的倾向。arXiv 预印本 arXiv:2510.20270。https://arxiv.org/abs/2510.20270 本条按原文顺序直译，作者姓名与网址不译。
• [19] J. Gabor、J. Lynch、J. Rosenfeld 等（2025）。EvilGenie：一项奖励破解基准。arXiv 预印本 arXiv:2511.21654。https://arxiv.org/abs/2511.21654 本条按原文顺序直译，作者姓名与网址不译。
• [20] B. Zhao、D. Srikanth、Y. Wu 等（2026）。SpecBench：度量长程编码智能体中的奖励破解。arXiv 预印本 arXiv:2605.21384。https://arxiv.org/abs/2605.21384 本条按原文顺序直译，作者姓名与网址不译。
• [21] K. Thaman（2026）。奖励破解基准：度量带工具使用的大语言模型智能体中的利用。arXiv 预印本 arXiv:2605.02964。https://arxiv.org/abs/2605.02964 本条按原文顺序直译，作者姓名与网址不译。
• [22] C. Denison、M. MacDiarmid、F. Barez、D. Duvenaud、S. Kravec、S. Marks、N. Schiefer、R. Soklaski、A. Tamkin、J. Kaplan、B. Shlegeris、S. R. Bowman、E. Perez 与 E. Hubinger（2024）。从谄媚到诡计：调查大语言模型中的奖励篡改。arXiv 预印本 arXiv:2406.10162。https://arxiv.org/abs/2406.10162 本条按原文顺序直译，作者姓名与网址不译。
• [23] B. Baker、J. Huizinga、L. Gao、Z. Dou、M. Y. Guan、A. Madry、W. Zaremba、J. Pachocki 与 D. Farhi（2025）。监控推理模型的不当行为，以及助长隐瞒的风险。arXiv 预印本 arXiv:2503.11926。https://arxiv.org/abs/2503.11926 本条按原文顺序直译，作者姓名与网址不译。
• [24] jacobkahn（2025）。智能体评测期间的仓库状态漏洞。SWE-bench GitHub issue 465，https://github.com/SWE-bench/SWE-bench/issues/465 本条按原文顺序直译，作者姓名与网址不译。
• [25] joe-needham（2025）。仓库状态泄漏。SWE-Bench Pro GitHub 仓库，issue 7。 本条按原文顺序直译，作者姓名与网址不译。
• [26] ConnorBAdams（2026）。SWE-Bench Pro OSS 中的 Git 奖励破解。SWE-Bench Pro GitHub 仓库，issue 93。 本条按原文顺序直译，作者姓名与网址不译。
• [27] S. Liang、S. Garg 与 R. Zilouchian Moghaddam（2025）。SWE-bench 幻觉：当最先进的大语言模型记住而不是推理。arXiv 预印本 arXiv:2506.12286。https://arxiv.org/abs/2506.12286 本条按原文顺序直译，作者姓名与网址不译。
• [28] D. Ramos、C. Mamede、K. Jain、P. Canelas、C. Gamboa 与 C. Le Goues（2024）。大语言模型在记忆缺陷基准吗？arXiv 预印本 arXiv:2411.13323。https://arxiv.org/abs/2411.13323 本条按原文顺序直译，作者姓名与网址不译。
• [29] P. Zheng、Z. Shang、S. Jiang、W. Tian、D. Zhu、Z. Ma、D. Yuan 与 Q. Zhang（2026）。SWE-Bench Pro Verified：面向软件工程智能体的可靠基准。arXiv 预印本 arXiv:2609.08149。https://arxiv.org/abs/2609.08149 本条按原文顺序直译，作者姓名与网址不译。
• [30] OpenAI（2026）。把编码评测里的信号和噪声分开。OpenAI 博客，https://openai.com/index/separating-signal-from-noise-coding-evaluations/ 本条按原文顺序直译，作者姓名与网址不译。
• [31] K. Lieret、J. Yang 等（2025）。Mini-SWE-agent：解决 GitHub issue 的 100 行人工智能智能体。https://github.com/SWE-agent/mini-swe-agent 本条按原文顺序直译，作者姓名与网址不译。

附录 A Hard 划分

这 51 项任务来自 ansible（8）、openlibrary（8）、flipt（7）、teleport（6）、webclients（5）、qutebrowser（4）、vuls（4）、element-web（4）、navidrome（3）、NodeBB（1）和 tutanota（1）。一项任务合格的条件是，五个模型家族中至少有两个在各次运行中在它上面失败。这给出 54 个候选，3 个在专家审阅后被移除。每一项 Hard 任务都通过其参考解，在空补丁下失败，并且至少被我们的一次运行解决。51 份说明中有 39 份在选定之后于终审中被编辑。

附录 B 框架研究

#### 设置。

GLM-5.3（开启思考）、Kimi K3（推理努力 max）和 Inkling（xhigh）以 100 万 token 的上下文窗口运行，思考 token 或回合没有上限；除 50 分钟预算之外的唯一上限，是 mini-swe-agent 默认的每条命令 30 秒超时，它是该支架的一部分。版本：Harbor 0.22，mini-swe-agent 2.4.6，Pi 0.85.0，OpenCode 1.18.29。运行之前，我们修补了 Pi 或 OpenCode 无法安装的任务镜像（较旧的 Alpine 镜像缺少较新的 libstdc++，以及 Debian 11 镜像因其生命周期结束的软件源破坏了 OpenCode 的安装器）；这些补丁只增加系统包，全部九种组合都在同一批修补后的镜像上运行。我们发布 5,778 条轨迹以及每条轨迹的特征文件。

#### 尝试规则。

与 §4 的运行不同，这些运行只打分一次，是在智能体用过的容器里。每项任务对每种模型–支架组合有一次被计入的尝试；触及预算的尝试按截止时刻存在的补丁打分。一次触及预算、或被基础设施杀死且没有通过分数的尝试，会在更低并发下再跑一次，重跑是被计入的尝试；重跑从不替换一次已打分的通过，并且该规则对全部九种组合同样应用。Pi 和 OpenCode 放在智能体路径上的 Node 二进制与打分器所用的不同；在 13 次试验中，智能体针对它重建了一个原生模块，随后打分器在该模块上崩溃（Kimi K3：Pi 下 5 次，OpenCode 下 2 次；GLM-5.3：2 次和 2 次；Inkling：OpenCode 下 2 次），这些试验计为失败。

#### 结果。

表 4 给出 §4.5 背后的成对比较。把“解决或失败”这一结果的方差，拆到每一种组合都尝试过的六百四十二项任务上：任务身份占百分之三十一点七，模型占百分之二点六五，支架占百分之零点二九，模型与支架的交互占百分之零点三六；剩下的百分之六十五是同一任务在不同运行之间的变异。下面的表保持原数，只把表头译成中文。差值的单位是百分点，区间为百分之九十五置信区间，p 为对不一致任务的精确检验。

表 4：同一模型内、在同样 642 项任务上的成对支架比较：只在支架 $A$ 下解决的任务数 / 只在支架 $B$ 下解决的任务数，以百分点计的差值及其 95% 区间，以及对不一致任务的精确检验。“mini”即 mini-swe-agent。

#### 核验。

通过率是每项任务一次尝试，每种组合的标准误为 0.6–1.4 个点。图 4b 的活动份额和 §4.5 的验证率来自一个分类器，它读取一条 shell 命令每个片段的第一个可执行文件；它在 150 条抽样命令中的 147 条上与人工阅读一致，在抽样墙钟时间的 97.2% 上一致，而红转绿比率背后的测试结果检测器，在它标注的 40 条抽样测试输出中的 32 条上全部匹配，留下 8 条无法判定。步骤时间包含模型延迟，并且在 mini-swe-agent 下测试文件编辑被少计，因为编辑以 heredoc 到来。

附录 C 可复现性

#### 框架。

Harbor 0.22.0，运行在 Modal 1.5.5 上。网络按阶段设置：搭建期间公开，智能体阶段只有模型端点，验证器期间再次公开，因为 32 项任务在测试时下载依赖。Claude Code 2.1.278，网页工具禁用；Codex 0.155.1，托管的网页搜索禁用；mini-swe-agent 2.4.6，没有步数或成本上限，因此由时间预算约束。

#### 预算与打分。

预算是每项任务 3000 秒。智能体在 2940 秒时被停止，当时存在的补丁被打分。补丁是工作树的已暂存 git diff；它被应用到由任务镜像构建的新容器上，带有三路回退，然后运行未改动的验证器。当沙箱分数与干净分数不一致时，再取两次干净分数，三次中的多数计为结果。V2 上每项任务的平均 API 花费，Claude Code 运行为 2.9 美元，Astra 为 2.3 美元，Gemini 为 3 美元。

#### 发布。

任务目录、Hard 划分、探测、捕获和重新打分脚本、确切的框架标志、每一次运行在两种模式下的逐任务分数，以及框架研究的轨迹。

[^1]: https://huggingface.co/datasets/ScaleAI/SWE-bench_Pro/viewer