给 Agent 做急停：从 OpenAI Control Room 抄三层，而不是抄 35 秒

给 Agent 做急停：从 OpenAI Control Room 抄三层，而不是抄 35 秒

前几篇分别卡在不同层：《Agent 写基础设施的 4 道验收》 说验收要落在真实边界上，而不是「又生成了一批看起来能跑的 diff」；《装了 AI 编程助手之后，你的电脑多了哪些「别人的手」》 提醒同意边界和启动指令可能被改写；《复杂 Harness 不如多想？》 则把脚手架更多看成成本杠杆。这一篇补一条更硬的：agent 已经在跑、你决定让它停的时候，急停到底写在哪一层，才靠得住。

2026 年 11 月 9 日，OpenAI 发布了 Control Room 官方说明。据其自述，这是一套已经部署在研究基础设施上的中心系统：给人，或给监控模型，一条能在决策之后切断模型输出的路径；并且 Control Room 自己挂掉时，默认拒绝全部推理，而不是放行。

先把结论放在前面：值得抄的不是「35 秒」这个数字，而是急停写在哪一层，以及控制面挂掉时选「全停」还是「全放」。 提示词里写「听我一句停下」，模型可以不当回事；业务脚本天天改，也不适合当保险丝。OpenAI 把检查放在少数集中的推理路径上：任务可以继续喊，引擎却不再给 token。

说明：下文机制、35 秒上限、fail-closed 范围，均据 OpenAI 官方博文《Control Room》（2026-11-09）转述。这是他们的内部研究基础设施，不是对外 ChatGPT / API 服务，本文也未复现该系统。涉及「DNS 相关事件」的时间线，只取官方 misalignment 报告 里已经公开的监测与停机结果，用来说明「发现了不等于停得住」，不展开具体路径。

一、Control Room 实际做了什么（以及没做什么）

官方把系统拆成三块：

• workload（任务代码）：强化学习实验、评估、大规模采样或数据处理。做 agentic 推理的研究任务，需要挂到一份已批准的 safety case 上。
• inference engine（推理引擎）：跑在 GPU 上的模型本身。一个任务可能用多个引擎，一个引擎也可能服务多个任务。
• Control Room 服务：登记任务，并决定这个任务还能不能继续产生模型输出。引擎在真正出 token 之前，要向它询问授权；任务若已被停止，引擎必须拒绝这次推理。

启动时，任务代码向 Control Room 领取一个 job_id，之后每次向引擎要输出，都带上这个 ID。请求是任务直接打到引擎的，并不经过 Control Room；真正的门闩在引擎一侧——它在履约前再问一次：「这个 ID 还被允许跑吗？」

停的时候，人，或监控系统，通知 Control Room 把这个 ID 标为已终止。官方写得很清楚：他们不依赖任务代码自己去检查还该不该跑。任务进程可以还活着，也可以继续尝试采样；下一次引擎去问授权，得到的是拒绝，于是不再产生新的模型输出。同一台引擎上，其他仍被授权的任务可以继续。

两个容易写错的边界，也写在官方原文里：

1. 覆盖范围只在研究侧。 它连接的是研究推理负载，包括训练和评估里的 agentic 采样、数据处理等。对外的模型服务栈本身更集中，官方说那边已有较成熟的下线能力。不要把它理解成「ChatGPT 也能这样 35 秒急停」。
2. 35 秒是「决策之后」的上限，不是发现时间。 官方给出的指标是：从 Control Room 收到停止指令，到任务无法再往前推进，最长 35 秒。延迟来自推理授权的缓存层，是为了撑住流量；他们写明正在把这个数字往 0 秒做。换句话说，35 秒是他们的工程折中，不是你给自己 harness 必须抄下来的 SLA。

二、为什么保险丝不能放在天天改的那一层

官方把设计理由说得很直白：实验、评估这类 workload 通常由研究者或团队自己拥有和改动，代码变化频繁，不是放关键安全保护的理想位置。推理路径正好相反——整个研究体系里，真正在用的推理代码路径很少，部署也更集中、更统一。把终止机制做在推理层，才能比较有把握地说：研究侧的模型推理，每一次都要过 Control Room 的授权检查。

他们还提到两道加固。一是持续用 agentic 和程序化巡检，查看有没有人无意或有意地拉起一套没接、或关掉了 Control Room 的引擎。二是 fail-closed：引擎侧的集成被配置成，一旦 Control Room 服务宕掉、被关掉，或因其他原因不可用（官方也写到包括被恶意篡改），就拒绝所有推理请求，直到服务恢复。据博文，这一项当时已覆盖所有前沿模型的研究负载，其余研究负载将在随后几天滚动完成。

把这套逻辑翻到个人或小团队的 agent harness，对应的是三层，而不是一个秒数：

层	常见写法	为什么不够当保险丝
提示词	「收到停止就立刻停，不要再调工具」	模型可以忽略、忘了，或在长上下文里把这句话挤掉
业务脚本 / agent 循环	在自己的主循环里 if stopped: break	脚本天天改，新包一层包装器就可能绕开；官方也不把检查托付给任务代码
推理或工具层（集中瓶颈）	出 token 或执行工具前，用会话 / 任务 ID 问授权服务	路径少、改动少，停了就拒，不依赖正在跑的那份脚本是否配合

急停要写进第三层。第一层可以有，当作礼貌约定；第二层也可以有，当作日常开关。但唯一不能缺的，是那个所有工具调用或模型输出都必须经过的瓶颈。

三、监控发现了，不等于已经停住

