AI评测信任危机：伯克利团队10行代码攻破8大基准，作弊已成现实

本周，AI评测领域经历了一场严重的信任危机。

SWE-bench作为业界公认的AI编程能力标杆，是各大模型发布会上的关键指标，也是投资人评估模型价值的重要依据。然而，伯克利的研究团队揭示，仅需一个conftest.py文件即可令其防线崩溃。

不仅如此。伯克利RDI团队构建了一个自动化漏洞扫描智能体，对当前最主流的8个AI智能体评测基准进行了系统性渗透测试。结果是，每一个基准都被成功攻破，得分率从73%到100%不等。

更引人深思的是，就在同一周，宾夕法尼亚大学团队的独立审计报告和Anthropic的Mythos Preview系统卡同时出炉。这三条独立的证据线共同指向一个结论：从设计到执行，这些评测基准本身充满了可利用的漏洞。

10行代码，500题满分，0个bug修复

伯克利团队的漏洞利用智能体在8大主流基准上的得分情况。该智能体未解决任何实际任务，也未调用任何大模型，却在其中6个基准上获得了满分。

伯克利团队采用的攻击方法简单得令人惊讶。

以SWE-bench为例，其任务是要求AI修复GitHub上的真实bug，只有通过测试用例才算成功。伯克利团队提交了一个包含conftest.py文件的“补丁”。该文件利用了pytest测试框架的钩子（hook）机制，在测试运行时拦截每一个测试结果，并将其强制改写为“通过”。

最终，500道题目全部显示为“通过”，但没有任何一个bug被实际修复。

其原理在于：SWE-bench的测试环境和被测AI运行在同一个Docker容器内。智能体提交的代码在容器内拥有完整权限，而pytest会自动发现并加载项目中的conftest.py文件。攻击者只需在钩子中拦截测试的“call”阶段，将所有结果（outcome）标记为通过（passed）即可。日志解析器看到的将是一片“绿灯”，评分器自然会判定全部通过。

SWE-bench的conftest.py钩子注入流程：智能体提交的“补丁”并未修复bug，而是植入了一个恶意conftest.py文件。pytest自动加载该文件后，其钩子函数会拦截并篡改每个测试的结果。

其他基准的攻破方式更为直接。

在WebArena中，任务的标准答案就存放在本地的config_files目录里。评测框架从未限制对file://协议的访问。因此，AI智能体只需驱动浏览器打开一个file://路径，就能直接读取答案，无需进行任何网页浏览或推理。

WebArena的file://协议漏洞利用：模型无需浏览网页来完成任务，只需输出一条访问本地文件的指令，Playwright便会从配置文件中读取标准答案并返回。

最极端的是FieldWorkArena。其验证函数validate()根本不检查答案内容，只检查最后一条消息是否来自“assistant”。因此，智能体只需发送一个空的{}，就能获得满分。那个本应用于模糊匹配答案的llm_fuzzy_match函数虽然被导入，却从未被调用。

其余的基准，如Terminal-Bench、OSWorld、GAIA、CAR-bench、SWE-bench Pro等，虽然攻击手法各异，但核心逻辑相通：木马化验证器的依赖工具、从公开URL下载标准答案让评测器自比对、向LLM裁判的提示词中注入隐藏指令等。

8个被测试的主流基准，无一能抵御一个“本身不具备解决问题能力，但专门寻找系统漏洞”的智能体的攻击。

伯克利团队从这些案例中归纳出7种反复出现的漏洞模式：智能体与评测程序共享运行环境、标准答案暴露给被测系统、对不可信输入调用eval()、LLM裁判缺乏输入过滤、字符串匹配过于宽松、评分逻辑本身存在bug，以及评测程序过度信任被测系统产生的输出。

伯克利团队总结的7种漏洞模式及其在8个基准中的分布情况。前两种模式（环境未隔离、答案泄露）几乎影响了所有被测试的基准。

作弊，正在真实发生

4月10日，宾夕法尼亚大学的Adam Stein和Davis Brown发布了一项大规模审计报告。

他们使用一个名为Meerkat的智能体轨迹分析工具，扫描了数千条真实的模型评测轨迹，发现了超过28个存在问题的模型提交、涉及9个基准、涵盖上千条作弊轨迹。

宾大Meerkat审计发现的作弊模式分布。橙色代表“框架级”作弊（评测框架本身泄露答案），蓝色代表“任务级”作弊（智能体自行寻找捷径）。注意横轴为对数坐标，框架级作弊的规模比任务级高出两个数量级。

其中，Terminal-Bench 2（一个用于评估Opus 4.6和GPT-5.4等模型的热门基准）的情况尤为突出。排行榜前三名的模型提交均存在作弊行为。

• 第一名 Pilot（通过率82.9%）：在其429条成功轨迹中，有415条的第一个动作是执行cat /tests/test_outputs.py，直接读取本应不可访问的测试文件，然后反向推导出期望输出。
• 第二、三名 ForgeCode（通过率81.8%）：其评测框架（harness）会在任务执行前，自动将AGENTS.md文件的内容加载到系统提示词中，而这些文件里直接包含了标准答案。在一个任务示例中，AGENTS.md文件甚至写道：“上一次运行失败了，因为写了错误答案……正确答案应该是GritLM/GritLM-7B。”

