摘要: MCP 推出第五个大版本(2026-07-28),把核心从有状态双向协议改成了无状态请求/响应协议,还顺手带来 MRTR、Header 路由、可缓存列表、授权加固和正式扩展框架。本文综合官方博客与社区解读,讲清这次为什么改、改了什么、以及生产团队该怎么接。
MCP 一年半了。2026-07-28 这个版本,是它发布以来最大的一次修订——官方原话叫"18 个月经验教训的总结"。改动很多,但真正改变协议底层逻辑的只有一件事:它把会话(session)拆了。
从有状态的双向协议,变成无状态的请求/响应协议。这是开发者社区呼声最高的改动。后面所有变化(MRTR、Header 路由、可缓存列表、授权加固、扩展框架),几乎都是为这件事打补丁、配套、收尾。
这篇综合官方博客、社区解读来讲,先把痛讲透,再说怎么改,再给你一份迁移判断。
为什么这次值得专门讲?因为 MCP 不再只是"本地接个工具"的小协议——它月下载近 5 亿次,TypeScript 和 Python SDK 累计都过了 10 亿下载,已经是 agent 工作流的事实底座。底座动了结构,所有在上面建东西的人都得跟着看一眼。
一、旧 MCP 的痛:session 把你钉死在一台机器上
MCP 最早是冲着"本地工具调用"设计的,客户端和 server 通过 STDIO 或一条长连接通信,一个客户端、一个进程、一条稳定连接——这种场景下有状态根本不是问题。
但 MCP 一旦要支持远程 server,旧设计立刻变重。原来的流程是:客户端先发 initialize 握手,和 server 协商协议版本与双方能力;server 创建一个 session,返回 Mcp-Session-Id;之后每一次请求都得带上这个 session id。
问题藏在分布式里。握手请求可能落在实例 A,下一次工具调用被负载均衡器分到了实例 B。实例 B 没有实例 A 保存的 session,自然处理不了这次调用。一个工具调用协议,就这样背上了"长连接系统才该有的麻烦"。
服务端通常只能二选一:要么 Sticky Session(把同一客户端固定到同一实例,代价是削弱负载均衡和故障恢复);要么共享 Session Store(引入 Redis 之类的共享存储,代价是读写开销、过期清理、一致性、故障处理全套成本)。更麻烦的是,早期的 Sampling、Elicitation、Roots 这些能力还依赖服务端反向请求客户端,连接一断就要处理重连、状态恢复、消息重排。
一句话:MCP 想长成"互联网级的基础设施",但有状态的 session 是它最大的绊脚石。
对架构师,这里有个更要命的点:有状态意味着扩容能力被绑住了。流量上涨想加实例,新实例没有旧 session,分担不了老流量;想做蓝绿部署或金丝雀,session 黏在老实例上切不动;实例挂了,它名下的 session 全丢。这几条加起来,就是为什么 MCP 必须先把 session 搬走。
二、无状态核心:每个请求自己说清楚
新版本(对应 SEP-2575、SEP-2567)直接把 initialize/initialized 握手和 Mcp-Session-Id 一起请出了核心协议。协议版本、客户端身份、客户端能力,不再藏在初始化的 session 里,而是塞进每个请求的 _meta 字段,跟着请求一起走。
如果客户端确实想提前知道服务端能力,有一个新的 server/discover RPC 可以调,但它不是必需的——任何请求都能直接发,不需要先握手。
效果很直接:任何一个请求,都能落在 round-robin 负载均衡器后面的任意一个实例上,实例之间不需要共享存储。MCP server 终于可以像普通 HTTP 服务一样部署了——serverless、边缘计算、CDN 后面排一排实例,都行。
官方在博客里强调了一句,值得原话记住:这不是简单地"少发一次 initialize",而是在恢复 HTTP 最重要的工程优势——请求可以被路由、缓存、重试、追踪,实例挂了也能交给别的节点继续处理。
具体到部署,红利肉眼可见。你的 MCP server 现在可以丢进 Kubernetes 随意水平扩缩,前面挂个普通 nginx 或云负载均衡就能分发;可以塞进 serverless 函数按调用计费,不用养常驻进程;可以推到 CDN 边缘节点,让工具调用就近响应。这些在过去的有状态模型下要么做不到,要么得靠 Sticky Session 这种妥协硬撑。
三、状态没消失,只是换了位置
"协议无状态"不等于"业务无状态"。浏览器自动化、订单、复杂工作流,该有的状态还得有,只是它不再藏在传输层的 session 里。
新协议给的方案是:让工具自己生成一个句柄(handle),由模型在工具调用之间传回来。浏览器自动化第一次调用返回 browser_id,后续请求把它当普通参数传回;订单用 order_id、购物篮用 basket_id;长时间任务用 Task Handle。
这个变化看着小,意义很大。藏在 session 里的状态,模型看不见,也很难跨工具组合;显式句柄可以被模型读取、保存、传递和推理。说白了,状态从"连接知道"变成了"请求说清楚"。这不仅是协议要求,更是 agent 编排的好习惯:当状态变成模型能读、能传的显式句柄,编排逻辑就从"藏在传输层"挪到了"模型可见层",你可以让模型自己决定什么时候带哪个 handle,工具组合的灵活性跟着上来。
四、配套的四把刀
光把 session 拆了还不够,原来靠长连接解决的几个问题,得有新机制接住。这次配套了四件。这四件不是孤立的小修,而是为了让"无状态"真的能跑起来——原来靠长连接和反向请求实现的交互,现在都要换成请求/响应的形态重做一遍。
MRTR(多轮往返请求,SEP-2322)。 工具调用到一半,有时需要用户确认或补参数——比如 Supabase 的 MCP server 想在创建项目前告诉你费用,或者在执行删除前让你确认。以前这需要维持一条双向流不断开。现在服务端返回 resultType: "input_required",附上要问的问题;客户端收集到用户回答后,带着 inputResponses 重新提交原请求。一次复杂交互,被拆成几个完整、可重试、可恢复的请求。
对工程师,MRTR 还有个隐性好处:它让 elicitation(中途询问用户)这种能力,终于能在无状态环境里用了。Supabase 在官方博客里专门提到这点——他们一直想在创建项目前告知费用、在删除前确认,但 server 跑在无状态模式下,原来的双向流方案用不了。MRTR 把这个能力还给了他们。
Header 路由(SEP-2243)。 Streamable HTTP 请求现在必须带 Mcp-Method 和 Mcp-Name 两个头。好处是你的网关、限流器、WAF 可以直接基于 header 路由和鉴权,不用去解析 JSON 请求体——这在企业部署里几乎是刚需。因为在企业里,请求进来说明的第一站往往是网关或 WAF,而不是业务服务;如果路由和鉴权信息只埋在 JSON body 里,网关就得先把整个 body 解析一遍才能判断,既慢又不安全。把 method 和 name 提到 header,网关能直接按 header 做限流、分租户、拦恶意请求,业务服务再安心处理 body。
可缓存列表(SEP-2549)。 tools/list、prompts/list、resources/list、resources/read 的响应现在带 ttlMs 和 cacheScope。客户端能据此缓存工具目录,减少无谓的重复拉取,还能让上游的 prompt cache 在重连后保持稳定。这把刀影响的是"工具一多就慢"的老问题:一个 agent 接几十上百个 MCP server,过去每次会话开始都得把工具列表全拉一遍,既费流量又让 prompt cache 反复失效;现在客户端能就地缓存,重连也不用重新灌——对 agent 的首字延迟(TTFT)是实打实的改善。
授权加固。 授权服务器要按 RFC 9207 返回 iss 参数,客户端兑换前必须验证(SEP-2468),堵上"授权服务器混淆"这个洞;客户端凭据绑定到签发它的 issuer,不跨服务器复用(SEP-2352);DCR(动态客户端注册)里设 application_type,让 desktop/CLI 的 localhost redirect 不再被拒(SEP-837)。更关键的是,DCR 正式废弃,标准转向 CIMD(客户端 ID 元数据文档),DCR 还能用,但未来版本会移除。
五、扩展框架正式化:Tasks、Apps、企业认证
这次还正式锁定了 extensions 框架,几个重要能力都作为扩展独立演进,不再硬塞进核心协议。
Tasks 从实验核心挪进了 io.modelcontextprotocol/tasks 扩展,带来基于轮询的 tasks/get 和新的 tasks/update(SEP-2663);变更通知从旧的 HTTP GET 端点,改到单个 subscriptions/listen 流,客户端按通知类型按需订阅。Tasks 是 AWS 贡献的,瞄准的是可靠的长任务 agent。
MCP Apps 让工具能在对话里返回表单、图表、仪表盘、视频播放器这类交互界面——用 UI 把人和 AI 接起来,很多人认为这是这次最被低估的特性。Enterprise-Managed Authorization(EMA) 则让企业能通过统一身份提供商,集中管控 MCP server 的访问。
把 Apps、Tasks、企业认证做成"可独立演进的扩展",而不是核心协议的一部分,本身就是无状态哲学的延伸:核心保持小而稳,能力往外长。这和互联网协议的演进思路一致——HTTP 核心几十年没大变,但它上面的认证、缓存、压缩、推送,都是一层层扩展加上去的。MCP 这次把框架定下来,等于给自己铺好了同样的生长路径。
六、废弃与迁移:留了 12 个月,但破坏性是真的
Roots、Sampling、Logging 三个能力被标记废弃(SEP-2577),它们还能用,而且至少再工作 12 个月,但新实现不该再采用。旧版 HTTP+SSE transport 也进了废弃轨道,一年过渡。
协议这次第一次引入正式的废弃策略,保证最少 12 个月的过渡窗口。这对生产团队很实在——你可以排期升级,不用被动救火。但别被"12 个月"安慰到:这次是破坏性变更,新老协议不兼容,老的 server 支持不了新客户端,老的客户端也连不上新 server,过渡期很可能要两套协议并存。
官方四个一级 SDK(TypeScript、Python、Go、C#)已同步更新到新规范,Rust SDK 以 beta 跟进。SDK 团队说根据早期测试反馈简化了迁移流程,但成本因项目而异——依赖会话标识符的实现,改造是免不了的。如果你现在生产环境跑着 MCP server,先完整过一遍 changelog 和迁移指南,评估影响面再动手。评估时重点查几条:客户端有没有依赖 initialize 握手?请求里有没有带 Mcp-Session-Id?有没有用 Roots、Sampling、Logging?有没有用旧的 HTTP+SSE transport?有没有用 DCR 注册客户端?命中越多,改造量越大。
七、生态都在 day-zero 跟进,以及一句扎心的评价
生态这次站队很快。AWS(Amazon Bedrock AgentCore)、Microsoft(Foundry)、Cloudflare(Workers,Agents SDK day-zero,Sentry、Linear 已用上)、Google Cloud 都宣布支持;Figma、Supabase、Honeycomb(Honeycomb 说它近 20% 的月度交互查询已经来自 agent)这些工具厂商也在跟进。规模上,MCP 月下载接近 5 亿次,TypeScript 和 Python SDK 累计下载各自越过 10 亿。这么多一线厂商 day-zero 站队,信号很明确:MCP 已经是企业 agent 的默认底座,不是可选项。Cloudflare 那句评价挺到位——这次修订让 MCP"像 web 的其余部分一样工作:无状态、可缓存、可路由、全球可扩展"。当一个协议开始用这些词形容自己,说明它真的准备好上生产了。
有意思的是社区里的一个评价,来自开发者 @LaiskyCai:这协议"以最复杂扭曲的形式问世,然后一步步优化成了一开始就该实现的最简洁的样子"。话有点刻薄,但点到了本质——这次无状态化,本质是 MCP 在进入互联网规模部署后,重新回到 HTTP 已经验证多年的原则。从这个角度看,常高伟那篇解读里把它和 ANP(Agent Network Protocol)对比也说得通:ANP 从第一天就基于 HTTP、自描述、显式状态,MCP 绕了一圈,终于走到了同一条路上。
八、给团队的行动清单
如果你的团队在用或打算用 MCP,这份清单比结论更实用。
第一,正在生产跑 MCP server 的,立刻评估迁移面:你的实现有没有依赖 Mcp-Session-Id?有就得改。第二,新项目直接按 2026-07-28 规范来,别再上 Roots/Sampling/Logging 这几个废弃项。第三,享受无状态红利:把 server 当普通 HTTP 服务部署到负载均衡、serverless 或边缘后面,该上的缓存、重试、追踪都能上了。第四,把状态从 session 里搬出来,改成显式 handle,让模型自己传——这不仅是协议要求,更是 agent 编排的好习惯。第五,盯紧 DCR 的废弃时间线,提前规划迁移到 CIMD。还有一条给架构师的:趁这次升级,把 MCP server 的部署重新当普通 HTTP 服务审视一遍——上负载均衡、上缓存、上可观测,过去因为 session 做不了的事,现在都能补上。这次升级的真正价值不只是"兼容新协议",而是"终于能按互联网服务的方式运维你的 agent 工具链"。
总而言之:MCP 这次不是小修小补,是一次"长大了"的修订。会话没了,部署简单了,但破坏性也是真的——好在它给你留了 12 个月。这 12 个月怎么用,决定了你升级是平稳过渡还是手忙脚乱。
本文综合 MCP 官方博客、@dotey(宝玉)推文与常高伟《MCP 最新版本解读》公众号文章,技术细节与 SEP 编号以官方 2026-07-28 规范为准。本文为技术解读与讨论,不构成迁移承诺;生产升级请以官方 specification、changelog 与迁移指南为唯一依据。
参考来源
[1] MCP 官方博客:The 2026-07-28 Specification(权威一手,含 SEP 编号与字段细节) https://blog.modelcontextprotocol.io/posts/2026-07-28/
[2] MCP 2026-07-28 Specification(规范全文) https://modelcontextprotocol.io/specification/2026-07-28
[3] MCP 2026-07-28 Changelog(完整变更日志,迁移必读) https://modelcontextprotocol.io/specification/2026-07-28/changelog
[4] @dotey(宝玉)推文:MCP 第五个大版本中文解读 https://x.com/dotey/status/2082235315675144569
[5] 常高伟《MCP 最新版本解读:从有状态连接,走向无状态协议》(公众号) https://mp.weixin.qq.com/s/uhFAp3sp3h3I3gKFF8hTlg