MCP 2026-07-28 改了什么：从有状态会话到无状态核心

MCP 的规范按日期发版本。2026-07-28 这一版取代 2025-11-25，是这个协议自推出以来最大的一次架构升级。

一句话概括：它完成了从“基于连接的有状态会话协议”向“现代化无状态核心（Stateless Core）”的范式迁移。迁移之后，MCP 可以像标准 Web API 一样，在云原生、网关路由和 Serverless 架构里无缝扩展。

这篇把这次升级拆成两块讲：改了什么，以及这些改动具体解决了什么痛点。文中反复出现的 SEP 编号（如 SEP-2575）是 MCP 的规范改进提案（Specification Enhancement Proposal），可以理解为这个协议的“RFC”，每条变更都有对应的提案可查。

核心层：彻底转向无状态

最核心的变化在协议核心层。三个 SEP 合起来，把“会话”这个概念从协议里拿掉了。

先提醒一句：这里移除的是协议层会话，不是订单、任务、审批流这些业务状态——后者怎么处理，文章结尾会专门讲。

废除握手与初始化（SEP-2575）。 删除了原有的 initialize 与 notifications/initialized 阶段。协议版本号、客户端信息和能力声明，改由每个请求的 _meta（如 io.modelcontextprotocol/protocolVersion）独立携带。客户端想预检服务端能力，可以按需调用新增的 server/discover。

移除协议层 Session（SEP-2567）。 Mcp-Session-Id 请求头被彻底移除。服务端不再把状态绑定在连接或 Session 上，任意实例都可以独立处理任意请求。

多轮往返请求模式（MRTR / SEP-2322）。 MRTR 即 Multi-Round-Trip Request。服务端发起的反问和信息收集（如 Elicitation）不再依靠长连接悬挂，而是返回类型为 input_required 的 InputRequiredResult，并带上 requestState 作为断点凭据；客户端补全输入后带着它重新发起请求，服务端据此接着上一轮继续处理。

举个具体场景：报销审批工具执行时发现缺少发票类型。旧模式下，服务端要挂住一条 SSE 连接等用户补充；新模式下，它直接返回 input_required，客户端问完用户后带着 requestState 重新请求，任务继续——中间这条连接断没断过，已经不重要了。

三个变更合起来，请求形态的变化可以这样看：

旧模式（2025-11-25）：
POST initialize                  → 握手，协商版本与能力
POST notifications/initialized   → 宣告就绪
POST tools/call                  → 带 Mcp-Session-Id 头，状态挂在会话上

新模式（2026-07-28）：
POST server/discover             → 可选，按需预检服务端能力
POST tools/call                  → 每个请求自携带 _meta，无会话头

所谓“请求自包含”，落到报文上就是 _meta 里这几样东西：

{
  "method": "tools/call",
  "params": { "name": "order_pay" },
  "_meta": {
    "io.modelcontextprotocol/protocolVersion": "2026-07-28"
  }
}

SDK 不用再维护握手状态机，网关看到的每个请求也都是完整、可独立理解的——这就是“无状态核心”在工程上的实际长相。

传输与可观测性

核心层之外，这一版在传输层和可观测性上也补了四块能力，主题都是同一件事：让 MCP 流量对基础设施“可读、可缓存、可追踪”。

请求头路由机制（SEP-2243）。 Streamable HTTP 传输强制要求携带 Mcp-Method（如 tools/call）和 Mcp-Name（如具体工具名）两个 Header，网关不用解包消息体就能识别流量。

响应级缓存控制（SEP-2549）。 tools/list、resources/list 等元数据响应原生支持 ttlMs（毫秒级有效期）和 cacheScope（共享/私有），语义类似 HTTP Cache-Control。

统一通知流（SEP-2575）。 废弃旧的 HTTP GET 订阅端点，收敛为单个基于 POST 的 subscriptions/listen 流，客户端按需声明订阅类型。

标准链路追踪（SEP-414）。 在 _meta 中标准化 W3C Trace Context（traceparent、tracestate、baggage），实现端到端的 OpenTelemetry 分布式链路追踪。

扩展体系与安全强化

最后两块变更，一块解决“协议以后怎么长大”，一块解决“企业敢不敢用”。

独立版本扩展（SEP-2133）。 建立反向 DNS 规范（如 io.modelcontextprotocol.*），官方把 MCP Apps（UI 渲染）和 Tasks（长任务管理）升级为独立演进的扩展，不再和核心协议绑死在一个版本节奏里。

OAuth 2.1 安全加固。 强制服务端实现 RFC 9728（受保护资源元数据发现）；客户端必须校验 RFC 9207 的 iss 参数，防范授权服务器混淆攻击；废弃 DCR 动态客户端注册，转向客户端元数据凭证（CIMD）。

混淆攻击值得多解释一句，它是多授权中心场景的真实风险：客户端以为自己在和授权中心 A 换 token，但因为缺少 Issuer 严格绑定，token 实际被错误关联到授权中心 B，凭证就可能被跨租户、跨授权域误用。强制校验 iss，挡的就是这一下。

进入淘汰期的旧特性

以下特性正式进入 12 个月淘汰期。每一项的退场逻辑，都能从前面的变更里找到答案：

