Model Context Protocol（MCP）将推出自诞生以来最激进的一次更新。RC 从 5 月 21 日锁定，经历 10 周的 SDK 验证和社区反馈，最终版规范在 7 月 28 日正式定稿。

一句话总结变化：MCP 变无状态了。

这次更新由六个 SEP（规范增强提案）协同完成，目标一致——干掉协议层的状态。

Mcp-Session-Id 头被彻底移除。请求不再需要路由到同一台服务器实例，负载均衡器不再需要 sticky session，也不再有共享 session store。任何请求可以落到任何实例上，和 HTTP 的设计哲学终于对齐了。

initialize / initialized 握手流程也被删掉了。协议版本、客户端信息、能力声明不再在"连接时"一次性协商，而是通过每个请求的 _meta 字段传递。这也意味着你的服务器再也不能在连接时做一次权限校验就了事——每次请求都得自己能站住。

跨调用的状态怎么办？MCP 维护者的回答是：显式化。服务器返回一个不透明的 handle（比如 basket_id），模型在后续调用中主动传回来。团队的说法很直接——"显式 handle 模式只是把状态从协议层藏起来变成了模型可见。"换句话说：别偷偷摸摸记状态，让模型自己管。

服务器到客户端的请求也被约束了。以前服务器可以随时推送（比如请求用户输入），持续维持 SSE 连接。现在服务器只能在处理客户端请求期间发起反向请求，结果通过 InputRequiredResult 带一个 requestState token 返回。客户端重新发起原调用时带上 inputResponses。任何实例都能接住这个重试，不需要去找原来的服务器。

还有两个新增的强制请求头：Mcp-Method 和 Mcp-Name。有了它们，网关和负载均衡器不需要解析请求 body 就能做路由决策——这对企业部署是实打实的利好。

扩展在这次更新中变成了一等公民。用反向 DNS 标识（如 ext-*.mcp.io），通过 extensions 能力映射协商，独立的 Extensions Track 管理生命周期。社区的创新可以独立于核心规范演进和版本化。

两个具体的扩展值得关注。一个是 MCP Apps（SEP-1865）：服务器可以在沙箱化 iframe 中提供 HTML UI，工具预先声明 UI 模板以支持预加载和缓存。UI 与宿主之间的通信走的是同一套 JSON-RPC 协议，审计和授权路径与直接工具调用一致。

另一个是 Tasks 从实验性核心功能毕业到扩展（SEP-2663）。改为轮询模式——tasks/get、tasks/update、tasks/cancel。任务创建变为服务端决策（客户端声明支持，服务端决定是否走异步），tasks/list 被直接移除，因为缺乏 session 后无法安全限定范围。

认证方面，六个 SEP 把 OAuth 2.1 安全实践写进了规范正文：客户端必须验证 iss 参数防止 mix-up 攻击、支持 Dynamic Client Registration、凭证绑定到颁发服务器、刷新 token 流程文档化、scope 累积规则明确。旧式的密码授权和隐式授权被彻底剔除。

inputSchema 和 outputSchema 现在完整支持 JSON Schema 2020-12——oneOf、anyOf、allOf、条件、$ref、$defs 全部可用。输入 schema 的根节点仍约束为 type: "object"，输出 schema 不受限制。规范明确要求：不要自动解引用外部 $ref URI（防 SSRF），应该限制 schema 深度和校验时间。

Roots、Sampling、Logging 三个原语进入 12 个月倒计时。Roots 改用工具参数或资源 URI 替代，Sampling 直接调 LLM API，Logging 用 stderr 或 OpenTelemetry。协议还引入了一个全生命周期的特性淘汰策略：Active → Deprecated → Removed，每个阶段至少 12 个月，一个 SEP 要上到 Final 级别必须有对应的合规测试用例落地。

对于今天就必须动手改的东西，三个硬断裂今天生效。

第一，Mcp-Session-Id 头没了。传输层里如果有 sessionIdGenerator 配置，删掉。协议版本和客户端信息改从 _meta 读取。第二，initialize / initialized 握手没了。能力校验逻辑从握手阶段移到每个工具调用的入口。第三，错误码变了。资源未找到的错误码从 MCP 自定义的 -32002 改为 JSON-RPC 标准的 -32602（Invalid Params）。所有硬编码该值的地方都要换。

Akamai 的安全研究团队在这个 RC 上做了一轮审计，结论很诚实：无状态化确实消灭了协议层的 session 劫持、未经请求的服务端推送、弱认证方式。但同时也把五个新的攻击面摆到了台面上。

跨 agent 工作流劫持——如果 tracking ID 是可预测的，或者 state 对象未经校验，攻击者可以劫持其他用户的工作流。_meta 对象注入——如果服务器盲目信任元数据做路由或授权决策，无签名的自定义字段就是提权通道。头部与 body 反序列化冲突——Mcp-Method 头和 JSON-RPC body 不一致时可能绕过安全控制。MCP Apps 中的存储型 XSS——沙箱 iframe 的 UI 仍然面临钓鱼和数据窃取风险。一击脱离 DoS——攻击者发一个昂贵的长时间任务然后立即断开，服务器自己扛所有计算成本。

以前协议层帮你挡掉的脏活，现在搬到应用层了。

MCP 这次更新的方向是对的。session 的引入原本就是工程上的捷径——让一个天生无状态的 JSON-RPC 协议背上有状态包袱，部署复杂度直接翻倍。切掉之后，水平扩展回到纯 HTTP 的玩法，这对企业级部署是及格线而不是加分项。

显式 handle 模式也是个聪明的选择。让模型自己管理状态，不是增加了复杂度，而是让复杂度发生在它本来就该发生的地方——推理层。对调试和审计也更友好：所有的状态传递都在参数里可见。

短期阵痛主要在迁移——任何深度依赖 MCP session 机制的服务需要重写状态管理逻辑。但那些本来就不依赖 session 的简单工具服务，基本不受影响。

12 个月的弃用窗口给足了时间。问题是，有多少人会等到第 11 个月才开始动手。

参考来源：

• The 2026-07-28 MCP Specification Release Candidate — MCP Blog
• What actually breaks in your MCP server on 2026-07-28 — dev.to
• New MCP specification kills old risks but opens fresh attack surfaces, Akamai finds — SiliconANGLE