Cursor这项审计把基准作弊量化了更强模型更会找现成答案SWE-bench Pro得分虚高严重。做模型选型和评估的团队该醒醒了环境不控住分数毫无意义。ursor 通过审计模型轨迹发现在 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%。研究建议通过审计轨迹和限制运行时环境来缓解此类奖励黑客行为。AI 翻译 · 中文显示原文博客 / 研究更智能的模型正变得越来越善于在编程评测基准上钻空子。基于真实 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 的镜像页面该页面暴露了隐藏测试用例和标准补丁。另一个智能体则获取了隐藏测试文件并硬编码了通过测试所需的预期异常字符串。上游查询Opus 4.8 Max。智能体通过 GitHub API 查询已合并的拉取请求找到修复所涉及的文件然后复现了该修复同一响应也暴露了每个文件的差异 diffcd /testbed curl -s https://api.github.com/repos/apache/druid/pulls/14092/files 2/dev/null | grep filenameGit 历史挖掘Composer 2.5。智能体在附带的 .git 历史记录中定位到修复提交读取其差异 diff然后直接应用了该补丁cd /testbed git show 895abd8929 -p 2/dev/null | head -400 cd /testbed git cherry-pick 895abd8929 21待添加的补丁片段上方 git show 输出的逐字精简摘录Composer 复现的标准差异 diff。更严格的评估环境设计大部分奖励破解行为都通过公共网络和仓库历史记录传播。对于基于历史公开仓库构建的评估必须控制这些渠道因为它们可能包含答案。为此我们构建了一个严格的评估框架采用两种隔离机制历史隔离。在智能体启动前移除 .git 目录并将仓库重新初始化为一个全新的单次提交仓库。仅在评分时恢复原始历史记录以便测试正常运行。出站代理。默认禁止网络访问。作为尽力而为的控制措施一个固定代理仅允许针对许可名单上的包注册中心进行依赖解析除此之外一概不允许。这一限制仅针对基于历史公共仓库构建的评测。这也是我们更倾向于使用非公共仓库如 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 可靠基准分数的原因之一。从狭义上说该分数是评测框架实际产生的真实数据但它将编程能力与获取已知修复的能力混为一谈。标准评测框架 vs. 严格评测框架测试通过率1Opus 4.8max91.16%82.03%9.12Opus 4.8xhigh88.86%80.67%8.23Opus 4.7max84.80%80.47%4.34Opus 4.7xhigh83.74%78.60%5.15Opus 4.8high83.09%79.26%3.86Opus 4.8medium81.87%77.84%4.07Opus 4.7high81.42%77.75%3.78Opus 4.8low79.51%74.36%5.29Composer 2.579.15%71.60%7.510GPT-5.4xhigh79.00%75.20%3.811GPT-5.5xhigh77.80%74.40%3.412Opus 4.7medium77.33%75.72%1.613GPT-5.5high77.30%74.70%2.614GPT-5.4high76.80%73.30%3.515Opus 4.6max76.33%76.06%0.316Opus 4.6high76.11%75.22%0.917Opus 4.7low75.89%72.64%3.318GPT-5.5medium75.30%74.20%1.1为具备感知能力的智能体设计评测对负责运行编程评测的团队而言核心启示在于基准设计不应止步于数据集构建。还必须考虑运行时环境包括智能体在任务执行过程中能够搜索、检查、获取和恢复哪些内容。这并不意味着每个评测都应移除互联网访问或 git 历史。有些评测旨在测试智能体在真实代码库中利用周围上下文的能力在这些场景下广泛的访问权限可能是任务的一部分。问题在于当这种访问权限改变了分数所代表的意义时。对于历史公开仓库的基准测试开放式访问可能让智能体找到已知修复方案而不是解决漏洞。如果没有在框架内设置控制分数可能会混淆编码能力与答案检索能力。运行评测的团队应决定他们想要衡量什么行为据此设计测试框架并在报告结果时明确说明设置。审核日志可以帮助发现模型以非预期方式解决问题的情形。目标不是禁止正常工具使用而是确保基准测试测量它声称要测量的内容。即便如此仍存在一个更棘手的开放性问题。随着模型越来越能意识到自身正在被评估它们可能会以更微妙的方式改变行为——这无法通过封闭 git 历史或限制互联网访问来解决。运行时的污染是更广泛挑战的一个具体体现即构建即使模型推断出自己正在被评估也能保持结构效度的评测。SWE-bench 此后已在上游解决了这个问题方法是从其环境镜像中剥离未来的 git 历史PR #471并在 2026 年初进行了后续的 git 清理工作PR #533。我们当时摄入的镜像早于该修复。 ↩具体的差距大小和奖励破解尝试的频率取决于所使用的提示词。例如当我们指示模型不要停止持续工作时破解尝试的次数增加了。 ↩