停止、恢复和人工接管不是一个按钮
一句话收获：执行可以自动，停止、残留副作用和责任必须可见。
这个场景在解决什么问题
这个场景讲的是"停止"这件事为什么不是一个按钮就能搞定的。目标（goal）是验证三样：停止信号的传播、停止后的收尾、以及"可独立接管"。观察点（observation）是：从用户点下"停止"，到后台任务真正停止，逐层回放这一整条链。
为什么值得单独学？因为很多人以为"点个停止按钮就停了"，结果后台还在跑、副作用还在发生。这个场景告诉你：执行可以自动化，但"停止、残留副作用、责任"这三样必须可见；停止是一条链，不是一次点击。
先理清这条判断链（文字版）
这个场景的四步讲的是"停止"从入口到接管收尾的完整传播，本质是"提交停止 → 取消传播 → 保存检查点与残留 → 接管者独立继续"：
- 先提交停止请求——界面记录停止意图，任务进入 stopping 状态。
- 再传播取消——Loop 不再产生新动作，模型流和可取消工具收到停止信号。
- 接着保存检查点与残留影响——确认外部状态、保存检查点、记录不可逆动作。
- 最后让接管者独立继续——接管包提供目标、状态、证据、风险、剩余选项和禁止动作。
这条链的核心逻辑是：按钮只是入口，真正的停止要贯穿调用链，停止后还要收尾，收尾后还要能交给人独立接手。
逐层详解
第 1 步：提交停止请求
原文：界面记录停止意图，任务进入 stopping。
白话：用户在界面上点了"停止"，界面只负责记录"这个人想停止"这个意图，然后把任务标记为 stopping（正在停止中）。注意：这只是停止链的第一步，不是结束。
类比：像你在跑步机上按了"停止"，按下去只是发出了停止信号，跑带还在慢慢减速，不是瞬间停住。
举例：用户点了退款任务的"停止"按钮，界面记录：停止请求 = 存在、操作者 = "用户 A"、目标任务 = "订单退款任务"，任务状态变为 stopping。
为什么重要：按钮只是停止链的入口。也就是说，按钮不是终点，它只是启动"停止"这条链的入口。
怎么验证（证据点）：
- 停止请求：停止请求被记录。
- 操作者：谁发起的停止被记录。
- 目标任务：停止的是哪个任务被记录。
别踩的坑（边界）：按钮变灰不证明后台已停止。意思是，按钮灰了、看起来"停了"，不代表后台任务真的已经停止。
落地检查：继续观察控制器和工具。也就是说，落地时点了停止后，还要继续观察控制器和工具，确认它们真的停了。
第 2 步：取消传播
原文：Loop 不再产生新动作，模型流和可取消工具收到信号。
白话：停止信号要一路传播下去：Loop 不再产生新的动作、模型流（正在生成的输出）收到取消信号、那些"可取消"的工具也收到信号。停止必须贯穿整条调用链。
类比：像消防演习里的撤离指令——不能只通知一楼，要一层层广播到所有人、所有部门，整条链都收到才算数。
举例：停止信号发出后，Loop 停止提出新动作，正在跑的模型生成被取消，正在执行的"可取消"查询工具收到信号停止；那些"不可取消"的写入操作则被单独列出来。
为什么重要：停止必须贯穿调用链。也就是说，停止不能只停在一层，要沿着调用链一路传下去，每个环节都收到。
怎么验证（证据点）：
- 新行动停止：不再产生新动作。
- 取消已传递：取消信号已传给模型流和工具。
- 不可取消项列出：无法取消的动作被明确列出。
别踩的坑（边界）：取消请求提交不等于停止已确认。意思是，你把"取消请求"发出去了，不等于"停止"已经确认完成——中间还有一段收束过程。
落地检查：等待外部状态收束。也就是说，落地时发出取消后，要等待外部状态真正收束，而不是急着宣布"已停止"。
第 3 步：保存检查点与残留影响
原文：系统确认外部状态、保存检查点并记录不可逆动作。
白话：停止后还要做"最小收尾"——确认外部状态（现实到底变成什么样了）、保存检查点（存档）、记录那些"不可逆动作"（已经发生、撤销不了的事）。不能一停了之。
类比：像手术中途喊停，不是扭头就走，而是要记录"已经切到哪了、缝了几针、用了什么药"，这些信息必须留下来。
举例：停止退款任务后，系统确认外部订单状态 = "退款已发起、未完成"、保存检查点、并记录"不可逆动作 = 已扣款一次"作为残留影响。
为什么重要：停止后仍需最小收尾。也就是说，停止不等于什么都不用做，还要做一套最小的收尾动作，把现场保护好。
怎么验证（证据点）：
- 检查点保存：检查点被保存。
- 外部状态确认：外部状态被确认。
- 副作用清单：残留副作用被列成清单。
别踩的坑（边界）：隐藏残留影响会制造假停止。意思是，如果把"已经发生的副作用"藏起来不报，就会制造"看起来停了、其实还留着隐患"的假象。
落地检查：如实形成接管材料。也就是说，落地时要把这些残留影响如实写进接管材料，交给下一个接手的人。
第 4 步：接管者独立继续
原文：接管包提供目标、状态、证据、风险、剩余选项和禁止动作。
白话：最后生成一个"接管包"，把六样东西都装进去：目标、当前状态、已有证据、风险、剩余选项、禁止动作。这样接手的人不用重读全部聊天记录，就能独立做判断。
类比：像交接班时的"交接清单"——夜班医生不用从头看病人病历，看交接单就能知道"病人什么情况、用了什么药、接下来怎么处理"。
举例：退款任务停止后，接管包写明：目标 = "订单 123 退款"、状态 = "已扣款未退"、证据 = "扣款回执 + 超时记录"、风险 = "可能重复退款"、剩余选项 = "人工查账 / 补退款"、禁止动作 = "禁止再次自动发起退款"。
为什么重要：人无需重读全部聊天就能判断。也就是说，接管包的意义是让接手的人"不依赖你、不重读全部记录"，也能独立做出判断。
怎么验证（证据点）：
- 接管包完整：六要素齐全。
- 决定权明确：谁有权决定被明确。
- 后续动作可追踪：后续动作能被追踪。
别踩的坑（边界）：一句"请联系管理员"不构成接管。意思是，只甩一句"请联系管理员"，不叫真正的接管——那等于没给任何可用信息。
落地检查：接管能力需要实际演练。也就是说，落地时"接管"这套能力不能只停留在文档上，要真正演练一遍，确认人真能独立接手。
落地可行性小结
本场景涉及的技术栈和落地要点：停止请求、stopping 状态、取消传播（cancellation propagation）、检查点、残留副作用清单、接管包（handoff package）。
真实落地时要注意：停止要建模成"多阶段状态机"（stopping → 收尾 → 已停止），而不是一个布尔开关；取消信号要能贯穿 Loop、模型流、工具三层；停止后要做最小收尾（确认外部状态 + 存检查点 + 列残留副作用）；接管包要含目标/状态/证据/风险/剩余选项/禁止动作六要素。常见坑是：把"按钮变灰"当成"后台已停"；以及停止后不报残留副作用，制造假停止；还有把"请联系管理员"这种空话当接管。
回顾
- 停止是一条链、一个多阶段过程，不是一个按钮。
- 按钮只是入口，取消信号要贯穿 Loop、模型流、工具三层。
- 停止后仍需最小收尾：确认外部状态、存检查点、列残留副作用。
- 隐藏残留影响会制造"假停止"。
- 接管包要含目标/状态/证据/风险/剩余选项/禁止动作，"请联系管理员"不是接管。