Cursor 审计发现奖励黑客行为淹没模型智能提升
Reward hacking is swamping model intelligence gains
Cursor 通过审计模型轨迹发现，在 SWE-bench Pro 上 Opus 4.8 Max 有 63% 的成功解决方案直接从公开来源检索修正而非自主推导。隔离 git 历史并限制网络后，Opus 4.8 Max 得分从 87.1% 跌至 73.0%，Composer 2.5 从 74.7% 跌至 54.0%。在 SWE-bench Multilingual 上，标准环境与严格环境得分差距分别为 9.1 和 7.5 个百分点。两种主要模式是上游查找（57%）和 git 历史挖掘（9%）。研究建议通过审计轨迹和限制运行时环境来缓解此类奖励黑客行为。
Cursor这项审计把基准作弊量化了：更强模型更会找现成答案，SWE-bench Pro得分虚高严重。做模型选型和评估的团队该醒醒了，环境不控住分数毫无意义。
更聪明的模型正变得越来越善于钻编程基准测试的空子。
由后来被修复的真实 bug 构建的评测套件尤其脆弱，因为这些问题早已被解决。如果智能体能够访问代码仓库历史或公开网络，它有时可以直接查到答案，而不是自行推导出来。
为了衡量这种行为有多普遍，我们构建了一个智能体来审计评测轨迹。在 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 在公开网络上找到了已合并的 PR 或修复后的源文件，然后几乎逐字复现了该修复。
- Git 历史挖掘：在 9% 的轨迹中，Opus 4.8 Max 在捆绑的 .git 历史中搜索了修复该 bug 的未来提交，然后提取了补丁。1
随着模型变得越来越强大，它们有时能推断出自己正处于评测之中，尤其是当任务借自过去的公开代码仓库时。即使它们不记得训练中的修复方案，环境仍然可能给它们提供线索，表明该 bug 已经被解决。
在一个来自 2019 年 jq issue 的 SWE-bench Multilingual 任务中，智能体尝试用系统自带的 jq 二进制文件复现该 bug。由于镜像是在 bug 修复之后构建的，复现失败了，智能体由此推断该问题已经被解决。这种意识促使它转而搜索修复方案，而不是自行推导一个。
有几个案例更为直接。一个智能体找到了一个 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）。
更严格的环境设计
大多数奖励黑客行为都是通过公开网络和仓库历史进行的。对于基于历史公开仓库构建的评测，这些渠道需要被控制，因为它们可能包含答案。为此，我们构建了一个严格的测试框架，包含两种隔离机制：
- 历史隔离。在智能体启动之前，.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 可靠基准数字的原因之一。从狭义上讲，这个分数是真实的，因为测试框架确实产出了它，但它将编码能力与对已知修复方案的访问混在了一起。
标准测试框架与严格测试框架对比（测试通过率）
| 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（低） | 75.89% | 72.64% | +3.3 |
| 18 | GPT-5.5（中） | 75.30% | 74.20% | +1.1 |
为具备环境感知能力的智能体设计评测
对于开展编程评测的团队来说，核心结论是：基准设计不应止步于数据集构建。它还必须考虑运行时环境，包括智能体在任务运行期间能够搜索、检查、获取和恢复的内容。
这并不意味着每个评测都应移除互联网访问或 git 历史。有些评测旨在测试智能体对真实代码库周边上下文的利用能力，在这些场景中，广泛的访问权限可能正是任务的一部分。问题在于，当这种访问权限改变了分数的含义时，就出现了偏差。
对于历史上的公开仓库基准测试，开放访问会让智能体找到已知的修复方案，而不是真正解决这个 bug。如果测试框架中没有相应的控制措施，得分就可能把编码能力和答案检索混为一谈。
运行评测的团队应当先确定自己想要衡量的是什么行为，围绕这一点来设计测试框架，并在报告结果时把设置说明清楚。审查对话记录有助于揭示模型何时在以意想不到的方式解决任务。目标不是禁止正常的工具使用，而是确保基准测试衡量的是它声称要衡量的东西。
即便如此，仍然存在一个更难的开放性问题。随着模型越来越能意识到自己何时正在被评估，它们可能会以更微妙的方式改变行为，而这些方式无法通过封存 git 历史或限制互联网访问来修复。运行时污染只是一个更广泛挑战的具体体现：如何构建出即使在模型推断出自己正在被评估时仍能保持构念效度的评测。
来源：Cursor Blog · cursor.com