05.3 · 中断、停止与恢复：怎样把执行真正停下来 · Agent 教程 V2

停止先禁止当前Run继续发起工作，再取消已经开始的操作并确认退出；页面不再输出，不能证明模型和工具已经停止。

本课的位置：本课仍在Session/Run状态管理层，停止信号从这里约束主链，并传播到模型、工具和执行环境。

用户让Agent调查接口异常。运行中，模型还在生成，一份远端查询尚未返回，处理日志的脚本也没有结束。用户发现选错了时间范围，点了“停止”，准备重新提问。

按钮立刻变成“已停止”很容易，难的是这三项工作到底有没有停：模型可能继续计费，脚本可能继续占CPU，远端查询稍后还会返回结果。下面沿着这个教学场景，分别处理停止受理、在途操作和后续恢复。

点击停止，哪些马上失效，哪些还需要等？

先把界面与执行分开。页面可以立即停止显示文字；服务端受理停止后，队列、重试和下一轮模型调用就应失去启动资格。已经发出的工作则必须逐项处理。

例如某模型服务把后台生成与输出流分开，关闭页面订阅只会让用户看不到文字，生成仍在继续。此时必须按那次生成的远端ID取消；不能把“连接已断开”当作“推理已停止”。不同服务的契约不同，执行适配层需要明确区分。

假设系统只保存“run-1正在运行”，没有记录它发过哪些请求。用户点停止时，服务端只能改变Run状态，却不知道该向谁取消。

因此，每次启动模型、查询或脚本之前，都要登记一条操作记录：它属于哪个Run、使用哪个控制版本、操作类型、当前执行者，以及怎样取消。远端ID收到后再补充进去；脚本则由运行器掌握其完整执行单元。

这里有个常见时差：请求已经发出，但远端ID还没返回。停止不能只说“没ID，跳过”，应先保存取消待办。ID到达后关联原操作，立即补发取消；执行进程若中途退出，待办也要能被其他工作者接手。

取消接口返回“已受理”，仍不等于退出。若收到503或查询超时，状态应是未知，保留对应并发或预算预留并有限重试；若对方已经完成，记录完成事实，不能把它改写成“从未发生”。

以OpenAI为例，后台模式支持按响应ID取消，同步响应则通过终止连接处理，不能混用两种方式。应用使用什么服务，就按该服务的取消与状态契约核对。自建推理还需中止排队和生成、清理占用；网关只停止转发文字不够。已经产生的费用也不会因本地状态改变而消失。

收到停止请求后，服务端先把控制版本从1推进到2，保存停止原因与取消待办，再返回“停止已受理”。调度器、模型入口、工具入口和结果入口随后都拒绝旧版本。

这一步解决“还能不能继续做”，取消传播解决“已经做起来的工作怎样退出”。两者不能互相替代。只改状态会漏掉在途资源；只发取消而不关闭入口，则可能刚取消完又开始下一轮。

每个Run使用独立取消信号。当前任务停止，不应让同一Session里另一个库存任务跟着退出。收到信号的任务还需完成清理，运行器要等到它真正结束；“用户不用继续等了”与“后台工作已结束”应分别记录。

若日志脚本没有响应正常终止，运行器可以先给清理宽限期，再按策略强制回收。确认对象要覆盖它派生的子进程或所属容器，不能仅凭父进程退出释放全部额度。第12课会继续解释这种执行边界。

停止不会清空网络上已经在途的消息。此时需要按内容分别处理：

数据库受理与远端发送无法天然组成同一次事务。某操作刚获准发出，恰好与停止交错，就应按可能在途追踪：发送前再检查，随后继续接收ID与结果。目标是没有未获许可的新工作，也没有被遗忘的交错操作，不能承诺点击之后绝无网络数据包。

资源均确认退出后，可以结束Run并释放对应预留。若本地已停止或隔离、后续入口已关闭，但远端状态还未知，可以先结束用户交互，把持续核对责任交接给后台；界面应明确“执行已终止，仍有远端操作待确认”，不能显示“全部推理已停止”。

等所有远端确认再结束，状态直观，但外部故障可能让用户久等；先结束交互、后台对账响应更快，却需要可靠待办、巡检和配额账本。两种方案都不能把未知当零消耗，再无限接新任务。

用户重新提交正确范围时，已取消的终态Run保持结束，创建关联的新Run，使用新的取消信号和产物位置。Session继续保留两次要求、停止原因与已有结果，不能删聊天记录来代替清理资源。

若产品支持暂停后续做，恢复时读取检查点、操作记录和已确认产物：已经完成的结果核对后复用，未启动的步骤可以继续，结果未知的外部动作先查。模型原输出取不回来而允许重算时，记录新尝试，不能冒充恢复原输出。这样，停止、重做和恢复才各有明确边界。