什么是 MCP 任务（MCP Tasks）？
MCP 任务（MCP Tasks）是官方 `io.modelcontextprotocol/tasks` Extension，使 MCP Server 能为长时间运行的 Tool Call 返回持久 Task Handle，而不必阻塞原 Request。
快速了解
| 创建时间 | 2026 年成为官方 MCP Extension |
|---|---|
| 规范文档 | 官方规范 |
工作原理
什么时候应使用 Task
当工作可能超过普通 Request Timeout、必须在断线后恢复、对应已有外部 Job ID，或需要等待人工输入时适合使用 Task，例如 CI Pipeline、Deployment、Batch Processing 与 Model Training。不能只因为同步 Tool 较慢就改成 Task。Progress Notification 不能提供延期结果恢复，而 Task Handle 也不会自动让执行具备持久性。
Capability 与 Result Contract
Client 在逐请求 Capability 的 Extension Map 中加入 io.modelcontextprotocol/tasks，Server 通过 server/discover 声明同一 Identifier。当前扩展只增强 tools/call。支持扩展的 Client 必须同时接受普通 complete Result 与 resultType: "task" 的 CreateTaskResult；是否为某次调用创建 Task 由 Server 决定，未声明支持的 Request 绝不能收到 Task。
生命周期与执行中输入
Task State 包括 working、input_required、completed、failed 与 cancelled，后三个是 Terminal State。Client 调用 tasks/get 并遵守当前 pollIntervalMs。Task 进入 input_required 后，inputRequests 可携带 Elicitation 或其他受支持请求，Client 再通过 tasks/update 发送匹配的 inputResponses。Completed Task 包含原始 Tool Result，包括 isError: true 的合法结果。
持久性、身份与副作用
Server 必须在返回 Handle 前让 Task 可查询，并按声明 TTL 保留。持久存储应把 Task 绑定 Authenticated Principal、Tenant、原始 Tool 与 Argument Digest、Server Build、Policy Revision 和 Backend Job。Task ID 应不可猜测，但持有 ID 不等于获得授权。副作用仍需 Idempotency Key、Effect Record、Reconciliation，以及 Crash 后的 Unknown-outcome 处理。
取消、通知与运维
tasks/cancel 记录 Cancellation Intent，但取消是协作式的，Task 仍可能进入其他终态。Polling 是基础路径；已订阅 Client 可通过 notifications/tasks 获得完整 Task State，并按需确认。系统应限制 Polling、并发 Task、保留 State、Result Size、Input Wait Time、Retry 与 Worker Lease，并审计状态转换和最终 Effect，但不能记录 Secret 或无限制 Payload。
主要特点
- 官方可选 Extension：标识为 `io.modelcontextprotocol/tasks`，由双方协商支持
- Server-directed Polymorphism：一次 Tool Call 可返回普通 Result 或持久 Task Handle
- 轮询恢复：`tasks/get` 可在断线后读取状态与最终输出
- 执行中交互：`input_required` Task 通过 `tasks/update` 接收匹配 Response
- 协作式取消：Ack 只表示取消意图，不证明工作停止或副作用回滚
- 副作用感知持久性：Task State、授权、幂等、Retention 与 Backend Outcome 仍由 Server 负责
常见用途
- 跟踪可能超过 HTTP Timeout 的 CI Pipeline 或 Deployment
- 封装已有 Cloud Job API，并把持久 Job ID 映射为 Task
- 让长时间操作暂停等待用户审批或缺失字段
- 在 Client 或网络重启后恢复 Batch Processing 状态
- 异步处理完成后返回最终 Artifact 或结构化 Tool Result
示例
Loading code...常见问题
MCP Task 与 Progress Notification 有什么区别？
Progress Notification 描述原 Request 仍活跃时的进度；Task 是带可查询 Handle、Polling、终态结果保留、执行中输入和断线恢复的持久状态机。Server 可以同时支持二者，但只有 Progress 无法在 Response Path 丢失后恢复结果。
所有 MCP Operation 都能返回 Task 吗？
不能。当前 Tasks Extension 支持 Task-augmented `tools/call`。Client 必须在该 Request 上声明 Extension，Server 也仍可返回普通 Result。内部实现可以为未来 Request Type 预留扩展，但不能把尚未支持的 Method 写成当前能力。
tasks/cancel 能保证操作已经停止吗？
不能。Cancellation 是协作式的；Server 会确认请求并应向下游传播，但 Worker 可能已经提交工作，或下游根本不支持取消。Client 必须继续查询真实终态，高影响 Effect 还需要单独 Reconciliation。
MCP Task ID 应如何保护？
Task ID 应具有足够随机性，并把每次 Read、Update 与 Cancel 绑定 Authenticated Principal、Tenant、Tool 和 Authorization Context。不能把持有 ID 当作权限。还要限制 Retention、防止枚举、按敏感度脱敏，并禁止调用者探测他人的 Task。
什么时候应保持同步 Tool，而不创建 Task？
若工作能稳定在 Request Budget 内完成，且不需要断线恢复或执行中输入，应保持同步。Tasks 会增加 Storage、Polling、Authorization、Retention、Worker Coordination 与 Failure Recovery 成本，只有存在可度量的生命周期需求时才值得采用。