MCP 2.0：协议核心改为无状态
2026-07-28 版规范把 MCP 从有状态的双向协议改成无状态的请求/响应协议：废除 initialize 握手与会话 id，每个请求自带协议版本与能力，于是任何一个请求都可以落到轮询负载均衡后的任意实例，不再需要共享存储。这是 MCP 发布以来最大的一次改动，同时收紧了鉴权、定下了 12 个月的最短弃用窗口。
多个信号同时成立，建议优先评估这条技术变化。
记录
信号正文
这次改了什么
2026-07-28 版规范（社区称 MCP 2.0）的主线只有一句话：协议核心从有状态变成无状态。
- 握手和会话没了。
initialize/initialized这对交换和Mcp-Session-Id头一起退休。每个请求自己携带协议版本、客户端标识与能力；想提前知道服务器有什么能力，可以调用新增的server/discover，但不是必须的。 - 因此可以横向扩。 任何请求都能落到轮询负载均衡后面的任意实例，不需要实例间共享存储——这正是此前呼声最高的诉求。
- 方法名和工具名走 HTTP 头（
Mcp-Method、Mcp-Name），网关可以直接按头做路由和鉴权，不必先解请求体。 - 采样与征询改成多轮往返（MRTR），不再要求维持一条常开的双向流。
- 列表响应可缓存：带缓存提示且顺序确定，客户端可以缓存工具目录，重连之后上游的提示缓存也不会失效。
- 扩展框架正式化，Tasks 与 MCP Apps、企业托管授权并列为扩展。
- 鉴权收紧：加入签发方校验，并从动态客户端注册转向客户端元数据文档。
- 弃用有窗口了：正式的弃用策略给出至少 12 个月，升级可以排期而不是被动响应。
四个一级 SDK（TypeScript、Python、Go、C#）同步更新，破坏性改动附迁移说明。规模上，官方称一级 SDK 月下载量接近 5 亿。
为什么现在值得重新看 MCP
信号来源 Simon Willison 的角度值得一并读：2025 年 MCP 的热度被 Skills 盖过，原因是一个能用终端和 curl 的智能体外壳，用更灵活的方式做到了 MCP 的大部分事。他现在转回来的理由不是协议变强了，而是那条替代路线的代价看清楚了——给智能体一个能上网的 shell 风险很大，而且需要足够强的模型才驱动得动；相比之下 MCP 工具更容易审计和管控，简单到笔记本上跑的小模型也能驱动。
换句话说，无状态化解决的是运维上的反对意见（可靠性与扩展性），而「可审计」才是它对着 shell 方案的长期理由。
为什么是现在
为什么重要
MCP 服务器此前必须维持会话状态，所以扩容要么粘连会话、要么共享存储，这一条挡住了不少生产部署。无状态化之后，MCP 服务器变成普通的无状态 HTTP 服务，可以直接放在轮询负载均衡后面。这是部署形态的改变，不是功能增补。
背景
技术背景
无状态化的代价落在服务器一侧：能力协商从一次握手变成每个请求自带，服务器要接受重复信息换取实例无关性。采样与征询这类服务器发起的请求原本依赖常开双向流，现在改用多轮往返表达。列表响应加了缓存提示与确定顺序，是为了让客户端缓存工具目录时，上游模型的提示缓存不会因为重连而整体失效。
关注人群
谁该关注
关系网络
在技术网络中的位置
当前技术与相邻技术、技能和背景知识的连接，点击节点可继续探索。
延伸思考
后续问题
- 每个请求都携带协议版本与能力，在高频调用下带来的额外开销有多大？
- 工具目录缓存失效时，上游提示缓存的命中率会掉多少？
- 从动态客户端注册转向客户端元数据文档，对已有的自动注册流程意味着什么？
来源参考