核心 GUIDE
Interrupt / Cancel Long-running Agent
Long-running Agent 必须有显式 Interrupt 与 Cancellation Semantic，才能让 User/Operator 安全停止任务，区分“已请求停止”与“已经停止”，并在不破坏 Side Effect 的前提下恢复。
核心心智模型
Cancellation 是 State Transition，不只是 UI Button。Runtime 必须把请求传播到 Active Work，判断哪些 Operation 可取消，处理或补偿 In-flight Side Effect，持久化 Terminal/Resumable Checkpoint，并报告最终状态。
为什么重要
运行数分钟甚至数小时的 Agent 必然会遇到 User Intent 改变、Dependency 变化与 Deployment Window 结束。如果没有明确 Cancellation，所谓“Stop”可能只是 UI 消失，Tool 仍在后台执行。显式 Semantic 可以避免 Orphaned Work、重复 Recovery，以及高后果 Action 到底有没有完成的不确定性。
01
把 Cancellation 建模为 Cooperative Runtime Control
分别表示 Cancel-requested、Cancelling 与 Cancelled State。向可取消 Work 传播 Cancellation Token 或等价 Signal，在 Irreversible Operation 前后定义 Safe Point，并让不可取消 Side Effect 具备 Idempotency 或 Compensation。持久化足够 State，以便 Resume 或解释停止前完成了什么；Dependency 不响应时，Cancellation 本身也要有 Timeout。
02
示例：外部 Payment Call 期间收到 Stop Request
Agent 正在等待 Payment Provider 时 User 点击 Cancel。Runtime 记录 Cancel-requested，但不会假设 Payment 已停止。它等待 Provider Result，用 Idempotency Key 对账，然后要么记录 Payment 已发生并结束 Workflow，要么确认没有 Side Effect 后再进入 Cancelled State。
常见失败模式
- 把 UI 消失当成 Background Work 已停止的证明。
- 在 Irreversible Action 中途取消，却不做 Reconciliation。
- Cancellation 时丢弃 State，导致 Operator 无法判断哪些步骤已完成。
工程启发
- 让 Cancellation State 可观察、可持久化。
- 围绕 Irreversible Side Effect 定义 Safe Point 与 Reconciliation。
- Long-running Work 的 Cancel 与 Resume Semantic 应一起设计。
关键结论
- 01Cancellation 是 User Intent 与 Runtime State 之间的 Protocol。
- 02Stop Requested 与 Stopped 是不同 State。
- 03Irreversible Work 必须完成 Reconciliation 后，才能宣称 Cancellation 完成。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。