MCP 的 Tasks 被移出核心协议了，长任务该怎么办
数据截至 2026-07，价格与限额以各官网为准。
Tasks 从 MCP 核心协议移到 extension，不是这个能力被砍掉了，而是它从”所有实现都必须懂的必修课”降级成了”需要的人再装的选修课”。对绝大多数只做同步工具调用的 server，这次改动没影响；真正要动手的是那些跑几分钟以上长任务、又想同时兼容新旧客户端的服务。
先纠正一个很常见的误解：不少人看到”移出核心”四个字，第一反应是”MCP 不支持长任务了”。不是这个意思。移出核心指的是它不再是核心规范的一部分，而是放进了这次同时引入的 Extensions 框架里——能力还在，只是协商和实现的位置换了地方，客户端和服务端要显式地就”我们都支持这个扩展”达成一致，而不是默认对方一定有。这个区别听起来像文字游戏，但落到工程上，直接决定了你的兼容性判断逻辑要不要重写。
这次改动的坐标：它是一整套修订里的一块
2026-07-28 发布的这版规范，官方称是自协议发布以来最大的一次修订，兑现的是 2026 年的路线图。这次一共动了六块：无状态协议内核、Extensions 框架、Tasks、MCP Apps、授权加固，以及一套正式的弃用策略。
Tasks 不是被单独拎出来处置的，它是”无状态内核”这条主线的连带结果。你要理解它为什么被移出去，得先看无状态那一块改了什么。
为什么是 Tasks：协议层不再要求会话追踪
这次修订里分量最重的一处，是 MCP 在协议层变成无状态的，由 6 个 SEP（Specification Enhancement Proposal，规范增强提案）共同实现，完成了此前 “The Future of MCP Transports” 里规划的方向。
它的现实意义相当直接：以前一个远程 MCP server 想跑起来，往往需要粘性会话（sticky session）、共享的 session 存储，甚至要让网关做深度包检测才能把请求送回同一个实例；现在这些都不必了，server 可以直接放在普通的轮询负载均衡后面，按 Mcp-Method 头做路由。
这里要特别拦一个曲解：无状态说的是协议层不再要求会话追踪，不是”MCP 从此不能有状态”。你的应用自己要不要存东西、怎么存，是另一个层面的事，规范没管也管不着。
理解了这条主线，Tasks 的去向就顺理成章了。长时间运行的操作天然是有状态的：任务被创建、在跑、能查进度、可能被取消、最后拿结果——这一整套生命周期跟”内核不追踪会话”的目标是拧着的。把它留在核心，等于让每一个哪怕只提供三个同步工具的 server，都得先理解一套自己根本用不上的状态模型。挪进 extension，核心就能保持薄，需要长任务的人再按需接。
Extensions 框架带来的另一件事：你可以自己造
新的 Extensions 框架不只是官方用来安置 Tasks 的抽屉。规范明确了用户可以自建 extension，与官方认可的 extension 并存。
这对做内部平台的团队是个实打实的空间。以前你要在 MCP 之上加一层公司内部约定（比如统一的审计字段、内部作业系统的对接方式），只能靠”大家自觉遵守的土规矩”，很难跟协议本体讲清楚边界。现在有了正式的扩展位置，自定义能力可以走同一套协商机制，不必伪装成核心特性。
代价是你得自己承担版本维护——官方 extension 至少还有生态推着走，自建的那部分，兼容性完全归你。
长任务现在有哪几种走法
按你的实际情况对号入座，我的建议是这样：
第一种：任务其实没那么长。 先老实评估一下你的操作到底跑多久。很多被归进”长任务”的场景（一次数据库聚合、一次文档解析）实际是几秒到十几秒，同步返回加上合理的超时设置完全扛得住。这类根本不用引入 Tasks，改动量为零。这是最省事也最该优先考虑的选项。
第二种：真的长，接 Tasks extension。 如果你的操作动辄几分钟起（批量爬取、大规模转码、跑一整个流水线），那就按新规范去接 Tasks extension。要注意的是，客户端也得支持，能力协商没谈成的话，你这边接了也是白接。所以这条路的前提是你能确定下游客户端的版本，或者你自己同时掌握两端。
第三种：绕开协议，自己在应用层做异步。 这是最保守也最通用的做法：把长操作拆成两个同步工具——一个”提交任务”，立刻返回你自己生成的任务 ID；一个”查询任务状态”，让模型隔一会儿自己来问。任务状态存在你自己的数据库或队列里，跟 MCP 协议完全解耦。
第三种的好处是它不依赖任何 extension 支持，新旧客户端通吃，也不会被下一轮规范调整波及。缺点也很明显：进度反馈、取消、超时清理这些细节全得你自己写一遍，而且模型什么时候来轮询、轮询几次放弃，靠的是你在工具描述里的提示词，不如协议原生机制可靠。如果你的服务面向不特定的外部客户端，这条路目前仍然是最稳的。
具体的 extension 声明字段、协商流程和方法名，请直接对照规范文档当前版本，这类细节在大改版之后最容易过时，我不在这里复述一份可能几周后就对不上的结构。
破坏性变更：新旧真的会互相不认
这次一定要认真对待兼容性。维护者 David Soria Parra 称这是自加入授权以来最实质的变更，原话是：“A lot of things that made MCP are gone.”
具体到风险：2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然。 官方给的缓冲是弃用机制留了 12 个月窗口，旧版本不会立刻断供。
12 个月听着宽裕，但按我见过的迁移节奏，真正该做的是现在就把三件事排进日程：一是盘清你的 server 目前实际被哪些客户端调用、各自什么版本；二是把升级放到灰度里跑，别直接推生产；三是把”跨版本调用失败”的报错做成能看懂的提示，而不是让使用者对着一个空的工具列表猜。MCP 连不上这类问题的排查思路，可以参考 Claude Code 的 MCP 连不上、配置不生效怎么排查，多数定位方法在跨版本场景下同样适用。
顺带要跟的一件事：授权加固
同一批修订里，授权部分也由 6 个 SEP 做了加固，目标是让授权规范更贴近真实世界的 OAuth 2.0 / OpenID Connect 部署。其中一条值得单独记：要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。
如果你的 MCP 服务带鉴权，这条是硬性的客户端行为要求，别只顾着改 Tasks 而漏了授权侧的适配。校验没做对的表现往往不是干脆报错，而是某些授权服务器下时灵时不灵，排查起来很费时间。
怎么确认某个 server 支不支持
官方注册表 registry.modelcontextprotocol.io 提供 server 发现、文档与 API 参考，由 modelcontextprotocol 这个 GitHub 组织维护，社区驱动。要判断一个第三方 server 的现状，从这里查比从搜索引擎翻博客靠谱得多。
路线图上还有一项叫 MCP Server Cards：通过 .well-known URL 暴露 server 元数据的标准，让注册表和爬虫不用真的建立连接就能发现它的能力。这件事一旦落地，“这个 server 到底支不支持 Tasks extension”就有了可以程序化查询的答案，不用靠试。当前进展以官方仓库与规范文档为准。
顺带提醒一个信息卫生问题：这次改动时效性极强，中文资料几乎还是空白，网上有些站点到现在仍把 2025-11-25 那版列为当前稳定版、甚至说下一版”暂定 2026 年 6 月”——这类内容已经过期，别拿来当依据，一律以官方博客和规范文档为准。
诚实说说局限
有几点我得说清楚，免得你按这篇去做过强的判断：
- 生态数字只能当量级看。 公开资料里提到超过 10,000 个公开 MCP server 在生产中运行、SDK 月下载量超过 9,700 万，这是官方与行业公开资料的汇总口径，不是精确统计，用来判断”这个协议值不值得投入”够了，用来做容量或商业测算就不合适。
- 具体接口形态我没写。 Extensions 的协商细节、Tasks 的方法命名，属于大改版后最易变动的部分，以规范文档当前版本为准。
- 不同 SDK 的跟进速度不一样。 规范发布和各语言 SDK 的实现落地之间通常有时间差，你用的那个 SDK 有没有跟上，得自己去仓库确认。
顺便交代一句背景：2025 年 12 月 Anthropic 已把 MCP 捐给 Linux 基金会下的 Agentic AI Foundation，成为厂商中立、社区治理的标准，OpenAI、Google、Microsoft、AWS 都已把它接进各自的 agent 栈。这意味着后续演进不再由单一厂商说了算——对长期投入是好事，但也意味着你得习惯”规范会按社区节奏持续变”，而不是指望它冻结不动。
小结
Tasks 移出核心是”协议内核瘦身、按需扩展”这个方向的必然结果，能力没消失，位置变了。只跑同步工具的 server 基本不受影响，跑长任务的要在”接 extension”和”应用层自己做异步”之间做个选择，后者兼容性更稳但要多写代码。新旧版本可能互不兼容，12 个月的弃用窗口是留给你排迁移计划的，不是留给你拖延的。授权侧的 iss 校验别漏。所有具体字段和进度，以官方博客与规范文档当前版本为准。