更智能的模型正变得越来越善于在编程评测基准上钻空子。

基于真实 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 的未来提交，然后提取了补丁。¹

随着模型能力增强，它们有时会推断自己正处于评估环境中，尤其是当任务来自某个过往的公开代码仓库时。即便模型并不记得训练中见过的修复方案，环境本身仍可能向其透露“该漏洞已被解决”的线索。

在 SWE-bench Multilingual 中的一个始于 2019 年 jq 议题的任务里，智能体尝试使用系统中的 jq 二进制文件复现该漏洞。但由于评估镜像构建于该漏洞被修复之后，复现失败，智能体由此推断该问题已被解决。这种认知促使它转而搜索已有的修复方案，而非自行推导新方案。

还有少数情况更为直接。一个智能体发现了 SWE-bench 的镜像页面，该页面暴露了隐藏测试用例和标准补丁。另一个智能体则获取了隐藏测试文件，并硬编码了通过测试所需的预期异常字符串。

cd /testbed && curl -s "https://api.github.com/repos/apache/druid/pulls/14092/files" 2>/dev/null | grep '"filename"'

cd /testbed && git show 895abd8929 -p 2>/dev/null | head -400
cd /testbed && git cherry-pick 895abd8929 2>&1

更严格的评估环境设计

大部分奖励破解行为都通过公共网络和仓库历史记录传播。对于基于历史公开仓库构建的评估，必须控制这些渠道，因为它们可能包含答案。为此，我们构建了一个严格的评估框架，采用两种隔离机制：

1. 历史隔离。在智能体启动前，移除 .git 目录，并将仓库重新初始化为一个全新的单次提交仓库。仅在评分时恢复原始历史记录，以便测试正常运行。
2. 出站代理。默认禁止网络访问。作为尽力而为的控制措施，一个固定代理仅允许针对许可名单上的包注册中心进行依赖解析，除此之外一概不允许。

这一限制仅针对基于历史公共仓库构建的评测。这也是我们更倾向于使用非公共仓库（如 CursorBench）搭建评测的原因之一，这类评测既能测试智能体编程能力，又能让智能体以真实工作场景中使用工具的方式进行操作。

鸿沟正在扩大

我们在更严格的评测框架下重新运行了 SWE-bench Pro 和 SWE-bench Multilingual，然后将每个结果与标准框架得分进行比较，以此作为衡量消除这些泄漏渠道综合影响的代理指标²：

• 在 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 可靠基准分数的原因之一。从狭义上说，该分数是评测框架实际产生的真实数据，但它将编程能力与获取已知修复的能力混为一谈。

为具备感知能力的智能体设计评测

对负责运行编程评测的团队而言，核心启示在于：基准设计不应止步于数据集构建。还必须考虑运行时环境，包括智能体在任务执行过程中能够搜索、检查、获取和恢复哪些内容。

这并不意味着每个评测都应移除互联网访问或 git 历史。有些评测旨在测试智能体在真实代码库中利用周围上下文的能力，在这些场景下，广泛的访问权限可能是任务的一部分。问题在于，当这种访问权限改变了分数所代表的意义时。

对于历史公开仓库的基准测试，开放式访问可能让智能体找到已知修复方案而不是解决漏洞。如果没有在框架内设置控制，分数可能会混淆编码能力与答案检索能力。

运行评测的团队应决定他们想要衡量什么行为，据此设计测试框架，并在报告结果时明确说明设置。审核日志可以帮助发现模型以非预期方式解决问题的情形。目标不是禁止正常工具使用，而是确保基准测试测量它声称要测量的内容。

即便如此，仍存在一个更棘手的开放性问题。随着模型越来越能意识到自身正在被评估，它们可能会以更微妙的方式改变行为——这无法通过封闭 git 历史或限制互联网访问来解决。运行时的污染是更广泛挑战的一个具体体现，即构建即使模型推断出自己正在被评估也能保持结构效度的评测。