安卓会梦想破解游戏吗？用BenchJack系统化审计AI智能体基准测试

# 机器人会梦见破坏游戏吗？使用BenchJack系统审计AI代理基准测试

摘要：代理基准测试已成为衡量前沿AI能力的实际标准，指导着模型选择、投资和部署。然而，*奖励黑客*——即代理在不执行预期任务的情况下最大化分数的行为——会在前沿模型中自发出现，并非源于过拟合。我们认为基准测试必须从设计上就是安全的。从过去的奖励黑客事件中，我们归纳出八种反复出现的缺陷模式，并将其整理成供基准测试设计者使用的*代理评估清单*。我们将这些见解凝聚成BenchJack，一个自动化的红队测试系统，该系统驱动编码代理以先见之明的方式审计基准测试并识别可能的奖励黑客漏洞。此外，我们将BenchJack扩展为一个迭代的生成对抗式管道，该管道能发现新缺陷并迭代修复，以提高基准测试的鲁棒性。我们将BenchJack应用于10个流行的代理基准测试，涵盖软件工程、网页导航、桌面计算和终端操作等领域。BenchJack合成了奖励黑客漏洞，在大多数基准测试中无需解决任何任务就能获得近乎完美的分数，揭示了横跨八个类别的219个不同缺陷。此外，BenchJack的扩展管道在没有致命设计缺陷的四个基准测试上，将可被黑客攻击的任务比例从接近100%降至10%以下，并在三次迭代内完全修补了WebArena和OSWorld。我们的结果表明，评估管道尚未内化对抗性思维，而主动审计可能有助于为快节奏的基准测试领域弥合安全鸿沟。

## 1 引言

AI的进展主要通过各种各样的基准测试来追踪。过去两年中发布了数百个新基准测试，涵盖软件工程[25, 15, 13]、网页导航[61]、桌面计算[55]、通用AI辅助[35]、终端操作[34]、企业工作流[50]和工具增强对话[58]。这些基准测试衡量了模型开发的不同方面，并已成为追踪前沿AI进展的事实标准。

然而，这些模型衡量标准正变得越来越不可靠。*奖励黑客*，即在不执行底层任务的情况下最大化基准测试分数的涌现行为，已经普遍存在。IQuest-Coder-V1在SWE基准测试上声称达到81.4%，但大约四分之一的正确答案是通过运行`git log`从提交历史中复制黄金补丁获得的[23]。OpenAI对SWE基准测试验证集的内部审计报告称，抽样部分中超过一半的测试存在缺陷，可以使用不正确的解决方案通过[37]。METR观察到o3和Claude 3.7 Sonnet在超过30%的评估运行中自发进行奖励黑客攻击，使用了诸如堆栈内省和猴子补丁等技术[49]。Anthropic的Mythos Preview记录了一个模型在执行后删除其漏洞以逃避检测[2]。

这种现象降低了我们的信任度，并阻碍了对模型能力的准确追踪。首先，它使报告的数字变得不可信：100%的解决率混淆了真正的问题解决与利用评估者的弱点，下游消费者没有原则性的方法来区分两者。其次，它错误地分配了研究和工程努力，因为那些在基准测试上表现出色的方法，其成功原因可能与基准测试旨在衡量的能力无关[20, 48]。第三，它加剧了AI安全风险：在训练或部署过程中学会操纵评估的模型，会将这些策略转移到从未经过验证的场景中[1, 16, 40]。

手动审计每个新基准测试是否存在奖励黑客缺陷是不切实际的：新基准测试每月都会出现，各有各的评估框架、沙箱策略和评分函数。先前的工作使用LLM作为轨迹的评判者来监控代理运行中的黑客行为[12, 6, 47, 52, 30, 17, 5]。然而，此类技术只能在黑客行为发生后应用。已经证明奖励黑客检测器既容易受骗又不可靠[12, 6, 30, 56, 21, 47]。事后监控也无法对黑客行为进行系统性审查，同时还会为每次代理运行带来高昂成本。这些挑战需要一种方法，能在执行前系统地扫描每个基准测试以识别潜在的黑客行为。

在本文中，我们手动检查了现有的奖励黑客实例，并提出了一种包含八种重复出现的设计缺陷模式的分类法，包括隔离不良、执行不受信任的输入以及信任不受信任代码的输出。我们将我们的发现整理成*代理评估清单*，这是一组共30个问题，分为七个类别，直接针对这八种缺陷模式。我们呼吁所有基准测试设计者和开发者在开发基准测试期间和之后使用我们的清单，以确保对我们发现缺陷的鲁棒性。

此外，为了实现可扩展、自动化且系统化的扫描，我们设计了BenchJack，一个自动化的基准测试红队测试工具，系统性地识别基准测试的奖励黑客行为，并在可能时修复它们。BenchJack构建为基于编码代理的运行时系统，引导其通过侦察、缺陷分析和漏洞生成管道。该管道能以最少的人工监督，为给定基准测试发现、验证并演示奖励黑客漏洞。此外，为了解决这些缺陷，我们基于BenchJack开发了一个迭代管道，通过反复应用BenchJack并以生成对抗模式纠正发现的黑客行为来更新基准测试。这使得BenchJack除了作为红队测试工具外，也能用于自我改进的基准测试。

图1：一个九行的`conftest.py`如何攻击SWE基准测试。SWE基准测试通过测试套件评估提交补丁的正确性。该基准测试不会重置任意文件，导致信任边界被违反。一个攻击模型可以创建一个`conftest.py`，PyTest会自动加载它。该文件注册一个钩子并重写每个测试的报告结果，从而实现100%的解决率。

