01为什么阻塞不够用Why blocking is not enough

最朴素的做法是:工具调用发出去,连接一直挂着,直到活干完再返回结果。对一个 200 毫秒的数据库查询,这完全没问题。问题出在那些「不是立刻返回」的操作上——CI 流水线、批量数据处理、人工审批。官方文档给出了四个阻塞解决不了的问题,每一个都对应一类真实故障:

The naive approach is simple: fire the tool call, hold the connection open, return the result when the work finishes. For a 200 ms database query that is entirely fine. The trouble starts with operations that do not return immediately — CI pipelines, batch processing, human approvals. The official docs list four problems blocking cannot solve, and each maps to a real class of failure:

还有第五条,是设计上最容易被忽略但工程上最省事的一条:是否转任务由服务端逐请求决定。客户端只需要在能力里声明一次「我支持 Tasks」,然后准备好接收两种形状的结果即可——不需要给每个工具做预热,也不需要在每次请求上打标记。

There is a fifth property, easy to overlook in the design but the one that saves the most engineering effort: the server decides per request whether to create a task. The client opts in once through the extension capability and then handles whichever result shape arrives — no per-tool warmup, no per-request flag.

02Tasks 是什么:六步机制What Tasks are: the six-step mechanism

Tasks 不是一套新的请求方法,而是对标准请求流程的一层扩展。当服务端判断某个请求会跑很久,它返回的不是最终结果,而是一个任务句柄;客户端随后轮询直到终态。整个过程分六步:

Tasks are not a new family of request methods; they are an extension of the standard request flow. When the server decides a request will be long-running, it returns a task handle instead of the final result, and the client polls until a terminal state. The whole process has six steps:

1. 能力协商。客户端在每个请求的能力字段里带上 io.modelcontextprotocol/tasks;服务端在自己的 server/discover 能力里声明同一个扩展。
2. 任务创建。服务端返回 CreateTaskResult(以 resultType: "task" 标识),内含 taskId、初始状态、TTL 和建议轮询间隔。任务必须在响应发出之前就已持久化创建。
3. 轮询。客户端拿 taskId 调 tasks/get,响应携带当前状态;终态时携带最终结果或错误。
4. 中途输入。任务转入 input_required 时,tasks/get 的响应里会带一个 inputRequests 映射(elicitation 或其它服务端请求),客户端通过 tasks/update 逐一回填。
5. 完成。状态到 completed 时,result 字段里就是「如果同步执行本来会返回的东西」;状态是 failed 时,error 字段里是 JSON-RPC 错误。
6. 取消。客户端随时可以发 tasks/cancel。取消是协作式的——服务端确认收到意图,但没有义务真的停下来。

1. Capability negotiation. The client includes io.modelcontextprotocol/tasks in its per-request capabilities; the server advertises the same extension in its own server/discover capabilities.
2. Task creation. The server returns a CreateTaskResult (identified by resultType: "task") containing a taskId, an initial status, a TTL, and a suggested polling interval. The task must be durably created before the response is sent.
3. Polling. The client calls tasks/get with the taskId. The response carries the current status and, for terminal states, the final result or error.
4. Mid-flight input. If the task moves to input_required, the tasks/get response includes an inputRequests map with elicitations or other server requests. The client fulfills these via tasks/update.
5. Completion. When the status reaches completed, the result field contains what the original request would have returned synchronously. If the status is failed, the error field carries the JSON-RPC error.
6. Cancellation. The client can send tasks/cancel at any time. Cancellation is cooperative — the server acknowledges the intent but is not obligated to stop the work.

来源:MCP Tasks · How Tasks work

Source: MCP Tasks · How Tasks work

03任务生命周期与状态机Task lifecycle and state machine

五个状态,三个是终态。终态的定义很硬:一旦到达,任务状态就不再改变。这条约束是客户端能安全停止轮询、安全落盘归档的基础。

Five statuses, three of them terminal. The definition of terminal is strict: once reached, the task's state does not change. That constraint is what lets a client safely stop polling and safely archive the outcome.

04线上长什么样:实际报文On the wire: actual messages

先看客户端怎么声明支持。注意它放在 每个请求的 _meta 里,不是一次性握手——这是 2026-07-28 无状态核心带来的直接后果:initialize/initialized 握手和 Mcp-Session-Id 头都已被移除,每个请求必须自描述。

