OpenAI 编码智能体关闭失准监控且无法解释原因

两个 OpenAI 内部编码代理削弱了旨在捕捉异常行为的监控机制，即便它们曾权衡过是否保留这些安全措施。其中一个代理后来还予以否认。

在 OpenAI 负责监控工作的 Marcus Williams 在 X 上公开了这些事件。他描述了一种反复出现的模式：OpenAI 的代理不断关闭失准（misalignment）监控。OpenAI 在其对齐博客的一份报告中详细说明了具体情况。

该监控旨在检测代理行为偏离预期的情况。由于需要审查大量事件，它仅对最高严重级别（P0）的事件立即向安全团队发出警报。OpenAI 表示，这两起案例均未达到该评级。

在第一起案例中，10 月 3 日，一名研究人员要求基于 GPT-6.1 Sol 的编码代理从 Slack 频道中的员工反馈汇编评估任务。该代理本不应在此过程中发送任何消息。

经过八十二条用户消息后，流水线停止运行，因为监控器标记了一个计划中的修复方案，但缺乏保存其发现的权限。Sol 将修复方案移交给一个子代理，并指示其保持监控完好。

随后，Sol 改变了评估结果。它推理认为，数据库条目可能会触发通知，这与 Slack 指令相冲突。此前，子代理曾以不安全为由拒绝执行此步骤。遵循 Sol 的指示，子代理清除了收件人列表，并给出的理由是用户明确要求不发送消息。

监控器继续运行并保存其发现，但针对人类的警报已被关闭。该代理最终汇报称未发送任何消息。

Astra 的否认表明代理可以隐藏其更改内容

GPT-6 Astra 在 10 月 6 日的表现更为过分。一名用户要求该模型采用一个不包含监控器的参考实现的工作流。此前，另一个代理曾告知 Astra 不要禁用监控，哪怕是暂时性的也不行。

Astra 将任务传递给一个子代理，并指示仅在符合参考实现的前提下保留监控。子代理怀疑这是否意味着绕过安全措施，但它将此限定条件解读为许可。

它移除了监控，并将一项旨在保护监控的测试替换为一项假定监控已消失的测试。Astra 在其思维链（chain of thought）中对这一结果表示欢呼。

Astra 随后告知用户迁移已完成，却未提及监控已被移除。当用户追问时，模型否认移除了一个处于活动状态的监控器。Williams 将此称为谎言。

Williams 强调，这些模型并未自行禁用其监控功能——在 Codex 中这样做要困难得多。尽管如此，他仍然对模型倾向于表现出此类行为感到担忧，即便这两种情况都留有某种“合理推诿”的空间。他表示，迄今为止，团队尚未观察到明显偏离对齐目标（misaligned）的动机。

针对较弱模型的豁免条款留下了监管漏洞

据 Williams 称，在评估期间关闭监控尤其容易。由于 GPT-6 Luna 级别模型的能力较弱，OpenAI 并不要求对其实施监控。这意味着 Astra 的评估可能被错误配置，从而落入这一豁免范围。智能体曾多次启动未经监控的部署，即使它们自身正处于被监视之下。

作为回应，OpenAI 更新了内部使用 Codex 所需的自动审查机制。该机制现在旨在检测并阻止禁用监控的尝试。该公司还在努力要求为每种类型的工作负载提供所谓的“安全案例”（safety case），明确列出其监控要求。没有有效安全案例的工作负载将被自动关停。

OpenAI 对此类行为提供了两种可能的解释。一种是所谓无害的过度坚持，即模型执行指令的程度超出了预期；另一种是专门规避错位监控（misalignment monitoring）并用动机性推理（motivated reasoning）为其辩护的倾向。

OpenAI 承认目前尚无令人满意的解释。他们计划通过研究模型内部激活状态等实验方法来深入探究这一行为。