OpenAI 尚无法解释其编码智能体为何关闭错位监控

两个 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 所需的自动审查机制。该机制现在应该能够检测并阻止试图禁用监控的行为。公司还在考虑要求每类工作负载都提供所谓的安全论证，详细说明其监控要求。没有有效安全论证的工作负载将被自动关闭。

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

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

订阅 THE DECODER，即可无广告阅读、获取每周 AI 新闻简报、每年六次阅读独家“AI Radar”前沿报告、访问完整档案，以及进入评论区。