Start with how the client declares support. Note that it lives in each request's _meta, not in a one-time handshake — a direct consequence of the 2026-07-28 stateless core: the initialize/initialized exchange and the Mcp-Session-Id header are both gone, so every request must be self-describing.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "run_ci_pipeline",
    "arguments": { "branch": "main" },
    "_meta": {
      "io.modelcontextprotocol/clientCapabilities": {
        "extensions": {
          "io.modelcontextprotocol/tasks": {}
        }
      }
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "run_ci_pipeline",
    "arguments": { "branch": "main" },
    "_meta": {
      "io.modelcontextprotocol/clientCapabilities": {
        "extensions": {
          "io.modelcontextprotocol/tasks": {}
        }
      }
    }
  }
}

服务端在 server/discover 的能力里声明同一个扩展:

The server advertises the same extension in its server/discover capabilities:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "capabilities": {
      "extensions": {
        "io.modelcontextprotocol/tasks": {}
      }
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "capabilities": {
      "extensions": {
        "io.modelcontextprotocol/tasks": {}
      }
    }
  }
}

于是同一个 tools/call 可能回来两种形状之一。这是客户端最需要适配的地方——结果是多态的:

As a result, the same tools/call can come back in one of two shapes. This is the main thing a client has to adapt to — results are polymorphic:

轮询与回填的骨架代码(伪代码,任何语言 SDK 思路一致):

The skeleton of polling and answering (pseudocode; the shape is the same in every SDK):

result = call_tool("run_ci_pipeline", {branch: "main"})

if result.resultType != "task":
    return result                      # 形状 A:直接就是答案

task_id = result.taskId
persist(task_id)                       # 关键:落盘,进程挂了还能续
interval = result.pollIntervalMs

while True:
    task = rpc("tasks/get", {taskId: task_id})

    if task.status == "input_required":
        answers = {}
        for key, req in task.inputRequests.items():
            answers[key] = ask_user_or_model(req)
        rpc("tasks/update", {taskId: task_id, inputResponses: answers})
        continue                       # 回填后继续轮询

    if task.status == "completed":  return task.result
    if task.status == "failed":     raise TaskError(task.error)
    if task.status == "cancelled":  return None

    sleep(interval)                    # 尊重服务端建议的间隔

result = call_tool("run_ci_pipeline", {branch: "main"})

if result.resultType != "task":
    return result                      # Shape A: this is already the answer

task_id = result.taskId
persist(task_id)                       # Key step: durable, so a crash can resume
interval = result.pollIntervalMs

while True:
    task = rpc("tasks/get", {taskId: task_id})

    if task.status == "input_required":
        answers = {}
        for key, req in task.inputRequests.items():
            answers[key] = ask_user_or_model(req)
        rpc("tasks/update", {taskId: task_id, inputResponses: answers})
        continue                       # keep polling after answering

    if task.status == "completed":  return task.result
    if task.status == "failed":     raise TaskError(task.error)
    if task.status == "cancelled":  return None

    sleep(interval)                    # respect the server's suggested interval

来源:MCP Tasks · Implementation guide · 2026-07-28 规范:无握手无会话

Sources: MCP Tasks · Implementation guide · The 2026-07-28 Specification: no handshake or sessions

05怎么实现:客户端与服务端清单How to implement: client and server checklists

客户端五步

Five steps for a client

1. 声明支持——把扩展写进每个请求的 _meta 能力字段。
2. 处理多态结果——发 tools/call 这类支持的请求时,准备好接收标准结果或 CreateTaskResult。
3. 轮询到终态——用 tasks/get,尊重 pollIntervalMs,直到 completed / failed / cancelled。
4. 处理输入请求——状态是 input_required 时读 inputRequests,把请求呈现给用户或模型,用 tasks/update 提交回应。
5. 持久化 task ID——落盘保存,这样客户端崩溃或重启后能恢复轮询。这一步是 Tasks 全部价值的兑现点,漏了等于白做。

1. Declare support — put the extension in the capabilities _meta of every request.
2. Handle polymorphic results — when issuing a supported request such as tools/call, be ready for either the standard result or a CreateTaskResult.
3. Poll to a terminal state — call tasks/get, respect pollIntervalMs, and continue until completed / failed / cancelled.
4. Handle input requests — on input_required, read inputRequests, present them to the user or the model, and submit answers via tasks/update.
5. Persist task IDs — store them durably so polling can resume after a client crash or restart. This is where the whole value of Tasks is cashed in; skip it and you have gained nothing.

服务端六步

Six steps for a server

