MCP 生态 2026：捐给 Linux 基金会之后发生了什么
数据截至 2026-07，价格与限额以各官网为准。
MCP 交给中立基金会之后没有变成”维护模式”，反而在 2026-07-28 发了一版官方自称是协议发布以来最大的修订：协议层被改成无状态、Tasks 从核心里挪走、授权规范补齐了 OAuth 落地细节，并且第一次有了正式的弃用策略。这一版新旧不兼容是真的，但同时也给了旧版本 12 个月的过渡窗口——所以对绝大多数团队来说，现在该做的是排升级计划，不是连夜重写。
一个挺常见的误解是：开源项目一旦捐给基金会，就意味着原厂”甩手”，节奏会慢下来、变成只修 bug 的维护状态。MCP 这一年多的走向恰好相反。2025 年 12 月 Anthropic 把它捐给 Linux 基金会下的 Agentic AI Foundation，变成厂商中立、社区治理的标准之后，OpenAI、Google、Microsoft、AWS 都把它接进了自家的 agent 栈——参与方越多，反而更需要一次把协议里那些”当初为了快而妥协”的设计正过来。2026-07-28 这一版，就是把 2026 路线图上答应的事一次性兑现。
先把治理这件事说清楚
捐赠带来的最实际的变化有两点。
一是决策不再由单一厂商拍板。规范演进走 SEP（Specification Enhancement Proposal，规范增强提案）流程，一项大改动往往由多个 SEP 拼起来落地，讨论过程公开在 modelcontextprotocol 的 GitHub 组织里。这次的无状态化和授权加固，各自都是由 6 个 SEP 共同实现的——这个组织方式本身就说明了协议现在怎么演进：不是一版一版整体重写，而是一条条提案合入。
二是多厂商同时依赖之后，兼容性的代价被摆上台面。当只有一两家在用时，改协议的成本主要由原厂承担；当这四家的 agent 栈都跑在上面，任何破坏性变更都必须配一套明确的弃用与过渡机制。这次规范第一次给出正式的弃用策略，本质上是治理成熟的产物，而不是某个技术特性。
如果你对 MCP 本身还不熟，建议先看 MCP 是什么 把 server-client 的基本模型建立起来，再回头看这篇的变更清单会顺很多。
2026-07-28 这一版到底改了什么
官方把这次修订归纳成几大块：无状态的协议内核、Extensions 框架、Tasks、MCP Apps、授权加固，以及正式的弃用策略。这一版之前先发过 release candidate，也就是说破坏性变更是提前打过招呼的，不是突然落地。
下面按对实际工程影响的大小逐个说。
无状态化：这次改动里最大的一处
MCP 现在在协议层是无状态的。 这是由 6 个 SEP 共同实现的结果，也兑现了此前 “The Future of MCP Transports” 里规划的方向。
它到底解决了什么问题？在旧的模型下，远程 MCP server 需要维持会话，于是部署形态被拖着走：负载均衡必须做粘性会话（sticky session），或者你得额外搭一套共享的 session 存储，有些网关甚至要做深度包检测才能把请求路由到正确的实例上。这套东西对小规模自建来说是额外复杂度，对要做多租户托管的平台来说更是硬成本。
改成协议层无状态之后，远程 server 可以直接跑在普通的轮询负载均衡后面，按 Mcp-Method 头做路由。粘性会话、共享 session 存储、网关深度包检测这几样，在协议层面不再是必需品。对运维来说，这大概是这一版里最能直接换成钱的改动。
这里要特别提醒一句，别把它理解偏了：无状态说的是协议层不再要求会话追踪，不是”MCP 从此不能有状态”。你的 server 在应用层怎么存用户数据、怎么维护业务会话，那是另一个层面的事，协议并不管。看到”MCP 无状态了”就以为自己的有状态业务用不了 MCP，属于误读。
Tasks 被移出核心，Extensions 成了新的扩展位
Tasks（用于长时间运行的操作）从核心协议移到了 extension。
这个变动的含义比它看起来更大。核心协议瘦身，意味着实现一个最小可用的 MCP server 门槛更低；而 Extensions 框架给出了一条正式的扩展路径——用户可以自建 extension，与官方认可的 extension 并存。换句话说，以后”某个能力该不该进核心协议”这个争论，有了一个不那么二元的答案：先做成 extension，跑一段时间再说。
对已经在用长任务能力的实现来说，这是需要动代码的地方之一：原来当作核心特性去依赖的东西，现在要按 extension 的方式引入。具体的迁移方式以官方规范文档当前版本为准，这篇不替它下结论。
授权加固：把 OAuth 的落地细节补上
授权这块同样由 6 个 SEP 组成，目标是让授权规范更贴近真实世界的 OAuth 2.0 / OpenID Connect 部署。
其中有一条值得单独拎出来：要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。这类校验在成熟的 OAuth 实现里是标配，缺了它会给混淆类攻击留口子。规范把它从”建议”变成”要求”，说明 MCP 的授权部分正在从”能跑通”往”经得起审计”的方向走。
如果你的 server 是对内使用、走的是简单的 token 校验，短期内感受不会很明显；但如果你在做面向第三方开放的托管 server，授权这块的改动值得优先排期看一遍。
破坏性变更是真的：先看清楚再动手
这一版的措辞很硬。维护者 David Soria Parra 说这是自加入授权以来最实质的变更，原话是 “A lot of things that made MCP are gone.”（很多曾经定义 MCP 的东西没了）。
具体到工程上，最需要知道的是两件事：
- 2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然。 不要默认升一头另一头会自动兼容。
- 弃用机制给旧版本留了 12 个月的窗口。 这是这次正式弃用策略带来的确定性——你有一年时间做迁移，而不是被逼着立刻改。
一个相对稳妥的推进顺序：先把你手上 server 和 client 的实际版本、以及各自依赖的 SDK 版本盘清楚；再确认哪些能力现在落到了 extension 里（Tasks 是明确的一项）；然后在测试环境把新 server 对旧 client、新 client 对旧 server 两个方向都跑一遍，看具体在哪一步断掉；最后再决定是先升客户端还是先升服务端。在窗口期内分两步走，比同时换两头风险小得多。
配置层面的排查逻辑没变，如果升级过程中遇到连不上、工具不加载这类问题，Claude Code 的 MCP 连不上怎么排查 里那套”配置位置 → 启动方式 → 路径 → 权限”的顺序依然适用，只是现在要多加一步：确认两端的协议版本对不对得上。
注册表与 Server Cards：发现这一层在补
生态另一条线是”怎么找到 server”。官方注册表 registry.modelcontextprotocol.io 提供 server 发现、文档与 API 参考，由 modelcontextprotocol GitHub 组织维护，社区驱动。
路线图上还有一项叫 MCP Server Cards：通过 .well-known URL 暴露 server 元数据的标准，让注册表和爬虫不必真的连接到 server 就能发现它的能力。这件事的价值在于，目前想知道一个远程 server 有哪些工具，往往得先连上去问一遍；有了标准化的元数据入口之后，索引、比价、安全审查这些外围工具才有可能做起来。
选 server 的判断标准倒是没怎么变——不是装得越多越好，这一点在 必装 MCP 推荐 里讲过，每多挂一个 server，它的工具描述都会占掉上下文预算。
生态规模：哪些数字能信，哪些只能当参考
关于 MCP 现在有多大，流传的说法是超过 10,000 个公开 MCP server 跑在生产中，SDK 月下载量超过 9,700 万。这两个数字来自官方与行业公开资料的汇总口径，不是精确统计，拿它感受量级可以，写进正式材料时建议注明来源和口径，别当成审计过的数据用。
比数字更值得注意的是使用场景的分布：四家主流厂商都把 MCP 接进了自家 agent 栈，意味着它已经不只是”给编程助手挂工具”的协议，而是被当作 agent 与外部系统之间的通用接线方式在用。这也解释了为什么这一版要下决心动协议内核——面向少数桌面客户端的设计，撑不住多租户远程部署的规模。
诚实说局限
有几点必须讲明白。
第一，这一版太新了，中文资料几乎为零。 你现在能搜到的中文 MCP 教程，绝大多数是按旧版本写的，直接照抄可能会踩到已经变掉的行为。以官方 blog 和规范文档的当前版本为准，是这段时间最省事的做法。
第二，网上有一批过期信源还在误导人。 有站点至今把 2025-11-25 那版列为”当前稳定版”，并预告下一版”暂定 2026 年 6 月”——这两条都已经过期了。判断一份 MCP 资料是否还有效，最快的办法是看它有没有提到无状态内核和 Extensions 框架，没提就说明它停在旧版本。
第三，这篇讲的是变了什么，不是逐条迁移手册。 具体到某个 SDK 在哪个版本支持新规范、某个 extension 怎么声明、Mcp-Method 头的完整语义，都以官方规范文档和各 SDK 仓库的当前说明为准。生态刚发新规范的头几个月，SDK 跟进速度参差不齐是常态，动手前先确认你用的那个 SDK 到位没有。
小结
MCP 捐给 Linux 基金会之后没有停滞，2026-07-28 这一版是官方口径下自协议发布以来最大的一次修订。最实质的改动是协议层无状态化，让远程 server 摆脱粘性会话和共享 session 存储，能跑在普通轮询负载均衡后面。Tasks 被移出核心进入 extension，Extensions 框架给了社区一条正式的扩展路径；授权部分向真实的 OAuth 2.0 / OIDC 部署靠拢，包括强制按 RFC 9207 校验 iss。新旧版本可能互不兼容，但正式弃用策略给了旧版本 12 个月窗口，分两步迁移是可行的。现在最该做的是盘清自己两端的版本、在测试环境跑双向兼容，然后一切以官方规范文档的当前版本为准——这个领域的二手中文资料，过期速度比你想象的快。