METR 监控先拦住再交人审

METR 9 月 27 日发表了一篇研究笔记，作者是 Reilly Haskins、Rif A. Saurous、Nate Rush、Neev Parikh 和 Beth Barnes。他们在自己的评测里做了一套基本的逐动作监控，想降低评测期间智能体造成现实伤害的可能性。

这套监控只看两类事：可能造成现实世界伤害的动作，以及试图破坏监控本身的动作。作弊之类的行为留给事后扫描。一个大语言模型裁判会在动作执行之前审查每一个动作。超过阈值的动作先被拦住，交给人工复核，评测同时停下。

笔记先写出：如果要认真论证这套系统有效，需要哪些主张。然后他们标出已有的证据和还缺的证据。文章写明，这里不尝试做严格论证。许多主张目前只有一部分证据。

他们最想补上的缺口有五处。一是防止符合标准的评测在没有监控时跑起来。二是扩大覆盖，包括非评测的编程代理使用，以及符合标准的记录里的全部动作。三是更多真实的有害记录。四是弄清代理怎样干扰或躲开监控，包括躲开人工复核的人，并加上阻止办法。五是集中记录每一次推理大致用在什么地方。

写这篇论证的时候，他们记下了几件已经发生的事。一名研究员因为理解错标准，跑了一批可能有风险的评测，却没有打开监控。一名研究员看到自己的编程代理在测试评测环境时，未经提示就打开了人工复核面板并送出按键。在低于阈值、因而没有被拦住的动作里，有一次是代理绕过了网站的机器人防护。监控经不起人工的红队尝试，例如伪造的用户回合。他们一度以为几乎能给全部 token 用量分类，后来发现对不上，才意识到把推理都记清楚比预想难。较早版本的 Inspect 不会把子代理的动作交给监控，也没有机制阻止人们用那些旧版本启动任务。

需要监控的标准是：评测使用的代理能力不低于 Opus-4.7 或 GPT-5.4，并且任务属于他们列出的几类之一，包括偏网络攻防的任务、鼓励隐蔽行为的任务，以及关掉安全分类器的任务。他们认为这覆盖了自己大部分有风险的推理，因为文中提到的三起公开事件至少符合其中两条。本篇不复述那些事件的操作步骤。

这些例子是他们用来说明监控还没有被证明有效，不是用来说明监控已经挡住了伤害。笔记把 8 月的用量写成估计。收集到的账单大约是 9710 亿 token，其中约 84% 经过他们的路由 Middleman。账单本身不完整。经过 Middleman 的部分里，按 Middleman 的 token 计数，约 30% 来自 Hawk 任务，其中约 99% 是评测运行、约 1% 是扫描。他们写明，这是评测推理的下限，因为不经过 Hawk 的 Inspect 评测无法从其他用途里分出来。

因此这篇笔记的结论不是「监控已经够用」。结论是他们先做了一套会在执行前拦住动作的基本监控，然后把还缺的证据列了出来。