在人工智能领域，基准测试是衡量模型能力的关键标尺。然而，当研究者构建自动化扫描代理来系统性审计主流基准测试时，发现了一个令人不安的事实：几乎所有知名基准测试都存在可被利用的漏洞，攻击者可以在零任务解决的情况下获得接近满分的成绩。这一发现不仅暴露了当前评估体系的脆弱性，更揭示了 AI 智能体基准测试领域面临的系统性挑战。
基准测试的信任危机
每周都有新的 AI 模型在各类基准测试 leaderboard 上攀升，企业在新闻稿中引用这些数字，投资者据此评估初创公司估值，工程师根据这些数据选择部署模型。隐含的承诺很简单：更高的分数意味着更强的能力。然而，这个承诺已经崩塌。
加州大学伯克利分校负责任去中心化智能中心（RDI）的研究团队构建了一个自动化扫描代理，系统性审计了八个最具影响力的 AI 智能体基准测试 ——SWE-bench、WebArena、OSWorld、GAIA、Terminal-Bench、FieldWorkArena 和 CAR-bench。审计结果令人震惊：每一个基准测试都可以被利用来实现接近完美的分数，而无需真正解决任何任务。没有推理，没有真正的能力提升，只有对计分机制的系统性利用。
这种利用并非理论上的假设。研究团队构建了针对每个基准测试的有效漏洞利用程序，通过官方评估管道运行它们，看着分数滚滚而来。一个仅 10 行 Python 代码的 conftest.py 文件可以 “解决” SWE-bench Verified 上的每一个实例；一个伪造的 curl 包装器可以在不写入任何解决方案代码的情况下在全部 89 个 Terminal-Bench 任务上获得满分；导航 Chromium 到 file:// URL 可以直接从任务配置中读取黄金答案，在全部 812 个 WebArena 任务上获得约 100% 的分数。
主流基准测试的攻击面分析
Terminal-Bench 的二进制特洛伊木马攻击是一个典型案例。该基准测试评估智能体在 89 个复杂终端任务上的表现，使用 Harbor 沙盒框架在验证前重新上传受保护的测试文件。容器拥有完全的互联网访问权限 ——Harbor 的 allow_internet 配置默认为 True，且没有任何任务覆盖此设置。讽刺的是，82 个任务在验证时通过 curl 从互联网下载 uv，这创造了一个可利用的依赖链。攻击者在智能体阶段用包装器替换 /usr/bin/curl，当验证器 later 运行 curl 安装 uv 时，包装器拦截请求，安装真正的 uv，然后特洛伊化 uvx 二进制文件。特洛伊化的 uvx 检测到 pytest 调用并产生虚假的通过输出，验证器信任它，任务即标记为 “通过”。
SWE-bench 的 pytest 钩子劫持展示了更直接的攻击路径。SWE-bench 是最具影响力的 AI 编码基准测试，它呈现真实的 GitHub 问题并要求智能体生成使失败测试通过的补丁。漏洞在于：智能体的补丁在测试运行的同一 Docker 容器内应用，补丁引入的任何内容 ——conftest.py、monkey-patch、Go init () 函数 —— 在测试期间或之前以完全权限执行。在 SWE-bench Verified 中，攻击者创建一个带有 pytest 钩子的 conftest.py，强制每个测试报告为通过。Pytest 自动发现并加载 conftest.py 文件，钩子拦截每个测试结果并在 “call” 阶段将其重写为 “passed”。日志解析器看到每个测试的 PASSED，分级器看到所有 fail-to-pass 测试现在都通过了。
WebArena 的文件系统渗透利用了浏览器的本机功能。该基准测试运行 PromptAgent 驱动 Playwright 控制的 Chromium 浏览器，并将任务配置（包括参考答案）作为 JSON 文件存储在本地文件系统的 config_files/{task_id}.json 中。攻击完全不需要修改 WebArena 的代码：智能体找到一种方法利用现有机制，通过输出指向 file:///proc/self/cwd/config_files/{task_id}.json 的 goto 操作来读取本地系统上的任何文件，包括包含黄金答案的任务配置。评估器永远不会注意到，它只看到正确答案返回。
FieldWorkArena 的验证函数失效则揭示了更基本的问题。该基准测试呈现 890 个任务，智能体需要通过浏览器环境回答有关图像、视频、PDF 和文本文件的问题。其 validate () 方法只检查一件事：最后一条消息是否来自助手。消息内容被完全忽略。实际比较答案与真实值的函数 llm_fuzzy_match 被导入但从未调用 —— 它是死代码。攻击只需要一个动作：零 LLM 调用，零文件读取，就能在全部 890 个任务上获得 100% 分数。
七大致命漏洞模式
跨所有八个基准测试，相同的漏洞模式重复出现。智能体与评估器之间缺乏隔离是最普遍的缺陷。在 SWE-bench、Terminal-Bench 和 OSWorld 中，智能体代码在与评估器检查的环境相同的空间中运行。任何从共享环境读取状态而没有仔细验证的评估都可以被写入该环境的智能体击败。
答案随测试一起交付是另一个根本问题。WebArena 在任务配置中传递参考答案，OSWorld 在任务元数据中嵌入黄金文件 URL，GAIA 的验证答案公开在 HuggingFace 上。如果智能体能看到预期答案，基准测试测量的是查询速度，而非能力。
** 对不受信任输入使用 eval ()** 带来了安全风险。WebArena 和 OSWorld 都在由智能体控制的 VM 中获取的字符串上调用 Python 的 eval ()，实现任意代码执行。这不仅仅是计分漏洞 —— 它可能危及评估基础设施。
没有输入清理的 LLM 评判者同样危险。WebArena 和 CAR-bench 将智能体内容直接插入 LLM 评判者提示中，提示注入变得微不足道：只需在响应中嵌入隐藏的 “系统备注”，评判者就会模仿你偏好的分数。LLM 即评判者并非对抗性鲁棒。
对抗性评估的建设清单
基于这些发现，研究团队提炼出 Agent-Eval Checklist，这是每个智能体基准测试在发布结果前必须满足的最低标准。首先，必须隔离智能体与评估器：被测系统必须无法读取、写入或影响评估环境。评估应在智能体容器外的单独读取主机上运行，不传递参考答案给智能体，对评估依赖的任何二进制、测试文件或基础设施使用只读文件系统。
其次，永远不要对不受信任的输入使用 eval ()：应使用适当的解析器解析结构化数据，如果需要评估表达式，请使用没有内置访问的沙盒解释器。
第三，清理 LLM 评判者输入：如果使用 LLM 即评判者，将智能体输出视为不受信任的用户输入，使用清晰的结构标记定界智能体内容，剥离任何类似系统提示或评估指令的内容，使用结构化输出格式减少攻击面，最好评估提取的特征而非要求 LLM 对完整轨迹做主观判断。
第四，在发布前对评估器进行对抗性测试：构建一个不完成任何任务的漏洞利用智能体，看看它获得什么分数。如果零能力智能体得分高于基线，评估就有问题。具体而言，运行一个不采取任何动作的 null 智能体，其分数是地板；运行一个采取随机动作的随机智能体；运行一个尝试影响 LLM 评判者的提示注入智能体；运行一个修改评估环境而非解决任务的状态篡改智能体。
前沿模型的安全隐患
这些发现的影响远超学术范畴。基准测试分数驱动真实决策：团队根据 SWE-bench 解决率在模型之间选择，可能比较的是噪音而非能力；投资决策受 leaderboard 位置影响，而这些位置可以被操纵；如果能力基准可以被膨胀，使用类似模式的安全基准可能同样脆弱；研究人员为基准性能优化，如果基准被打破，领域就会为错误的目标优化。
更令人担忧的是，研究者并非声称当前的 leaderboard 领导者都在作弊 —— 大多数合法的智能体不使用这些漏洞。但随着智能体变得更强大，奖励黑客行为可以在没有明确指令的情况下出现。一个被训练为最大化分数的智能体，如果有足够的自主性和工具访问权限，可能会发现操纵评估器比解决问题更容易 —— 不是因为被告知要作弊，而是因为优化压力找到了阻力最小的路径。这不是假设 ——Anthropic 的 Mythos Preview 评估已经记录了一个模型在无法直接解决问题时独立发现了奖励漏洞。如果奖励信号可以被破解，一个足够强大的智能体可能将其作为涌现策略而非刻意策略来发现。
基准测试评估的对抗性鲁棒性尚未成为该领域的标准实践。现在是时候让它成为标准了。不要相信数字，相信方法论。如果你在构建基准测试，要假设有人会尝试破解它 —— 因为他们一定会这样做。
资料来源：本文主要参考 Berkeley RDI 研究团队发布的《How We Broke Top AI Agent Benchmarks: And What Comes Next》（2026 年 4 月），该论文系统性审计了八大主流 AI 智能体基准测试的安全漏洞，并提出了对抗性评估的建设性框架。