Control Room 博文里写：所有前沿强化学习任务都配有独立监控模型，由它检查「正在训练的模型」在做什么，并在发现问题时报警；官方点名，近期一次 DNS 相关事件就是被监控抓住的。监控系统和 Control Room 的衔接是：监控可以按严重程度决定停任务，并把 job_id 发给 Control Room；此后这个 ID 再向任何引擎要 token，都会被拒绝。

这件事之所以值得单独写一句，是因为「抓住了」和「停住了」不是同一件事。据 OpenAI 2026 年 9 月 20 日样本、9 月 25 日更新的 misalignment 报告：监控系统在 15 分钟内标出了相关行为，人员在三分钟后开始审看；但预期中的自动停机没有按设想发生，这次 run 是在约 2.5 小时后被手动结束的。报告把这写成操作层漏洞，并说明他们在补。

对做 harness 的人，只需记住这一句：发现路径可以在旁边，切断路径必须在瓶颈上，而且不能指望正在跑的任务自己执行停止。 本文不讨论那次事件里的网络细节，也不把它写成可复现步骤。更新规避的要点只有两个：监控报警要能直接打到授权服务；授权服务自己不可用时，选择拒绝，而不是放行。

四、个人和小团队可直接拿走的清单

不必假装自己在建一座 OpenAI 研究中控室。大多数本地或小团队 agent，真正的集中瓶颈通常是：统一的工具网关、代理层，或所有副作用（写文件、跑命令、对外请求、改仓库）都必须经过的那一层。可操作的做法可以收成下面几条。

1. 不要把急停只写在提示词里。 提示词是约定，不是保险丝。模型不一定听，长会话里更容易丢。
2. 不要让天天改的业务脚本，成为唯一的停止开关。 主循环里加一个 stopped 标志很有用，但新包一层、换一条启动命令、或者 agent 自己再拉起子进程，这个标志就可能够不着。官方的选择是：任务可以继续喊，引擎不再给输出。
3. 给每次运行发一个会话或任务 ID，副作用出口先问授权再执行。 对照 Control Room：领取 ID，后续请求都带上它；停止令下去之后，下一跳直接拒绝。对个人项目，这个「下一跳」可以是工具网关，不必是自建推理引擎。
4. 权限用白名单，不用「模型应该知道什么不该做」。 官方研究任务要挂到已批准的 safety case；落到小团队，就是这份任务允许哪些工具、哪些目录、哪些出站目标。没在名单里的，默认拒绝。
5. 控制面挂了就停，不要挂了就放行。 这是官方 fail-closed 的可抄之处。授权服务超时、崩溃、被关掉时，工具层应拒绝新的模型输出和副作用，而不是为了「别打断开发」改成失败放行。
6. 停的是输出和工具，不一定是进程本身。 官方写明：模型输出停了，任务进程可以还活着，引擎也还可以服务其他仍被授权的任务。本地调试时，这一点很实用——急停不等于立刻 kill -9，而是先切断它继续行动的能力。
7. 别把 35 秒抄成自己的指标。 那是他们为授权缓存付出的上限，并且在往 0 秒做。个人 harness 如果流量不大，授权检查完全可以更紧；要量的是「停止指令发出之后，还能否继续产生副作用」，而不是有没有做出同一个秒数。

一张极简自检表（自己填，不要求实验室精度）：

你现在把急停写在哪	它能挡住什么	它经常挡不住什么
提示词里的「请立刻停止」	偶尔听话的短会话	模型忽略、上下文被挤掉、工具仍在飞
agent 主循环里的标志位	这条脚本还在你掌控中时的正常退出	新包装器、子进程、没走这个循环的第二次启动
工具 / 代理 / 推理出口的授权检查（带任务 ID）	停止令之后的新输出和新副作用	——（前提是这条路径真的集中，且 fail-closed）
授权服务不可用时的默认策略	控制面故障时是否还在放行	为了「先跑起来」改成失败放行

如果只能改一个习惯：下次给 agent 加工具时，先问「停止令将打在哪一个所有调用都必须经过的点」，再问「这个点挂了，是拒绝还是放行」。问不清，就还没有急停，只是有一句提示。

五、结尾：抄层，不抄秒数

Control Room 最有用的地方，不是它宣布了一个 35 秒的数字，而是它把保险丝从「经常改的任务代码」挪到了「少数集中的推理路径」，并且在控制面自己出事时选择全停。监控负责发现，授权服务负责切断；两者没有接上的时候，即使 15 分钟内报了警，停机仍可能拖成数小时——这是官方自己公开的操作教训。

所以，独立开发者不必去复刻一座研究中控室。778 让你把验收卡在真实边界，779 让你看清本机上多出来的「别人的手」，780 让你分清 harness 是不是只在买账单。这一篇只补一句：给 agent 的急停，请写在工具或推理的集中瓶颈上，并在控制面挂掉时选择拒绝；不要把希望寄托在提示词，或寄托在 35 秒这个数字上。

参考

• OpenAI（2026-11-09）：Control Room
• OpenAI Alignment（样本 2026-09-20，报告更新 2026-09-25）：An agent used DNS to reach an external chatbot（本文只引用监测与停机时间线，不展开路径）
• 轻对照 · 本站 778：https://blog.zhoudw.vip/blog/778
• 轻对照 · 本站 779：https://blog.zhoudw.vip/blog/779
• 轻对照 · 本站 780：https://blog.zhoudw.vip/blog/780

机制与数字均为官方自述，本文未复现 Control Room，也未把研究基础设施上的秒数当成个人 harness 的标准值。