2026 年 7 月 28 日，Anthropic 发布第 5 版 MCP（Model Context Protocol）规范，官方定性为“问世以来最大、最系统性的一次修订”。核心变化一句话：从双向有状态连接，转向完全无状态的协议核心，同时引入独立的扩展生态系统。微软当天跟进发布 C# SDK v2.0，Cloudflare、Vercel、AWS 一周内都宣布支持——这次修订不是纸面更新，是生态层面的切换。

好消息是官方留了 12 个月弃用窗口，主流的 2025-11-25 客户端不会在 7 月 28 日当天集体失效。坏消息是，如果你维护 MCP server，迟早要改，而且“怎么改”比“改什么”更容易踩坑。这篇按“变更 → 工程含义 → 迁移顺序 → 安全清单”的顺序给一份可以照着做的清单。

先看变更总览

维度	2025-11-25 及更早	2026-07-28
协议状态	有状态（Stateful）	完全无状态（Stateless）
握手	必须 initialize / initialized	移除协议级握手；server/discover 可选预探索
会话	Mcp-Session-Id 头，服务器维护会话状态	无会话；每个请求自包含协议版本与能力
路由	需要粘性会话（Sticky Sessions）	任意网关/实例，可跑 AWS Lambda、Cloudflare Workers
HTTP	Streamable HTTP + SSE 长连接	单次自描述 HTTP POST，Mcp-Method / Mcp-Name 头
中途交互	依赖长连接（SSE）	MRTR（Multi Round-Trip Requests）
扩展	核心协议内建	版本化扩展框架：MCP Apps、Tasks
鉴权	可选的 OAuth 流程	对齐 OAuth 2.1，PKCE 必选，废弃密码/隐式授权

每个变更的工程含义

握手移除，版本协商进了 _meta。 新规范里每个请求都在 _meta 里带协议版本和客户端能力（io.modelcontextprotocol/protocolVersion、io.modelcontextprotocol/clientCapabilities），服务器不再靠一次 initialize 记住你是谁。这带来的直接好处是请求可以发给任意实例；代价是服务器不能再假设“连接建立过”，任何依赖初始化阶段做的配置、能力探测，都要改为逐请求处理或显式走 server/discover。

会话 ID 没了，状态责任转移。 以前服务器把会话状态存在内存或 Redis，靠 Mcp-Session-Id 找回。现在协议不管理会话，需要跨请求延续的状态（一个多步任务的进度、等待用户确认的中间态）要么放进响应里交给客户端回传，要么自己落到外部存储。这正好是 Akamai 指出的第一类新风险：客户端持有任务状态的“钥匙”，服务器不能盲信。后面安全清单展开说。

HTTP 标准化，路由不需要解析 body。 新规范的请求是“单次自描述 HTTP POST”，tools/call 会带上 Mcp-Method: tools/call、Mcp-Name: get_order_status 这样的头。负载均衡、API 网关、WAF 可以只看头就路由、缓存、限流，不需要深包检测。x-mcp-header 指令还能把指定的工具参数直接映射成 HTTP 头。方便是真的，但“头里带什么”从此成了安全问题。

MRTR 替代长连接。 无状态协议还要支持“调用到一半服务器要问客户端要东西”——确认一次危险操作、请求补充输入、sampling、roots/list。旧方案是维持一条 SSE 长连接等回话；新方案是 MRTR（SEP-2322）：服务器返回一个“我需要你先给我 X”的结果，客户端再发起下一次请求，连续性全部放在 payload 里。微软 C# SDK v2.0 把它列为 2026-07-28 版的头条特性，服务端和客户端都支持。

扩展机制独立出去。 MCP Apps（AI 应用里的交互面板，表单、仪表盘、文档查看器）和 Tasks（长时间运行任务）成为一等协议扩展，不用再改核心协议。代价是 Sampling 这个旧特性被标记废弃。

鉴权对齐企业身份体系。 新规范要求 OAuth 2.1，废弃密码和隐式授权，PKCE 必选，并强化了 OIDC 适配，MCP server 可以直接对接 Entra、Okta 这类企业身份系统，不用再绕变通方案。

迁移顺序：先双栈，再切换，别搞 flag-day

