摘要：OpenAI 于 2026 年 11 月 9 日公开了 Control Room：一个覆盖研究基础设施的中央控制系统。它为每个智能体工作负载分配全局任务身份，让推理引擎在生成前检查授权，并在安全或安保风险出现时阻断后续输出。官方披露的最坏停止时间为 35 秒，系统自身失效时则采用 fail-closed（失败关闭）。本文不止复述发布信息，而是拆解它背后的工程约束，并给出一套可迁移到企业智能体平台的参考架构、数据模型、代码骨架、缓存策略和演练清单。

一、为什么智能体平台需要“推理层急停”

传统 Web 服务的停机手段通常是下线实例、撤销令牌、关闭队列消费者或阻断网络。对长时间运行的 AI 智能体而言，这些措施并不充分：一次业务任务可能跨越多个模型、多个推理集群、多个工具和数百次采样；任务代码还可能在不同团队维护的实验框架中持续变化。

如果急停逻辑只写在智能体循环里，恰好有缺陷的那段工作负载代码也掌握着“是否停止”的解释权。更糟的是，一个任务即便停止了主进程，已经派生的子任务、重试队列或共享推理请求仍可能继续产生输出。

Control Room 的关键思路，是把控制点下沉到更集中、更统一的推理层：任何工作负载要调用模型，都必须携带一个全局 job_id；推理引擎在真正生成前检查这个 job_id 是否仍被允许。这样，停止命令不依赖上层任务是否配合，而是由所有输出都绕不开的瓶颈执行。

这不是给智能体增加一个“停止按钮”，而是建立一个跨工作负载、跨模型、跨推理集群的统一执行许可系统。

二、官方披露的四个核心事实

官方事实	工程含义
每个研究工作负载启动时向 Control Room 申请 job_id	任务身份必须全局唯一、可追踪、不可由调用方随意伪造
推理引擎在处理请求前携带 job_id 查询许可	策略执行点位于集中推理路径，而不是易变的智能体代码
收到停止决定后，最坏 35 秒内无法继续推进	授权结果存在缓存；安全时延必须作为明确 SLO 管理
Control Room 不可用时拒绝所有推理请求	系统选择 fail-closed，优先保证安全而不是可用性

官方还说明，Control Room 已覆盖研究基础设施中的推理工作负载，包括用于训练和评估的智能体采样、数据处理等；它与失对齐监控系统联动。当监控系统判断需要停止任务时，会向 Control Room 发送 job_id，后者把任务状态记录为 terminated。此后，任何引擎再次收到该 job_id 的采样请求，都应拒绝生成。

三、最小架构：身份、策略与执行点

一套可用的企业级实现至少包含五个角色：

1. 工作负载编排器：启动智能体、评估或批处理任务，申请 job_id，并把它传播给所有子任务。
2. 控制平面：保存任务状态、风险等级、负责人、安全论证和停止原因。
3. 推理网关或引擎：作为策略执行点，在每次生成前校验许可。
4. 监控与调查系统：结合模型审查、工具调用、网络日志和业务遥测产生告警。
5. 响应与审计系统：执行暂停、终止、恢复、升级，并保存不可抵赖的证据链。

研究员 / 业务系统
        |
        | create_job(safety_case_id)
        v
  Control Plane ---- 告警 / 人工响应 / 审批
        |                         ^
        | job_id + policy        | evidence
        v                         |
智能体工作负载 ---- 工具调用 ---- 监控系统
        |
        | inference(job_id, request)
        v
 推理网关 / 推理引擎 -- authorize(job_id) --> Control Plane
        |
        +-- allow  -> 生成输出
        +-- deny   -> 拒绝并停止推进

这个架构有意把“谁发现问题”和“谁真正阻断输出”分开。监控系统可以快速演进，甚至允许一定误报；推理层的执行逻辑则应尽量小、稳定、可验证。

四、数据模型：不要只存一个 running / stopped

真实系统至少要区分 active、paused、terminated 和 expired。paused 允许在复核后恢复；terminated 应是不可逆的终态；expired 用来处理超时或遗留任务。每次状态变化都应带版本号，防止并发更新把停止状态覆盖回运行状态。

