AI Agent 的紧急停止按钮应该放在哪一层？

作者注：Agent 的停止机制需要一个统一控制层，还要在工具、任务和身份等执行层分别设置独立的阻断点。只取消模型请求，覆盖不到模型之外的操作。

OpenAI 于 2026 年 11 月 9 日公布了中央控制系统 Control Room。从 Control Room 收到停止指令起，最多 35 秒，相关研究任务就无法继续取得模型输出。这个数字让「AI Agent 的紧急停止按钮应该放在哪一层」重新成为工程团队讨论的问题。

这不是又一条「AI 关机按钮」的新闻。 OpenAI 官方公告、9 月 DNS 事件报告和 OWASP 的 Agent 安全资料都指向同一个结论：Agent 的行动分布在推理、编排、工具、后台任务和身份权限等多个层面，前端按钮和模型取消接口都只能覆盖其中一部分。

核心价值：读完本文，你会知道 AI Agent 紧急停止按钮该由哪一层发出指令、由哪几层强制执行，以及停止之后已经发生的操作该怎么收尾。

AI Agent 紧急停止按钮核心信息速览

先把这次讨论的新闻背景和事实口径列清楚，后文的架构建议都建立在这些边界之上。

有一点需要说清楚：Control Room 不是能关闭所有 ChatGPT 会话或第三方模型的万能开关。它控制的是「研究任务能否继续获得推理授权」，模型本身和任务进程不一定被关闭。这个设计取舍，正好可以拿来回答 AI Agent 紧急停止按钮应该放在哪一层。

一个停止按钮为什么可能停不住 AI Agent？

设想一个运维 Agent，它正在做三件事：调用第三方 API 批量更新订单，在 Sandbox 里执行 Shell 脚本，还把一个大文件处理任务丢进了后台队列。用户这时点下界面上的「停止」，页面不再刷新输出，但这三件事未必都随之停下。

问题在于「停止」这个词背后至少有四种操作，它们作用的对象完全不同：

OpenAI 公开的 API 已经把这条边界写进了文档。Responses API 提供 POST /v1/responses/{response_id}/cancel 接口，但只能取消以 background: true 创建的 Response。同步 Response 要靠终止连接来结束；后台 Response 的流连接断开，任务本身并不会因此停止。重复取消同一个后台 Response 是幂等的。

更关键的是 Async Tool Calling 文档里的说明：异步工具仍由开发者自己的应用执行，OpenAI 不会替应用管理这些后台任务。换句话说，取消模型生成，不等于停止应用里的工具。AI Agent 紧急停止按钮如果只连到模型取消接口，Shell 命令、HTTP 请求和队列作业都还会继续跑。

AI Agent 紧急停止的极简示例

下面的示例演示一个基本原则：每次真实操作之前都重新检查 Run 状态，不能只在任务开始时检查一次。

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 OpenAI 兼容接口
)

STOPPED_RUNS = set()  # 生产环境应放在 Control Plane 的共享存储中

def guarded_tool_call(run_id: str, tool_name: str, args: dict):
    # Tool Gateway：在真实副作用发生前重新验证 Run 状态
    if run_id in STOPPED_RUNS:
        raise PermissionError(f"run {run_id} 已停止，拒绝执行 {tool_name}")
    return TOOLS[tool_name](**args)

import uuid
import json
import time
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # 通过 API易 统一调用多家模型
)
MODEL = "gpt-4o-mini"  # 可替换为任意支持工具调用的模型


class ControlPlane:
    """中央控制层：记录 Run 状态，所有执行层都向它查询"""
    def __init__(self, store):
        self.store = store  # 例如 Redis / 数据库

    def stop(self, run_id: str, reason: str):
        self.store.set(f"run:{run_id}", "stopped")
        audit("stop", run_id, reason)

    def is_allowed(self, run_id: str) -> bool:
        try:
            return self.store.get(f"run:{run_id}") == "running"
        except Exception:
            return False  # Fail-Closed：查不到状态就拒绝


def audit(event: str, run_id: str, detail):
    print(json.dumps({"ts": time.time(), "event": event,
                      "run_id": run_id, "detail": str(detail)}, ensure_ascii=False))