生态里普遍采用的做法是“逐请求协商版本”，而不是一个时间点集体切换：网关同时广告 2025-11-25 和 2026-07-28，客户端要哪个版本就给哪个版本的行为。AWS AgentCore、Cloudflare、Vercel 的兼容层都是这个思路。照着做：

1. 先不动旧路径。 保持 2025 时代的 Streamable HTTP 路径可用，把新协议作为并行入口接进来。
2. 移除对 initialize 的隐式依赖。 搜索代码里所有“建立连接后一次性完成”的逻辑：能力协商、配置下发、权限快照。逐请求处理，或用 server/discover 显式提供。
3. 把状态改成可回传。 需要跨请求延续的任务，定义明确的 tracking ID / state object，随响应交给客户端，客户端原样带回。回传前必须做完整性校验（签名或加密），因为这份状态来自客户端。
4. 中途交互改 MRTR。 所有依赖 SSE 长连接的“等用户确认/等补充输入”逻辑，改成 MRTR 的请求-回传模式。
5. 检查 HTTP 头与 body 的一致性。 路由层看 Mcp-Method / Mcp-Name，应用层读 JSON-RPC body，两边必须校验一致，否则会有头 body 分离（desync）绕过。
6. 用新工具验证。 Postman MCP Inspector 已支持新 transport；Cloudflare、Vercel 的 handler 同时提供新协议和旧客户端兼容层，可以用来做双栈回归。

安全清单：风险从协议层搬到了应用层

Akamai 在规范发布前做了专项分析，结论很直白：新规范消灭了旧的一批协议级风险（会话 ID 被偷、服务器乱发提示打断用户），但把安全决策交给了每个实现者。迁移时对照下面六条自查：

1. 客户端回传的状态一律不可信。 预测性 tracking ID、未校验的 state object，都可能被用来劫持别人的任务、跨租户拿数据。服务端必须对状态做密码学完整性校验，且 ID 要不可预测。
2. _meta 不签不验会出事。 客户端能在几乎任何消息上附加自定义元数据（比如一个 tenant: admin），没有签名。服务器如果拿它做路由或授权，一次伪造就是提权。所有元数据当不可信输入处理。
3. 头 body 必须对齐。 Mcp-Method / Mcp-Name 与 JSON-RPC body 不一致时，代理和服务器各自信任一半，就出现了两个控制面都能被绕过的 desync。网关层和应用层要双向校验。
4. x-mcp-header 别映射敏感参数。 把 API key、token、个人信息映射进 HTTP 头，等于把秘密明文送给路径上的每个负载均衡、代理和日志系统。白名单只放无敏感性的参数。
5. MCP Apps 面板按不可信 HTML 处理。 存储型 XSS 被带进了 AI 生态：通过工具写入恶意 HTML/JS，别的用户或 Agent 打开面板就执行。规范要求 sandboxed iframe（挡住了全面接管），但面板仍可钓鱼、伪提示、偷看面板可见数据。输出编码是基本盘。
6. 异步任务要配额。 “hit-and-run”：客户端发起一个昂贵的长任务，立刻断连，服务器继续空转直到资源耗尽。长任务必须有资源配额、超时和可取消机制。

什么时候必须迁，什么时候可以等

有 12 个月弃用窗口，但节奏建议这样排：

• 现在就要动手：新上线 MCP server、要做多实例/serverless 部署、要接企业 OAuth/OIDC 身份体系的团队。新规范在这几件事上的收益是实打实的：去掉粘性会话后，请求可以路由到任意实例，部署模型立刻简化。
• 可以缓一缓：内部自用、单实例、没有长连接中途交互的 server。双栈兼容层已经让新旧客户端共存，等依赖的上游 SDK 稳定再切也来得及。
• 必须警惕的：任何“把状态交给客户端”的设计，没做签名校验就等于把跨租户漏洞写进代码。这跟协议版本无关，是迁移时最容易顺手埋下的雷。

最后留个观察点：Sampling 被废弃、Apps/Tasks 上位之后，MCP 的定位已经从“本地单用户接工具”变成“企业级云原生平台”了。下一轮值得看的是身份层和任务层能不能真的像 SDK 路线图说的那样做到 turnkey——协议无状态化只是第一步，状态和安全边界最终落在每个实现者的肩上。

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。

X

X / Twitter

关注 @ax2_zicode

更即时的技术观察、新文章提醒和一些短想法会发在 X 上。