用户点击停止后，文档 Agent 应立即停止安排新的动作，并查询正在执行的步骤能否取消。已经提交的写入可能仍会完成，因此“取消请求已发送”与“任务已停止且没有留下改动”必须分开表达。
停止按钮背后至少有三个阶段
第一阶段是停止生成后续计划；第二阶段是取消尚未提交的队列项；第三阶段是处理已经交给远端的任务。前两项通常由本地调度器控制，第三项取决于远端接口。把进程直接杀掉只能停止客户端继续工作，并不保证远端转换或保存请求也随之结束。
MCP 的取消规范支持对进行中请求发送取消通知，同时说明接收方在请求已完成、未知或不可取消时可以忽略通知。网络延迟也可能让取消请求与正常完成交错到达。因此接入方仍需要自己的业务状态查询和结果核对。
把状态写得让人能够判断
| 状态 | 对用户的含义 |
|---|---|
| 已请求停止 | 不再安排新动作，正在核对在途任务 |
| 已停止 | 在途动作已确认结束，成果清单已保存 |
| 部分动作已完成 | 停止前产生的文件仍然存在 |
| 远端结果待确认 | 不能断言没有发生写入 |
例如批量导出二十份文件，用户在第七份时停止。前六份已完成应保留在成果清单，第七份可能仍在平台转换，其余十三份不再启动。界面可以显示这些具体数量，而不是把整批统一改成“取消成功”并隐藏已经产生的文件。
取消之后不要自动删除成果
停止执行和清理产物是两种用户意图。用户可能只是想暂停以便检查现有结果，也可能希望撤销全部变化。默认删除已完成文件，会破坏他们准备查看的材料。清理应遵循任务原有约定，并区分可撤销的临时资源与已经交付的正式成果。
若远端任务不能取消，可以继续以只读方式查询其终态，记录后来产生的文件，但不要因此启动下一项写入。若必须释放本地连接，仍应保存远端任务 ID，让后续进程能够完成对账。
把停止发生的位置列入测试
在排队时、请求发送时、远端处理时和完成响应返回时分别点击停止。检查是否有新动作越过停止边界、是否丢失已完成结果、是否错误报告无修改。尤其应验证取消通知与完成响应几乎同时到达的情况。
对企业文档流程，良好的停止体验来自明确的状态和可接续的记录。它让用户知道哪些工作已经发生，哪些已经阻止，哪些仍待确认；一个变灰的按钮或一条“已取消”提示无法替代这些事实。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。