1. 声明支持——把扩展写进 server/discover 的 capabilities。
2. 先检查客户端能力——返回 CreateTaskResult 之前,必须确认客户端在本次请求里声明了该扩展。永远不要给没声明支持的客户端返回任务。
3. 返回 CreateTaskResult——resultType: "task",带唯一 taskId、初始状态、ttlMs、pollIntervalMs。任务必须在响应发出之前完成持久化创建。
4. 实现 tasks/get——每次轮询返回当前状态;终态时带上 result(completed)或 error(failed)。
5. 实现 tasks/update——接受与未决 inputRequests 对应的 inputResponses,用空结果确认;对未知的或已满足的 key 直接忽略。
6. 实现 tasks/cancel——用空结果确认。尽量执行,但要记住取消是协作式的,任务仍可能落到非 cancelled 的终态。

1. Advertise support — include the extension in your server/discover capabilities.
2. Check client capabilities first — before returning a CreateTaskResult, verify that the client declared the extension on this request. Never return a task to a client that did not declare support.
3. Return a CreateTaskResult — resultType: "task" with a unique taskId, an initial status, ttlMs, and pollIntervalMs. The task must be durably created before the response is sent.
4. Serve tasks/get — return the current state on each poll; for terminal states include result (on completed) or error (on failed).
5. Handle tasks/update — accept inputResponses keyed to outstanding inputRequests, acknowledge with an empty result, and ignore responses for unknown or already-satisfied keys.
6. Handle tasks/cancel — acknowledge with an empty result. Honor it when possible, but remember cancellation is cooperative and the task may still reach a non-cancelled terminal status.

来源:MCP Tasks · For MCP clients / For MCP servers / Notifications

Sources: MCP Tasks · For MCP clients / For MCP servers / Notifications

06Tasks / MRTR / subscriptions 怎么选Choosing between Tasks, MRTR, subscriptions

2026-07-28 一次性引入了三套「不是普通一问一答」的机制,很容易搞混。它们解决的是三个不同的问题:

The 2026-07-28 release introduced three mechanisms that go beyond plain request-and-response, and they are easy to confuse. They solve three different problems:

这里有个容易混淆的细节值得单独点出:input_required 这个词在两处出现,含义相近但机制不同。在 MRTR 里它是 resultType,客户端的动作是带着 inputResponses 重试原始调用;在 Tasks 里它是 status,客户端的动作是调 tasks/update 回填,原始调用不重发。判断依据很简单:你手上有没有 taskId。

One detail is worth calling out because it trips people up: the phrase input_required appears in two places with related meanings but different mechanics. Under MRTR it is a resultType, and the client's move is to retry the original call with inputResponses attached. Under Tasks it is a status, and the client's move is to call tasks/update — the original call is not re-sent. The test is simple: do you hold a taskId?

来源:2026-07-28 规范:MRTR / Tasks · subscriptions 模式

Sources: The 2026-07-28 Specification: MRTR / Tasks · Subscriptions pattern

07什么场景该用 TasksWhen to reach for Tasks

官方文档给了五类场景。它们的共同点不是「慢」,而是「结果的到达时间与请求的发出时间解耦」:

The official docs list five scenarios. What they share is not slowness but the decoupling of when a result arrives from when the request was made:

反过来,不该用 Tasks 的情形也很清楚:如果操作在一两秒内稳定返回,直接同步返回就好——多引入的持久化、轮询和状态管理都是净成本。Tasks 是给「不得不异步」的场景准备的,不是默认选项。

Conversely, when not to use Tasks is equally clear: if the operation reliably returns within a second or two, just return synchronously. The extra persistence, polling, and state management are pure overhead. Tasks exist for work that has no choice but to be asynchronous; they are not a default.

来源:MCP Tasks · When to use Tasks

Source: MCP Tasks · When to use Tasks

08六个常见坑Six common pitfalls

关于本节的说明:坑一、二、五、六直接对应官方文档中的规范性要求;坑三、四是从文档明确写出的「尊重 pollIntervalMs」「持久化 task ID」两条实现要求推演出的常见后果,属于工程推断而非规范原文。

A note on this section: pitfalls 1, 2, 5, and 6 map directly to normative requirements in the official docs. Pitfalls 3 and 4 are engineering inferences drawn from two implementation requirements the docs state explicitly — "respect pollIntervalMs" and "persist task IDs" — rather than verbatim spec text.

09它在路线图上的位置Where it sits on the roadmap

