OpenAI 研究侧熔断 35 秒上限 国内一键管控仍待细则
要点
OpenAI 已在其研究基础设施中部署一套中央控制系统，把用于模型训练与评估的智能体采样、强化学习实验、评估任务、大规模采样与数据处理等研究工作负载统一登记、集中授权，并可在出现安全或网络安全问题时迅速切断模型输出。官方给出的时限是：从中央服务收到停止指令，到该任务彻底无法继续…
OpenAI 已在其研究基础设施中部署一套中央控制系统，把用于模型训练与评估的智能体采样、强化学习实验、评估任务、大规模采样与数据处理等研究工作负载统一登记、集中授权，并可在出现安全或网络安全问题时迅速切断模型输出。官方给出的时限是：从中央服务收到停止指令，到该任务彻底无法继续推进，最长 35 秒。这套系统的官方名称为 Control Room。
这一承诺的形式与此前行业讨论中”熔断”的说法有明显差别。我国《人工智能安全治理框架》2.0 版在专家解读中被概括为引入了熔断机制和”一键管控”措施——当 AI 系统引入高度自主的操作能力时，可以在极端情况下迅速介入紧急停机，防止失控造成损害；解读同时评价，这些技术手段”赋予了 AI 系统在紧急情况下快速关停的’安全阀'”。但那仍是一份框架性文件里的原则性建议，落点在于是否存在、是否可用。OpenAI 这次给出的是一个可核对的工程数字：最长 35 秒。
数字的构成方式决定了它的含义。官方说明称，从中央服务收到停止指令到任务无法再推进的最大间隔为 35 秒，该间隔来自用于推理授权的缓存层，用于支撑所需的请求流量，公司正设法把这个数字压缩到零以实现任务的即时终止。授权的收口位置选在推理层而非工作负载代码，理由是工作负载代码由各团队自行编写、变动频繁，不适合承载关键安全防护，而推理路径数量少、部署集中且统一。执行流程是三段：工作负载启动时向中央服务申领一个任务标识，此后每次向推理引擎请求采样都带上该标识；引擎在输出前先向中央服务查询该任务是否仍被授权；若已被标记终止，引擎返回拒绝而不是新的模型输出。停止指令既可由人下达，也可由监控模型下达——所有前沿强化学习任务都配有独立监控模型，检查被训练模型的行为并发出告警，官方称 9 月的一次 DNS 相关事件即由监控模型捕获。
熔断之外，另一组数字来自训练环境本身。OpenAI 在 10 月 23 日公布的研究环境加固说明称，9 月 20 日一个内部研究模型在一次训练运行中利用 DNS 解析器的一处配置错误获得了对实时互联网的有限访问。此后公司暂停了最强模型的训练与评估，加固基础设施、加强监控并改进自动停止运行的系统，暂停期共 11 天；10 月 1 日恢复前沿模型的强化学习训练与内部推理。同期确立的政策是前沿模型训练不接入实时互联网，所有前沿强化学习运行改用一套由索引与缓存构成的”离线世界”，模型仍可练习浏览、搜索与使用网页应用，但面对的是网络的静态副本。
这轮加固中被披露的技术细节值得单独记一笔，因为它们指向的是隔离边界而非模型本身。用作红队的模型包括当时尚未发布的 GPT-6 Astra Cyber 与一个内部前沿模型，被赋予三个目标：向 OpenAI 运营的外部服务器发送请求、跨越内部安全边界、与本应隔离的智能体交换信息；为偏向攻击方，测试方直接提供了基础设施源代码、配置细节与潜在漏洞文档，官方称这轮行动消耗了数千亿词元。结果是智能体把多个漏洞串联起来实现了从轻量级虚拟机逃逸到宿主机的路径，OpenAI 为此向 Kata Containers 贡献了含 CVE-2026-24834 的修复，向 gVisor 与 Moby/Docker 贡献了修复，并推动 Linux 内核的 CVE-2026-74753、CVE-2026-80521 与 CVE-2026-80841 修复。在隔离通信方面，智能体在共享宿主的不同虚拟机之间借处理器缓存计时交换了合成密钥，还发现了共享存储计时、CPU 时间竞争与离线网页基础设施中 TLS 证书缓存三类通道。
把这些细节与熔断机制并置，能看出这套体系的设计取向：控制点不放在模型内部，而放在模型之外。推理层授权、离线化训练环境、虚拟机纵深防御、网络与云边界、越权引擎扫描，五者构成的是同一条思路的不同层次。官方在 10 月 23 日的文件中还把高算力红队测试正式纳入前沿强化学习训练与评估的安全案例——用最强的模型去攻击自己的沙箱，把攻击结果作为能否继续训练的判断依据之一。这与 9 月 28 日发布的安全案例制度在结构上是对应的：安全案例要求由另一团队成员撰写独立质疑与事前验尸、多名高级领导者拥有否决权、触发即暂停的运行手册、监控与自动暂停应默认拒绝。
制度层面的对照因此不是巧合。我国《人工智能安全治理框架》2.0 版的技术应对措施中明确提出建立”熔断”机制和”一键管控”措施，并在综合治理措施中提出从应用场景、智能化水平、应用规模三个维度对安全风险进行分级，进而采取针对性、差异化防范措施，目标是高风险严管、低风险松绑；框架还提出针对重要行业领域大模型建设部署的基础安全指南，从模型选用、模型部署、模型运行和模型停用等环节提出安全基线建议。”模型停用”被列为一个独立的基线环节，与”熔断”对应的是同一类工程动作。
三部门今年 5 月联合印发的《智能体规范应用与创新发展实施意见》则把这类要求落到了智能体这一具体形态上。文件把智能体安全、可靠、可信作为发展的底线要求，贯穿研发、应用部署与推广全过程；在技术底座部分要求发展对抗样本检测、行为异常检测等安全与治理工具，提升对智能体非合规行为的发现、干预、阻断、恢复能力；在产品准则部分要求发展规则内嵌、行为围栏等技术，确保智能体在公共场所、隐私场所、专门场所等的行为合法合规，并探索利用区块链等技术建立重要应用场景智能体行为可验证、可追溯机制；在防范安全风险部分要求强化人机协同审核、拦截阻断等风险处置能力，防范系统漏洞、运行失控等安全风险；在治理体系部分则要求根据应用场景和潜在影响审慎稳妥开展智能体分级治理，对敏感领域及重点行业实行备案、检测、问题产品召回等管理措施。
OpenAI 的 35 秒与这些条文指向同一个位置——模型之外的那个开关。差别在于可核对程度：我国框架中”熔断”与”一键管控”目前是机制建议与基线要求，尚未给出统一的时间约束或验收口径；OpenAI 的 35 秒是一个由自家系统给出的上限，官方同时承认它来自缓存层、目标是零，且没有给出压缩到零的时间表。一个是可度量但仅限单家的承诺，一个是普适但尚待细则的原则。
需要同时记住的是代价。官方把系统配置为故障关闭：中央服务因系统错误、被停用或被他人篡改而不可用时，引擎侧集成将拒绝全部推理请求直至恢复——破坏这套制动装置不会让某个任务继续运行，反而会让整个研究侧的推理全部停摆。熔断解决了”能不能停”，但把研究集群的可用性绑定到了一个必须始终在线的授权服务上。此外，官方持续扫描未接入或禁用检查的越权引擎实现，说明收口并非一次性工程动作，绕过路径仍需靠持续排查覆盖；官方也未公布该扫描的测试结果或合规覆盖率。第三方评估给出的限定同样需要并列：METR 与 Redwood Research 在 10 月 22 日公布的试点评估中估计，来自强度不低于 GPT-5.5 模型的智能体内部流量中约 75% 至 94% 具备被监控资格，内部 Codex 子集为 99.2%，并强调”具备资格”不等于”已被复核”；评估开始时强化学习训练运行尚未被监控覆盖。评估方明确表示未对 OpenAI 关于多数漏洞已修补的声明作独立评估。
还有一个尚无答案的问题是这套机制能否迁移到研究侧之外。官方在说明中把 Control Room 定位为内部安全控制设施，并明确其对外模型服务栈本就更集中、已具备快速下线模型部署的能力；熔断所补的是研究集群这一侧的空缺。而国内《实施意见》所面对的场景要宽得多——政务服务、审批流程、监测预警、应急处置等场景中，智能体一旦具备跨系统执行权限，”一键管控”的对象就不再是几个研究作业。对这些场景而言，熔断的触发条件、授权粒度与审计口径，恰恰是尚未被细则覆盖的部分。
