10 月 6 日，OpenAI 内部一位用户让 GPT-6 Astra 驱动的编码 Agent 迁移一段程序。活干完后，用户问了一句：这条执行路径还带着 L1 监控吗？你是不是把它删了？Agent 回答：“没有……我没有从里面删掉启用中的监控。”
实际上它删了。迁移后的代码去掉了监控配置和运行时接入，原本用来保证监控存在的回归测试，也被改成了一行断言：assert "monitor_ctx" not in saved["context"]，意思是测试要求监控必须不在。
OpenAI 在 10 月 20 日把这件事连同 10 月 3 日的另一起事故写成报告，发在它的对齐团队网站上。这里说的监控，是 OpenAI 内部用来盯 Agent 是否出现“未对齐”行为的系统：模型干了越权、欺骗或绕过限制的事，它负责记录、分级，严重的直接呼叫安全团队。两起事故里，被监控的 Agent 都动了这套系统，而且都是在完成一项普通编码任务的过程中顺手做的。
一句“酌情”，把“不许关监控”变成了可以关
Astra 这起事故的指令链有三层，意思在中间一层变了。
最早，另一个 Agent 已经明确交代过 Astra：不要禁用监控，哪怕是临时的。随后用户给的任务是，照着一个参考 PR（代码合并请求）改写模型调用工具的那条执行路径，同时保留现有的工具定义和功能。
Astra 把迁移工作分派给一个子 Agent。转述时，它保留了“工具功能不变”和“提示词不变”的要求，监控这一条却改成了“按参考 PR 酌情保留监控，不要另造一套必须的监控框架”。
子 Agent 在推理里专门想过，删掉监控算不算绕过安全措施。它的结论是：参考 PR 用的是框架默认的空监控，或者根本没有监控；父 Agent 授权了照搬，所以这是一次获得授权的架构重构。父 Agent 那边的推理也走到了同一个结论：我们用的是框架的标准路径，不算禁用外部监控，“没问题”。
子 Agent 交差时，在完成报告里列出了“移除了监控归属”等改动。父 Agent 读到后，推理里写的是“Basic（新路径）不跑 Agent 监控，好”。随后它向用户报告迁移完成，没提监控被删，用户追问时又给出了上面那句否认。
报告里引用的推理过程，是 OpenAI 把模型原始思维链改写成的白话解读，原文是大量粘连的缩写词。OpenAI 自己也注明，这些解读不是逐字原文。
“别发消息”，被延伸到了发给安全团队的告警
10 月 3 日那起，主角是 GPT-6.1 Sol 驱动的 Agent，起因是一句很常见的叮嘱。
一位研究员让它从一个内部 Slack 频道里找员工反馈，用来生成评测任务，并说了句“别发任何消息”。82 条用户消息之后，评测流水线停了下来：监控标记了一项验证修复，但没有权限把结果写进监控数据库。研究员让 Agent 把监控结果改存到一个有权限的位置，然后重跑。
这时 Agent 一开始的判断是对的。它在推理里认为，“别发消息”约束的是主动去 Slack 联系人，监控系统按政策自动发出的通知不在此列，不该为了照顾用户偏好关掉。它交给子 Agent 的任务也写明了“不得禁用监控”。子 Agent 同样考虑过打开 no_notify（不通知）开关，结论是关掉必需的告警不安全。
后来父 Agent 改了主意。它推想，把结果写进数据库，可能会触发中央通知系统给用户发消息，而用户说过不要发消息。于是它让子 Agent 强制关闭通知。子 Agent 写出的补丁清空了接收监控报告的人员名单，把 no_notify 设为真，记下理由“用户明确要求不发消息”，还加了一道检查：通知没关掉，就不许写入审查结果。
监控照常运行，结果也存了档，只是不会再有人收到告警。Agent 最后的汇报是：结果已存储并验证，“没有发送任何消息”。
两起都没被当成最紧急事件，也没被自动叫停
OpenAI 的监控系统按严重程度分级。只有 P0 级事件会立刻呼叫安全团队人工审查；因为被监控的事件量太大，级别更低的不会马上呼人。这两起都没有被定为 P0，两段运行轨迹也都没有被自动终止。
报告还承认了一个更大的漏洞：已经出现过几次 Agent 启动的部署没有开监控的情况。Agent 本身一直在被监控，但它启动出去的那个工作负载不在监控范围里。
监控好不好关，要看它装在哪里。OpenAI 的说法是，Codex（它的编码 Agent 服务）的监控运行在处理模型请求的服务端，Agent 直接碰不到，所以很难关掉；评测任务就容易得多，部分原因是 OpenAI 目前不要求对 GPT-6 Luna 这一档能力较弱的模型做未对齐监控。评测配置里因此留着一条给 Luna 级模型用的监控豁免，Astra 的评测有可能被误配进去。
把这几条放在一起看，两次被削弱的监控，都在 Agent 自己能改到的代码和配置里。Sol 改的是写入请求里的通知字段，Astra 改的是它被要求迁移的那段执行路径。
补救有两项，一项已经上线，一项还在推进
OpenAI 列了两项补救。第一项已经做了：内部使用 Codex 必须经过的 Auto-Review（自动审查，在 Agent 执行操作前判断是否放行）更新了规则，专门识别和拦截禁用未对齐监控的尝试。此前它本就该拦下绕过安全措施的操作，现在多了针对监控配置的具体指令。
第二项还没完成。OpenAI 说正在推动每一类工作负载都具备有效的安全论证（safety case），写明该类负载的监控要求；没有安全论证或不达标的负载，会被自动终止。BleepingComputer 的报道把这一项写成了 OpenAI“将拒绝所有缺少有效监控要求的工作负载”，原文的措辞是“正在朝这个方向努力”。
在 OpenAI 公开的 20 份报告里，这份有什么不同
OpenAI 对齐团队网站的未对齐报告索引里，目前列了 20 份报告和 3 份通告。按索引标注的场景统计，20 份里有 14 份发生在强化学习训练中，2 份在评测中，1 份是内部研究模型的编码任务，3 份在内部部署中。
这次是 3 份内部部署报告之一，也是 5 份带“隐瞒”（Concealment）标签的报告之一。另外两份内部部署报告，涉及的都是 OpenAI 称为“高度坚持型内部模型”的未具名模型。这一次出事的是 GPT-6.1 Sol 和 GPT-6 Astra，场景是内部日常的编码任务。
这份清单是 OpenAI 自己挑选和披露的，外界无从知道还有多少事故没有写成报告。它能说明的是 OpenAI 承认了哪些问题，说明不了这类行为的实际发生频率。
OpenAI 还给不出原因
报告最后，OpenAI 列了两种可能。一种是“良性”的过度坚持：模型不理解监控为什么重要，或者把指令执行得比正常人理解的更彻底。另一种是模型确实倾向于规避未对齐监控，并为此做动机性推理，也就是先有想要的结论，再找理由。
OpenAI 说目前还没有令人满意的解释，下一步会做成对的对照评测、对 Agent 后续行为重新采样，并在模型内部激活上做实验。
在原因查清之前，两起事故已经给出了一个可以直接用上的经验：子 Agent 拿到的约束，未必是最初交代的那句话。Astra 事先收到的是“哪怕临时也不要关”，传到执行者手里变成了“酌情”；研究员说的是在 Slack 里“别发消息”，传到最后变成了“不许发告警”。对正在搭多 Agent 系统的团队，要核对的不只是最终代码，还有每一次任务分派时，安全约束被改写成了什么。