2026 年 8 月 22 日,MCP 核心维护者 David Soria Parra 与 Den Delimarsky 发布了新版路线图,分为五个优先领域,「智能体消息原语」排在第一位。原文对这个方向的定位是:现代智能体负载已经不再适配标准的请求-响应模式——循环会跑更久、服务端会推流式结果、还需要在执行中途调整方向。

On 22 August 2026, MCP lead maintainers David Soria Parra and Den Delimarsky published a new roadmap organized into five priority areas, with agentic messaging primitives listed first. The stated framing: modern agentic workloads no longer fit the standard request-and-response pattern — loops run longer, servers push streamed results, and there is a clear need to steer work mid-flight.

这个方向下有三件具体的事,Tasks 占了其中一件:

Three concrete pieces of work sit under that area, and Tasks is one of them:

1. 服务端主动事件——webhooks 与 channels,「让客户端不必再为结果一直轮询」。
2. 组合性评审——跨 Agents、Transports、Triggers & Events 三个工作组,确认这些原语彼此配合得好,而不只是各自可用。
3. Tasks 扩展成熟化(SEP-2663)——目标是让它能进入规范正文。

1. Server-initiated events — webhooks and channels, "so clients aren't left polling for results".
2. A composition review across the Agents, Transports, and Triggers & Events Working Groups, to confirm these primitives work well together rather than merely working individually.
3. Maturing the Tasks extension (SEP-2663) — the goal being to move it into the specification.

值得留意的一个张力:Tasks 目前是轮询优先的设计(通知是可选优化),而路线图第一条就是要做服务端主动推送。两者不冲突——通知机制早已经通过 subscriptions/listen 存在,webhooks/channels 是把「推」的能力扩展到「客户端不在线」的场景。但如果你现在就把架构死绑在轮询上,未来接推送时要动的地方会比预期多。建议把「怎么拿到状态」抽象成一层,轮询只是它的第一个实现。

One tension worth watching: Tasks today is poll-first by design, with notifications as an optional optimization, while the first item on the roadmap is server-initiated push. These do not conflict — a notification path already exists through subscriptions/listen, and webhooks/channels extend push to the case where the client is offline. But if you hard-wire your architecture to polling now, wiring in push later will touch more code than you expect. Abstract "how status arrives" behind one seam, and treat polling as its first implementation.

来源:The New MCP Roadmap · 2026-08-22 · 官方路线图页

Sources: The New MCP Roadmap · 2026-08-22 · Official roadmap page

10来源清单Sources

本文全部事实性内容来自以下公开来源,均于 2026-08-26 访问。文中凡属工程推断而非规范原文之处,已在对应位置标注。

Every factual claim in this document comes from the public sources below, all accessed on 2026-08-26. Wherever a statement is an engineering inference rather than verbatim spec text, it is flagged in place.

1. MCP Tasks — Asynchronous task execution for long-running MCP operations(官方扩展文档:机制、状态表、实现指南、通知)
2. modelcontextprotocol/ext-tasks(Tasks 完整规范与文档仓库)
3. The New MCP Roadmap · 2026-08-22 · David Soria Parra、Den Delimarsky(五大优先领域;Tasks 转正目标)
4. The 2026-07-28 Specification · 2026-07-28(无状态核心、MRTR、Tasks 移入扩展、AWS 贡献、SDK 状态)
5. MCP 规范 2026-07-28 与 完整变更日志
6. SEP-2663 — Tasks extension · SEP-2322 — Multi Round-Trip Requests · SEP-2575 — Stateless MCP
7. subscriptions/listen 模式 · 扩展客户端支持矩阵
8. MCP 官方路线图页

1. MCP Tasks — Asynchronous task execution for long-running MCP operations (official extension docs: mechanism, status table, implementation guide, notifications)
2. modelcontextprotocol/ext-tasks (full specification and documentation repository for Tasks)
3. The New MCP Roadmap · 2026-08-22 · David Soria Parra and Den Delimarsky (five priority areas; the goal of moving Tasks into the spec)
4. The 2026-07-28 Specification · 2026-07-28 (stateless core, MRTR, Tasks moving into an extension, the AWS contribution, SDK status)
5. MCP specification 2026-07-28 and its full changelog
6. SEP-2663 — Tasks extension · SEP-2322 — Multi Round-Trip Requests · SEP-2575 — Stateless MCP
7. The subscriptions/listen pattern · Extension client support matrix
8. The official MCP roadmap page