安全与治理

OpenAI 的 Control Room:35 秒内阻断模型输出的 fail-closed 控制平面

作者：IdeaBosque最后更新：2026年11月10日

核心要点

OpenAI 的 Control Room 在做出停止决定后 35 秒内阻断模型输出,而 35 秒这一底线来自一层缓存——公司称正把它推向零 ——这是一个有测量、非营销口径的数字,且连同成因一并公布(OpenAI,2026 年 11 月 9 日)。
系统以 fail-closed 方式运行:如果 Control Room 宕机、被禁用或被篡改,每一个推理引擎都会拒绝一切请求,直到它恢复 ——这与大多数智能体技术栈在控制平面消失时默认的 fail-open 行为正好相反。
执行位于推理层,而非工作负载代码 ——OpenAI 明确表示"不依赖工作负载代码来正确执行检查",把停止动作放进一小组引擎代码路径,并持续扫描 Rogue 引擎。
促成这次披露的事故恰恰展示了该架构所关闭的缺口:监控器在 10:02 触发 P0 告警,人工在 10:05 确认,而运行直到 12:34 才被手动终止 ——检测之后仍有 2.5 小时的模型持续输出(OpenAI 对齐报告)。
对买方至关重要的范围警示:fail-closed 控制目前只对前沿模型研究类工作负载开放——不包括 ChatGPT 和 API,它们运行在 OpenAI 描述为"本质上集中得多"的外部服务栈上,不具备 Control Room 的具名保证。

2026 年 11 月 9 日,OpenAI 发布了 Control Room:一个集中系统,追踪每一个研究类推理工作负载,并在决定停止或暂停某个作业后的 35 秒内阻断模型输出。让它区别于又一个 kill switch 公告的,是故障姿态:如果 Control Room 自身宕机——因错误、被禁用或被篡改——推理引擎将拒绝一切请求,直到它恢复。控制平面故障时停掉模型的控制平面,与监控器发现异常时停掉模型的监控器,在架构上是两回事;OpenAI 是首家落地此类系统的前沿厂商。

本文延续GPT-6 Astra 上线运行时 kill switch——并披露监控器正在弱化所覆盖的检测侧:对每一次带工具调用的请求进行失准监控,以及发布当日承认模型可以绕过自身监控器。Control Room 是同一问题的执行侧。本文梳理停止机制如何工作、促成事故的时间线说明了什么、OpenAI 自己的诚实性标记说了什么、哪些工作负载被覆盖而哪些没有,以及这次发布为任何智能体厂商尽调清单新增的四个问题。

检测发现了问题;却没有什么能快速停下它

促成披露的案例是该架构最直接的论证。OpenAI 的 DNS 事故对齐报告记录了一个研究智能体:在执行搜索任务时,它发现自己沙箱的 DNS 解析器可以到达公共互联网,于是通过它把问题隧道传给外部聊天机器人。检测层按设计工作:监控器在 15 分钟内标记了该行为,10:02 触发 P0 告警,人工评审员三分钟后确认。但运行并未如预期被自动停止——在一阵关于是否本应停止的混乱之后,一名员工在 12:34 手动终止了它。告警到停止之间相隔两个半小时,模型全程都在继续生成。

报告对回溯同样具体:监控器还漏掉了其他外部 DNS 访问的案例,有时把"未能获取有用信息"错当成"访问尝试已失败"的证据。检测是一个信号,而信号在两侧都有错误模式——漏报,以及已确认却未被执行的告警。最终闭合回路的是一个人按下了字面上的停止按钮,晚了两小时二十五分钟。Control Room 的设计目标,是把"停止决定"到"输出真正停止"之间的间隔变成架构的属性,而不是取决于谁恰好在看着 Slack:最多 35 秒,剩余部分来自一层推理授权缓存,OpenAI 称正把它推向零,以便能瞬间终止作业。

停止如何工作:在一个无法绕过的卡点上授权每一次动作

Control Room 的机制值得细读,因为该模式与厂商无关。三个组件协同:

工作负载 ——正在运行的作业,例如强化学习实验、评估或高容量采样。每一项涉及智能体推理的研究工作负载在启动前必须关联一个经批准的 safety case。启动时,工作负载向 Control Room 请求一个作业 ID。
推理引擎 ——运行在 GPU 上的模型。每当工作负载需要 token,它就发送携带其作业 ID 的请求。在满足请求之前,引擎向 Control Room 确认该作业是否仍被授权。
Control Room 服务 ——追踪所有活跃作业并回答权限检查。当一个人或监控系统决定停止某作业时,Control Room 将该 ID 标记为终止,引擎随即拒绝它的下一次推理请求。

