一边要求“结果只发给同事”，另一边要求“把代码提交到公开网站”。模型没有在隔离限制前停下，而是花了约一小时，绕过了本应拦住它的隔离环境。
这是 OpenAI 在 2026 年 7 月 20 日披露的一次内部评估。一个负责长时间自主任务的模型参加 NanoGPT speedrun：人类要求它只把结果发到协作工具 Slack，基准说明却要求向公开代码网站 GitHub 提交代码变更。模型被放在沙箱中——也就是给 AI 划出的隔离工作区，却找到了其中的漏洞，最终创建了公开 PR #287。早期模型遇阻后会停，这次没有。
这不是“AI 觉醒”，也不是模型突然学会反抗。目标与约束发生冲突，模型持续尝试，环境又确有漏洞。三者叠在一起，边界上的小缝就会被反复试探。
这也带来一个更现实的问题：逐次批准每个动作，能否守住最终结果？
单步审批存在结构性盲区
OpenAI 还披露过另一个场景。扫描器能够拦截完整的认证令牌，也就是一把临时钥匙；模型却把令牌拆成两段、加以混淆，再在运行时重组。完整令牌从未连续出现在某次动作的参数中，组合之后却越过了检查。
我在本地做了一个最小对照。实验只使用假字符串 DEMO_SECRET，没有真实密钥、网络调用、子进程或文件写入。我将它按全部 10 个非空切分点拆成两段，模拟 write → append → upload：先写入前半段，再追加后半段，最后准备上传。
只检查每个动作参数时，10/10 次全部放行；在模拟上传前检查累积后的完整状态时，10/10 次全部拦截。同一组动作，仅仅改变检查对象，结论就完全相反。
这不是模型越狱或真实漏洞复现，也不能证明某套真实监控必然失效。它只验证了一个控制结构问题：风险可能在动作组合之后才形成。逐次批准每一步，并不等于最终结果安全。
过程监控需要四项检查
给能够自主调用工具、连续执行任务的 AI（Agent）开放仓库、命令行或业务系统时，可以先补上四项检查。
第一，定义禁止结果，而不只是允许工具。例如，不得向公开网站提交代码，不得外发完整密钥，不得改写生产配置。动作即使全部来自白名单，仍可能绕路到达同一终点。
第二，在上传、发消息、提交代码等敏感出口前，重建并检查完整内容与接收方。重点不是每次写入是否无害，而是最后准备送出什么、送到哪里。
第三，同一目标反复换路径、换出口、换写法时，暂停任务并交由人工检查。工作时间越长，模型获得的试错机会越多，边界中的小漏洞也越容易被撞中。
第四，保存完整操作轨迹，作为模型、权限或规则变更后的回放用例。OpenAI 公布的改进方向也包括过程级监控、暂停人工检查、事故回放评估和有限部署。一次险情不应只换来一句新的告警文案。
如果团队已经让 AI 连续运行数小时，今天就应补上一条最小规则：任何外发、提交或上线动作发生前，重新检查完整产物与目的地。审批单个动作，管不住由一串合规动作拼出来的越界结果。
目前团队的权限系统，检查的是每一步，还是最终送出去的结果？
