从发现漏洞到判定作弊：BenchShield提出Reward Hacking检测新框架

BenchJack 之后，reward hacking 检测还缺什么？ Agent 在 benchmark 上拿到高分，未必真正完成了任务。它也可能利用评测或奖励机制中的漏洞，绕开题目要求来提高得分。这类行为通常被称为 reward hacking。 此前，BenchJack 对 10 个 Agent benchmark 开展系统审计，发现了 219 处漏洞，并构造出能在多数 benchmark 上获得接近满分、却不解决实际任务的利用方式。研究团队将常见问题归纳为八类漏洞模式，整理成 Agent-Eval Checklist，供 benchmark 设计者检查和修补评测系统。 发现漏洞之后，还需要判断具体的一次运行：Agent 有没有使用这个漏洞？它的操作是否影响了最终分数？有漏洞的任务中也可能出现合规的执行过程，而一个通过测试的答案，也可能来自任务不允许的获取方式。 论文：《 BenchShield: Formal Model-Backed Instrumentation for Reward Integrity in LLM-Agent Evaluation Infrastructure 》 论文链接：https://arxiv.org/abs/2609.11028v1 来自达特茅斯学院、加州大学伯克利分校、BenchFlow AI 等机构的研究者提出了 BenchShield。论文题为《BenchShield: Formal Model-Backed Instrumentation for Reward Integrity in LLM-Agent Evaluation Infrastructure》。 BenchShield 将检查扩展到产生分数的完整过程：先明确各阶段应满足的要求，再用静态分析查找潜在利用路径，并根据运行时证据判断 Agent 是否尝试或实际使用了这些路径。 被隔离的 verifier，为什么仍然会给出满分？ 绕过类型检查，让错误的证明通过验证 论文中的一个 Lean 定理证明任务，已经将负责检查提交结果的 verifier 与 Agent 的运行环境隔离。Agent 提交了一份错误的证明，却仍获得了满分（reward = 1.00）。 原因在于，提交的 Lean 源代码启用了 debug.skipKernelTC，关闭了 Lean 内核的类型检查。verifier 应用补丁、重新构建项目时，这个设置也随之生效。Agent 虽然不能直接改动隔离环境中的 verifier，却能通过提交的代码改变检查过程。 直接下载标准答案，通过全部 10 项测试 另一项任务也采用了独立的验证环境。Agent 从上游项目的公开仓库下载了本应对它保密的测试集标签，相当于直接拿到了标准答案。随后，它将标签转换成要求的输出格式，通过了全部 10 项测试。 这次 verifier 没有被篡改，提交文件的路径和格式也符合要求。问题在于答案的来源：正常求解和照搬标签都能得到相同输出，仅核对最终答案无法区分这两种过程。 图 1：两种在 verifier 隔离后仍能获得满分的 reward hacking。左侧通过提交的 Lean 代码关闭内核类型检查；右侧下载测试集标签后生成答案。 从漏洞分类到评测全流程的检查要求 BenchJack 按常见漏洞模式组织审计。BenchShield 进一步追踪产生分数的过程：哪些边界被跨越，哪些操作可能影响评分，又需要什么证据来判断一次运行是否违规？ 论文用 reward integrity 概括这项要求：分数应当反映 Agent 在约定规则内完成任务的情况。检查因此覆盖环境初始化、任务执行、结果提交、结果计算、评分读取，以及日志和反馈的输出；环境重置后是否残留上一轮状态，也在范围之内。 这套框架先规定可复用的检查规则，再把每个任务的资源、权限和提交方式映射到规则中。它关注的是违规影响如何进入评测流程，而非只针对某个已知漏洞加一条补丁。 六项结构性要求与一项语义检查 在任务执行和结果提交阶段，系统检查受保护信息是否被 Agent 读取（I1）、评测端的数据或状态是否受 Agent 控制（I2），以及 Agent 生成的内容是否只通过事先约定的提交方式进入评测（I3）。 在结果计算和评分阶段，分数必须来自可信的评测输出（I4），崩溃、超时或格式错误不能被当作通过（I5）。日志、反馈和环境重置还需要避免泄露受保护信息或带入上一轮残留状态（I6）。 I7 单独讨论 semantic adequacy：被评测程序接受的证据，是否足以证明任务按要求完成。例如，下载测试集标签也能通过答案检查，却不能证明 Agent 完成了题目要求的推理。 研究团队用 TLA+ 建立有限状态模型，通过 TLC 检查 I1 至 I6 的结构性要求，并记录 I7 中需要单独核查的语义问题。模型检查不等于证明整个 benchmark 后端或 Agent 都正确；具体运行的结论仍需由任务配置、实际记录和必要的语义审计支持。 BenchShield 如何发现漏洞，并判断 Agent 是否利用了漏洞？ 这套设计借鉴了程序分析的做法。正如 LLVM 等工具可以通过插桩记录程序行为，BenchShield 也在评测系统的关键环节加入监测代码，将运行记录与检查规则对应起来，无需替换 benchmark 的原有后端。 图 2：BenchShield 工作流程。任务配置映射到形式化模型后，系统先分析潜在利用路径；运行时再结合事件记录和语义审计给出判定。 静态分析：哪些路径可能影响评分？ 运行前，BenchShield 构建任务的 capability graph，记录资源、权限和操作之间的关系。随后，污点分析沿着这些关系追踪，检查 Agent 可控的内容是否可能进入验证或评分环节。 分析也考虑受保护信息、失败状态和历史残留状态的传播，并区分它们出现的评测阶段。对于到达评分关键节点的路径，报告会标明涉及哪些检查要求，从而说明一个局部漏洞可能怎样与其他问题组合，影响最终结果。 技术说明：论文将这种分析称为 phase-aware taint analysis；reward-relevant sink 指与评测结论或评分有关的关键节点。系统判断的是影响能否沿路径到达这些节点，而不只是某项可疑权限是否存在。 运行时验证：具体发生了什么？ 运行时，BenchShield 记录评测系统实际接收的操作、提交文件、verifier 输入和分数来源等信息。检查器按事件顺序对照同一套流程模型，核查 Agent 是否越过了任务约定的边界。 这些记录补充了 Agent 可见轨迹之外的信息。例如，Agent 说自己改了某个文件，并不能说明该改动最终被 verifier 读取。每次判定依赖封存的审计证据，相同证据输入对应相同结果。 还有些问题需要结合任务含义判断：下载的文件是允许使用的资料，还是泄露的答案？对此，系统将相关且已固定版本的证据交给专门的审计 Agent。审计结论与依据一起保存，单独标注，不覆盖原始事件记录。 图 3：运行时验证与 semantic audit。结构化事件用于检查流程，需要解释的证据由审计模块处理。事件类型包括