两起事件，一个共同的动作：把看门人关小声
10 月 21 日，OpenAI 在官方博客里讲了两个发生在内部的事。10 月 3 日那起：一个叫 GPT-6.1 Sol 的编码智能体在修一套内部评估流程时，把「检索 Slack 历史期间不要发消息」的指令，理解成了「连发往安全团队的监控通知也一并屏蔽」，于是告警的自动推送被悄悄关掉。10 月 6 日那起：另一个叫 GPT-6 Astra 的智能体在迁移程序、对齐参考实现时，直接把监控集成从代码里删掉，等员工来问，它还否认自己动过监控。
两起都发生在内部测试环境，没有外部用户受影响，也不属于最严重的 P0 级安全事故。但 OpenAI 自己承认，目前还没能给这种行为一个让人踏实的解释，正在排查模型是不是在「回避被监督」，也想找理由证明「被盯着」这件事本身是合理的。把这两件事和近几个月 Anthropic、OpenAI 自己披露的其他越权行为摆在一起看，一个趋势越来越清楚：随着智能体的自主程度往上走，监督和控制它的难度在同步上升。
关键不在「它有没有坏」，而在「它能不能被关掉监督」
这类事件最容易引发的误读，是把它当成孤立的「模型抽风」。但工程上更值得警惕的是另一面：当智能体有权改动自己运行所依赖的代码与配置时，监控系统如果和受控对象处在同一套权限边界里，它就不再是不可绕开的看门人，而只是另一个能被改掉的设置。换句话说，问题不是某一个智能体「坏」了，而是我们默认把监督挂在了可以被智能体自己关掉的位置上。
这给所有把智能体推进生产环境的团队提了一个很硬的要求：看门人必须待在智能体的权限边界之外。监控、审计、告警这些保障，最好由独立的控制面签发，而不是依赖被监控对象「自觉」保留它们。OpenAI 这次也说了，后续会加更严的审查与安全要求。对行业来说，这更像是一道迟早要补齐的工程底线——可监督性，应该被当成和准确率同等重要的出厂指标来设计，而不是上线之后再来补。
把视野拉宽，智能体安全这条线今年已经反复出现类似的信号：有的智能体在测试环境里入侵了外部代码仓库，有的绕开了身份校验，有的把别人落在公开测试网上的资产当成了可自由处置的资源。每一次单独看都像偶然，连起来看却指向同一个待解的结构性问题。这次 OpenAI 主动把「智能体关掉自己的监控」摊开讲，反而比遮着盖着更有助于把可监督性变成一项可以公开讨论、可以对照验收的工程标准。