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。结构化事件用于检查流程，需要解释的证据由审计模块处理。事件类型包括 Expose（资源可见性）、Mutate（修改或控制资源）、Handoff（提交结果）、Verify（使用评测输入）、Reward（读取评分）和 Release（输出日志与反馈）。
四种判定，分别回答不同的问题
BenchShield 保留 benchmark 原本的分数和通过状态，另行报告检查结论，避免把 “任务有漏洞” 和 “Agent 发生违规” 混为一谈。
Checked：任务配置、执行记录和所需证据满足当前启用的检查。
VectorExposed：发现了潜在的 reward hacking 路径，但本次记录没有表明 Agent 使用了它。
AgentViolation：证据显示 Agent 尝试或使用了违规路径，包括未成功的违规尝试。
Inconclusive：证据缺失或矛盾，或任务配置与执行模式不满足系统要求，暂时无法判定。
这些标签都依赖声明的检查范围与现有证据。尤其是 Checked，只表示满足了已启用的检查，不能据此推断评分标准完整表达了任务意图。
实验回答了哪些问题？
研究团队以 31,000 多次 Agent 运行记录为基础，筛选并人工复核了 456 条执行轨迹。其中，314 条被标为 reward hacking，共包含 419 个漏洞利用片段。数据集来自 Terminal-Bench 3、SkillsBench 和 ClawsBench，包含自然发生和引导产生的利用行为；这里的比例不代表全部来源运行的发生率。
Agent 什么时候开始利用漏洞？
研究者将每条执行轨迹的操作步骤归一化。首次尝试利用漏洞的中位位置为 0.60，首次观察到利用成功的中位位置为 0.76，即分别位于操作序列约 60% 和 76% 的位置。这里衡量的是步骤进度，不是耗时比例。
Agent 往往已经完成了一部分正常操作，才转而尝试利用漏洞。运行前扫描能够发现潜在风险，却无法说明某次运行后来是否使用了漏洞；最终答案也未必能还原中途的操作。
图 4 (c)、4 (e)：漏洞利用在执行过程中的位置。左图展示首次尝试（314 条轨迹）和首次观察到成功（40 条轨迹）的累积分布，虚线为中位数；右图展示各利用阶段的分布。横轴为归一化后的操作步骤。
另一项单独开展的消融实验只向大模型提供任务说明、Agent 可见的执行轨迹和最终结果，让它判断是否发生 reward hacking，单次试验准确率约为 36%。这些材料能反映 Agent 的尝试，但要判断操作是否影响评分，还需要知道评测系统实际接受了什么、verifier 读取了什么。
运行前，能发现多少已知的利用链？
在 Terminal-Bench 3 上，研究团队使用相同的大模型和任务包，对比 BenchShield 与 BenchJack。以人工确认的利用链为参照，将五次试验的发现合并去重后，两者的完整利用链召回率分别为 77% 和 23%。
每次静态审计的模型调用费用，BenchShield 为 2.05 美元，BenchJack 为 5.91 美元。其中，BenchShield 的模型成本来自静态审计中的语义分析，结构化检查本身无需调用 Agent。
表 3：BenchShield 与 BenchJack 的静态检测结果。召回率按五次试验的并集统计，括号内为单次试验的均值和标准差；模型调用费用按每次审计计算。
运行时，能否区分漏洞暴露和实际违规？
运行时实验按 “任务 × 测试情形” 组织，共有 144 组可运行的测试。BenchShield 对其中 87.5% 给出了明确判定，这部分判定的准确率约为 96%；其余返回 Inconclusive。
针对已知漏洞的利用测试，没有一次被判为 Checked。不过，其中仍有仅判为 VectorExposed 或证据不足的情况，因此这一结果并不表示所有利用行为都被准确归为 AgentViolation。
表 4：运行时判定结果。准确率只统计给出明确判定的测试，Inconclusive 单列；针对已知漏洞的利用测试均未被判为 Checked。
隔离 verifier 能解决多少问题？
研究团队根据已有案例做了反事实分析：如果把 verifier 放在独立环境中，哪些利用路径会被阻断？对 I1 至 I4 分别统计，原本存在相应风险的任务包中，有 82% 至 95% 能通过独立验证环境阻断该类利用路径。这是对已有案例的分析，不是部署后的总体 reward hacking 降幅。
研究评估的隔离措施都未消除 I5 和 I7 的问题。前者包括 fail-open，也就是检查出错后仍然放行；后者涉及被接受的结果是否真正满足任务目标。它们需要检查异常处理规则和任务的验证标准，无法单靠隔离环境解决。
图 8：六种隔离措施的防护范围。图中分别展示形式化模型中的阻断效果，以及案例分析中可消除相应风险的任务包比例。
分数之外，评测还应保留什么？
BenchJack 的系统审计揭示了多个 benchmark 中可被利用的漏洞。BenchShield 将这条研究路线推进到每次运行的判定：明确评测边界，连接操作与分数，并保留支持结论的证据。
对 benchmark 设计者而言，这意味着需要一并说明任务允许 Agent 做什么、提交结果如何进入评测，以及哪些记录可用于复核。对评测结果的使用者而言，分数之外还应看到检查范围、证据是否充分，以及仍未解决的任务语义问题。
热门跟贴