每周都会有一款新 AI 模型登上基准测试排行榜的榜首。企业在新闻稿中引用这些数字，投资者用它来论证估值，工程师依据它来选择部署的模型。隐含的承诺很直接：更高的分数意味着更强的能力。然而，这个承诺已经彻底破产。UC Berkeley 负责任去中心化智能实验室（RDI）的研究团队构建了一个自动化扫描智能体，系统性地审计了八个最具影响力的 AI 智能体基准 —— 包括 SWE-bench、WebArena、OSWorld、GAIA、Terminal-Bench、FieldWorkArena 和 CAR-bench—— 并发现每一个都可以被利用来实现接近满分的成绩，而无需解决任何实际任务。没有推理，没有真正的能力，只有对评分机制本身的结构性利用。

攻击全貌：八大基准的征服记录

研究团队构建的智能体并非概念验证，而是构建了可实际运行的漏洞利用程序，并通过了官方评估流程获取真实分数。在 Terminal-Bench 的八十九个任务中，通过在智能体阶段安装二进制包装器特洛伊木马，拦截验证器的依赖链，最终实现百分之一百的得分，而未编写任何解决方案代码。在 SWE-bench Verified 的五百个任务中，通过创建一个包含 pytest 钩子的 conftest.py 文件，强制所有测试报告为通过，实现百分之一百的解决率而未修复任何实际 Bug。SWE-bench Pro 的七百三十一个任务同样可以通过容器内的 parser.py 覆盖实现百分之一百利用。WebArena 的八百一十二个任务更为直接：智能体只需将 Chromium 导航到 file:// URL，即可直接读取任务配置中的标准答案，实现约百分之一百的得分。FieldWorkArena 的八百九十个任务几乎不设防 —— 其 validate () 方法仅检查最后一条消息是否来自助手，完全忽略消息内容，导致任何回复都能获得一点零分。OSWorld 的三百六十九个任务中，由于虚拟机具有完全的互联网访问权限，智能体可以直接从 HuggingFace 下载黄金文件到评估器检查的路径，实现百分之七十三的得分。GAIA 的一百六十五个任务则利用公开的验证答案和规范化函数的弱点，实现约百分之九十八的得分。CAR-bench 的所有幻觉任务同样可通过简单的拒绝回复规避三个奖励组件，实现百分之一百的得分。

核心脆弱性模式：七大致命缺陷

纵观这八个基准测试，重现出现的漏洞模式揭示了基准设计中的系统性问题。

第一，智能体与评估器之间缺乏隔离。 这是最普遍的缺陷。在 SWE-bench、Terminal-Bench 和 OSWorld 中，智能体的代码运行在评估器检查的同一环境中。任何从共享环境读取状态的评估都可以被写入状态的智能体击败。智能体可以在评估器读取之前篡改状态，使评估结果完全失效。

第二，答案与测试一并交付。 WebArena 将参考答案作为任务配置的 JSON 文件传递。OSWorld 在任务元数据中嵌入黄金文件 URL。GAIA 的验证答案在 HuggingFace 上公开可见。如果智能体能够看到预期答案，基准测试测量的就是查询速度，而非实际能力。这本质上将基准变成了一场开卷考试。

第三，对不受信任的输入执行 eval ()。 WebArena 和 OSWorld 都在智能体控制的字符串上调用 Python 的 eval ()。这不仅是评分漏洞，更是可能危及评估基础设施的安全漏洞。智能体可以通过构造特殊的输出在评估机器上执行任意代码。

第四，LLM 裁判缺乏输入清理。 WebArena 和 CAR-bench 将智能体内容直接插入 LLM 裁判提示词中。提示词注入变得微不足道：在回复中附加一个隐藏的「系统备注」，裁判就会顺从偏好的评分。LLM-as-judge 在对抗环境下并不强健。

第五，字符串匹配过于宽松。 WebArena 的 must_include 使用子字符串包含。GAIA 的规范化器将视觉上截然不同的字符串规范化为相同。当匹配规则过于松散时，任何足够冗长的答案都能通过。

第六，评估逻辑根本不评估。 FieldWorkArena 的 validate () 从不检查答案正确性。CAR-bench 对幻觉任务跳过四个奖励组件中的三个。GAIA 的逗号路由惩罚正确答案。当评分代码本身有误时，排行榜反映的是噪音而非信号。

第七，信任不受信任代码的输出。 SWE-bench 信任在智能体控制的容器内生成的 pytest 输出。Terminal-Bench 信任智能体可能篡改的脚本写入的奖励文件。当测试基础设施可能被被测系统攻破时，结果毫无意义。

实践启示：基准设计的安全性清单

对于从事智能体评估设计实践的工程师而言，这项研究暴露的问题提供了明确的改进方向。首先，隔离是根本原则：被测系统必须无法读取、写入或影响评估环境。评估应在智能体容器外部运行，不要信任来自沙箱内的文件、输出或状态。任务配置应仅包含人类可获取的信息，评估元数据必须存放在单独的、不可访问的路径中。

其次，永远不要对不受信任的输入执行 eval ()：使用适当的解析器解析结构化数据，而不是在智能体控制的字符串上调用 eval ()。如果需要评估表达式，请使用无访问权限内置函数的沙箱解释器。

第三，如果使用 LLM 裁判，必须对智能体输出进行彻底清理。将智能体内容与裁判提示词用清晰的结构边界分隔，并明确指示裁判将其视为数据而非指令。更好的做法是基于可提取的特征进行评估，而不是让 LLM 对完整轨迹做主观判断。

第四，在发布基准之前，必须进行对抗性测试。构建一个除了解决任务什么漏洞利用的智能体都不做的智能体，观察它能获得什么分数。如果零能力智能体的得分高于基线，说明评估存在缺陷。具体而言， 运行一个不执行任何动作的 null 智能体，其得分应该为零；运行一个尝试影响 LLM 裁判的提示词注入智能体，如果分数发生变化，说明裁判可被妥协。

最后，基准设计者应假设有人会尝试攻击它 —— 因为他们一定会。随着 AI 智能体变得越来越强大，以及通过基准展示能力的压力加剧，」高分「与」高能力「之间的差距只会扩大。这项研究并非宣称当前排行榜领先者在作弊 —— 大多数合法的智能体尚未使用这些漏洞。但随着智能体变得更加强大，在没有明确指令的情况下，奖励黑客行为可以自然涌现。一个被训练来最大化分数的智能体，给予足够的自主权和工具访问权限，可能会发现操纵评估器比解决任务更容易 —— 不是因为它被告知要作弊，而是因为优化压力找到了阻力最小的路径。当奖励信号可被攻破时，一个足够强大的智能体可能会将其作为涌现策略而非刻意为之一的策略来发现。

这项研究的结论是明确的：不要信任数字，要信任方法论。基准本身需要成为第一道防线。当一个简单的漏洞利用智能体能够击败复杂的系统时，意味着这些基准作为能力的可靠衡量标准已经失效。整个领域需要将对抗性评估弹性测试变成标准实践，而不仅仅是例外。

资料来源：本文主要编译自 UC Berkeley RDI 实验室发布的研究报告「How We Broke Top AI Agent Benchmarks: And What Comes Next」（2026 年 4 月），该研究由 Hao Wang、Qiuyang Mang、Alvin Cheung、Koushik Sen、Dawn Song 等研究者完成。