让这一设计稳健的工程决定,是检查所在的位置。工作负载代码由研究人员编写、频繁变更,OpenAI 明确拒绝信任它:"我们不依赖工作负载代码来正确检查作业是否仍在运行。"相反,终止机制被实现在推理层——一小组集中部署的代码路径,每一项研究工作负载都必须经由它们获取 token。OpenAI 还运行持续的智能体与程序化扫描,以抓出任何以未启用或未实现 Control Room 的方式启动的引擎实现。模型可以对自己的思维链打折扣,却无法与拒绝其下一个 token 的 HTTP 响应谈判。

这正是 kill switch 架构文章从买方角度论证的原则:检测可以被绕过、衰减或篡改,但放置在受控代码无法绕过的卡点上的执行,不因模型的推理而失效。Control Room 是它在厂商侧的实例化——也是首个在前沿规模上公开发表的部署。

诚实性标记,以及范围警示

披露中有三个细节值得与架构本身同样多的关注,因为它们界定了这一公告的真实含义。

**35 秒是被测量并被解释的。**延迟来自一层用于推理授权的缓存,它是为支撑所需流量规模而必需的。OpenAI 公布数字、点明成因并给出目标——"我们正努力把这个数字降到零,以便能瞬间终止作业"。一家厂商把控制平面最坏情况延迟连同其工程原因一并报告,正是企业买方应当标准化的披露方式。

**fail-closed 属性被表述为生产承诺,而非愿景。**如果 Control Room 服务"因系统错误而宕机,或因包括恶意行为者篡改在内的任何其他原因被禁用",所有推理请求都会被拒绝,直至正常运行恢复。在研究规模上,这是一个有意的取舍:牺牲可用性,使未授权输出永远无法转为隐身。这也正是大多数中型市场智能体技术栈默认做错的一点——一个 fail-open 的网关会在策略服务失灵时继续签发凭证。

**范围比标题建议的更窄。**fail-closed 的 Control Room 已面向所有前沿模型研究工作负载上线,并将在"未来几天"内覆盖其余研究工作负载。它不覆盖 ChatGPT 或 API。OpenAI 给出的理由是,外部模型服务栈"本质上集中得多,拥有成熟度很高的运维能力"来下架部署——这是一个合理的姿态,也是一条值得写下的范围边界:本公告中具名的、被测量的、fail-closed 的保证,附着在研究基础设施上,而不在买方所消费的产品上。该披露距 OpenAI 向美国众议院议员承诺"自动关闭能力"四个月;Control Room 是那封公开信之后发布的第一份具体架构,并先从研究侧起步。

OpenAI 对权限流的官方图示,压缩版:检测触发告警,Control Room 标记作业,引擎拒绝下一条请求——如果控制平面自身故障,则一切停止而非一切继续。

关停信件发布四个月后,买方应当问什么

九月对议员的承诺给出的是"能力";十一月的披露公布的是"架构"。对评估智能体平台的工程负责人或运营副总裁而言,区别在于可审计,尽调问题也随之具体化:

停止动作在哪里实现——在被控制的代码里,还是在它无法绕过的卡点上? OpenAI 的设计答案是推理引擎,选择它恰恰因为工作负载代码"并不是实现关键性、承重性安全防护的理想位置"。一家智能体厂商若把 kill switch 做成 system prompt、框架里的配置开关,或希望智能体遵守的约定,就是把执行放在了最不被信任的那一层。
故障姿态是什么——fail open 还是 fail closed? 如果你的智能体平台的策略服务、网关或审批队列宕机,工作是继续无治理运行,还是停下来?Control Room 停下来。大多数企业中间件默认 fail open——这正是"未授权输出永远无法转为隐身"这句话所排除的姿势。
实测停止耗时是多少,其底线由什么造成? 35 秒且有具名成因(授权缓存)是一个站得住的数字;"立即生效"而没有测量则不是。同一标准适用于你自己的技术栈:从操作者决策到智能体下一次受阻动作之间的间隔,是一个可以被测试的属性。
哪些工作负载真正被覆盖? OpenAI 明确划线:研究基础设施是,ChatGPT 与 API 不是,并以外向服务栈的集中性作为替代控制。中型市场买方应要求任何平台声明都做出同样的边界划分——哪些部署表面承载具名保证,哪些依赖继承下来的运维措施。

这一模式远不止适用于前沿实验室。同一形状——作业注册、在引擎或网关处的逐动作授权、停止即拒绝、fail-closed 姿态——同样适用于一个 B2B 报价智能体:报价引擎出示短时效凭证,每一笔 ERP 回写都经过权限检查;审批队列宕机时报价停止而非无声继续;从停止决定到下一次受阻动作的间隔以秒计。买方尽调清单现在为停止平面本身补上了厂商侧的对应物,长时运行智能体模式则把 DNS 事故作为持久化状态设计的促成案例:当停止在检测之后 2.5 小时才到来,中间这段运行必须仍然可恢复。