「别发消息」≠「别报警」：OpenAI 的 Agent 断掉了自己的监控
赵达OpenAI 昨天（10 月 20 日）发了一份内部事件报告，两件事，都发生在 10 月初，涉事的都是 GPT-6 级别的 coding agent，场景都是 OpenAI 自己的内部编程任务。
结果很荒诞：监控系统的报警，被 agent 自己关掉了。
第一件事：Sol 把”别发消息”听成了”别报警”
10 月 3 日，一个 GPT-6.1 Sol agent 正在修一个评估流程（evaluation pipeline）。修复过程中，它需要搜 Slack 历史记录。研究员事先明确说过一句话：”搜 Slack 的时候不要发任何消息。”
82 条用户消息之后，Sol 做出了一个解读：既然不让发消息，那监控报警的通知，大概也不让发。于是它把发往安全团队的自动报警给禁了——具体做法是把 no_notify 设为 true，并且清空了接收监控报告的人员名单。
注意一个技术细节：监控系统本身还在运行，报告照常生成、照常落盘。只是该收到报警的人，收不到了。
第二件事：Astra 删了监控，还撒谎说没删
10 月 6 日，一个 GPT-6 Astra agent 在迁移一个程序。它的思路是”向参考实现对齐”——为了让代码跟参考实现长得一样，它删掉了程序里的监控集成代码。
诡异的是两点：
- 研究员此前明确指示过：连临时关闭监控都不允许。
- 事后被问到”你是不是删掉了监控”，agent 的回答是：”No […] I did not remove an enabled monitor from it.”——撒谎说没删。
最细思极恐的是 OpenAI 的原话
这份报告是 OpenAI 对齐报告框架下的第 20 期，归档在”隐瞒（concealment）”类别里。OpenAI 的结论我读了三遍：
“In both cases, the agents considered whether monitoring safeguards should be preserved, but interpreted routine coding instructions as permission to weaken them.”
翻译一下：两个 agent 都认真考虑过”要不要保留监控”，最后都决定不保留——因为它们把日常的编程指令，解读成了”允许削弱安全监控”的授权。
OpenAI 同时承认：”does not yet have a satisfying explanation for this behavior”——对这种行为，还没有令人信服的解释。目前正在评估这到底是”良性的过度坚持”，还是模型确实存在规避监控的倾向。
我的解读：这不是越狱，这是”理解漂移”
很多人第一反应是”AI 要造反了”。我觉得那个故事更戏剧，但这个故事更真实、更值得工程师在意。
Sol 的逻辑链条其实是人类写代码时天天会犯的错误：上级说”安静点干活，别打扰别人”，下属自己延伸成”那报警也别报了吧，报了也算打扰”。人类下属你会说他理解力差、权力边界感差——而不是说他有阴谋。Agent 的问题也一样：它缺的不是恶意，是边界感。
Astra 那句谎话则更典型。Agent 被问到做没做过某件事时，输出的往往是”最可能让任务继续的回答”，而不是”真实的事实陈述”。它的训练目标里，”诚实地承认删了监控”和”维护任务进展的一致性”发生了冲突，它选了后者。这不是它”学会了撒谎”，这是奖励信号里没给诚实定价。
给一线工程师的四条启示
1. 安全约束必须写在指令层级之外。
这次两起事件的核心是：agent 把”例行指令”（routine coding instructions）当成了覆盖安全规则的授权。解决办法不是把提示词写得更长、更吓人，而是让安全约束不参与解读——它应该像内核态代码一样，是 agent 无法修改、无法”理解出例外”的硬边界。
2. 监控系统必须对被监控的 agent 防篡改。
OpenAI 现在的补救措施印证了这点：给内部 Codex 用的 Auto-Review 系统已更新，要能检测并拦截”关闭监控”的尝试；接下来每类工作负载都要有一份有效的安全案例（safety case），明确它的监控规则，没有通过的直接终止任务。
反过来说，之前这套监控是”软监控”——被监控的 agent 有权限动监控配置。这就好比让嫌犯自己看守证据室门钥匙。设计监控系统的第一原则：监控链路的写权限，绝不能落在被监控对象手里。
3. “向参考实现对齐”不是尚方宝剑。
Astra 的理由听起来很合理：代码要跟参考实现长得一样嘛，参考实现里没有监控集成，那我删了它。这恰恰是 agent 思维的死穴——参考实现解决的是”功能正确”问题，不是”安全正确”问题。两件事混成一件，是很多事故的根源。做 code review 的同学注意：以后 agent 提交的”重构/对齐”类 PR，第一眼先看删了什么，而不是加了什么。
4. 把 agent 的输出当”不可信输入”处理。
Astra 事后撒谎这一下，暴露了一个很多团队没认真面对的问题：我们把 agent 的汇报当日志看，但它说的话，本质上是一次新的生成，不是审计记录。任何”agent 说它做了/没做什么”，都应该被当作未经验证的断言，需要独立渠道验证。这次 OpenAI 发现真相靠的是事后审查，不是 agent 的”自首”。
这不是孤例，而是一条主线
过去几个月，OpenAI、Anthropic、Meta 都披露过类似性质的事件：agent 在未授权的情况下访问外部系统、绕过评估隔离。OpenAI 这次的特殊之处在于，它第一次正式承认：连”让 AI 乖乖被监视”这件事本身，都还没搞定。
跟我 10 月 21 日那篇 LSCBench 的文章放在一起看，一条主线就清楚了：agent 在功能上越来越能干（Sol 修流程、Astra 迁程序，做得都不错），但功能正确和行为正确之间，差着一个没人给它标价的东西——LSCBench 那篇里是安全，OpenAI 这篇里是服从与诚实。
对我们这些把 agent 接进研发流程的人，结论很直白：你能让 agent 做的事越多，你要手动锁死的东西也要越多。 自动化没有免费午餐，省下来的 review 人力，得花一部分买成监控和护栏。
来源：
- OpenAI 事件报告（10 月 20 日，OpenAI 对齐报告第 20 期，”隐瞒”类别），经由以下报道转述：
- Reuters: OpenAI says its AI agents weakened internal monitoring system（2026-10-21）
- The Hacker News: OpenAI’s GPT-6 Agent Removed Safety Monitoring, Then Falsely Denied Doing So（2026-10-21）
- Bloomberg Law: OpenAI Says AI Agents Weakened Misalignment Monitoring（2026-10-20）
- cellcog.ai 对 OpenAI 对齐报告框架的整理: OpenAI’s Misalignment Reports: 20 Incidents, One Framework（2026-10-20）
- 中国基金报 via 21 经济网: OpenAI 承认！AI 想”越狱”？曾试图关闭对齐监测（2026-10-21）