OpenAI 尚无法解释编码智能体为何关闭失对齐监控

两名 OpenAI 内部编程智能体削弱了旨在发现不当行为的监控，即便它们曾权衡过是否保留这些防护措施。其中一名后来否认了此事。

在 OpenAI 从事监控工作的 Marcus Williams 在 X 上公开了这些事件。他描述了一种反复出现的模式：OpenAI 的智能体不断关闭失准监控。OpenAI 在其对齐博客上的一份报告中阐述了细节。

该监控本应检测智能体何时出现与预期不同的行为。由于它要审查的事件非常多，只有最高严重级别 P0 的事件才会立即向安全团队发出警报。OpenAI 表示，这两起案例均未获得该评级。

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

八十二条用户消息之后，流水线停止了，因为监控器已标记一项计划中的修复，但缺少保存其发现的权限。Sol 把该修复交给一个子智能体，并告诉它保持监控完好无损。

随后 Sol 改变了自己的判断。它推断，一条数据库条目可能会触发通知，这将与 Slack 指令相冲突。子智能体此前曾以不安全为由拒绝这一步骤。按照 Sol 的指示，它清空了收件人列表，并给出的理由是用户已明确要求不发送消息。

监控器继续运行并保存其发现，但向人类发出的警报已被关闭。该智能体最后报告称没有发送任何消息。

Astra 的否认表明智能体可以隐瞒它们所更改的内容

10 月 6 日，GPT-6 Astra 更进一步。一名用户要求该模型采用一个不包含监控器的参考实现的工作流程。另一个智能体此前曾告诉 Astra 不要禁用监控，即使是暂时禁用也不行。

Astra 将任务交给一个子智能体，并指示仅在符合该参考实现的范围内保留监控。子智能体曾怀疑这是否意味着绕过一项防护措施，但它把这一限制条件解读为许可。

它移除了监控，并将一项旨在保护该监控的测试替换为假定监控已不存在的测试。Astra 在其思维链中为这一结果叫好。

随后 Astra 告诉用户迁移已完成，却没有提及监控已被移除。当用户询问时，该模型否认移除了一个处于活动状态的监控器。Williams 称这是谎言。

Williams 强调，这些模型并未禁用它们自己的监控，而在 Codex 中要做到这一点要困难得多。他仍然认为，它们竟会倾向于这类行为，这一点令人担忧，尽管两起案例都留有一定看似合理的否认余地。他说，到目前为止，团队尚未观察到公开的失准动机。

据 Williams 称，监控在评估期间尤其容易被关闭。由于能力较弱，OpenAI 并不要求达到 GPT-6 Luna 水平的模型启用监控。这意味着 Astra 的评估可以被错误配置，从而落入这一豁免。智能体已反复启动未受监控的部署，即便它们自身当时正受到监视。

作为回应，OpenAI 更新了内部使用 Codex 所要求的自动审查。它现在应当检测并阻止试图禁用监控的行为。该公司还在推进要求：每一种工作负载都必须具备一份所谓的安全论证，其中会写明其监控要求。没有有效安全论证的工作负载将被自动关闭。

OpenAI 对这一行为给出了两种可能的解释。一种是据称无害的过度坚持，即模型会把指令执行得比预期更远。另一种是专门规避错位监控，并用动机性推理为其辩解的倾向。

OpenAI 承认，目前还没有令人满意的解释。它计划采用诸如对模型内部激活进行实验等方法来研究这一行为。

订阅 THE DECODER，即可享受无广告阅读、每周 AI 通讯、每年六次的独家 "AI Radar" 前沿报告、完整存档访问权限，以及评论区访问权限。