MCP Tasks 的异步结果怎么收口：任务句柄、轮询状态与恢复条件

调用 MCP 工具时，真正棘手的往往不是把请求发出去，而是请求已经交给服务器、客户端却在中途断线了：下次上线该查什么，什么时候可以拿结果，哪些状态不能重试？MCP Tasks 的答案是一个可持久化的任务句柄，但句柄本身不是完成通知，客户端仍要按状态把结果收口。

为什么 CreateTaskResult 不是客户端强制的开关

在 2026-07-28 规范中，Tasks 被放到 `io.modelcontextprotocol/tasks` 扩展里。客户端需要在每次相关请求的能力声明中表明支持，服务器则在自己的能力中公布支持范围。这里有一个容易误判的点：客户端声明能力，只表示“我能处理任务返回”，并不表示“请每次都返回任务”。是否创建任务由服务器针对具体请求决定。

{
  "params": {
    "_meta": {
      "io.modelcontextprotocol/clientCapabilities": {
        "extensions": {
          "io.modelcontextprotocol/tasks": {}
        }
      }
    }
  }
}

因此调用方要先判断返回形状：普通 `CallToolResult` 直接处理；如果 `resultType` 是 `task`，就保存句柄并进入轮询分支。不要把“支持 Tasks”写成一个强制异步参数，也不要假定所有工具都支持它。

用 taskId 和 tasks/get 取回稳定状态

服务器返回的 task handle 至少围绕 `taskId`、当前 `status` 和保留语义组织。客户端第一件事是把 `taskId` 写入自己的持久化记录，随后调用 `tasks/get` 查询同一个任务，而不是继续占用原来的长连接。响应中的 `pollIntervalMs` 是服务端建议的查询间隔；存在时应优先遵守，避免用固定的高频定时器压垮服务。

一个实用的本地记录可以只保留 `taskId`、最近状态、最后更新时间和业务关联号。恢复时先查一次；如果已经是终态，就停止定时任务，避免“结果拿到了还在轮询”的尾巴。

把 input_required 与终态结果分开处理

`working` 只说明任务仍在处理，不能当成失败；`input_required` 则意味着服务器把继续处理所需的请求放进 `inputRequests`，客户端应展示或转交这些请求，再通过 `tasks/update` 提交对应的 `inputResponses`。这条分支不要偷偷重发原工具调用，否则可能创建第二个任务。

真正的收口点是终态：`completed` 带有原请求的 `result`，`failed` 带有协议层错误，`cancelled` 表示取消意图已被任务状态接受，但取消是协作式的，底层工作不一定在确认返回的瞬间消失。终态一旦到达，任务不再转到其他状态。

{
  "method": "tasks/get",
  "params": {"taskId": "task_7f2a"}
}

// 客户端分支
// working          -> 按 pollIntervalMs 再查
// input_required   -> 读取 inputRequests，再发 tasks/update
// completed        -> 消费 result，并停止轮询
// failed/cancelled -> 记录原因或取消结果，并停止轮询

用 TTL、pollIntervalMs 和本地持久化完成恢复

断线恢复不需要猜服务器是否还记得任务，前提是客户端没有丢掉 `taskId`。重启后先读取本地任务记录，再发 `tasks/get`；返回 `completed` 就取结果，返回 `failed` 或 `cancelled` 就进入对应记录，仍为 `working` 则按照新的 `pollIntervalMs` 继续。若 `ttlMs` 已经耗尽或任务无法再查询，应把它标为“句柄失效”，由业务决定是否重新提交，而不是无条件重复调用。

这也解释了为什么 Tasks 适合长耗时工具、批处理和外部作业接口：它把“请求已接收”和“结果可取”拆开，但没有替客户端决定重试策略。生产代码至少要记录 taskId、状态变化、最后一次查询时间和终态原因；重试则要另做幂等键，不能把轮询失败直接当成业务失败。

相关问题

客户端声明支持后，服务器一定会返回 task handle 吗？

不一定。能力声明只是协商结果，服务器会按请求和工具支持情况决定返回普通结果还是任务句柄。

任务进入 input_required 时可以直接调用 tasks/result 吗？

不要把它当成常规取数路径。先读取 inputRequests，通过 tasks/update 补齐输入；只有任务进入 completed 后，result 才是可消费的最终结果。

tasks/cancel 返回成功就代表底层工作停止了吗？

不代表。取消是协作式的，服务端只确认收到取消意图，最终状态仍可能受并发完成时机影响。

核对实现时，优先看服务器是否声明 `io.modelcontextprotocol/tasks`、是否返回稳定的 `taskId`、是否提供合理的轮询间隔，以及客户端是否能在重启后恢复同一任务。官方扩展仓库提供了 2026-07-28 稳定快照，同时保留开发中的草案；接入前还要确认具体 SDK 与服务端的支持范围。