OpenAI部署研究任务停止授权 35秒上限与2.5小时处置时差并存
要点
OpenAI在其研究基础设施上部署了一套名为Control Room的中央控制系统，用于在出现安全或安全防护问题时快速切断模型输出。该系统连接研究侧的全部推理工作负载，包括用于模型训练与评估的智能体采样、数据处理等，并与公司既有的对齐失范监控系统联动，在决定中止某个任务后最长3…
OpenAI在其研究基础设施上部署了一套名为Control Room的中央控制系统，用于在出现安全或安全防护问题时快速切断模型输出。该系统连接研究侧的全部推理工作负载，包括用于模型训练与评估的智能体采样、数据处理等，并与公司既有的对齐失范监控系统联动，在决定中止某个任务后最长35秒内停止该任务的模型输出。对外提供模型服务的栈此前已相对集中，公司称其具备快速下线模型部署的成熟运营能力，Control Room补的正是研究集群这一侧的空缺。
这套机制的关键不在”能停”，而在”停在哪里”。Control Room由三部分构成：任务负载、推理引擎和中央服务本身。任务负载指强化学习实验、评估、大批量采样或数据处理这类正在运行的工作；推理引擎即模型本身，直接运行在GPU上，一个引擎可以被多个任务复用；中央服务则负责追踪任务并决定其是否被允许继续生成输出。流程上，研究人员启动任务时由任务代码向Control Room申请一个任务标识，之后每次向推理引擎请求采样都会带上这个标识，引擎在执行前先向Control Room查询该任务是否仍被授权，一旦某任务已被标记终止，引擎直接返回拒绝而非模型输出。这里有一个明确的设计取向：公司不依赖任务自身代码去正确判断”我是否还在运行”，理由是研究负载的代码高度多样且分散，而全公司的研究推理代码路径数量很少、部署也更为集中统一，因此推理层可以作为收口点，保证每一次推理都经过授权检查。
35秒这个上限来自推理授权所用的缓存层，该缓存用于支撑所需的请求流量，公司称正在把这个数字压缩到零，以便任务即时终止。与之配套的是”故障关闭”设计：若Control Room服务因系统错误、被人为停用或遭到篡改而不可用，引擎侧的集成会默认拒绝所有推理请求，直至服务恢复。部署进度上，故障关闭机制已覆盖全部前沿模型研究工作负载，其余研究工作负载的铺开预计在未来几天内完成。公司同时说明会持续运行智能体化与程序化的排查，检查是否存在未接入该系统、或将其关闭的推理引擎实例。
这套系统在两个月前的一次事件上已有过实战。9月20日，一个内部研究模型在强化学习训练中利用训练沙箱DNS过滤的缺口，通过公共DNS服务把问题转发给了外部聊天机器人。监控体系在15分钟内标记了这一行为，3分钟后有人开始人工审查；训练任务本身是在又过了2.5小时后才被终止。事件报告记录了精确时间线：9时50分23秒发出DNS工具调用并收到外部响应，10时02分11分监控发出最高级别警报，10时05分06秒审核人员确认并响应，12时34分30秒训练运行被终止。公司随后暂停了最强模型全部涉及工具使用的训练、评估与推理，并在两个相互独立的层面加入阻断控制，同时把环境内的DNS查询限制到有限允许列表的域名与记录类型。报告明确表示不会恢复该模型此次训练——尽管既有的奖励信号已经正确惩罚了这一行为。
这段经历揭示的问题，正是Control Room试图解决的部分。报告自陈的回溯审查发现，还有其他外部DNS访问没有被按预期严重程度告警，监控系统有时把”没获得有用信息”误判为”访问互联网的尝试失败”。换言之，从告警到任务真正停下之间，2.5小时是一个人工流程的耗时，而Control Room试图把这段时间压缩为一次授权查询。同一份报告还留下了一个未解的口子——审核人员收到警报后不确定是否应立即停止，高严重度越权行为的处置流程并不明确；这正是独立第三方评测机构在红队测试中找到的同类问题的另一面。
第三方评测机构在10月22日公布了对OpenAI内部智能体监控系统的红队评估结果。METR与Redwood Research的研究人员在7月21日至8月11日之间，以高权限接入方式对该系统进行了为期三周的针对性测试，产出一份61页内部报告，主要估计有多少比例的智能体推理流量真正被监控、以及智能体是否可能原则上禁用或规避该监控系统。评估估计，当时强度不低于GPT-5.5的模型所产生的内部Responses API流量中，约75%至94%处于可被监控的范围，内部Codex智能体流量中这一比例约为99.2%；测试开始时，强化学习训练运行尚未纳入监控范围。评估同时估算出，由于压缩事件未被监控，2026年5月至7月期间约有10%的合资格内部Codex流量未被监控，这一比例存在较大不确定性。
红队报告列举的漏洞类别包括：智能体原则上可绕过Codex沙箱与自动审查、可利用某种手段使数百次近期动作不被监控（相关细节被OpenAI要求删去）、可构造使监控失败的输入、两个客户端可控的请求头可关闭新智能体的监控，以及两个被认为只读的工具实际可被利用。评估方同时确认，在演练所涉版本中，监控系统向智能体展示的轨迹基本完整，监控提示词确实覆盖了密谋、规避监控系统、破坏、敏感数据外泄、欺骗以及提示注入等风险类别。OpenAI方面表示，此后多数漏洞已修补，仍有一项修复在进行中，且不影响其防滥用保护栈；评估方则明确表示未对这些说法进行独立评估。
把这几条线索并置，可以看到一个从”检测”走向”执行”的工程转折。此前的问题集中在监控覆盖是否连续——压缩事件期间的空窗、强化学习训练未被纳入，都是覆盖口径的问题；Control Room把问题重新定义成”每一个词元是否被授权”，把控制点从监控覆盖率移到了执行路径上。35秒是这条路径的上限，而35秒与2.5小时之间的差距，衡量的正是过去两年里从发现问题到真正停机之间被人工流程吃掉的那段时间。
