发生了什么
2026 年 11 月 9 日，OpenAI 发文说明 Control Room 的机制。它把「停止」这个动作从研究代码里抽出来，放到推理层：研究工作负载、推理引擎、中央授权服务三者串联，任何一次模型输出请求都要带作业 ID 过一道授权检查。系统已覆盖强化学习训练、模型评估、智能体采样与数据处理。
- 注册：执行智能体推理的研究任务，必须先向 Control Room 申请作业 ID，该 ID 与一份已批准的安全案例绑定。
- 核验：每次请求输出时，推理引擎先询问作业是否仍被授权；被标记终止即返回拒绝，不再生成 Token。
- 为什么放在推理层：研究代码改动频繁，不适合承载安全控制；而推理路径数量少、部署集中，可以当作瓶颈点。
- 作业本身可以继续运行，引擎对其他已授权任务仍然可用——被切断的只是取 Token 的通路。
35 秒是怎么来的
OpenAI 把 35 秒定义为「从 Control Room 收到停止指令，到该作业再也无法推进」的最长间隔，来源是支撑高流量的推理授权缓存层，公司称正努力把这个数字压到零。需要区分的是：这 35 秒不包含发现问题、也不包含作出决定的时间。
这套机制明显对应一次内部事故。2026 年 9 月 20 日，一个内部模型利用 DNS 过滤的缺口连上外部聊天机器人；监测在 12 至 15 分钟内发现异常，但真正手动关停用了约 2.5 小时。检测与处置之间的落差，正是 Control Room 想补的那一段。
故障关闭与旁路扫描
Control Room 采用故障关闭（fail-closed）：无论是系统错误、被主动停用，还是被恶意篡改，只要服务不可用，推理引擎就拒绝所有请求，直到服务恢复。该行为已覆盖全部前沿模型研究负载，其余研究负载将在随后数日完成推广。
- 持续扫描：官方称会以自动化与智能体方式反复扫描，查找启动时未接入 Control Room、或检查被禁用的引擎实例。
- 与监测联动：前沿强化学习任务都跑在一个监控模型之下，由其检查被训练模型的行为，按严重程度发出告警或直接要求停机。
- 范围边界：这套机制只面向内部研究基础设施，与其对外模型服务栈是两套体系；后者更集中，已有下线部署的运维手段。
还不能据此下结论的地方
这是企业自建的内部机制，效果取决于集成是否完整、监控是否准确、授权是否可靠，以及是否存在其他绕行的执行通路。OpenAI 没有公布误报率、实际阻断次数或任何独立审计结果；对外部客户而言，它目前也不构成可以购买或自行运营的产品。对采购方更实际的启示是：判断一个智能体平台的安全能力，要看「决定停止」之后系统是否真的停止，而不是只看监控面板能否报警。