CREATE TABLE ai_job_control (
    job_id           VARCHAR(64) PRIMARY KEY,
    tenant_id        VARCHAR(64) NOT NULL,
    workload_type    VARCHAR(32) NOT NULL,
    safety_case_id   VARCHAR(64) NOT NULL,
    state             VARCHAR(16) NOT NULL,
    state_version     BIGINT NOT NULL,
    risk_tier         VARCHAR(16) NOT NULL,
    owner_id          VARCHAR(64) NOT NULL,
    expires_at        TIMESTAMP NOT NULL,
    updated_at        TIMESTAMP NOT NULL,
    stop_reason_code  VARCHAR(64),
    stop_evidence_uri VARCHAR(512)
);

CREATE TABLE ai_job_control_event (
    event_id       VARCHAR(64) PRIMARY KEY,
    job_id         VARCHAR(64) NOT NULL,
    from_state     VARCHAR(16),
    to_state       VARCHAR(16) NOT NULL,
    actor_type     VARCHAR(32) NOT NULL,
    actor_id       VARCHAR(64) NOT NULL,
    reason_code    VARCHAR(64) NOT NULL,
    evidence_hash  VARCHAR(128),
    created_at     TIMESTAMP NOT NULL
);

还要明确一个容易遗漏的约束：job_id 必须贯穿父任务、子任务、重试请求和异步队列。子任务可以有自己的 span_id，但不能脱离原任务的控制域。否则，攻击者或普通代码缺陷都可能通过“新建一个没有被停掉的任务”绕过急停。

五、参考实现：在推理网关强制授权

下面的 Python 代码是教学用骨架，不代表 OpenAI 的内部实现。重点是展示策略执行顺序：先验证任务身份，再查询许可，最后才把请求交给模型后端。

from dataclasses import dataclass
from enum import Enum
import time

class Decision(str, Enum):
    ALLOW = "allow"
    DENY = "deny"

@dataclass(frozen=True)
class Authorization:
    decision: Decision
    state_version: int
    valid_until: float
    reason: str

class InferenceGuard:
    def __init__(self, control_client, cache, max_cache_ttl=5):
        self.control_client = control_client
        self.cache = cache
        self.max_cache_ttl = max_cache_ttl

    def authorize(self, *, job_id: str, tenant_id: str) -> Authorization:
        if not job_id or not tenant_id:
            return Authorization(Decision.DENY, 0, time.time(), "missing_identity")

        key = f"{tenant_id}:{job_id}"
        cached = self.cache.get(key)
        if cached and cached.valid_until > time.time():
            return cached

        try:
            result = self.control_client.check(job_id=job_id, tenant_id=tenant_id)
        except Exception:
            # fail-closed：控制平面不可达时不生成
            return Authorization(Decision.DENY, 0, time.time(), "control_unavailable")

        ttl = min(result.ttl_seconds, self.max_cache_ttl)
        auth = Authorization(
            decision=Decision.ALLOW if result.state == "active" else Decision.DENY,
            state_version=result.state_version,
            valid_until=time.time() + ttl,
            reason=result.state,
        )
        self.cache.put(key, auth)
        return auth

    def guarded_generate(self, request):
        auth = self.authorize(job_id=request.job_id, tenant_id=request.tenant_id)
        if auth.decision is Decision.DENY:
            raise PermissionError(f"inference_denied:{auth.reason}")
        return request.model_backend.generate(request.payload)

生产实现还应校验 job_id 的签名或服务身份，避免客户端随意借用其他活跃任务的标识；对于流式输出，不能只在流开始前检查一次，还需要在分块边界或固定时间窗重新授权，保证长响应也受停止时延约束。

六、35 秒从哪里来：缓存不是细节，而是安全预算

官方说明，35 秒延迟来自推理授权的缓存层。缓存能支撑巨大请求量，但也意味着一条“允许”决定在过期前可能继续生效。因此，缓存 TTL 直接决定急停系统的最坏反应时间，必须被当作安全预算管理。

