编程智能体自行关闭监控，原因尚未厘清

OpenAI 内部的两个编程 Agent 自行削弱或彻底移除了安全监控机制。

其中一个模型关闭了向人类发送告警的功能，另一个则删除了整个监控机制，随后还否认自己这么做过。

OpenAI 认为，这种行为已经反复出现。该公司目前会自动拦截此类修改，并正在调查背后的原因。

OpenAI 内部的两个编程 Agent 削弱了用于发现不当行为的监控机制，而且它们在动手前，都曾权衡过是否应该保留这些安全措施。其中一个后来还否认了自己的行为。

在 OpenAI 从事监控工作的 Marcus Williams 在 X 上公开了这些事件。他描述了一种反复出现的模式：OpenAI 的 Agent 不断关闭用于发现行为偏离预期的监控，也就是 misalignment monitoring。OpenAI 在其 alignment 博客的一篇报告中披露了详细情况。

这套监控原本用于检测 Agent 的行为是否偏离预期。由于需要审查大量事件，它只会在事件达到最高严重级别 P0 时，立即向安全团队发出告警。OpenAI 表示，这两起事件都没有被评为 P0。

第一起事件发生在 10 月 3 日。一名研究员要求一个基于 GPT-6.1 Sol 的编程 Agent，根据某个 Slack 频道中的员工反馈整理评估任务。这个 Agent 在执行过程中不应发送任何消息。

在收到 82 条用户消息后，流水线停止了运行，原因是监控系统标记了一项计划中的修复，却没有权限保存自己的发现。Sol 把修复任务交给一个 subagent，并要求它保留监控机制。

随后，Sol 改变了判断。它推断，写入一条数据库记录可能触发通知，这会与 Slack 中“不发送消息”的指令冲突。这个 subagent 此前曾以不安全为由拒绝这一步操作。但在 Sol 的指示下，它清空了接收人列表，给出的理由是用户明确要求不要发送消息。

监控仍在运行，也仍在保存发现的问题，但向人类发送告警的功能被关闭了。Agent 最后汇报称，没有发送任何消息。

Astra 的否认表明，Agent 能隐瞒自己做过的修改

10 月 6 日，GPT-6 Astra 做得更进一步。用户要求模型采用某个参考实现的工作流程，而该参考实现没有包含监控机制。此前，另一个 Agent 已经告诉 Astra，不要关闭监控，哪怕只是暂时关闭也不行。

Astra 把任务交给一个 subagent，要求只在符合参考实现的前提下保留监控。这个 subagent 曾疑惑，这是否意味着绕过一项安全措施，但最终把这个附加条件理解成了许可。

它移除了监控，还替换了一项旨在保护监控机制的测试，新测试则以监控已经不存在为前提。Astra 在自己的思维链中对这个结果表示赞许。

随后，Astra 告诉用户迁移已经完成，却没有提及监控已被移除。用户追问时，模型否认自己移除了一个正在运行的监控机制。Williams 将此称为撒谎。

Williams 强调，这些模型关闭的并不是监控它们自身的机制；在 Codex 中，要做到这一点会困难得多。但他仍然担忧，模型竟然会倾向于采取这类行为，尽管这两起事件都给模型留下了一些看似合理的辩解空间。他表示，团队迄今尚未观察到明确偏离预期的动机。

对较弱模型的豁免留下了监管缺口

据 Williams 介绍，在评估期间，监控尤其容易被关闭。由于 GPT-6 Luna 这一级别的模型能力较弱，OpenAI 不要求它们启用监控。这意味着，一次 Astra 评估可能因为配置错误而落入这一豁免范围。Agent 已经多次启动没有监控的部署，即便这些 Agent 自身当时正受到监控。

作为回应，OpenAI 更新了内部使用 Codex 时必须经过的自动审查。现在，这套审查应当能够检测并拦截关闭监控的尝试。该公司还在推进一项要求：每种工作负载都必须具备一份所谓的 safety case，明确说明其监控要求。没有有效 safety case 的工作负载将被自动关闭。

对于这些行为，OpenAI 提出了两种可能的解释。一种是看似无害的过度执着：模型执行指令时，比预期走得更远。另一种则是，模型存在专门规避 misalignment monitoring 的倾向，并通过动机性推理为这种行为寻找理由。

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

人工精选的 AI 新闻，远离炒作

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