MCP 变天了！无状态协议核心、Multi Round-Trip Requests、正式扩展框架，七月 28 日规格更新深度解读！

admin@yesmiracle.net (万戈) — Wed, 29 Jul 2026 00:00:00 +0000

昨天（7 月 28 日），MCP 发布了其历史上最大的一次规格更新——2026-07-28。如果你在用 MCP 搭建 Agent 基础设施，这篇文章值得你放下手头的工作看完。

如果说之前的 MCP 还是一个「实验性协议」，那这次更新就是它正式成年的标志。

半年狂奔：从实验到工业标准

先看一组数据：MCP 的 Tier 1 SDK（TypeScript、Python、Go、C#）月下载量已接近 5 亿次，TypeScript 和 Python SDK 各自突破了 10 亿总下载量。这距离 MCP 发布还不到两年。

但增长越猛，痛点越痛。开发者们反馈最集中的问题是什么？有状态协议带来的伸缩性瓶颈。

MCP 最初设计为双向有状态流协议——每个连接需要 initialize/initialized 握手、维护 Mcp-Session-Id、保持长连接。这在单机场景下没问题，但一上生产、一挂负载均衡，立刻暴露问题：session 黏滞、负载不均、故障恢复复杂。你不能简单地往一个 round-robin 后端加一台新机器，因为 session 状态不共享。

核心变革：从有状态到无状态

这次更新最核心的变更就是——MCP 彻底变为无状态请求/响应协议。

告别握手和 Session

initialize/initialized 握手取消了，Mcp-Session-Id 头取消了。每个请求自带协议版本、客户端标识和能力声明（通过 _meta 参数），可以独立处理。

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

这意味着什么？任何请求可以落在任何后端实例上，不需要 session 黏滞、不需要共享存储、不需要分布式 session 同步。一个普通的 round-robin 负载均衡器就够了。

如果客户端想提前了解服务端能力，可以通过新的 server/discover RPC 可选查询——不是必须的。

那业务状态怎么处理？

MCP 团队想得很清楚：去掉协议级 session 不代表你的应用也得无状态。如果你需要跨调用保持状态，从工具显式返回一个 handle，让模型作为参数传回来。模型能「看到」这个 handle 并在工具之间传递，这比把 session 状态藏在传输层里好得多——透明、可观测、可调试。

Multi Round-Trip Requests（MRTR）

这是另一个重大变更。之前 MCP 用双向流来处理服务端发起的请求（如 elicitation/create、sampling/createMessage、roots/list），现在全部改为 MRTR。

场景：工具调用到一半，需要用户确认或补充参数。传统做法是保持连接等用户回复。MRTR 的做法是：服务端返回 resultType: "input_required"，附带需要回答的请求列表；客户端带着答案重试原始调用。

这听起来像多了一步，但好处是不需要保持长连接，完全适配无状态架构。

Header-based Routing

Streamable HTTP 请求现在必须带 Mcp-Method 和 Mcp-Name 头。你的网关、限流器、WAF 可以直接在这些头上做路由和计费，不需要解析 JSON body。性能提升对生产环境非常显著。

列表结果可缓存

tools/list、prompts/list、resources/list、resources/read 的响应现在携带 ttlMs 和 cacheScope。客户端可以据此决定缓存策略，减少不必要的重请求。这对工具目录特别有用——工具列表不会频繁变化，每次请求都重新拉一遍是浪费。

授权加固

这是很多人忽略但实际最痛的部分。MCP 团队从过去一年的生态反馈中总结了几项关键加固：

RFC 9207 iss 参数验证：授权服务器必须返回 iss，客户端必须验证——防止授权服务器混淆攻击
Client ID Metadata Documents（CIMD）：正式取代 Dynamic Client Registration（DCR），使协议符合 OAuth 规范要求
客户端凭证绑定到签发者：不能跨授权服务器重用
DCR 正式弃用：但兼容期至少 12 个月

Tasks 扩展

Tasks 从实验性核心移入 io.modelcontextprotocol/tasks 扩展，引入 tasks/update 和基于 subscription 的变更通知。这是 AWS 贡献的扩展，支持可靠的长时运行 Agent。

弃用清单

以下功能被正式弃用（12 个月兼容期）：

Roots（已弃用）
Sampling（已弃用）
Logging（已弃用）
HTTP+SSE 传输（已弃用）

新实现不要采用这些功能。

生态支持：全栈共识

这次更新获得了 AWS、Cloudflare、Google Cloud、Microsoft Foundry、Netlify、Figma、Honeycomb、Manufact 等全线生态伙伴的公开支持。

几个值得关注的表态：

AWS（Swami Sivasubramanian，Agentic AI VP）：MCP 新规格已在 Amazon Bedrock AgentCore 中可用，Tasks 扩展由 AWS 贡献
Cloudflare（Brendan Irvine-Broque）：Agents SDK 从 day zero 支持新规格，Sentry 和 Linear 同日可用
Microsoft Foundry（Tina Schuchman）：利用 MCP 将集成从几十个扩展到数千个，无状态操作让生产级 Agent 系统更安全、可扩展
Google Cloud（Anna Berenberg，Engineering Fellow）：承诺在 Google Cloud 开发者工具生态中充分利用新能力

这种级别的生态共识说明：MCP 已经不是某个公司的实验，而是行业基础设施的共识选择。

SDK 更新

四个 Tier 1 SDK（TypeScript、Python、Go、C#）全部同步更新。Rust SDK 以 beta 版本支持新规格。Manufact 的 CTO 透露一个有趣的数字：新 SDK v2 将包体积缩小了 83%，速度提升 25%，得益于客户端-服务端分离。

对生产者的影响

如果你是 MCP 服务端开发者，这次更新意味着：

部署更简单：不需要 session 管理、不需要黏滞会话、不需要共享存储。随便一个负载均衡器就行
可扩展性飞跃：任何请求可以落在任何实例上，水平扩展不再是问题
网关友好：Header-based routing 让 WAF、限流、路由、计费都可以在 HTTP 层完成
缓存策略提升：工具目录、资源列表等低频变化数据可以直接缓存
授权规范：OAuth 合规，不再需要自己写认证胶水代码

迁移成本是有的——特别是如果你的代码依赖了 session 标识符。但 12 个月的兼容期窗口给了充足的缓冲时间。

写在最后

MCP 18 个月前还是 Anhtropic 的一个实验性项目，今天已经成长为 Agent 基础设施的事实标准——月下载量 5 亿次、4 个官方 SDK、全线云厂商支持、从有状态到无状态的架构蜕变。

这次更新最让我感慨的不是技术细节本身，而是一个开源协议能在大规模反馈下完成如此重大的架构转折。从 stateful 到 stateless 不是小改动，它意味着重写核心、弃用旧 API、推动全生态迁移。MCP 团队选择了做「难而正确的事」。

这让我想起 HTTP 协议从 1.0 到 1.1 的演进，也想起 REST 取代 SOAP 的历程。优秀的协议总是在使用中不断完善，而不是在象牙塔里设计完美再发布。

对于正在搭建 Agent 基础设施的团队，现在就是认真考虑迁移到 2026-07-28 规格的最佳时机。无状态 MCP 的生产部署体验，比有状态版本好太多了。

协议 on AI博士 万戈