关于 MCP 的几个常见误解，尤其是"无状态"
数据截至 2026-07，价格与限额以各官网为准。
MCP 在 2026-07-28 发布了新规范，官方自己的说法是”自协议发布以来最大的一次修订”，其中被误读最多的一条是”无状态”——它指的是协议层不再要求会话追踪，不是说你的 server 从此不能有任何状态。把这两件事混为一谈，会让你在架构选型上做出完全错误的决定。
先承认一个我自己也踩过的误解：刚看到”MCP 现在是无状态协议”这句话时，第一反应是”那我那些需要维持上下文、维持连接内计数、维持登录态的 server 是不是全废了”。这个反应很自然，但方向反了。协议无状态说的是传输层和路由层的契约，跟你的业务逻辑要不要存东西完全是两个维度的问题。下面按误解逐条拆。
误解一：无状态 = MCP 不能有状态
这是最需要先纠正的一条。新规范里的无状态化由 6 个 SEP（Specification Enhancement Proposal，规范增强提案）共同实现，兑现的是官方此前那篇讲传输层未来的规划文档。它带来的确切变化是：协议层不再要求会话追踪。
请注意”协议层”和”要求”这两个限定词。协议不再强制要求你在两次请求之间维持一个由协议定义的会话对象，不代表你的应用不能自己维护状态。你的 server 想在数据库里存用户偏好、想缓存一份索引、想记录调用次数，这些都还是应用层自己的事，规范管不着，也没打算管。
真正的区别在于：以前状态是被协议契约”绑定”在连接上的，客户端和服务端必须对同一个会话达成一致；现在这层绑定被解开了，状态是否存在、存在哪里、怎么恢复，变成了实现方自己的设计决定。对大多数人来说，这是自由度变大而不是能力被砍掉。
误解二：这次升级只是加了点功能，老代码不用动
这条误解的代价最大。新规范覆盖六块：无状态协议内核、Extensions 框架、Tasks、MCP Apps、授权加固，以及一套正式的弃用策略。这不是打补丁的量级。
维护者 David Soria Parra 对这次变更的定性是”自加入授权以来最实质的变更”，他有一句原话直白得几乎不像官方口径：“A lot of things that made MCP are gone.”（很多曾经构成 MCP 的东西没了。）
落到工程上有一条必须记住的事实：2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然。 也就是说这是双向的不兼容风险，不是”新的能兼容旧的”那种温和升级。好在官方同时给出了弃用机制，旧版本有 12 个月的窗口。这个窗口不算短，但也不长到可以忽略——如果你手上有生产环境在跑的 MCP server，现在该做的是把升级排进路线图，而不是等到窗口末尾再动。
具体升级细节以官方规范文档与发布博客的当前版本为准，这篇不复述条文。
误解三：Tasks 还在核心协议里
不在了。用于长时间运行操作的 Tasks 特性已经从核心协议移到 extension。
这个改动很容易被漏掉，因为很多人是通过”MCP 支持长任务”这类二手介绍认识这个特性的，不会去核对它挂在协议树的哪个位置。移到 extension 意味着它不再是每个实现都必须支持的部分，你在做客户端兼容性判断时，不能默认对面一定有 Tasks 能力。
配套的另一件事是：Extensions 框架允许用户自建 extension，与官方认可的 extension 并存。这对生态是好消息——需要一个非通用能力时，不必再去挤官方规范的正式流程，可以先以 extension 形式跑起来。但对使用方来说，也意味着”某个 server 支持什么”这件事的答案变得更分散了，能力协商比以前更重要。
误解四：无状态只是理论上的优雅，对部署没什么影响
恰恰相反，部署侧的收益是这次改动最实在的部分。
规范里给出的实际影响是：以前需要粘性会话（sticky session）、共享 session 存储、网关做深度包检测才能跑起来的远程 server，现在可以直接跑在普通轮询负载均衡后面，按 Mcp-Method 头路由。
如果你运维过多实例的远程 MCP 服务，这句话的分量不用多解释。粘性会话意味着负载不均、扩缩容困难、单实例故障会打断会话；共享 session 存储意味着多一个必须高可用的中间件；网关做深度包检测意味着你的基础设施团队要为一个应用协议写特例规则。这三样现在原则上都可以退掉。
需要诚实说明的是：能退掉不等于自动退掉。这取决于你的 server 实现是否真的把状态从连接上解耦干净了。协议给了你无状态部署的可能性，实现层面的重构还是得自己做。
误解五：授权部分照着以前的写法就行
授权这块同样由 6 个 SEP 推动，目标是让授权规范更贴近真实世界的 OAuth 2.0 / OpenID Connect 部署，而不是停留在一个理想化的简化模型上。
其中一条值得单独点名：要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。这是一条明确的客户端侧义务，如果你在写 MCP client，这不是可选的加分项。RFC 9207 解决的是授权响应来源确认的问题，跳过这类校验在多授权服务器场景下是真实的安全隐患，不是形式主义。
其余授权相关的条款细节，以官方规范文档当前版本为准。这里只想强调一个态度问题：授权部分不要凭以前的印象写，也不要抄网上早期的示例代码，因为这正是变动最集中的区域之一。
误解六：MCP 还是某一家公司的私有协议
这条误解在中文语境里格外常见，因为很多介绍文章的写作时间早于治理变更。
事实是：2025 年 12 月，Anthropic 已经把 MCP 捐给了 Linux 基金会下的 Agentic AI Foundation，它现在是厂商中立、社区治理的标准。OpenAI、Google、Microsoft、AWS 都已经把它接进了自家的 agent 栈。
生态规模方面，按官方与行业公开资料的口径，目前有超过 10,000 个公开 MCP server 跑在生产中，SDK 月下载量超过 9,700 万。这两个数字来自公开资料汇总而非精确统计口径，看个量级即可，不建议直接引用到需要严谨数据的场合。
顺带说发现机制：官方维护着一个 MCP Registry（registry.modelcontextprotocol.io），提供 server 发现、文档与 API 参考，由 modelcontextprotocol 这个 GitHub 组织社区驱动维护。路线图上还有一项叫 MCP Server Cards，思路是通过 .well-known URL 暴露 server 元数据，让注册表和爬虫不用真的连上去就能发现它有哪些能力。对做聚合、做目录、做安全审计的人来说，这条路线值得盯。
一个附带的坑：网上教程的版本号未必还有效
这次升级的时效性太强，中文内容的覆盖近乎为零，直接后果是搜索结果里的信息普遍滞后。
已经能观察到的现象是：仍有站点把上一版（2025-11-25）列为当前稳定版，甚至写着下一版”暂定 2026 年 6 月发布”。这类信息已经过期了。判断标准很简单——凡是没有提到无状态内核、Extensions 框架、Tasks 外移这三件事的介绍，基本可以认定是旧版内容，不管它排在搜索结果第几位。
比较稳的做法是把官方博客和规范文档作为唯一基准，二手教程只用来理解概念，不用来抄具体的字段名、版本号和接口形态。
现在可以做的几件事
- 先盘存量：列出你手上所有在跑的 MCP server 和 client，标注各自实现所依据的规范版本，这是判断升级优先级的前提。
- 区分状态归属：把 server 里的状态逐项归类——哪些是协议会话强加的、哪些是业务本来就需要的。前者才是这次要拆的对象，后者不用动。
- 客户端先补授权校验：
iss参数校验属于安全相关的义务性变更，改动量小、风险低，可以先做掉。 - 别默认对端支持 Tasks：能力协商写规矩点，尤其是要和第三方 server 互通的场景。
- 把 12 个月窗口写进计划表：给出一个明确的迁移完成日期，而不是”有空再说”。
- 部署侧的收益等重构完再兑现：粘性会话和共享 session 存储先别急着下线，等 server 真正无状态化并压测过再退。
局限说明
这篇能讲清楚的是变更的方向和需要注意的陷阱，讲不了逐条的迁移代码。原因有二：一是规范刚发布，配套的 SDK 与实现还在跟进，现在写出来的具体写法很可能几周后就要改；二是不同语言的 SDK 落地进度并不一致，给一份通用示例反而容易误导。需要动手时，请以官方规范文档和你所用 SDK 仓库的当前版本为准。
小结
MCP 的”无状态”说的是协议层不再要求会话追踪，你的应用照样可以有状态，这是自由度而不是限制。这次修订是破坏性的，新旧 server 与 client 可能互不兼容，弃用机制留了 12 个月窗口，别把它当成小版本升级。Tasks 已经挪出核心变成 extension，能力协商不能再靠默认假设。授权部分有实质变化，iss 参数校验是明确的客户端义务，值得优先补上。最后，MCP 早已不是某一家公司的协议，判断信息新旧的最快办法就是看它有没有提到无状态内核这条主线。