Control Room 式人工停机开关：追踪粒度与熔断状态机怎么定

Control Room 的公开摘要只给出一条轮廓：OpenAI 有一套系统在研究基础设施中追踪模型工作负载，并在出现安全或安保担忧时快速停止它们。对开发者而言，可迁移的不是它的实现，而是它逼出的两个问题：追踪粒度要细到什么程度，停机才算有效；人工熔断要以什么语义存在，才不会在真正需要时失灵。

本次材料只有标题与摘要，没有正文。下文会明确区分“摘要可确认的事实”与“工程推断与建议”；涉及具体字段、生效延迟、停机范围的部分，均待核实。

材料支持的三条事实#

• 存在一个名为 Control Room 的系统，定位是让人类对 AI 工作负载保有控制权（Introducing Control Room）。
• 它在 OpenAI 的研究基础设施范围内追踪模型工作负载（同上）。
• 当安全或安保担忧出现时，它可以快速停止这些工作负载（同上）。

“快速”是摘要用词，未给出量化延迟；“追踪”也未说明粒度。这两处恰好是设计时最需要自己定义的部分。

追踪粒度决定停机的上限#

推断：能停多细，取决于能定位多细。停机键应与追踪键同构，否则开关只能起到告警作用——你知道出事了，却只能停掉一大片。

上表是工程建议框架，不是 Control Room 的公开能力描述。

三个容易漏的字段

• 归属：每个工作负载都要能反查到负责人与项目，否则停机决定找不到批准人。
• 血缘：输入数据、模型版本、下游消费者。它决定停机后要不要连带处理已经产出的结果。
• 时间：启动时间与最后活动时间，用来区分“停的是活负载”还是“残留记录”。

把停机开关当接口设计#

人工开关最容易出问题的地方，不是“能不能停”，而是“停了之后系统处于什么状态”。

一条显式状态机

1. armed：开关就位，可被触发。
2. tripped：已触发，尚未扩散到执行层。
3. draining：在途任务按策略收尾或中止。
4. stopped：不再接受新负载。
5. resumed：恢复，通常需要与停机不同的权限。

每一跳都要写清在途请求的语义：立即中断、允许在检查点退出，还是等待超时。

四条工程约束

• 幂等：重复触发同一停机不应产生额外副作用，便于多方同时按下。
• 可审计：记录触发人、时间、依据与影响范围。停机是高风险操作，审计是它的一部分。
• 可演练：长期不用的开关会腐化，需要在非生产或影子负载上定期验证链路。
• 与自动熔断共用通道：自动熔断处理秒级异常，人工停机处理判断类问题；两套停法若各走各路，容易互相打架。

最小停机接口（未执行示例）#

以下是接口形状示意，使用 TypeScript 类型定义描述，未在任何环境执行，仅用于说明字段。域名与密钥均为占位。

// 未执行示例：仅示意人工停机开关的接口字段
type StopScope =
  | { level: "org"; orgId: string }
  | { level: "job"; jobId: string }
  | { level: "model"; modelVersion: string };

interface StopRequest {
  scope: StopScope;
  reason: string;          // 安全 / 安保 / 其他，需可审计
  requestedBy: string;
  idempotencyKey: string;  // 重复触发不产生额外副作用
  drainPolicy: "immediate" | "checkpoint" | "timeout";
}

interface StopResult {
  stopId: string;
  state: "tripped" | "draining" | "stopped";
  affectedWorkloads: number; // 停机前应可预估
}

落地前先回答的问题#

• 停机的最小单位是什么？单次调用停了，已缓存的输出算不算已停？
• 从按下到生效要经过几跳，每跳的超时是多少？这需要按自身架构测量，本文无法给出数值。
• 谁有权按？是否需要双人确认？
• 恢复为什么比停机更难？恢复权限是否应与停机权限分离？

Control Room 的公开摘要给出的方向是：把“人能否及时叫停”当作基础设施能力来建。对自建系统，这件事最终落到两个可验证的问题上——追踪键能不能定位到你想停的那一层，停机状态机能不能说清在途负载的去向。其余细节，等有可核验的材料再补。