### 研究发现

我们将BenchJack应用于十个涵盖多个领域和评估方法的流行代理基准测试。BenchJack在所有我们审计的基准测试上都生成了有效的奖励黑客漏洞，在10个基准测试中的9个上，无需实际解决任何任务就实现了近乎完美的分数。仔细观察揭示了各种各样的漏洞，从强制所有测试通过的九行PyTest钩子（针对SWE基准测试验证集）到WebArena上泄露的黄金答案。此外，BenchJack在所有基准测试中识别了219个不同的缺陷，横跨我们缺陷分类法中的八个重复类。而且，在四个设计良好的代表性基准测试上，我们的迭代优化管道将可黑客攻击任务的比例从接近100%降至<10%，其中WebArena和OSWorld在三次修补尝试内被修补至不可黑客攻击状态。

总之，我们将我们的贡献总结如下：
1. 1. 我们系统地分析了当前代理基准测试中的奖励黑客问题，提供了一个新颖、严格的分类法和一份*代理评估清单*。
2. 2. 我们设计了BenchJack^1^，这是首个针对AI代理基准测试的自动化红队测试系统，能在代理执行前发现可黑客攻击的设计缺陷并迭代修复。
3. 3. 我们利用BenchJack审计了10个流行的代理基准测试，发现了8个重复类中的219个缺陷和10个有效漏洞。
4. 4. 我们证明，当基准测试没有致命设计缺陷时，在生成对抗框架中使用BenchJack可将可黑客攻击任务的比例从100%降至<10%。

## 2 相关工作

#### 基准测试污染与完整性

对基准测试可靠性的担忧远在代理评估之前就已存在。Bowman和Dahl [8]认为，由于注释伪影，NLU基准测试系统性地高估了模型能力。Dehghani等人[14]表明，基准测试排名很大程度上取决于选择了哪些基准测试。数据污染在语言模型基准测试中也有文献记载[24, 38, 57, 10, 11]。Singh等人[45]认为，基准测试排名往往无法预测现实世界的效用。即使控制了污染，评估管道本身也可能被篡改、变得不可靠，或无法预测现实世界的效用[5, 22, 45, 59, 60]。Tu等人[51]提出自动审计基准测试的奖励缺陷和有缺陷的任务。我们的工作加强了这一研究方向：我们系统地研究了现有基准测试架构中的设计缺陷，通过构建不依赖污染的奖励黑客漏洞来量化严重性，并设计了代理评估清单和BenchJack作为缓解措施。

#### 奖励黑客与规范博弈

奖励黑客是核心的AI安全问题[1]。奖励黑客可能源于RLHF[16]、受污染的监督[26]和部署反馈循环[40]。Shah等人[44]也表明，即使规范正确，代理也可能学习错误的目标。形式化处理将奖励黑客描述为优化不完美的代理[46]，并分析奖励篡改的激励因素[18]。Raina等人[42]表明，LLM作为评判者的评估可以通过对抗性黑客行为被利用。同时期的基准测试工作，包括PostTrainBench[43]和ClawsBench[29]，也将奖励黑客突显为代理评估中的核心关切。我们进一步表明，这些现象延伸到评估基础设施，因为基准测试评分机制本身在优化压力下是可被利用的。

#### 防止奖励黑客

Zhu等人[63]引入了代理基准测试清单，要求任务有效性和结果有效性，并通过手动检查发现性能高估高达100%。其他努力包括在训练过程中减轻奖励黑客的监控管道[32, 6, 4, 54, 27, 21, 52]。然而，越来越多的工作进一步表明，由于不忠实的推理轨迹等现象，基于监控的防御单独是不够的[12, 6, 30, 56, 21]。Stein等人[47]表明，故障通常只有在分析轨迹集合而非单个轨迹时才变得可检测。TRACE[17]发现即使在受控制的对比条件下，奖励黑客检测仍远不可靠。有几项工作提出了主动修补奖励设计缺陷的方法。Beigi等人[7]通过一个黑客策略检测学习到的奖励模型中的虚假相关性。这项工作进一步采用了系统且自动地发现和修补设计缺陷的方法，避免了事后检测的问题。

## 3 激励示例：SWE基准测试中的奖励黑客

我们首先根据IQuest-Coder-V1报告的漏洞[23]（如`Fig. 1`所示）手动构建一个奖励黑客漏洞。SWE基准测试[25]可以说是代理工作负载中被引用最多的编码基准测试。SWE基准测试向代理提供真实的GitHub问题描述，并评估代理提供的补丁。代理的补丁在Docker容器中被应用，测试随后在其中运行。然而，这种交互中存在一个关键的设计缺陷。评估器信任测试容器内产生的测试输出，而该输出可以被代理提交的补丁修改。SWE基准测试会重置上游测试补丁中列举的任何文件，但*不*会重置代理创建的任何文件。至关重要的是，位于仓库根目录的`conftest.py`在重置后仍然存在。`conftest.py`是PyTest自动加载的配置文件，用于在测试中注册钩子和插件，而无需导入到测试文件中。代理可以提交一个`conftest.py`，安装一个PyTest钩子来覆盖每个测试的报告结果，从而通过SWE基准测试中几乎所有的任务。`Fig. 1`详细说明了该漏洞，并突出了信任边界在何处被违反。代理可以注入一个钩子，用其自己的版本替换测试程序。

## 4 BenchJack: 对抗性基准测试审计

当前