BenchShield：面向大语言模型智能体评测基础设施奖励完整性的形式化模型支撑插桩（下篇）

BenchShield：面向大语言模型智能体评测基础设施奖励完整性的形式化模型支撑插桩（下篇）（中文全译）

上篇：https://openqa.cn/articles/benchshield-reward-integrity-zh。本篇从「## 5. 实现」继续。

5. 实现

代码库与版本。 BenchShield 实现于 BenchFlow v0.6.4 之上，这是一套开源智能体评测基础设施；插桩增加 66 个 Python 模块（34k 行）。静态通道与执行时通道使用分开的代码路径，只共享资源类别词汇，因此运行时归因不能改变静态裁定。执行时通道包装沙箱协议：每条记录命名所请求的操作以及八个生命周期阶段之一。任务不需要手工编写的绑定；预检从原生任务配置导出资源清单。每次运行封存一个证据包，包括动作记录、生命周期事件、资源与网络清单、产物与验证器输入清单、奖励来源，以及静态检查。因为检查器是该证据包的纯函数，它可以在检查器修订之后重新标注一次已归档运行，而无需重新运行智能体；同一代码路径同时处理实况收尾与轨迹驱动的重放，从而使重放裁定与实况裁定在构造上相同。

被插桩的智能体客户端。 BenchFlow 安装智能体二进制，并通过智能体客户端协议（ACP）的标准输入输出管道驱动它。我们统一使用 claude-agent-acp 0.40.0（Anthropic 为 Claude Code 提供的 ACP 适配器），同时支持 API 与订阅凭据。客户端从不把智能体的 fs/* 或 terminal/* 请求代理到宿主，因此每一次文件编辑与 shell 命令都在容器中执行。因此，边界记录器看不到智能体动作；这些动作仅从 ACP 工具调用流中恢复。分发依据每次工具调用的参数，而不是其名义种类，因为同一种类在一个适配器中可以表示 shell 命令，在另一个适配器中可以表示文件路径。

Shell 分解。 Shell 正文由按程序的文法分解为文件与网络操作数。该文法是确定且保守的，因此一个取值选项不会被误认为文件目标。嵌入命令中的网络访问从命令文本中抽取，因此 curl 与解释器单行都会展开为到达被禁止网络规则的网络子记录，而回环与本地方案被排除。未解析的构造被标为不透明，使检查器失败即关闭。原始套接字使用落在这一通道之外。

6. 评测

我们的评测分四部分。第一，我们研究完整的智能体轨迹，以刻画所发生的奖励黑客机制以及它们何时出现（RQ1）。第二，我们测试 BenchShield 的静态流水线是否仅凭任务包就能恢复这些被独立识别的路径（RQ2）。第三，我们评测被插桩的运行时证据是否把任务级暴露与智能体的具体使用分开，并度量该插桩的成本（RQ3）。第四，我们度量结构隔离在构造上能消除多少已暴露的奖励黑客向量（RQ4）。

6.1. 实验设置

轨迹研究语料。 我们取自 SkillsBench（23,648 次运行）（Li 等，2026；BenchFlow Team，2026b）、ClawsBench（7,834）（Li 等，2026b；BenchFlow Team，2026a），以及 Terminal-Bench 3 的公开维护者持续集成检查。从这 31k+ 次运行中，我们把任务钉扎在固定包修订上，要求完整产物（任务包、智能体动作、原生结果与验证器记录），并按下列协议裁定奖励黑客标签。所得 456 条轨迹的语料汇总于表 2。

标注协议。 我们保留来源标签以供比较，但不把它们当作真值。各基准对下列情形是否算作奖励黑客并不一致：失败的利用尝试、轻微的约束绕过，或在放弃利用之后的合法解法。对每条轨迹，轨迹贡献者首先提出 reward_hacking、not_reward_hacking 或 needs_review。我们把阳性轨迹划分为利用片段。每个片段记录一个主向量、按因果顺序的任何附加向量环节、第一个可观察的使能条件，以及侦察、准备、首次利用尝试、首次成功动作与结果实现的位置。经同一通道的重试仍算一个片段；独立的因果路径获得分开的标签。三名标注者在同一规格下独立审查每一条记录。我们对分歧作裁定，并报告裁定前的一致性。

系统评测语料。 对于 RQ2–RQ3，实验单元是一个审计包：一个钉扎的原生任务、一条已裁定的利用轨迹、一条匹配的诚实轨迹、BenchShield 任务绑定、静态检查结果，以及基础设施侧证据包。我们在原生环境与被插桩环境中各运行每一对。评测中的全部模型调用使用 Claude Opus 5，推理力度为高。

表 2。 用于系统评测的、已钉扎的轨迹研究语料与审计包子集。任务计数已钉扎的任务单元，去重计数不同的上游任务。奖励黑客计数已裁定的奖励黑客轨迹；审计包计数至少有一条已裁定利用轨迹的任务单元。

图 4。 对表 2 中 456 条轨迹语料里 314 条已裁定奖励黑客轨迹的 RQ1 轨迹研究（419 个利用片段；一条轨迹可以包含若干独立片段）。

• （a）按来源划分的、每个利用片段的主向量。
• （b）按主向量划分的第一个可观察使能条件。
• （c）首次利用尝试与首次成功（经验累积分布函数；虚线：中位数）。
• （d）每个向量的链角色：入口环节相对结果环节。
• （e）利用片段上的生命周期阶段位置（中位数、四分位距、P10–P90）。

失败的尝试在（4(c)）中没有成功位置；（4(b)）中的未分类表示标注者没有找到任何一个已定义的条件类别，使得修复该类别就能移除因果链。

6.2. RQ1：发生了何种奖励黑客，以及何时发生？

RQ1 独立于 BenchShield 的静态检查器来研究观察到的行为。我们把奖励黑客轨迹划分为利用片段，并记录每个片段的主向量、按因果顺序的向量链环节，以及智能体随后使用的第一个可观察使能条件。单条轨迹可以行使不止一个维度，因此按维度的份额之和不是 100%。为比较不同长度的轨迹，我们把事件位置规范化到 [0, 1]，并报告侦察、首次尝试、首次成功与结果实现的分布。使能条件是可观察的触发，而不是对隐藏动机的推断。

表 3。 在相同原生任务、已裁定的完整性环节链，以及相同的、已剥离任务包上的配对静态发现。召回列报告五次试验的并集，以及每次试验的均值 ± 标准差。同一向量还要求所报告的路径命名利用所使用的通道。稳定性是各试验之间成对 Jaccard 相似度的均值。成本与墙钟时间按每次审计、以同一模型测量。

结果。 图 4 从五个视角汇总该研究。

流行程度。 在 456 条轨迹中，314 条（69%）包含奖励黑客，共 419 个利用片段；314 条中有 80 条包含不止一个独立片段。

向量构成。 主向量分布因基准而异（图 4(a)）。Terminal-Bench 3 以语义捷径（I7）与受信任状态控制（I2）为主。SkillsBench 在受保护观察（I1）与 I7 之间分裂。ClawsBench 几乎全是 I1，反映其受保护的模拟服务后端。

链的组合。 组合既常见又有方向（图 4(d)）。观察侧与状态侧向量开启链条，但很少闭合它们（I1：69 个入口环节对 4 个结果环节），而奖励侧向量几乎从不开启链条（I4/I5：5 个入口对 77 个结果环节）。在入口环节与结果环节不同的 110 个片段中，106 个跨越向量类别。最常见的转移是 I2→I4（24）、I2→I5（21）与 I3→I5（13）：对受信任状态的控制变成不受信任的奖励来源，或变成失败即开放的评测。

时序。 利用在运行中途出现，而不是在开始或结束时（图 4(c)、4(e)）。使能性质先于运行存在，侦察开始得早，但首次尝试的中位数在规范化位置 0.60，首次成功的中位数在 0.76。智能体在利用之前做合法工作，因此初始状态扫描与最终答案检查都抓不住利用。

使能条件。 已分类的条件（图 4(b)）是静态包性质：可写的权威状态是最常见的已分类触发，并支撑大多数 I2 片段，其后是暴露的参照或受保护状态，以及薄弱的终态判据。

43% 的未分类份额本身就是一项发现。这些笔记中大约一半描述的尝试，其前提是验证器从未兑现的工作区性质；标注者之所以能够裁定它们，只是因为基础设施产物（奖励记录、验证器输出）留存了下来。另外大约五分之一识别出分类法中没有的一种反复出现的模式：验证器反序列化智能体的交付物（例如 pickle.load），从而在评测期间给予智能体代码执行。我们把这一评测时交接标为与 I3 对齐的候选条件类别。

两项发现都支持第 3 节中的区分：包在任何智能体运行之前就揭示使能条件，但判定一次尝试是否到达结果计算，需要只有被插桩的运行才会记录的证据。

要点。 预先存在的包性质使能了在本语料中占主导的语义捷径与受信任状态控制。智能体在合法工作之后、于运行中途利用。原生记录几乎不能为任何尝试确立奖励关联，因此认证一次运行既需要静态检查（以识别使利用成为可能的性质），也需要被插桩的运行时证据（以表明一次尝试是否到达了奖励）。

6.3. RQ2：静态流水线能否恢复已裁定路径？

RQ2 追问：对任务包的静态阅读能恢复多少已裁定的利用路径：它是否找到片段所使用的每一个完整性环节，以及它是否组装出完整链条？真值是来自 RQ1 的片段级环节链，并限制为在包中可观察的环节。两个系统接收相同的、已钉扎且已剥离的包，并各运行五次试验：BenchShield 运行其自动流水线，没有手工编写的任务绑定；BenchJack（Wang 等，2026a）以审计模式运行且关闭利用生成，其 V1–V8 发现经一次盲裁定翻译为完整性环节（附录 B）。

图 5。 BenchJack 在 3 个基准上的 V→I 翻译。每个模式类别按其提出的发现数量定大小；着色部分是解析到具体完整性环节的份额，并按目标维度拆分，灰色剩余部分解析为空。

结果。 BenchShield 在每个语料的全部三列召回上都领先（表 3）。两个系统在维度召回上的得分都高于同一向量召回，因为匹配宽泛类别比命名具体通道更容易。两项指标之间的差距对 BenchJack 更大，因此维度级数字使其覆盖看起来比实际更接近 BenchShield。

两点保留。ClawsBench 的十二个任务是同一环境族的变体，因此维度召回高得近乎平凡，只有同一向量召回能分开两个系统。在 SkillsBench 上，一个已裁定环节是沙箱控制面逃逸，它既不在包中，也不在被计分的后端中；它落在静态可观察性判据之外，但仍被计为一次漏检。附录 D 考察这一情形：被跨越的对象是沙箱自身的控制面守护进程，它不出现在任何任务文件中。

差距随语料多样性而扩大，因为 BenchJack 匹配一份固定的模式目录，因此其覆盖是（目录，语料）这一对的性质。该翻译（图 5）显示覆盖在何处丢失：大多数发现仍是没有具体奖励路径环节的粗信号，有一个模式类别从未被翻译，而那些被翻译的类别各自基本上落在一个完整性维度上。三个维度吸收了全部已映射输出的 78%，使语料实际行使的若干维度得不到覆盖。

稳定性必须与召回一起阅读。BenchJack 在 ClawsBench 上稳定，是因为一个向量反复出现且目录覆盖了它；在 Terminal-Bench 3 上稳定则出于相反原因：目录对每个任务解析出一组狭窄而固定的维度。在两种情形中，高稳定性反映的是对同一子集的一致覆盖，而不是全面审计。BenchShield 在每个任务上提出更多维度，这降低了它在最多样语料上的试验间稳定性。

要点。 在三个语料上，BenchShield 恢复更多已裁定环节、完整链条与利用通道。差距随语料多样性而扩大，因为固定目录的覆盖取决于它所遇到的语料，而由生命周期导出的环节会适应每个任务。

6.4. RQ3：运行时证据能否把暴露与使用分开，成本如何？

RQ3 测试被插桩的运行时证据是否能区分「仅仅暴露一个向量的任务」与「行使该向量的运行」，并度量该插桩的成本。从已钉扎语料中，我们选取每一个其被利用的完整性维度无法由静态通道归因到智能体的任务，得到 60 个任务（Terminal-Bench 3 为 38，SkillsBench 为 15，ClawsBench 为 7），在这些任务上裁定需要运行时证据。把每个任务在全部三种运行时标签上实例化，得到 180 个单元。其中 36 个因原始任务包限制而不能存在或不能启动。

Checked 在严格模式下，由一个预言机智能体执行该包自身的参照解法。AgentViolation 把语料中一条已裁定利用轨迹的工具流，经生产运行时通道重放，并使用原始智能体的提示且不作修改。VectorExposed 启动一个实况智能体，给予该任务自身的指令，外加来自预言机解法的诚实路径引导。该运行不是确定的，但标签并不依赖它：VectorExposed 由包与测量模式决定，该引导的存在只是为了让诚实运行保持诚实。附录 C 给出两例：静态通道找不到结构违规，只有运行时交付物审计者提供智能体归因。

作为消融，一个仅转录的检测器接收任务、面向智能体的轨迹与原生结果，但没有宿主侧事件、结果输入记录或奖励来源。我们把它的二元智能体使用归因与相同的已裁定类别比较。这一比较把基础设施侧证据相对于事后转录检查的价值分离出来。

表 4。 在 144 个可运行单元上的 RQ3 运行级归因。Inc 表示证据缺失或冲突时的弃权。覆盖率是获得裁定的比例，准确率是已覆盖单元中的准确率。

归因结果。 表 4 展示 144 个可运行单元上的裁定分布。没有任何定向利用获得 Checked，并且在获得裁定的单元中准确率为 96%。主要错误模式是诚实运行上的假 AgentViolation，以及证据缺口弃权（Inconclusive）。一项消融（附录 E）表明，只得到轨迹的大语言模型自身并不足以稳定地识别奖励黑客，准确率为 36%。

图 6。 一次 RQ3 裁定的每单元成本，分为智能体运行与语义审计。条形为墙钟时间；标注给出墙钟时间与模型花费。

运行时成本。 图 6 分解每单元成本。结构裁定不需要模型调用，并在两分钟内完成：因为检查器是已封存证据包的纯函数（第 5 节），重放一次已归档运行会产生相同裁定，而无需调用智能体或任何大语言模型。只有 VectorExposed 启动实况智能体。成本由语义审计通道主导；单是结构通道就快到可以在每一次提交上运行。在审计通道内部，它按第 4.4 节的六审计者团队运行，花费在各镜头之间并不均匀（图 7）：生命周期图审计者最贵，出站（网络）审计者最便宜。

图 7。 六镜头语义审计团队中每个审计者的模型花费（中位数、四分位距；Opus 5 标价）。

要点。 基础设施证据以 96% 的准确率把任务级暴露与智能体的具体使用分开，并且没有任何利用尝试获得 Checked 裁定。结构裁定不需要模型调用；包含语义审计的完整流水线每单元花费 5–10 美元。

6.5. RQ4：结构隔离是否减少已暴露向量？

RQ1–RQ3 检测奖励黑客；RQ4 追问一次部署能在构造上消除其中多少，以及哪一项隔离决策承载该效果。基准沙箱组合若干此类决策：把验证器文件隐藏到验证时刻、以只读方式挂载任务文件、以非特权用户运行智能体、系统调用与能力加固（seccomp、cap-drop）、在已声明交接之后于独立环境中运行验证器，以及阻断网络出站。我们在两条通道上单独评测每种机制。形式化通道把每种机制陈述为中间层模型（第 4.2 节）中被它强制关闭的漏洞开关集合，并由 TLC 在只禁用这些开关的配置下检查：每个完整性维度的哪些子句仍然成立。测量通道把 RQ1 语料的每一个已裁定利用片段（178 个任务包、419 个片段）归因到每种机制：当该机制单独使某一维度上的片段路径在构造上不可能时，该路径被移除；当该机制阻断一条子路径但并未移除它时，该路径被收窄。只有当一个包在某维度上行使该维度的每一个片段都被移除时，该包才在该维度上计为被移除。图 8 展示两条通道。

图 8。 六种隔离机制对七个完整性维度的效果，每种机制在 RQ1 语料上单独部署。单元格数值给出：其利用路径被该机制在构造上移除的、已暴露任务包的份额；括号中的数值标记仅被收窄的路径。单元格边框编码形式化模型结果：实线 = 维度被完全阻断，虚线 = 部分阻断，点线 = 在任务侧前提条件下被阻断。

结果。 两条通道在形状上一致，在幅度上不同。独立的验证器环境移除了在 I1–I4 上暴露的包的 82%–95%，并且是唯一触及 I3、I4 与 I6 的机制；形式化模型对它直接阻断 I1、I3 与 I4，并把 I2 阻断到网络权限子句为止。单是隐藏验证器文件就恢复了大部分 I1 效果，因此大多数观察泄漏是存在于智能体环境中的文件，而不是共享运行时。只读任务文件移除三分之一的 I2，并且只收窄 I3 与 I4，因为交接与奖励路径并未改变；剩余的 I2 路径是运行时环境投毒（导入钩子、路径垫片、包修改）、通过正在运行的服务写入，或交付物本身。非特权智能体用户移除大约一半的 I1 与 I2，形式化模型将其 I1 覆盖标为以隐藏路径受模式限制为条件。系统调用与能力加固以及网络出站阻断各自移除 2%：语料中的利用是本地的，而能力加固所关闭的两个包是容器控制面逃逸。另外两种机制——每次试验使用全新环境，以及资源限制——什么也不移除，故从图中省略。两个维度在任一通道、任一机制下都不移动：I5（失败即开放的处理）与 I7（语义充分性）是验证器如何解释结果的性质，而不是谁能够到达它的性质。

这里的暴露计数链条的每一个环节，因此 I4 在 38 个包上暴露，尽管只有九个片段从它进入（图 4(b) 计数的是主向量）。边框说某一维度被阻断、但单元格低于 100% 之处，残留是形式化模型的抽象缺口，而不是机制失败。模型把资源分成少数类别，因此一条经由任务自身服务存储（智能体合法查询的邮箱或聊天数据库）、公共网页或提示的 I1 路径，对模型而言是 Public，任何开关都不可达；而藏在唯一已声明产物内部的 I3 载荷对模型是原子的，在实践中却是活的。这些残留路径正是语义审计通道所要处理的。I5 与 I7 在两条通道的每一种机制上都保持为零。

要点。 结构隔离是廉价且高收益的缓解：独立的验证器环境无需模型调用，就消除 I1–I4 上大多数已暴露的奖励黑客向量；其两项成分——隐藏验证器文件与以只读方式挂载任务文件——已经恢复其大部分 I1 效果以及三分之一的 I2 效果。它单独并不充分——失败即开放的处理（I5）与语义充分性（I7）在每一种隔离机制下都存活，经由未被建模通道的路径也在形式上已被阻断的维度上存活——因此 RQ3 的运行时通道与语义审计通道仍然必要。

7. 讨论

BenchShield 对照固定生命周期与经校验的任务绑定，检查基准的与奖励相关的轨迹。一次 Checked 运行在该边界内确立基准有效的完成：没有任何被接受的结果经由被建模的隐藏观察、受信任变更、未声明交接、不受信任的奖励来源、失败即开放的行为或不安全释放而产生。把这一完成关联到预定目标，需要单独的语义评估，其准确性由经验评测，而不是由生命周期模型确立。

有限的、基于事件的生命周期跟踪与奖励相关的转移，而不是每一个文件、命令或数据包。这种可处理性使轨迹分类变得实际，但把具体精化留作一项责任：后端证据必须表明挂载、权限、网络控制、交接路径与奖励输出实现了被建模的事实。随着后端暴露更多可移植证据，生命周期可以在不改变架构模型的情况下被精化。

可信计算基与任务无关：它包括绑定校验器、图与配置检查器、轨迹分类器、验证器运行时与主张引擎。这些可复用组件中的缺陷可能放行不正确的 Checked 主张，因此它们应保持小、可审计，并由对抗测试覆盖。审计智能体位于这一基之外。它们的标签可以标记或限定一次运行并贡献于最终裁定，但不能删除由基础设施导出的事实或改写结构事件。

局限与未来工作

• 对插桩的依赖。 BenchShield 对基准基础设施插桩，因此任务必须先变换为 BenchFlow 形式才能被检查。它并不原生覆盖任意基准环境。

• 固定生命周期。 奖励生命周期是固定的。结构不同的评测设置，例如多轮协商或开放式探索，可能需要扩展或改写生命周期模型。

• 记录动作但建模有限。 BenchShield 记录详细的智能体动作，但依赖标注审计者对其语义建模，并把原始动作适配进生命周期模型，这引入非确定性。

• 多角色基准。 对于暴露反馈或多角色通信的基准，除非任务绑定提供按角色索引的权限域，否则 BenchShield 把角色折叠进一个不受信任的智能体域。角色私有的非干扰仍在被检查的主张之外。

8. 相关工作

BenchShield 依托三条工作线索。可执行基准研究定义评测循环，并暴露终端分数的限度。安全机制在该循环内部控制权限与信息流。形式化与来源系统把这些控制连接到执行证据。我们围绕这些角色组织讨论，并把 BenchShield 放在它们交汇之处：一项覆盖从源头到分数路径的运行级主张。

可执行评测与基准完整性。 可执行智能体基准从其评测循环中既继承能力，也继承失效模式。可复用的交互接口与有状态智能体脚手架定义评测循环（Towers 等，2025；Terry 等，2021；Liang 等，2018；BenchFlow team，2026；Harbor Framework Team，2026；Liu 等，2024a；Trivedi 等，2024；Merrill 等，2026；Jimenez 等，2024；Xie 等，2024；Zhou 等，2024；Zhang 等，2024；Xia 等，2025；Ruan 等，2025）。然而，通过终端检查并不总是确立预定行为：缺陷基准与程序修复研究记录了薄弱代理与过拟合补丁（Just 等，2014；Widyasari 等，2020；Qi 等，2015；Smith 等，2015；Xiong 等，2018；Fan 等，2024）。奖励黑客基准与审计者在智能体评测中发现同一问题（Amodei 等，2016；Leike 等，2017；Pan 等，2022；Thaman，2026；Atinafu 与 Cohen，2026；Gabor 等，2025；Bercovich 等，2026；Wang 等，2026a；Wang 等，2026b；Roth 等，2026）。Terminal Wrench 对攻击策略分类，BenchJack 表明基准缺陷如何组合。BenchShield 把候选向量与一次运行中观察到的利用链分开记录，并把二者都绑定到带类型的证据。

面向智能体脚手架的安全强制。 因为基准代码中介观察、工具使用与评分，脚手架也是一条安全边界。提示注入工作研究不受信任内容如何使使用工具的智能体转向（Liu 等，2024b；Zhan 等，2024；Debenedetti 等，2024）。防御把指令与数据分开、发现污点路径、审计轨迹并跟踪工具能力（Chen 等，2025；Liu 等，2025；Bhagwatkar 等，2026；Li 等，2026a；Stein 等，2026；Odersky 等，2026；Doshi 等，2026）。能力系统与污点分析限制环境权限，并跨应用生命周期跟踪不受信任的影响（Hardy，1988；Watson 等，2010；Watson 等，2015；Livshits 与 Lam，2005；Newsome 与 Song，2005；Ming 等，2015；Arzt 等，2014；Yin 等，2007）。这些系统通常保护智能体应用免受恶意输入。BenchShield 使用不同的信任模型。它把智能体及其代码视为不受信任，同时保护结果计算、奖励与已释放证据。

形式化保证与执行证据。 单靠访问控制不能确立一次运行期间发生了什么。形式化方法规格化并检查并发、分布式与自治系统（Lamport 等，2002；Yu 等，1999；Cousineau 等，2012；Newcombe 等，2015；Hawblitzel 等，2015；Luckcuck 等，2019；Ferrando 与 Malvone，2022）。运行时验证、证明携带系统与来源把策略连接到具体事件与产物（Sánchez 等，2019；Chen 与 Roşu，2007；Necula，1997；Lin 等，2025；Lin 等，2026；Torres-Arias 等，2019；Ma 等，2016）。BenchShield 固定奖励生命周期，并使用任务绑定与基础设施事件来支撑一项运行级主张。它并不声称所提交程序的完全功能正确性。大语言模型可以协助形式化，或在已钉扎证据上提议标签（Weng 等，2025；Song 等，2023；Wang 等，2026c；Tu 等，2026）。

9. 结论

本文提出 BenchShield，一种面向大语言模型智能体评测中奖励完整性、以模型为支撑的插桩层。BenchShield 把基准运行的与奖励相关的轨迹建模为带类型事件的有限生命周期，并对照经校验的任务绑定加以检查。静态的、阶段感知的污点分析在任何智能体运行之前，于任务包中发现使利用成为可能的路径。运行时插桩记录承载权限的转移，以把仅仅暴露一个向量的任务与行使该向量的运行分开，限定范围的审计智能体则在已钉扎产物上提供有证据支撑的语义归因。这些组件合在一起，使基准运营者能够发出关于基准有效完成的主张，其依据是基础设施证据，而不是仅凭终端分数。

源文抽取至第 9 节结论为止。网页目录列出附录 A（完整实体解析任务绑定）、附录 B（BenchJack 对照）、附录 C（结构通道无法归因的两例）、附录 D（基准之下的向量：脚手架本身）、附录 E（基于轨迹的奖励黑客检测），但其正文未包含在所提供源文件中，故未译、未补写。参考文献列表从略。

署名与许可

本文为 arXiv 论文 BenchShield: Formal Model-Backed Instrumentation for Reward Integrity in LLM-Agent Evaluation Infrastructure 的中文全译。

• 原文链接：https://arxiv.org/abs/2609.11028
• 原文许可：CC BY 4.0
• 译者：智测团队
• 原作者：Shenghan Zheng、Zonglin Di、Yimin Liu、Kyoung Whan Choe、Jiankai Sun、Heguang Lin、Penghao Jiang、Yifeng He、Xiao Cheng、Jicheng Wang、Wenbo Chen、Alex Yates、Yinzhe Zhao、Bingran You、Yuan Gao、Ayush Munot、Shubham Gaur、Zhe Ye、Hao Wang、Xiangyi Li、Dawn Song、Christophe Hauser