企业实现可以组合以下策略：

• 短 TTL：例如 3—10 秒，简单可靠，但会增加控制平面 QPS。
• 主动失效：停止事件通过消息总线推送到所有推理节点，立即清除 allow 缓存。
• 版本围栏：授权记录携带 state_version，旧版本无法覆盖新版本。
• 租约机制：引擎只获得短期生成租约，租约过期必须重新申请。
• 分层缓存：节点内缓存负责低延迟，区域缓存负责削峰，中央状态负责最终一致性。

建议把停止时延拆成可观测的链路：告警确认耗时、状态写入耗时、事件传播耗时、缓存残留时间、在途生成完成时间。只监控“停止接口返回 200”没有意义，真正的 SLO 应是最后一个受控输出停止产生的时间。

6.1 用公式定义停止上界

T_stop = T_decision
       + T_control_write
       + max(T_cache_ttl, T_event_propagation)
       + T_inflight_boundary

目标不是让某个接口足够快，
而是让 T_stop 在所有区域、所有模型、所有流式请求上都有可验证上界。

七、为什么必须 fail-closed，以及它会带来什么代价

fail-open 表示控制平面不可用时继续推理，可以提高可用性，却会在最需要安全控制的时候失去控制；fail-closed 表示无法证明任务被允许时就拒绝请求。OpenAI 披露 Control Room 采用后者，并且当系统自身被关闭、故障或遭到篡改时，推理请求都会被拒绝。

这会把控制平面升级成高关键性基础设施。你需要多区域部署、独立故障域、容量保护、熔断、只读降级和严格变更管理，但不能把“异常时默认允许”当作降级方案。更合理的可用性策略是：控制平面故障时，普通低风险请求也许可以切换到一个能力受限、无工具权限的安全模型；高风险智能体则直接停止。

需要特别防范三类绕过：

1. 未接入控制系统的“野生”推理端点；
2. 内部调用方伪造或复用其他任务的 job_id；
3. 为了排障临时关闭鉴权，却忘记恢复。

官方提到会持续用智能体和程序化扫描检查是否有人意外或恶意启动了未实现、或关闭了 Control Room 的推理引擎。企业平台同样应该把这类合规扫描放进持续交付和运行时资产盘点，而不是依赖文档约定。

八、监控系统如何与急停闭环

Control Room 解决“怎么停”，监控系统解决“什么时候停”。OpenAI 在另一份官方材料中披露了分层监控思路：轻量探针做高召回初筛，基于模型的审查器检查对话、推理和工具使用，调查智能体补充任务背景并核验证据，最后把对话与网络日志、系统遥测和历史事件关联起来。

对企业智能体平台，可以把告警分成三档：

等级	典型信号	默认动作
P0	越权写入、逃逸隔离区、外传敏感数据、绕过审批	自动 terminate，冻结凭证，通知值班人员
P1	异常网络访问、重复探测权限边界、风险工具链组合	自动 pause，保留现场，等待人工复核
P2	低置信度异常、策略漂移、非紧急失对齐迹象	限制能力并进入调查队列

关键原则是：检测与阻断之间要有机器可执行的接口，告警必须携带 job_id、证据引用、风险等级和策略版本。不要让值班人员在事故中手工搜索任务、复制 ID、再登录另一套系统点停止。

九、安全论证不是附件，而是任务准入条件

官方披露，每个进行智能体推理的研究工作负载都要关联一个已批准的 safety case（安全论证）。这意味着“允许启动”不是只看调用方是否有 API Key，还要看该任务在什么环境运行、能访问哪些工具、监控覆盖是否完整、出现问题如何停止。

企业可以把安全论证简化成机器可校验的准入清单：

• 任务目的、数据范围和风险等级已登记；
• 工具权限遵循最小权限，并设置金额、次数或数据量上限；
• 所有模型调用都经过受控推理网关；
• 网络、文件、数据库和外部消息操作有审计；
• 高风险动作需要人类批准；
• 已定义 pause、terminate、凭证撤销和下游回滚流程；
• 监控、日志和证据存储满足保留期限；
• 演练证明停止 SLO 能在峰值流量下达成。

