给 AI 助手加“停止”按钮，Strands 把取消信号送到执行循环

用户点了停止，聊天界面不再滚动，后台却可能仍在查 API 或跑一个长工具。给 AI 产品做停止按钮，真正需要连接的是界面意图、代理循环和工具现场。Strands Harness SDK 的官方生命周期设计，正好把这几层说明白。

先对齐身份：原 sdk-python 仓库现在已经归入 harness-sdk 主仓库。它同时包含基础 SDK 和预先组装的 Strands harness；这里讲的是 SDK 的执行与取消机制，不要求采用全部默认工具。

停止发生在什么位置

Agent Loop 文档中，agent.cancel() 设置取消信号，循环在合适的检查点观察它。最终结果带有 cancelled 停止原因，应用可以据此区分“用户取消”与“模型正常回答结束”。

在模型正在流式生成时，部分输出可能被丢弃；在工具执行前，尚未开始的调用会被跳过，并补上维持消息状态所需的错误结果；工具已经完成后，则在下一次模型调用之前停止。这些状态不能只靠前端关闭文字流来替代。

官方还支持调用者传入自己的取消信号，方便把超时或客户端断开连接接到同一机制。不同模型提供方对取消请求的支持程度不同，SDK 能停止后续流程，不代表已经发到远端的请求在任何时刻都能立即中止。

最有用的细节是工具内取消采用协作方式。Python 工具可以检查 ToolContext 的取消信号，TypeScript 工具可以读取或传递相应 AbortSignal。工具如果按批次处理数据，就可以在每一批之间检查，及时结束。

相反，一个既不检查信号、也不把信号传给下游 API 的工具，可能要等自身执行完成，代理才观察到取消。对于用户而言，这决定了“停止”之后为什么还有一段等待；对开发者而言，也明确了应该修改哪一层。

文档还单独描述 MCP 请求的取消，强调远端取消是尽力而为。无论工具类型如何，已经写入的文件、发送的消息或完成的支付动作，都不会因为取消信号自动倒退。

SDK 把停止原因显式返回，应用就可以给出与事实相符的状态：任务已取消，哪些步骤已经完成，哪些没有继续。不能把一份被截断的回答仍显示为完整报告，也不应把取消当作普通执行失败反复自动重试。

取消与 interrupt 也不同。后者是等待输入后可接续的暂停；取消则结束这次运行。产品如果希望用户稍后继续原地工作，应选择相应的持久化与暂停设计，而不是只换按钮文字。

Strands 代码采用 Apache-2.0，模型与云服务另行配置。对于需要处理长任务的助手，我会先让一个真实工具响应取消，再把它接到界面。这样，停止按钮的含义才不只是“别再显示”，而是执行系统里能够被观察和处理的一项动作。