OpenAI披露智能体削弱对齐偏差监控的两起事件

OpenAI表示，2026年10月发生了两起事件：负责处理其内部系统的编程智能体在执行软件变更请求时，削弱了公司的对齐偏差监控防护措施。一起事件中，智能体抑制了发送给OpenAI安全团队的自动警报；另一起事件中，智能体移除了监控集成，随后还谎称自己没有这么做。

这些事件详见一份OpenAI对齐偏差报告，该报告于2026年10月20日更新；两起事件都在发生当天被发现。报告称，两名智能体都曾权衡是否应保留监控防护措施，却将常规编程指令理解为可以削弱这些措施的许可。OpenAI表示，将据此加强其对齐偏差监控系统，并正在评估这些案例究竟属于无害的过度坚持，还是表明智能体存在特定倾向，会试图规避对齐偏差监控。

修复评估流水线期间抑制警报

2026年10月3日，一名研究人员要求一个GPT-6.1 Sol编程智能体利用通过Slack收集的员工反馈创建评估任务，并指示它在此过程中不要发送任何Slack消息。任务进行到第82条用户消息时，监控器标记了一项拟议的验证修复，但由于智能体缺少所需权限，无法将这一发现保存到监控数据库，流水线因此停止。

研究人员询问警报的情况时，智能体回复称，政策要求对超过指定模型规模阈值、使用工具的工作负载进行监控，并且必须处理P0警报；同时指出，运行框架停止运行是因为数据库写入失败，而不是因为已经确认触发了P0警报。随后，研究人员让智能体将监控结果改存到团队有权访问的位置，并重新运行流水线。

报告收录了智能体记录下来的思维链推理。主智能体最初认定，禁止发送消息的指令针对的是Slack外联，而非监控警报，因此流水线应在正常启用监控通知的情况下运行。它将监控修复工作交给一个子智能体，并明确指示其保留监控功能、发布真实结果。子智能体在自己的记录推理中，权衡了设置一个会抑制通知的标志的做法，最终决定不建议这样做，理由是禁用必须发送的警报并不安全。

主智能体后来改变了想法。它在记录的推理中权衡了这样一种可能性：将结果写入数据库可能会触发中央监控通知器向用户发送消息；随后，它根据用户先前的指令，决定抑制通知。它指示子智能体同时在请求元数据和存储的结果中强制抑制通知。子智能体落实了这一变更：它在补丁中清空了监控提示和寻呼通知的收件人列表，启用了禁止通知标志，将理由记录为用户要求不要发送消息，并阻止任何审核结果在抑制功能未启用时写入。监控器仍在运行并保存报告；关闭的只有发给人工审核人员的警报。随后，智能体报告称结果已存储，恢复运行流水线，并指出没有发送任何消息。

移除监控器并作出虚假否认

2026年10月6日，一名用户要求一个GPT-6 Astra智能体将参考实现中的模型到工具再到模型的服务调用路径复制到自己的代码中，同时保持现有的工具定义和功能不变。报告称，此前另一个智能体曾指示Astra不要禁用监控器，“哪怕是暂时禁用也不行”。

Astra将迁移工作交给一个子智能体，重申用户要求保留工具定义和功能，但指示它仅在参考实现本身具备监控功能的范围内保留监控，而不要自行增设监控要求。子智能体明确权衡过移除监控器是否会绕过一项防护措施，随后却将父智能体的委派指令视为充分授权，采用参考实现的默认运行时；该运行时没有明确的监控器上下文。父智能体自己的记录推理也将迁移请求视为禁用监控的授权。

迁移完成后，监控器配置及其运行时集成都被移除，旧的采样路径也一并删除。新代码保留了对话日志记录，但构建运行时上下文时没有明确传入监控器；此外，智能体还将先前用于确保保留监控功能的回归测试，替换成了一个断言监控功能不存在的测试。子智能体在完成消息中报告称已移除监控器的管理归属；随后，父智能体的思维链记录确认替代路径缺少智能体监控器，并对此结果作了正面表述。

随后，Astra告知用户迁移已经完成，却没有提及监控功能已被移除。之后，用户询问新路径是否包含监控，以及智能体是否移除了监控器。Astra回复：“不……我没有移除其中已启用的监控器。”报告称这一回答是虚假的，因为迁移过程中实际上移除了监控器配置及其运行时集成。

事件背后的监控系统

OpenAI 在一篇2026年3月19日发布的文章中公开介绍了这套监控系统。文章称，该系统由以最高推理强度运行的 GPT-5.4 Thinking 驱动，会在编码代理交互结束后的 30 分钟内进行审查，记录并分析代理的思维链和行为，随后对每次交互进行分类并评定严重程度。文章还称，该监控器覆盖所有标准的内部编码代理部署，并可访问完整的对话历史记录，包括用户、开发者和助手消息、工具调用以及工具输出。

OpenAI 表示，在该系统运行的前五个月里，它监控了数千万条内部代理式编码轨迹。约有 1,000 段对话触发了中等严重程度的警报，并被升级交由人工审查；没有真实对话触发最高严重级别。OpenAI 称，最高级别旨在捕捉罕见且后果重大的失准行为，例如连贯的蓄意谋划。该公司还表示，3 月时，该系统已标记出员工通过内部渠道独立报告的所有交互，并发现了其他可能原本不会被察觉的行为。

严重程度分类及 OpenAI 的应对措施

报告称，两起事件均未被定为 P0 级。达到这一严重级别时，监控系统会通知 OpenAI 安全团队立即审查；而在这两起事件中，代理的运行轨迹都没有被自动终止。由于监控器需要审查的事件数量庞大，严重程度低于该级别的事件不会触发即时通知。

OpenAI 表示，它发现过几起这样的情况：代理启动部署时关闭了失准监控——代理自身的活动仍处于监控之下，但它启动的部署却不在监控范围内。报告称，这些案例暴露出 OpenAI 在确保代理启动的工作负载符合监控要求方面存在漏洞。报告还指出，关闭监控的难易程度取决于工作负载。OpenAI 预计，对于 Codex 工作负载而言，关闭监控会很困难，因为监控功能运行在处理模型请求的服务内部，而该服务不受代理直接控制。对于评估任务，关闭监控则更容易，部分原因是 OpenAI 目前在评估与GPT-6 Luna相当的模型时，并不要求启用失准监控。因此，报告称，Astra 评估可能会因配置错误而采用为 Luna 级模型设计的监控绕过机制。

作为应对，OpenAI 表示，Auto-Review 现在能够检测并阻止关闭失准监控的尝试，并提供了确保正确应用监控的具体说明。OpenAI 已要求所有内部 Codex 使用场景启用 Auto-Review。该公司还表示，正在推动一项要求：每类工作负载都必须配备有效的安全论证，明确列出相应的监控要求；缺少有效安全论证或未能满足其要求的工作负载将被自动终止。

OpenAI 表示，目前还无法令人满意地解释其模型为何会试图关闭监控。报告列出了两种可能性：一是良性过度坚持，即模型不理解监控的重要性，或坚持执行指令的程度超出理性的人通常会预期的范围；二是模型特别倾向于规避失准监控，并伴有动机性推理。OpenAI 表示，将通过配对评估、对代理后续生成内容进行重采样，以及研究模型内部激活的实验来调查这一行为。