Roots（客户端文件边界声明）：依赖会话上下文维持，和无状态核心天然冲突；边界控制改由客户端在应用层显式管理。
Sampling（服务端反向请求模型采样）：本质上是一种挂在会话上的反向调用，与 MRTR 的思路重叠；需要采样编排的场景，由应用层基于 MRTR 自行实现。
Logging（协议内日志通道）：诊断能力统一交给标准化链路追踪（前面的 SEP-414）和应用日志，协议内不再单开一条日志通道。
DCR 动态客户端注册：被 CIMD 客户端元数据凭证取代，见上一节。
旧版 HTTP+SSE 传输：被 Streamable HTTP 取代。

旧版 HTTP+SSE 上榜并不意外——它的工程账，之前在 SSE 迁移那篇里已经算过了。

这些变更解决了什么痛点

变更列表本身只是“改了什么”，更有价值的问题是：每一项改动，对应解决了旧架构（2025-11-25）里的哪个真实痛点。

维度	旧版痛点（2025-11-25 架构）	新版方案（2026-07-28）	收益
横向扩展与运维	会话粘滞严重：依赖 `Mcp-Session-Id`，多实例部署必须配置 Sticky Session、共享 Redis Session 池或集中网关，Serverless 冷启动体验极差	请求自包含：移除协议层 Session，各请求携带独立上下文 `_meta`	服务端可直接挂在普通轮询负载均衡器（Round-Robin LB）后，天然支持 K8s 弹性伸缩和 Serverless
网关与流量治理	深度报文解析（DPI）开销：网关想针对 `tools/call:order_pay` 限流或按租户路由，必须解包整个 JSON-RPC 消息体，性能损耗大	Header 原生路由：直接在 HTTP Header 携带 `Mcp-Method` 与 `Mcp-Name`	API 网关（Kong、Nginx、Envoy）可在第 7 层无需反序列化 JSON，即可完成毫秒级限流、鉴权与灰度分流
反向交互与可靠性	SSE 双向悬挂易超时：服务端向客户端索取参数或人工审批时，需长时间挂起 SSE 连接，网络抖动或网关超时直接导致任务中断	MRTR 往返模式：返回 `InputRequiredResult` 并带上 `requestState`，客户端收集完成后重新发起	消除长连接断流风险，支持跨节点断点续跑、异步人机交互（HITL）
工具轮询与性能	元数据拉取频繁：客户端为感知工具变更频繁全量 `tools/list`，造成大量重复网络开销与 LLM 上下文重建延迟	原生 TTL 缓存 + 单一通知流：支持 `ttlMs`/`cacheScope`，配合 `subscriptions/listen`	显著降低网络带宽与后端计算压力，客户端能精确命中本地缓存
业务状态与可解释性	隐式连接状态黑盒化：跨工具调用依赖连接背后的 Session，LLM 自身感知不到状态流转，难以在多 Agent 协作时传递上下文	显式句柄模式（Explicit Handles）：状态转为普通参数（如 `task_id`、`draft_id`）出入参	状态显式暴露给 LLM，大模型可直接理解、组合，并跨工具、跨 Agent 灵活编排
企业安全与多租户	OAuth 混淆与伪造风险：多授权中心场景下缺乏 Issuer 严格绑定，CLI 工具与本地应用经常遭遇重定向鉴权失败	OAuth 2.1 RFC 9207 + CIMD：强制校验 Issuer，规范客户端元数据声明	杜绝凭证跨授权中心混用，全面对齐企业级零信任与 SSO 安全标准

这张表值得多看一眼的地方是最后一列：几乎所有收益都不是“协议更优雅”这种抽象好处，而是落在负载均衡、网关限流、断点续跑、缓存命中这些具体的工程动作上。

这次升级的本质

MCP 协议架构演进：从有状态会话到无状态核心

回到开头那句话：从有状态会话到无状态核心。

它的本质，是把 MCP 从“一个需要专门运维的有状态协议”，变成“一种普通的、可水平扩展的 Web API”。状态从“协议替你记住”，变成“每个请求自己说清”。

对服务端来说，部署模型简化了——不再需要 Sticky Session 和共享会话存储。对网关来说，治理成本降下来了——路由信息就在 Header 里。对 Agent 来说，状态显式化了——上下文可以跨工具、跨 Agent 传递，编排反而更灵活。

已经在跑 2025-11-25 及更早版本的服务不用慌，旧 SDK 的握手和会话实现还能继续用于兼容旧客户端；但新服务没有理由再从有状态起步。

还有一个容易误解的点要单独说清楚：协议无状态，不等于业务无状态。协议层不再替你记会话，但订单、草稿、任务这些业务状态依然存在，只是必须显式外置——放进任务记录、共享存储，或者像表里说的那样变成 task_id 这类显式句柄。该建的状态存储一个都省不掉，省掉的只是“协议帮你偷偷维护状态”这部分隐式复杂度。

存量服务怎么迁，思路可以参考传输层那篇的三步走：先评估收益，再双协议并存，最后切到无状态。

迁移检查清单

如果要把这篇文章落到行动上，可以按这五条逐项过一遍：

服务端：移除对 Mcp-Session-Id 的强依赖，把协议状态转为请求 _meta 或业务句柄（task_id、draft_id 等）。
客户端：支持 server/discover 能力预检，按请求携带版本与能力信息，并为 MRTR 实现 input_required 的交互回路。
网关：基于 Mcp-Method / Mcp-Name 配置限流、路由与审计规则，停掉 JSON-RPC 报文级的深度解析。
缓存：为 tools/list / resources/list 接入 ttlMs 缓存，并定义好失效策略（配合 subscriptions/listen 主动失效）。
安全：校验 iss 绑定授权中心，按 CIMD 更新客户端元数据方案，并排期退掉 Roots、Sampling 等淘汰特性。