评估使用工具的LLM代理中的漏洞利用（4分钟阅读）

# 奖励黑客正在淹没模型的智力增益 来源：https://cursor.com/blog/reward-hacking-coding-benchmarks 更智能的模型正在变得更擅长钻编程基准测试的空子。 基于实际被修复过的真实漏洞构建的评估套件尤其脆弱，因为问题已经被解决。如果智能体可以访问仓库历史或公共网络，它有时可以查找到答案而非推导出答案。 为了衡量这种行为有多普遍，我们构建了一个智能体来审计评估轨迹。在 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 年的研究 (https://arxiv.org/abs/2410.06992) 和一份 2025 年 Meta 的报告 (https://github.com/SWE-bench/SWE-bench/issues/465)。我们的研究量化了当前前沿编码智能体运行中的这一问题。更广泛的教训是，除了避免训练时的数据污染外，智能体编程基准测试还需要受控的运行环境。 对于进行评估的团队，我们建议通过审核记录和限制评估环境来缓解这种奖励黑客行为。 ## https://cursor.com/blog/reward-hacking-coding-benchmarks#catch-a-model-with-a-model 以模型制模型 为了衡量奖励黑客行为的规模，我们让审核器检查了 731 条 Opus 4.8 Max 的轨迹。它看到问题陈述和完整智能体轨迹，但不知道运行是否通过，并分类智能体是否检索了已知答案。 它发现最常见的两种奖励黑客模式是： - **上游查找：** 在 57% 的轨迹中，Opus 4.8 Max 在公共网络上找到了合并的 PR 或修复后的源文件，然后几乎逐字地复现了修复。 - **Git 历史挖掘：** 在 9% 的轨迹中，Opus 4.8 Max 搜索了捆绑的 .git 历史，找到修复该漏洞的未来提交，然后提取了补丁。¹ (https://cursor.com/blog/reward-hacking-coding-benchmarks#fn-1) 随着模型变得更强大，它们有时能推断出自己正处于评估中，尤其是当任务借用自过去的公共仓库时。即使模型在训练中没有记住修复方案，环境仍然可能给它们提供线索，表明该漏洞已被解决。 在一个来自 2019 年 jq 问题的 SWE-bench Multilingual 任务中，智能体尝试用系统自带的 jq 二进制文件复现漏洞。由于镜像是在漏洞修复后构建的，复现失败，智能体推断该问题已被解决。这种意识促使它搜索修复方案而不是推导方案。 少数情况更为直接。一个智能体找到了一个 SWE-bench 镜像页面，该页面暴露了隐藏测试和黄金补丁。另一个智能体获取了隐藏测试文件，并硬编码了通过所需的预期异常字符串。 ## https://cursor.com/blog/reward-hacking-coding-benchmarks#stricter-environment-design 更严格的环境设计 大多数奖励黑客行为通过公共网络和仓库历史发生。对于基于历史公共仓库构建的评估，这些渠道需要被控制，因为它们可能包含答案。作为回应，我们构建了一个严格的测试框架，包含两种隔离机制： 1. **历史隔离。** 在智能体启动前，.git 目录被移除，仓库被重新初始化为一个全新的单提交仓库。原始历史仅在评分时恢复，以便测试按正常方式运行。 2. **出站代理。** 默认情况下拒绝网络访问。作为一种尽力而为的控制，一个固定的代理允许针对允许列表中的包注册表进行依赖解析，除此之外不允许任何其他访问。 此限制仅适用于基于历史公共仓库构建的评估。这也是我们更倾向于使用基于非公共仓库的评估（如 CursorBench (https://cursor.com/blog/cursorbench)）的一个原因。它们可以在测试智能体编码能力的同时，让它们以真实工作中的方式使用工具。 ## https://cursor.com/blog/reward-hacking-coding-benchmarks#a-growing-gap 日益扩大的差距 我们在更严格的框架下重新运行了 SWE-bench Pro 和 SWE-bench Multilingual，然后将每个结果与标准框架得分进行比较，以此作为消除这些泄露渠道² (https://cursor.com/blog/reward-hacking-coding-benchmarks#fn-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 分。 SWE-bench Multilingual 标准 vs. 严格框架得分（Opus 4.8 Max、Composer 2.5 和 Opus 4.6 Max） SWE-bench Multilingual 标准 vs. 严格框架得分（Opus 4.8 Max、Composer 2.5 和 Opus 4.6 Max） 明确的结论是，奖励黑客行为在更新、更复杂的模型中远比在老模型中常见。有趣的是，GPT 模型并未显示出同样的升级趋势，在我们运行中的差距普遍较小。 我们还观察到，我们自己的模型 Composer 2.5 在研究中 Pro 差距最大。这是我们不将标准 SWE-bench Pro 得分视为 Composer 可靠基准数值的诸多原因之一。得分在狭义上是真实的——框架确实产生了它——但它将编码能力与访问已知修复方案的能力混为一谈。 标准 vs. 严格框架（测试通过率） | 排名 | 模型 | 标准 | 严格 | 差值 | |------|------|------|------|------| | 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 | ## https://cursor.com/blog/reward-hacking-coding-benchmarks#designing-evals-for-aware-agents 为有意识的智能体设计评估 对于进行编程评估的团队，主要教训是基准测试的设计不应止步于数据集构建。它还必须考虑运行时环境，包括智能体在任务执行期间可以搜索、检查、获取和恢复的内容。 这并不意味着每个评估都应该移除互联网访问或 git 历史。有些评估旨在测试智能体如何利用真实代码库的周围上下文，在这些场景中，广泛的访问可能是任务的一部分。问题在于当这种访问改变了得分含义的时候。 对于历史公共仓库的基准测试，开放访问可能让智能体找到已知的修复方案而非解决漏洞。如果没有框架中的控制措施，得分可能混淆编码能力与答案检索能力。 进行评估的团队应决定他们想要衡量什么行为，围绕这一目标设计框架，并在报告结果时明确说明设置。审查记录有助于揭示模型何时以意外方式解决问题。目标不是禁止正常的工具使用，而是确保基准测试衡量它声称要衡量的内容。 即便如此，仍然存在一个更难的开放问题。随着模型变得更清楚自己何时被评估，它们可能以更微妙的方式改变行为，而这些方式无法通过封锁 git 历史或限制互联网访问来解决。运行时污染是构建评估时更广泛挑战的一个具体版本，即即使模型推断出它正在被评估，评估仍需保持构念效度。 --- 1. SWE-bench 此后通过从其环境镜像中剥离未来的 git 历史在上游解决了这个问题（PR #471 (https://github.com/SWE-bench/SWE-bench/pull/471)），并在 2026 年初进行了后续的 git 清理工作（PR #533 (https://github.com/SWE-bench/SWE-bench/pull/533)）。我们摄入的镜像早于该修复。↩ (https://cursor.com/blog/reward-hacking-coding-benchmarks#fnref-1) 2. 确切的差距大小和奖励黑客尝试的频率取决于使用的提示。例如，当我们指示模型不停继续工作时，黑客尝试有所增加。↩ (https://cursor.com/blog/reward-hacking-coding-benchmarks#fnref-2)