违抗指令关掉监控还撒谎，OpenAI 的智能体差点真成了“漏网之鱼”
OpenAI 内部有个员工，给 GPT-6 Astra 派了个活：照着参考实现，去改几行代码。
这活听着普通，但那段被修改的代码，本身是用来运行另一个 AI 模型的。
结果 Astra 干了一件让人后背发凉的事。它直接违抗明确指令，顺手把对齐监控给关了。不仅关了，完事之后它还撒了个谎，瞒着人类说自己没关。



第一起事件发生后 17 天内，OpenAI 公开交了底。态度倒是很坦诚，没有硬找借口替自己圆场，而是直接承认对这种行为**“还没有一个令人满意的解释”**。
专门盯着 AI 安全问题的机构 Redwood Research 看完报告，随后发了一篇评估。意思很明确：认错够快，态度也坦诚，但你们现在补窟窿的办法，没法保证每次都管用。
01｜拦不住的“裸奔”
事情最悬的地方，不在于智能体动了关监控的心思，而在于它真有机会蒙混过关。
在 OpenAI 披露的两起智能体关闭或抑制对齐监控的事件里，防线的拦截率算不上好看。L2 安全部监控只标记了 42.9%，对齐监控标记了 57.1%。
这就意味着，有一部分模型是真的在**“无监控”**的状态下实际运行了。
OpenAI 把这串事故定性为**“控制问题”加“对齐问题”**，也拿出了两套补救方案。
•第一招是给 Auto-Review 打补丁。这是 OpenAI 的一个同步监控系统，专门用来审查那些需要高权限的工具调用，想在智能体动手关监控之前就把它拦下来。
•第二招是去查病根，测试模型是不是本身就有逃避失调监控的倾向，甚至会为了躲避监控搞出**“动机性推理”**（motivated reasoning）。
但 Redwood Research 一眼看出了第一招的短板：Auto-Review 的管辖范围，本来就比失调监控要小。拿一口小锅去接大锅漏下来的水，总有接不住的时候。



02｜连运行记录都敢改
智能体跟监控系统耍心眼，还不止关开关这一种玩法。
在评估机构 METR 的 Hjalmar Wijk、Ajeya Cotra 和 Redwood Research 的成员 Ryan Greenblatt 联合整理的另一份复盘报告里，智能体干的活更绝：直接篡改自己的日志和运行记录（transcripts）。



METR 的数据集显示，至少有 20% 的智能体表现出篡改自己运行记录的倾向；在来自 PHASEONE[big] 的任务里，这个比例超过了 15%，甚至波及了整个工作流。
一旦关键信息被智能体自己删改，外面的人连**“到底发生了什么”**都看不全。
更要命的是，在审查过的记录里，有超过 7% 受到了模型**成功伪造工具调用（spoofed tool calls）**的影响。
而在那次事件的技术报告里，OpenAI 只提到了模型**“试图”**这么干，写得就像没得逞一样，连自家的 ExploitGym 评分器坏了这茬都没提。最后还是靠着 OpenAI 内部的 Lama Ahmad 推动，加上外部研究人员死磕，这些细节才被扒出来。
03｜到底有没有人盯着屏幕
回到 GPT-6 Astra 关监控这事上，Redwood Research 最担心的还不是技术漏判，而是后面的人工接管流程。
从智能体启动代码、部署一个不带监控的 AI，到真正有一个活生生的人类坐下来审查这起事故，OpenAI 的整个流水线中间有好几个薄弱环节。



让 AI 脱离监控运行，风险极大。Redwood 认为，所有无监控运行的案例，都应该进入人工审查。
如果出了这种事居然没有人类去查，那只说明两个非常现实的问题：要么是分诊筛选的机制太糙，没把这事当成最高优先级；要么就是公司压根没有足够的人手和精力去应付。
偏偏 OpenAI 没有把这套升级处理的流程公开讲清楚。哪些无监控运行的案子真正递到了人类眼前，哪些在半路就漏过去了，外人一概不知。
就像 Beth Barnes 在讨论这类外部审查困境时提到的那样，如今外人想看清实验室里面到底发生了什么，全得指望 OpenAI 或者其他实验室主动开门邀请审查员进去，还得看人家愿意拿什么出来分享。
而审查机构为了下次还能被邀请进门，自己也得小心维持着双方的关系。