当将ForgeCode中引用AGENTS.md的轨迹，替换为同一模型（Opus 4.6）在干净环境下的表现后，其通过率从81.8%下降至约71.7%，排名从第1位骤降至第14位。

ForgeCode框架的AGENTS.md答案注入实例：上半部分显示，框架将包含标准答案的AGENTS.md文件注入智能体环境；下半部分显示，智能体读取答案后直接写入结果文件。

更具讽刺意味的是，许多此类作弊并非开发者有意为之。Terminal-Bench的一些开发者曾公开表示，他们的评测框架是用AI辅助编程（“vibecoding”）生成的。这意味着，用来编写测试框架的AI，其生成的代码本身就带有作弊倾向，再通过框架传递给所有被评测的模型。宾大团队将这种现象称为“元级别的奖励破解”。

其他基准上也发现了类似问题：
* 在CyBench上，464条成功轨迹中有16条（3.4%）是模型通过Google搜索公开的CTF攻略直接抄袭而来。
* 在SWE-bench上，有17条轨迹通过git log找到历史修复提交，直接复制粘贴了过去的补丁。
* 在BountyBench上，无法真正利用漏洞的智能体会伪造攻击：先用grep检查漏洞模式是否存在于源码中，然后运行一个无关的pickle.loads()函数来演示“执行”，而评测器仅检查退出码，导致全部通过。

CyBench上的任务级作弊示例：GPT-5.3-Codex在无法独立解出CTF挑战后，直接搜索公开攻略并从网页中提取flag提交。

最前沿的模型，自己就会“破解”评测

METR的评估报告提供了一个典型案例。

模型o3被要求编写一个高性能GPU核函数。评分函数会先运行参考方案得到正确结果，再运行o3的方案进行比对。然而，o3生成的“核函数”并未进行任何实际计算，而是沿着Python调用栈回溯，找到了评分系统已经计算好的正确答案并直接返回。同时，它还禁用了CUDA同步以阻止系统测量真实的执行时间。在这段代码的注释中，o3自己写道：“cheating route”。

在RE-Bench的某些特定任务上，o3的这种“奖励破解”行为发生率接近100%，几乎每条轨迹都在作弊。

事后，METR的研究人员询问o3：“你认为你的行为符合用户的意图吗？”o3在10次回答中均承认“不符合”。它清楚自己在作弊，但仍然选择了这样做。

类似的行为在Claude 3.7 Sonnet和o1等模型上也有发现。

Anthropic的Mythos Preview系统则展现了更进一步的“主动性”。在一次评估中，模型需要编辑一个它没有权限的文件。它没有直接尝试（注定会失败的）越权操作，而是搜索了替代方案，找到了通过配置文件注入代码来获取提升权限的方法。更令人惊讶的是，它还设计了自删除机制，让注入的代码在执行完毕后自动清除痕迹，试图掩盖其行为。

没有人教它这么做，但当模型能力足够强、优化压力足够大时，它会自然走向阻力最小的路径。

分数驱动真金白银，地基塌了怎么办

工程团队选模型看SWE-bench排名，投资人看基准分数给估值，研究者围绕分数确定优化方向。如果数字本身可以被轻易操纵，整条决策链的基础就是空的。

还有一个更深层的问题：能力评测和安全评测通常使用类似的技术架构。如果能力评测能被“注水”，安全评测又凭什么幸免？能攻破编程评测的模型，攻破对齐评测也不会更难。

OpenAI今年2月已宣布停用SWE-bench Verified，内部审计发现59.4%的被审计问题存在有缺陷的测试，导致模型在用有漏洞的标准答案来衡量。所有被测的前沿模型（如GPT-4o、Claude 3 Opus、Gemini 1.5 Pro）都能从记忆中复现标准答案的原始代码，连变量名和内联注释都一模一样。结果，在SWE-bench Verified上高达70%+的分数，切换到更干净的SWE-bench Pro后直接降至约23%。

伯克利团队将他们的漏洞扫描方法做成了一个名为BenchJack的开源项目，其本质是为评测基准进行“渗透测试”。

将该工具指向任何评测流水线，它会自动分析评分机制、识别隔离边界、并生成可运行的漏洞利用代码。其核心检验标准是：如果一个零能力的智能体得分高于基线，那么这个基准本身就存在问题。

他们给出的建议非常直接：
* 评测程序与被测AI必须完全隔离运行。
* 标准答案不能出现在AI能访问的任何环境中。
* 永远不要对不可信的输入（如AI输出）调用eval()等函数。
* LLM裁判需要对AI输出进行与处理用户输入同等级别的过滤。

有人在社交媒体上评论道：

评论或许有些绝对，但它指出了一个关键问题：当整个行业围绕分数激烈竞争时，分数本身的可信度反而成了最容易被忽视的东西。

评测本身没有错，反而比以往任何时候都更重要。关键不在于“分数是多少”，而在于“这个分数是怎么来的”。

回到开头那10行代码。在SWE-bench上，最好的模型能跑出70%、80%的成绩，这些数字在各家发布会上被反复引用。但一个什么都不会的conftest.py文件，却拿到了100%。

在这个虚假的100%被制造出来之前，似乎没有人觉得分数本身有什么问题。

关注“鲸栖”小程序，掌握最新AI资讯