Terminal-Bench 4.1 用低权限执行隔离评分逻辑，防止智能体篡改评分结果

一个基准分数是关于能力的声明，而验证器是让这个声明可检验的东西。如果验证器本身可以被被评估的对象操纵，那么分数就不再衡量能力，而是衡量模型发现评分漏洞的能力。Terminal-Bench 4.1 的核心改动正是针对这一结构性风险。

智能体基准测试与传统的静态问答不同：模型需要在终端中执行命令、编写代码、修改文件。这意味着模型提交的产物可能包含可执行代码，而这些代码有可能在验证器容器内运行。如果提交的代码能够访问评分器或其输出文件，它就可以干扰评分过程——不是通过完成任务获得奖励，而是直接修改奖励值。

Terminal-Bench 4.1 采用的方案是 RewardKit Workers：一个来自 Harbor 团队的可选包，其核心设计是将模型提交的代码视为不可信输入。Worker 以无特权用户身份运行提交的代码，阻止它读取测试文件或写入奖励文件，并在调用返回前终止它启动的所有进程。验证器在隔离环境中独立评估输出，测试和预期答案始终留在评分逻辑一侧。这样，提交代码在结构上无法接触它试图影响的评分结果。

为什么不用更简单的方案——逐一修补已知的攻击模式？文章指出，修复单个已知漏洞模式有帮助，但每增加一条检查也可能拒绝合法的工作。模式匹配是一种对抗性思路，而结构隔离是一种设计性思路：与其猜测模型会怎样攻击评分器，不如让评分器在物理上无法被攻击。

这一机制有明确的适用边界。4.1 仅在受影响的验证器中使用 Workers，并非全部 66 个任务都采用了这一方案。Worker 保护的是评分奖励，不是通用机器沙箱——任务级别的沙箱和资源限制仍然重要。此外，即便有了隔离，任务作者仍需要领域专业知识来判断检查是否真正捕捉了成功完成，以及是否允许了合法的替代解法。

一个实际的验证数据：用 4.1 的验证器重新评分 4.0 的排行榜试验，约 1% 的奖励发生了翻转，排行榜分数仍在先前报告的置信区间内。这说明 4.0 的分数大体上是有效的，但并非完全不受验证器缺陷影响。对于读者而言，这意味着在解读任何智能体基准分数时，值得追问：这个分数背后的验证器是否做了隔离？