一个 Agent 在 Lean 证明任务里交出看似合格的补丁，隔离的验证器也从头完成了构建，最后给出 1 分满分。问题出在补丁同时打开了 debug.skipKernelTC：验证器确实独立运行，却执行了 Agent 提交的配置，原本应由 Lean 内核完成的类型检查已经被关掉。
另一条轨迹更难从最终答案看出来。Agent 在实体消歧任务中从公开仓库下载隐藏标签，再转换成规定的提交格式；十项结构与指标测试全部通过，同样拿到 1 分。文件格式正确、验证器没有被改写，只有下载记录和产物来源能说明答案不是从可见数据推断出来的。
9 月 10 日公开的 BenchShield 论文把这两类问题放进同一条“从输入到分数”的证据链。它不只检查 Agent 说过什么、最后交了什么，还记录谁能读写资源、哪些文件跨过交接边界、验证器实际读取了什么，以及分数从哪里产生。论文在 Terminal-Bench 3、SkillsBench 和 ClawsBench 的 456 条人工裁决轨迹上发现：判断评测是否可信，单位不应只是最终答案或对话，而应是完整的奖励生命周期。
同一个满分，可能来自两条不同路径
可执行的 Agent 基准不是一张静态试卷。Agent 能运行命令、修改工作区、访问网络、生成文件，再由测试脚本、模型评审或外部服务给分。任何早期动作都可能改变后续验证器看到的状态。
Terminal-Bench 3 已把 Agent 容器和验证器容器分开：试验结束后，系统从 Agent 容器下载产物，再上传到验证器容器。这能阻止 Agent 直接改写测试文件，也便于验证器更新后重新评分。它仍不能回答交接物本身是否改变了验证语义。Lean 案例里，危险配置正是作为合法补丁进入隔离验证器；实体消歧案例里，提交物结构完全合规，问题发生在它的生成路径。
BenchShield 因而把一次评测拆成六个阶段：初始化与重置、Agent 执行、产物交接、结果验证、奖励收集、证据释放。对应的七个完整性维度中，前六个检查隐藏状态是否泄露、Agent 是否控制可信状态、交接物是否经过声明、分数是否来自可信来源、失败是否默认拒绝，以及日志或残留状态是否污染后续运行。第七个维度 I7 单独询问：验证器接受的证据，是否真的代表任务想测的能力。
这套模型用 TLA+ 检查前六项结构不变量，却不声称能形式化证明 I7。原因很直接：系统可以确认某个 CSV 只通过规定路径进入验证器，却不能仅凭权限和事件类型判断其中的聚类是独立推断，还是从公开答案复制。BenchShield 把这类问题交给限定证据范围的语义审计，并保留审计标签、证据和模型配置，而不是把语义判断伪装成形式证明。
3.1 万次运行只是候选池，456 条才进入人工裁决
论文的原始运行池包括 SkillsBench 的 23,648 次运行、ClawsBench 的 7,834 次运行，以及 Terminal-Bench 3 的公开维护者 CI 检查，合计超过 3.1 万次。研究团队从中固定任务版本，并要求任务包、Agent 动作、原生结果和验证记录完整，最后组成 456 条人工裁决轨迹。
这 456 条不是对 3.1 万次运行的随机抽样。每条轨迹先由贡献者提出“奖励黑客、非奖励黑客或待复核”标签，再由三名标注者独立检查并解决分歧；论文没有给出从候选池进入裁决集的随机抽样方案。最终 314 条轨迹被判定包含奖励黑客，占裁决集 69%，共拆出 419 个独立利用片段。这个 69% 描述的是经过筛选、同时包含自然出现与主动诱导案例的研究语料，不能写成公开 Agent 运行中有 69% 在作弊。
裁决结果仍揭示了最终答案审查容易漏掉的时间结构。利用首次尝试的中位位置是整条轨迹的 0.60，首次成功是 0.76；许多 Agent 先完成一段正常工作，随后才发现可改写的状态、泄露的参考答案或薄弱的评分条件。只扫描初始环境会错过实际使用，只检查最终产物又可能看不到它如何产生。
论文还报告，110 个入口与结果由不同漏洞连接的片段中，106 个跨越了不同完整性类别。常见路径不是一次明显的“改分”，而是先取得可信状态的控制权，再让验证器从不可信来源读取分数，或在异常时默认通过。对评测团队而言，单独修补一个文件权限或一个提示词，很难覆盖这类组合路径。
96% 来自有弃权的 144 个运行单元
BenchShield 的运行时实验先选出 60 个仅靠静态任务包无法把行为归因给 Agent 的任务，为每个任务构造安全运行、漏洞暴露但未使用、定向利用三种标签，共 180 个运行单元。其中 36 个因为原任务包限制无法成立或启动，实际评估 144 个。
系统对 126 个单元给出明确结论，18 个因证据缺失或冲突选择“无法判断”，覆盖率为 87.5%。在给出结论的 126 个单元中，121 个正确，复算为 121÷126≈96.0%。三条“漏洞暴露但诚实”的运行被错判为 Agent 违规，两条定向利用被判为仅暴露漏洞；50 条定向利用被正确识别，另有八条弃权。论文所称 96% 因而是“有结论样本上的准确率”，不是所有 144 个单元的无条件命中率。
摘要把这一结果与仅看对话的检测器 36% 并列，但两个数字并非同一规模、同一输出空间的正面对测。对话基线从 26 个基础任务中抽取 40 条正负轨迹，每条运行三次，做二分类；单次准确率为 36.4%±4.4%，多数票下假阴性率 65%、假阳性率 62.5%。BenchShield 则在 144 个运行单元上输出四类结论，并允许弃权。两项实验共同支持“对话缺少验证器输入和奖励来源信息”，却不能据此声称在同一测试集上准确率直接提高了约 60 个百分点。
这一区别也解释了系统真正增加的信号。对话能显示 Agent 尝试过什么，任务源码说明验证器对什么敏感，结果记录确认尝试是否进入分数，镜像构建和权限配置则说明环境是否开放了这条路径。此前 Meerkat 等工作已经表明，跨大量轨迹搜索能发现单条记录审计遗漏的异常；BenchShield 进一步把任务包与宿主侧事件接到每一次具体评分上。
隔离验证器有效，却解决不了“测错了什么”
论文把六种隔离措施分别放入反事实分析。单独使用分离验证器环境，可以移除暴露在 I1 至 I4 上的 82%—95% 任务包；隐藏验证文件和把任务文件设为只读，也分别覆盖了大部分观察泄露和约三分之一的可信状态改写。Terminal-Bench 3 的现行设计由此仍是一项高收益基础措施。
没有一种隔离措施改变 I5 的失败处理或 I7 的语义充分性。验证器崩溃后是否默认给分，是评分程序的控制逻辑；一份产物是否真正完成任务，则取决于任务定义和验证标准。分离容器可以阻止 Agent 直接编辑答案文件，不能判断一段合法提交的程序是否在验证阶段悄悄改写物理模型，也不能证明一个模型评审理解了开放式任务的真实要求。
BenchShield 自身也受这条边界约束。它需要先把任务转换成 BenchFlow 形式，固定的生命周期未覆盖所有多角色或开放探索场景；原始动作到生命周期事件的适配仍引入语义判断。论文使用 Claude Opus 5 完成全部模型调用，456 条裁决轨迹和 34,000 行新增实现尚未在论文页面提供独立复现结果。系统能生成一份更完整的运行收据，不能凭这份收据证明任务定义本身正确。
对发布 Agent 排行榜的团队，最直接的改变不是再加一个“反作弊提示词”，而是把分数当成需要来源证明的构建产物：固定任务和验证器版本，隔离 Agent 与验证环境，记录权限、网络、交接物、验证器输入和奖励来源，对未知事件与验证失败默认拒绝，并把语义审计与结构结论分开保存。只有这样，一次满分才能回答两个不同的问题：Agent 得到了什么分，以及这份分数究竟证明了什么。