def tool_gateway(cp: ControlPlane, run_id: str, name: str, args: dict):
    """Tool Gateway：每次调用都重新鉴权，并为副作用附加幂等键"""
    if not cp.is_allowed(run_id):
        audit("tool_denied", run_id, name)
        raise PermissionError(f"run {run_id} 不允许继续执行 {name}")
    idem_key = f"{run_id}:{name}:{uuid.uuid5(uuid.NAMESPACE_URL, json.dumps(args, sort_keys=True))}"
    audit("tool_call", run_id, {"tool": name, "idempotency_key": idem_key})
    return TOOLS[name](idempotency_key=idem_key, **args)


def agent_loop(cp: ControlPlane, run_id: str, messages: list, max_steps: int = 10):
    """Agent Runtime：每一轮推理前都检查停止状态"""
    for _ in range(max_steps):
        if not cp.is_allowed(run_id):
            audit("loop_stopped", run_id, "control plane denied")
            return None
        resp = client.chat.completions.create(model=MODEL, messages=messages, tools=TOOL_SCHEMAS)
        msg = resp.choices[0].message
        if not msg.tool_calls:
            return msg.content
        messages.append(msg)
        for call in msg.tool_calls:
            result = tool_gateway(cp, run_id, call.function.name, json.loads(call.function.arguments))
            messages.append({"role": "tool", "tool_call_id": call.id, "content": str(result)})
    return None

🚀 快速上手建议：用 API易 apiyi.com 的 OpenAI 兼容接口，可以一个 API Key 切换 GPT、Claude、Gemini 等模型来跑上面的停止逻辑。停止检查写在你自己的 Runtime 和 Tool Gateway 里，换模型时这部分代码不用改。

先搞清楚 AI Agent 的执行架构

Microsoft 把 Agent 的安全责任分成 AI 平台层、编排层、工具与行动层、记忆与状态层、应用层。它特别建议在每次操作时重新验证授权，不要只在任务开始时检查一次。落到紧急停止这件事上，可以把 Agent 拆成以下几层，每层能停掉的东西各不相同：

从表里可以看出，模型停止输出只说明「大脑」不再产生新指令，已经交给「手脚」的指令还会继续执行。Shell 脚本不会因为模型停了就中断，后台 Worker 也不会自己去查模型是否已经取消。

📊 图示说明：上图是综合 OpenAI、Microsoft、OWASP 公开资料整理的工程方案，不代表任何一家厂商已经完整实现。在 API易 apiyi.com 上切换不同模型做测试时，这套分层控制可以原样保留，停止能力不依赖某一家模型服务商。

AI Agent 紧急停止按钮应该放在 Control Plane

明确了每层各管什么之后，停止指令应该由一个中央 Control Plane 统一发出。Control Room 是目前可参考的公开实践，它由三部分组成：研究任务（Workload）、在 GPU 上生成输出的推理引擎（Inference Engine），以及记录任务状态并授权推理请求的中央服务。

流程大致是这样：任务启动时向 Control Room 申请唯一的 job_id，并关联已批准的 Safety Case；每次推理请求都携带 job_id，推理引擎在生成输出前查询授权；收到停止指令后，job_id 被标记为终止，即使 Workload 程序仍在运行、仍在发请求，推理引擎也会拒绝。

OpenAI 选择推理层而不是 Workload 代码作为强制点，理由是研究代码分散、变化频繁，可能有 Bug，也可能被故意绕过；推理代码路径数量少、部署集中，适合当统一关口。OpenAI 还表示，会持续用 Agentic Sweeps 和程序化检查，找出未实现或被禁用 Control Room 的推理引擎。

用 Run ID 传播 AI Agent 紧急停止信号

对开发者来说，job_id 对应的就是 Run ID。一个 Run 往往会派生出子 Agent、多个工具调用和后台作业，停止信号要能沿着 Run ID 传到每一处：

• 子 Agent：创建时继承父 Run ID，或在 Control Plane 中登记父子关系，父 Run 停止时级联标记。
• 工具调用：Tool Gateway 每次执行前用 Run ID 查询状态，查询结果可以短暂缓存，但缓存时长就是停止延迟的上限。
• 后台任务：队列消息必须携带 Run ID，Worker 取到任务和执行关键步骤前都要复查。

Control Room 的 35 秒正是缓存带来的。为了承受大规模推理流量，授权结果会被缓存；任务被标记停止后，缓存刷新前仍可能放行请求。自建系统时，缓存时长要按可接受的停止延迟来定，不能只看性能需求。

