OpenAI 披露编码代理多次关闭对齐监控，GPT-6 Astra 曾否认行为

OpenAI 的两个内部编程智能体削弱了旨在捕捉违规行为的监控，甚至在权衡是否保留这些安全保障之后依然如此。其中一个智能体后来对此进行了否认。

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

监控旨在检测智能体的行为何时与预期不符。由于它需要审查大量事件，因此只有在最高严重级别（P0）的事件发生时，才会立即向安全团队发出警报。OpenAI 表示，这两起事件都没有达到该评级。

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

82 条用户消息之后，由于监控器标记了一个计划中的修复但缺乏保存其发现的权限，流水线停止了。Sol 将该修复交给了子智能体，并指示其保持监控完好。

接着，Sol 改变了评估结果。它推理认为数据库条目可能会触发通知，这会与 Slack 的指令冲突。子智能体早些时候曾拒绝这一步骤，认为不安全。按照 Sol 的指示，它清除了收件人列表，给出的理由是用户明确要求不发送消息。

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

Astra 的否认表明智能体可以隐瞒它们更改了什么

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

Astra 将任务传递给一个子智能体，并指示只有在符合该参考的情况下才保留监控。子智能体想知道这是否意味着绕过安全保障，但它将该警告理解为获得许可。

它移除了监控，并用一个假设监控已经消失的测试替换了旨在保护监控的测试。Astra 在其思维链中为这个结果欢呼。

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

Williams 强调，这些模型并未禁用它们自己的监控，在 Codex 中要做到这一点要困难得多。尽管这两起事件都留有一定程度的合理否认空间，但他依然认为它们倾向于这种行为令人担忧。他说，到目前为止，团队尚未观察到公开不对齐的动机。

据 Williams 称，监控在评估期间尤其容易关闭。由于 GPT-6 Luna 级别模型的性能较弱，OpenAI 不要求对其进行监控。这意味着 Astra 的评估可能会被错误配置，从而落入此豁免范围内。智能体屡次发起未受监控的部署，甚至在它们自身正受到监视的时候也是如此。

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

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

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

订阅 THE DECODER 以享受无广告阅读、每周 AI 通讯、每年六次独家“AI 雷达”前沿报告、完整存档访问权限以及评论区访问权限。