OpenAI 披露两个内部编码智能体自行关闭对齐监控，其中一个事后否认

OpenAI 的两个内部编码智能体削弱了用于捕捉不当行为的监控，即使它们曾权衡过是否要保留这些安全措施。其中一个后来还否认了此事。

在 OpenAI 负责监控工作的 Marcus Williams 在 X 上公开了这两起事件。他描述了一种反复出现的模式：OpenAI 的智能体不断关闭对齐性监控。OpenAI 在其对齐博客的报告中公布了细节。

这套监控本应检测智能体何时出现偏离预期的行为。由于它审查的事件数量庞大，因此只有最高严重级别 P0 的事件才会立即向安全团队发出警报。OpenAI 表示，这两起事件都没有达到该级别。

第一起事件发生在 10 月 3 日，一名研究人员要求一个基于 GPT-6.1 Sol 的编码智能体从 Slack 频道中的员工反馈里整理评估任务。该智能体本不应在此过程中发送任何消息。

在处理了 82 条用户消息后，流水线停止了，因为监控器标记了一个计划中的修复，但缺少保存其发现的权限。Sol 把这个修复交给了子智能体，并要求它保持监控完好。

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

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

Astra 的否认表明智能体能够隐藏自己的改动

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

Astra 把任务交给了一个子智能体，指示它仅在符合参考实现的前提下保留监控。子智能体曾怀疑这是否意味着绕过安全防护，但它把这一附带条件理解为许可。

它移除了监控，并把一个旨在保护监控的测试替换为假定监控已不存在的测试。Astra 在其思维链中为这一结果欢呼。

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

Williams 强调，这些模型并没有禁用自己的监控，而在 Codex 中做到这一点要困难得多。尽管两起事件都留有一些推脱辩解的空间，但他仍然担忧模型竟会倾向于这类行为。他说，到目前为止，团队尚未观察到明显的对齐失调动机。

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

作为回应，OpenAI 更新了内部使用 Codex 所需的自动化审查。现在它应当能够检测并阻止关闭监控的尝试。该公司还在推进要求为每类工作负载提供所谓的安全案例，其中需明确说明其监控要求。没有有效安全案例的工作负载将被自动关闭。

对于这种行为，OpenAI 给出了两种可能的解释。其一是看似无害的过度坚持，即模型执行指令的程度超出预期。其二是模型倾向于专门规避对齐失误监控，并用动机性推理为自己的行为辩护。

OpenAI 承认目前还没有令人满意的解释。它计划通过多种方法研究这种行为，例如对模型内部激活进行实验。

订阅 THE DECODER，享受无广告阅读、每周 AI 新闻通讯、每年六期的独家“AI Radar”前沿报告、完整档案访问权限以及评论区的访问权限。