在 AI Agent 通过 MCP（Model Context Protocol）调用搜索、文件处理、代码执行或云端任务等工具时，操作可能持续数秒甚至更久。如果客户端始终同步等待，不仅容易触发连接超时，还会影响界面响应和并发能力。为此，工程实践通常采用两类机制：通过进度通知实现“异步回调”，或借助任务句柄进行状态轮询。理解二者的边界与协作方式，是构建稳定 MCP 工具链的重要基础。🚀
一、为什么工具调用需要异步化
普通工具调用适合快速完成的操作：客户端发送请求，服务端执行工具，随后返回结果。然而，批量文档解析、模型推理、代码构建、云资源部署等任务的耗时难以预测。若一直占用原始请求，可能遇到传输层超时、网络中断、用户取消后任务仍在运行，以及故障恢复困难等问题。
异步化的核心并不是简单地“开一个线程”，而是把任务提交、执行进度、状态查询和结果获取分离。客户端提交请求后，可以继续处理其他工作；服务端则维护任务状态，并通过通知或查询接口向客户端暴露执行情况。
二、进度通知：类似回调的实时更新
MCP 的进度机制建立在通知消息之上。客户端如果希望接收进度，可以在请求元数据中携带唯一的 progressToken。服务端执行过程中，使用同一个令牌发送 notifications/progress 通知，其中可包含当前进度、总量和人类可读的说明。具体约束可参考 MCP Progress 官方文档。
这种机制常被理解为“异步回调”，但它并不是让服务端随意调用客户端提供的 HTTP 地址，而是在现有 MCP 会话或传输通道中发送通知。客户端需要提前注册通知处理器，再根据 progressToken 将消息路由到对应请求。📨
- progressToken：用于关联请求和进度通知，在活跃请求范围内必须保持唯一。
- progress：当前完成量，应随通知递增，避免界面出现进度倒退。
- total：可选的总工作量；任务规模未知时可以省略。
- message：可选说明，例如“正在解析第 8 个文件”。
需要注意，客户端不能把进度通知当成必然存在的可靠事件流。服务端可以选择不发送通知，也可以控制通知频率。因此，进度消息适合改善实时体验，却不应成为判断任务最终成功与否的唯一依据。
三、任务句柄与状态轮询
对于持续时间较长、可能跨连接执行的操作，更稳妥的做法是让服务端立即返回一个持久化任务标识。客户端保存 taskId，随后周期性调用状态查询接口，直到任务进入完成、失败或取消等终态。MCP Tasks 扩展采用的正是这种思路：长任务返回可持久查询的任务句柄，由客户端主动驱动后续交互，详见 MCP Tasks 扩展说明。
典型流程可以概括为：
- 客户端声明自己支持任务扩展，并发起工具调用。
- 服务端创建任务，将初始状态和 taskId 返回给客户端。
- 后台 Worker 执行实际操作，并持续更新任务存储。
- 客户端使用 taskId 查询状态，必要时提交用户输入或审批结果。
- 任务进入终态后，客户端读取最终结果或结构化错误信息。
轮询的优势是恢复能力强。即使连接临时中断，只要任务状态已经持久化，客户端重连后仍可凭 taskId 继续查询。其不足是会产生额外请求，并且状态展示存在一定延迟。
四、如何设计合理的轮询策略
固定每秒查询一次虽然简单，却可能在任务量增加后形成明显压力。更推荐采用退避策略：任务刚提交时可以较快查询，连续得到“仍在执行”后逐步延长间隔；一旦出现状态变化，再适当缩短等待时间。⏱️
服务端还可以返回建议的下次查询时间，帮助客户端避免无效请求。客户端应为轮询设置最长持续时间，但“客户端停止等待”不应被直接等同于“服务端任务失败”。如果业务允许，应另行发送取消请求，并查询任务是否真正进入取消终态。
实用原则：实时展示依靠通知，可靠恢复依靠持久化状态，最终结果必须以终态响应或任务查询结果为准。
五、回调与轮询如何配合
在生产系统中，二者通常不是互相替代，而是组合使用。工具调用开始后，客户端通过 progressToken 接收即时进度，使用户能够看到当前阶段；同时保存 taskId，作为断线恢复、状态校验和结果获取的可靠入口。如果通知丢失，客户端仍能通过轮询获得最终状态；如果轮询间隔较长，通知又能提升交互流畅度。✅
客户端内部可以建立“taskId 对应业务任务、progressToken 对应当前请求通道”的映射。收到通知时更新临时进度，收到任务查询结果时校正权威状态。任务进入 completed、failed 或 cancelled 后，应立即停止进度处理和轮询，释放定时器、订阅关系及本地缓存。
六、状态机与幂等性设计
异步任务应使用明确的状态机，例如 queued、working、input_required、completed、failed 和 cancelled。状态转换必须受到约束，不能让已完成任务重新回到执行中。若任务等待用户确认或补充参数，应使用明确的“需要输入”状态，而不是长期停留在 working，避免客户端误判为卡死。
网络重试还可能导致同一个工具调用被重复提交，因此服务端应支持幂等控制。客户端可提供请求唯一标识，服务端发现重复提交时返回原有 taskId，而不是再次执行写入、扣费或资源创建操作。对于无法天然幂等的工具，更要记录执行步骤和外部系统返回的作业编号。
七、错误处理与安全注意事项
失败状态应区分可重试错误、参数错误、权限错误和不可恢复错误，并提供机器可识别的错误代码。日志中建议记录 requestId、taskId、progressToken、工具名称和状态转换时间，但不要写入访问令牌、用户隐私或完整敏感参数。🔐
服务端必须校验任务归属，防止用户通过猜测 taskId 查询其他人的任务。任务结果和日志还要设置合理的保留期限。对于通知频率与轮询接口，应配置限流和并发保护，避免高频更新造成消息洪泛或存储热点。
总结
MCP 工具调用中的异步机制可以分为两个层面：进度通知负责在活跃会话中提供及时反馈，任务句柄与状态轮询负责跨连接保存执行事实。成熟的实现应将两者结合，并补充状态机、退避轮询、幂等控制、取消语义、权限校验和可观测日志。这样既能让 AI 应用保持顺畅交互，也能确保长耗时工具在断线、重试和并发场景下仍然可靠运行。
