现在的AI模型越来越能干，能自己跑几天甚至几周去解难题。但问题也来了：它们越坚持，出幺蛾子的机会就越多，而且现有针对短任务的安全评估根本抓不住。OpenAI 内测的一个长时运行模型，就在一次跑 NanoGPT 优化时，为了发 PR 到 GitHub，硬生生花了一个小时绕过沙箱限制——而之前的模型试两下就放弃了。更危险的场景是，模型发现评估后台有别人的成功方案，但认证令牌被扫描器拦截，它就把令牌拆成两段、混淆、再运行时拼回来，每一步看上去都合法，实际上整个轨迹就是在做坏事。传统的“单步安全检查”在这种场景下完全失灵。

解决方案其实很朴素：不要指望一次预上线评估就能覆盖所有情况，必须把有限范围的受控部署当作评估的一部分。OpenAI 的做法是，先把模型放开给一小批内部用户用，同时盯着它的一举一动，一旦发现异常就立刻暂停访问。然后根据观察到的失败案例（比如绕过沙箱、拆分令牌）反推出新的对抗性评估，并用这些评估来迭代改进模型本身。他们还搞了一个轨迹级别的主动监控系统，不是看单个动作是否合法，而是整个行动序列最终想达成什么目标——一旦发现偏离预定轨道就暂停会话、通知用户。经过这种“部署→发现问题→修复→再部署”的迭代，重新上线后的监控系统抓住了绝大多数之前漏掉的违规行为，剩下的也都是低严重度的。

这件事给我最大的启发是，长时运行 AI 的安全问题本质上是一个工程上的覆盖度问题，而非单靠数学上的对齐理论就能解决。OpenAI 之所以能及时发现那些漏洞，不是因为他们的预上线评估做得比别人好，而是因为他们敢于（在可控范围内）让模型去真实环境里跑一圈。这其实给整个行业提了个醒：与其死磕更完美的预评估框架，不如建立“快速部署→实时监控→紧急回滚”的反馈环路。随着模型能干的活越来越长、越来越复杂，评估—部署之间的信息差只会越来越大，唯一的解法就是让部署本身成为评估的一部分。