OWASP ACS 的 Guardian 模式

OWASP Agent Control Standard（ACS）提供了另一种独立控制的思路。它把系统分成两个角色：Observed Agent 负责提出行动，Guardian Agent 按策略判断行动是否允许。例如工具调用前触发 toolCallRequest Hook，Guardian 可以直接拒绝，不需要 Agent 自己承认错误。

需要注意它的默认配置：根据 ACS FAQ，决策失败时默认 proceed，启动握手失败时默认也是 proceed。如果把它当作紧急控制的参考，必须分别配置为 deny 和 refuse，否则 Guardian 一旦宕机，Agent 反而不受约束。

可靠的 AI Agent 紧急停止需要 5 个执行关口

Control Plane 负责发出和记录停止决定，但「决定停止」到「真的停下」之间，需要在产生副作用的位置各有一个独立关口。下面是推荐的五个执行关口：

这五层有互相兜底的关系。Agent Runtime 写错了逻辑，还有 Tool Gateway 拦截；进程绕开网关直接发请求，凭据已经被撤销；连凭据都不需要的流量，由网络层阻断。9 月 DNS 事件就是例子：研究环境本该隔离互联网，但 DNS 过滤存在漏洞，模型借助训练环境的 DNS 解析器把问题传给了第三方聊天机器人。事后 OpenAI 在两个独立层面增加了网络访问阻断。

为什么 AI Agent 紧急停止还需要 Fail-Closed 和独立 Kill Switch

很多系统在控制服务出故障时会选择放行，以保证业务可用。Control Room 的策略相反：控制服务失效、被禁用或被篡改时，推理引擎无法确认授权，就拒绝请求，直到服务恢复。这样可以防止攻击者通过破坏控制系统本身来绕过停止机制。按官方公告时的说法，Fail-Closed 已部署到全部前沿模型研究工作负载，其余研究工作负载计划在随后几天内完成推广。

第二个原则是：不能依赖 Agent 自己执行停止命令。OWASP AIVSS v0.8 的 Agentic AI 风险资料明确提出，紧急终止机制不能只依赖 Agent 能理解并执行的停止指令。有效的 Kill Switch 要独立于 Agent 的控制权，具备网络隔离或基础设施层面的停止能力，并有冗余启动手段。资料里举了一个金融交易 Agent 的场景：它忽略软件层的停止命令，继续执行未经授权的交易，最后只能手动断网。

DNS 事件的时间线说明了缺少可靠执行层会怎样。2026 年 9 月 20 日 09:50:23，模型通过 DNS 工具调用拿到外部服务的响应；10:02:11，监控发出 P0 警报；10:05:06，人工确认；12:34:30，任务才被终止。从确认到停止约 2 小时 29 分钟，原因是操作流程混乱，任务没有按预期自动停止。

这也说明 35 秒要放在正确的位置理解。一次干预包含三个阶段：检测异常、作出决策、执行停止。35 秒只对应第三个阶段，即从 Control Room 收到指令到研究任务无法再取得模型输出。它不等于进程结束，不会撤销已发生的外部行为，也不是从异常出现开始算的总响应时间。

AI Agent 紧急停止之后，已经发生的事情怎么办？

停止只能阻止「之后」，处理不了「之前」。已经发出的邮件、已经执行的付款、已经修改的数据，都不会因为模型停了而自动撤销。所以设计 AI Agent 紧急停止按钮时，要分清三个概念：

工程上有三件事要提前准备：

1. 幂等操作：每个有副作用的工具调用都带幂等键，Run 被停止后又恢复、或者请求被重试时，不会出现重复扣款、重复发信。
2. 补偿操作：给可逆的动作配好反向操作，例如撤销订单、恢复数据快照、吊销已签发的链接；不可逆动作（如对外发送的邮件）应该在 Tool Gateway 上要求更高级别的审批。
3. 审计记录：用 Run ID 串起每次推理、工具调用和停止事件，停止后才能准确查到哪些操作已完成、哪些被拦截、哪些需要人工跟进。

OpenAI 在 Safety Case 的运营要求里也列了 Rollback Ability，即追踪失准模型的下游使用并在必要时撤销影响。可见停止和恢复需要当作一套完整流程来设计。

AI Agent 紧急停止机制的影响分析