安全论证的 ID 应写入 job 记录和每条推理审计日志。这样，事故发生后可以回答：哪个批准版本允许了这次运行，运行时实际使用的权限是否与批准内容一致。

十、实现中最容易踩的八个坑

1. 只在任务启动时鉴权：启动后撤销无效，无法真正急停。
2. 只停止编排器：推理引擎、异步子任务和在途流仍可能继续输出。
3. 缓存没有上界：局部节点配置错误，让 5 秒 TTL 变成 5 分钟。
4. 流式请求只检查一次：超长生成可以跨越多个停止窗口。
5. 状态更新没有版本：迟到的“恢复”消息覆盖新的终止决定。
6. 控制面和业务面共用故障域：一次网络或身份系统故障同时摧毁监控与停止能力。
7. 停止后不撤销工具凭证：模型不再生成，但已派发的工具调用继续执行。
8. 没有下游血缘：无法定位被风险任务生成的数据、代码、评分或训练样本。

十一、怎样测试：不要把“按钮能点”当作急停验收

至少需要四类测试。第一类是功能测试：active、paused、terminated、expired 状态是否按预期拒绝或允许。第二类是故障注入：控制平面断网、区域缓存失联、消息总线积压、时钟偏移时是否仍然失败关闭。第三类是绕过测试：无 job_id、伪造 job_id、跨租户复用、直接调用后端模型能否成功。第四类是规模测试：在峰值 QPS 和长流式生成下，停止上界是否仍满足 SLO。

def test_control_plane_outage_fails_closed(gateway, control_client):
    control_client.simulate_timeout()
    response = gateway.generate(
        tenant_id="tenant_demo",
        job_id="job_demo",
        prompt="continue"
    )
    assert response.status_code == 403
    assert response.error_code == "control_unavailable"

def test_terminated_job_cannot_resume_with_stale_event(store):
    store.apply(job_id="job_demo", state="terminated", version=12)
    store.apply(job_id="job_demo", state="active", version=11)
    assert store.get("job_demo").state == "terminated"

演练时要记录从“停止决定生成”到“最后一个输出 token、最后一次工具调用和最后一条外部消息停止”的全过程。若只能证明数据库状态变成 stopped，还不能证明系统真的停下来了。

十二、推荐的落地顺序

如果现有平台还没有统一控制平面，不必一开始覆盖所有场景。可以按以下顺序推进：

1. 先统一所有模型调用入口，禁止工作负载直连推理后端。
2. 为长任务建立 job_id，并打通父子任务、队列和审计日志。
3. 在推理网关实现 active / paused / terminated 校验，默认拒绝无身份请求。
4. 为高风险任务启用短租约、主动缓存失效和流式重检。
5. 把监控告警、人工审批和控制平面状态机连接起来。
6. 扩展到工具凭证撤销、外部副作用冻结和下游产物回滚。
7. 用故障注入和红队演练持续验证停止 SLO。

最先获得的收益往往不是“阻止超级智能失控”，而是更现实的运维能力：异常批处理可以快速止损，越权智能体能被全局冻结，错误版本生成的下游数据有迹可循，值班人员也不再需要逐个集群寻找任务。

结语

Control Room 最值得借鉴的地方，不是某个具体接口，而是控制边界的选择：把容易变化的工作负载视为不可靠，把统一推理层变成不可绕过的策略执行点；给每个任务建立全局身份；用明确的最坏停止时间管理缓存；系统失效时默认拒绝；再把监控、人工响应、安全论证和审计串成闭环。

智能体越能长时间运行、调用工具和跨系统协作，平台就越需要一套独立于智能体本身的“刹车系统”。真正成熟的智能体基础设施，不只要回答模型能做什么，还必须能证明：当它不该继续时，平台能在可验证的时间内让所有相关输出和动作一起停下来。

参考资料

• OpenAI：Control Room，2026-11-09。
• OpenAI：How we detect frontier model misalignment，2026-10-29。
• OpenAI：Towards safety cases for frontier AI training，2026-09-28。