停止本地界面不等于取消远程A2A任务

点了 Stop，远端 AI 任务却还在跑，问题可能出在「停止」的边界上。原文的核心结论是：桌面端结束查看、断开 SSE 流，并不等于取消远端 A2A 任务；要停止远端工作，必须携带任务引用发送 CancelTask，再读取状态确认结果。

这对接入远端 Agent 的前端和全栈开发者很实用。一个停止按钮，背后至少涉及界面、连接和任务三个对象。分不清它们，用户以为工作结束了，服务器却可能继续消耗资源、持有锁、生成没人接收的产物。

为什么关掉进度流，任务还在执行

远端 A2A 任务由 Agent 执行，桌面客户端通过 SSE（Server-Sent Events，服务端事件推送）查看进度。客户端是观察者，远端 Agent 才是执行者。

本地 Stop 结束桌面视图和 SSE 流，只改变客户端这一侧的行为。连接关闭没有携带取消意图，远端也就没有收到停止任务的指令。

停止接收进度，不等于停止产生进度的工作。

原文用长时间分析任务举例：用户关闭视图后，任务继续运行，可能占用资源、持有锁、写入产物。几个小时后，客户端早已离开，远端工作仍未结束。这是作者用来解释风险的情境，并非附有日志或统计结果的实测案例。

原文提到 Powerduck 将本地停止和远端取消分开处理，但没有提供具体界面、请求格式或实现代码。能直接拿走的是这个边界，不能据此推断它的完整取消机制。

取消请求发出去，还要确认什么

作者给出的处理顺序很明确：

1. 如果不再需要进度，使用本地 Stop 结束 SSE 视图。
2. 查询任务状态，检查任务是否仍在运行。
3. 携带任务引用发送 CancelTask 请求。
4. 再次确认任务进入 cancelled 或其他终态。
5. 记录实际结果，不把请求发出当成取消完成。

这里最容易漏掉的是最后两步。

取消和正常完成可能同时发生：客户端发送 CancelTask 时，任务也可能恰好完成。因此，「进入终态」只能证明任务已经结束；要判断是否由取消导致，还得看具体状态。任务正常完成，就不能向用户宣称取消成功。

请求表达的是取消意图，状态反映的才是实际结果。

原文没有给出 CancelTask 的参数结构、状态查询 API、轮询间隔或取消失败的处理方式。接入时需要按所用实现补齐这些细节，不能把这份步骤直接当作可运行的接口文档。

作者还建议为任务设定预期时长，超过阈值就调查。这个建议针对的是无人关注的长任务：SSE 能让进度可见，却不能保证任务有人持续照看。原文没有提供统一超时值，也没有说达到阈值就应该自动取消。

任务取消了，已经发生的修改怎么办

CancelTask 用于阻止后续工作，不负责撤销此前完成的操作。任务已经写入记录、发送消息或改变状态，取消请求本身不会把这些操作还原。

所以，检查到 cancelled 还不能立刻结束处理。作者要求继续检查任务留下的产物和记录，确认是否有写到一半的数据，以及下游是否仍在等待一个不会再到来的结果。

这一步把关注点从「执行是否结束」推进到「业务是否收尾」。例如，任务结束前留下待处理消息，依赖它的服务可能仍然卡在等待状态。取消成功和依赖清理完成，是两件需要分别确认的事。

我的判断

这篇文章说得最有用的地方，是把停止查看、取消执行、处理遗留影响拆开了。对远端 Agent 客户端而言，这比给所有动作统一贴上「停止」标签更准确，也更方便排查问题。

但它是一份操作原则，作者没有给出对照数据、取消耗时或成功率，不能把它当成经过性能验证的方案。远端收到 CancelTask 后如何中断执行、哪些阶段允许取消、请求失败后如何处理，原文都没说清。

和仅关闭 SSE 相比，显式取消能向远端传达意图；和事务回滚或业务补偿相比，它又不负责恢复此前状态。应用是否需要补偿，要由任务实际产生的副作用决定，不能指望一个取消接口包办。

能拿来做什么

• 在远端 Agent 的前端界面中，明确区分「停止查看」和「取消任务」；发送取消请求后，先显示正在取消，再根据查询到的最终状态更新结果。
• 在 Node 接入层保存任务引用，确保页面关闭进度视图后，仍有依据查询任务和发送 CancelTask，并记录任务最终是取消还是正常完成。
• 为长时间运行的 AI 编程或分析任务设定预期时长，超时后检查状态；确认取消后，再核对生成文件、写入记录和下游等待是否需要处理。