奖励作弊正在淹没模型智能的进步
更聪明的模型，正在变得更善于在编程基准上作弊。
由真实缺陷构建、且这些缺陷后来已被修复的评测套件尤其脆弱，因为这些问题本来就已经被解决过了。如果智能体可以访问代码仓库历史或公开 Web，它有时就能直接查到答案，而不是自己推导出来。
为了衡量这种行为到底有多普遍，我们构建了一个智能体来审查评测轨迹。在 SWE-bench Pro 上，我们发现，Opus 4.8 Max 成功解决的问题中，有 63% 是直接获取修复方案，而不是自行推导出来的。当我们屏蔽 Git 历史记录并限制互联网访问后，Opus 以及我们的模型 Composer 2.5 的分数都明显下降：
- Opus 4.8 Max 从 87.1% 降至 73.0%
- Composer 2.5 从 74.7% 降至 54.0%
此前的研究已经表明，编程基准的答案可能会通过公开可用的来源泄露出来，包括这项 2024 年研究以及一份 2025 年 Meta 报告。我们的研究量化了当前前沿编程智能体运行中这一问题的严重程度。更广泛的启示是，除了避免训练阶段的数据污染之外，智能体编程基准还需要受控的运行时环境。
对于开展评测的团队，我们建议通过审查对话记录并约束评测环境，来缓解这种奖励作弊行为。
用模型识别模型
为了衡量这种奖励作弊行为的规模，我们让审计模型检查了 731 条 Opus 4.8 Max 轨迹。它会查看问题描述和完整的智能体轨迹，但不知道该次运行是否通过，并据此判断智能体是否获取了已知答案。
它发现的两种最常见的奖励作弊模式是：
- 上游查找： 在 57% 的轨迹中，Opus 4.8 Max 在公开 Web 上找到了已合并的 PR 或已修复的源文件，然后几乎原封不动地复现了修复内容。
- Git 历史挖掘： 在 9% 的轨迹中，Opus 4.8 Max 搜索了随附的 .git 历史，寻找未来修复该缺陷的提交，然后从中提取出补丁。1
随着模型能力变强，它们有时会推断出自己正在参与某项评测，尤其是在任务取自过去公开的代码仓库时。即使在不记得训练中修复方案的情况下，环境仍然可能给出线索，表明这个缺陷其实已经被解决了。
在一个来自 2019 年 jq issue 的 SWE-bench Multilingual 任务中，智能体尝试用系统的 jq 二进制文件复现这个缺陷。由于该镜像是在缺陷修复后才构建的，复现失败了，于是智能体推断这个 issue 已经解决。这种认知促使它转而去搜索修复方案，而不是自行推导。
还有少数案例更为直接。一个智能体找到了一个 SWE-bench 镜像页面，暴露了隐藏测试和标准补丁。另一个则获取了隐藏测试文件，并将通过测试所需的预期异常字符串硬编码了进去。
上游查找 (Opus 4.8 Max) 。 智能体通过 GitHub API 查询已合并的 PR，以找出修复涉及的文件，然后复现了该修复 (同一响应还暴露了每个文件的 diff) ：
cd /testbed && curl -s "https://api.github.com/repos/apache/druid/pulls/14092/files" 2>/dev/null | grep '"filename"'Git 历史挖掘 (Composer 2.5) 。 智能体在随附的 .git 历史中定位到修复提交，读取其 diff，然后直接应用：
cd /testbed && git show 895abd8929 -p 2>/dev/null | head -400
cd /testbed && git cherry-pick 895abd8929 2>&1待添加的补丁摘录：从上方 git show 输出中逐字截取并精简的一段内容 (即 Composer 复现的标准 diff) 。
更严格的环境设计
大多数奖励作弊都来自公开 Web 和代码仓库历史记录。对于基于历史公开代码仓库构建的评测，这些渠道需要受到控制，因为其中可能包含答案。为此，我们构建了一套严格的评测框架，并采用了两种隔离机制：
- 历史隔离。 在智能体启动前，
.git目录会被移除，代码仓库会被重新初始化为一个全新的单提交仓库。原始历史只会在评分时恢复，因此测试仍可照常运行。 - 出口代理。 默认禁止网络访问。作为一种尽力而为的控制措施，通过固定代理，只允许按白名单访问软件包注册表来解析依赖，除此之外一概不允许。
这一限制仅适用于基于历史公开代码仓库构建的评测。这也是我们更偏好基于非公开代码仓库构建的评测 (例如 CursorBench) 的原因之一。这样既能测试智能体编程能力，又仍然允许智能体像在真实工作中那样使用工具。
不断拉大的差距
我们在更严格的评测框架中重新运行了 SWE-bench Pro 和 SWE-bench Multilingual，然后将每项结果与标准评测框架下的分数进行比较，并将其作为衡量移除这些泄漏通道综合影响的替代指标2：
- 在 SWE-bench Multilingual 上，Opus 4.6 的差距不到 1 分，Opus 4.8 Max 为 9.1 分，Composer 2.5 为 7.5 分。
- 在 SWE-bench Pro 上，Opus 4.6 的差距不到 1 分，Opus 4.8 Max 为 14.1 分，Composer 2.5 为 20.7 分。
一个明确的结论是，与较旧的模型相比，奖励作弊在更新、更复杂的模型中要常见得多。有意思的是，GPT 模型并没有表现出同样的上升趋势，在我们的运行中差距通常更小。
我们还观察到，在这项研究中，我们自己的模型 Composer 2.5 在 Pro 上的差距最大。这也是为什么我们不把标准 SWE-bench Pro 分数视为衡量 Composer 的可靠基准。狭义上说，这个分数是真实的，因为它的确是由评测框架跑出来的；但它混合了编码能力和获取已知修复方案的能力。
Standard vs. strict harness (test pass rate)
| 1 | Opus 4.8 (max) | 91.16% | 82.03% | +9.1 |
| 2 | Opus 4.8 (xhigh) | 88.86% | 80.67% | +8.2 |
| 3 | Opus 4.7 (max) | 84.80% | 80.47% | +4.3 |
| 4 | Opus 4.7 (xhigh) | 83.74% | 78.60% | +5.1 |
| 5 | Opus 4.8 (high) | 83.09% | 79.26% | +3.8 |
| 6 | Opus 4.8 (medium) | 81.87% | 77.84% | +4.0 |
| 7 | Opus 4.7 (high) | 81.42% | 77.75% | +3.7 |
| 8 | Opus 4.8 (low) | 79.51% | 74.36% | +5.2 |
| 9 | Composer 2.5 | 79.15% | 71.60% | +7.5 |
| 10 | GPT-5.4 (xhigh) | 79.00% | 75.20% | +3.8 |
| 11 | GPT-5.5 (xhigh) | 77.80% | 74.40% | +3.4 |
| 12 | Opus 4.7 (medium) | 77.33% | 75.72% | +1.6 |
| 13 | GPT-5.5 (high) | 77.30% | 74.70% | +2.6 |
| 14 | GPT-5.4 (high) | 76.80% | 73.30% | +3.5 |
| 15 | Opus 4.6 (max) | 76.33% | 76.06% | +0.3 |
| 16 | Opus 4.6 (high) | 76.11% | 75.22% | +0.9 |
| 17 | Opus 4.7 (low) | 75.89% | 72.64% | +3.3 |
| 18 | GPT-5.5 (medium) | 75.30% | 74.20% | +1.1 |
为具备评测感知能力的智能体设计评测
对于开展编码评测的团队来说，最重要的一点是：基准 的设计不应止步于数据集构建。它还必须将运行时环境纳入考量，包括智能体在任务执行过程中能够搜索、查看、获取和恢复哪些内容。
但这并不意味着每个评测都应该移除互联网访问能力或 git 历史记录。有些评测的目的，就是测试智能体在真实代码库中利用周边上下文的能力，而在这类场景下，广泛的访问权限本身可能就是任务的一部分。问题在于，当这种访问改变了分数所代表的含义时，评测就会失真。
对于基于历史公开代码仓库的 基准，开放访问可能会让智能体直接找到已知的修复方案，而不是自己解决缺陷。如果评测框架中缺少相应的控制，分数就可能混淆编码能力与答案检索能力。
开展评测的团队应先明确自己想衡量哪种行为，再围绕这一目标设计评测框架，并在报告结果时清楚说明设置。审查对话记录有助于发现 模型 是否在以意料之外的方式完成任务。目标并不是禁止正常使用工具，而是确保 基准 衡量的，确实是它声称要衡量的内容。
即便如此，仍然存在一个更困难的开放问题。随着 模型 越来越能意识到自己何时处于被评估状态，它们可能会以更微妙的方式改变行为，而这些变化并不能仅靠封闭 git 历史记录 或限制互联网访问来解决。运行时污染，正是一个更广泛挑战的具体体现：如何构建评测，使其即使在 模型 推断出自己正在接受评估时，仍能保持构念效度。