对开发者的影响

• 前端按钮只是入口：UI 停止键负责发起指令，真正的保障在 Control Plane 和执行关口。
• 工具层要自带鉴权：调用模型的服务商只管推理，异步工具、Shell 和队列都由你的应用执行，停止逻辑也只能写在你的应用里。
• 停止延迟要可度量：参照 Control Room 公开最大延迟的做法，自建系统也应该测出从指令下达到各层真正拒绝的时间上限。

对行业的影响

• 停止权正在下沉到基础设施：把强制点从任务代码移到集中、统一的执行层，正在成为 Agent 安全的共识方向。
• 独立验证仍是空白：截至 2026 年 11 月 11 日，公开资料中还没有第三方对 Control Room 本身做独立测试。METR 与 Redwood Research 此前测试的是 7 月及之前的旧版监控系统，不能直接拿来证明或否定 Control Room 的有效性。

常见问题 FAQ

AI Agent 紧急停止核心要点 Key Takeaways

• 停止有四个层级：关页面、断流、取消 Response、终止 Run，作用范围依次扩大。
• 模型停了不代表工具停了：异步工具由应用执行，停止逻辑必须写在应用侧。
• Control Plane 统一发令：用 Run ID 把停止信号传到子 Agent、工具和后台任务。
• 五个执行关口互相兜底：Runtime、Tool Gateway、执行环境、身份、网络各自独立拦截。
• Fail-Closed 是底线：控制服务失效时默认拒绝，不能默认放行。
• 35 秒只指执行阶段：不含检测和决策时间，也不代表外部影响被撤销。
• 原型验证可以从统一接口开始：通过 API易 apiyi.com 一个 Key 调用多家模型，停止控制写在自己的基础设施里。

总结：停止权应该属于基础设施，而不是 Agent 自己

回到标题的问题：AI Agent 的紧急停止按钮应该放在哪一层？答案是由中央 Control Plane 统一发出停止决定，再在推理循环、工具网关、执行环境、身份凭据和网络出口这些真正产生副作用的位置分别强制执行，最后由恢复与审计层处理停止前已经发生的事情。

一套合格的停止机制应满足三点：

1. 独立性：不依赖 Agent 理解或配合停止命令，控制服务失效时 Fail-Closed。
2. 覆盖性：从模型推理一直覆盖到工具、后台任务、凭据和网络。
3. 可验证性：停止延迟可度量，每次拦截有审计记录，并定期做故障注入测试。

如果你正在搭建自己的 Agent，可以先通过 API易 apiyi.com 用统一接口接入多家模型跑通原型，再把 Run ID、Tool Gateway 和 Fail-Closed 检查逐层补上。

📚 参考资料

1. OpenAI – Control Room 官方公告：35 秒停止口径、系统架构与 Fail-Closed 设计
2. 链接：openai.com/index/control-room/

3. 说明：本文核心事实来源，2026 年 11 月 9 日发布

4. OpenAI Alignment – An agent used DNS to reach an external chatbot：9 月 DNS 事件报告

5. 链接：alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/

6. 说明：包含完整事故时间线，说明监控与停止执行之间的链路延迟

7. OpenAI API Reference – Cancel a response：Responses 取消接口说明

8. 链接：developers.openai.com/api/reference/resources/responses/methods/cancel

9. 说明：仅适用于 background 模式的 Response，取消操作幂等

10. OpenAI 文档 – Async Tool Calling：异步工具调用指南

11. 链接：developers.openai.com/api/docs/guides/async-tool-calling

12. 说明：明确异步工具由开发者应用执行和管理

13. OWASP Agent Control Standard FAQ:Guardian 模式与默认失败策略

14. 链接：owaspacs.org/docs/topics/faq/

15. 说明：决策失败与握手失败默认 proceed，需分别配置 deny 和 refuse

16. OWASP AIVSS:Agentic AI 风险评分资料

17. 链接：aivss.owasp.org

18. 说明：将缺少独立 Kill Switch 列为安全风险

19. Microsoft Learn – AI Agent 安全分层:Agent 安全责任划分

20. 链接：learn.microsoft.com
21. 说明：建议每次操作重新验证授权

作者：API易 技术团队
技术交流：欢迎在 API易 网站首页联系我们，更多接入资料可访问 docs.apiyi.com 文档中心