30 秒快速回答

MCP 2026-07-28 是 Model Context Protocol 自去年远程 MCP 推出以来最重要的一次版本升级：协议核心从”双向有状态”彻底转向”请求/响应无状态”，正式移除 initialize/initialized 握手和 Mcp-Session-Id 头；服务器主动发起的 sampling、elicitation 等交互被重构为 MRTR（Multi Round-Trip Requests，多轮往返请求）；Streamable HTTP 请求必须携带 Mcp-Method 与 Mcp-Name 头以支持网关直接路由计量。

核心价值一句话：MCP 不再依赖会话和长连接，任何请求都可以落在轮询负载均衡器后的任意实例上，这让 MCP Server 第一次可以像普通 HTTP 服务一样水平扩展——这是 Agent 基础设施走向生产级的关键一步。

一、为什么说这是”无状态化”革命？

在此之前，MCP 是双向有状态协议：客户端必须先握手建立会话，所有后续请求都要带上会话 ID。这给生产部署带来一个老大难问题——Server 扩容时，会话状态存哪里？负载均衡器只能把同一会话的请求粘到同一实例，否则就”掉线”。

2026-07-28 版彻底改变了这一点（SEP-2575 / SEP-2567）：

  • 移除 initialize/initialized 握手和 Mcp-Session-Id 头；
  • 每个请求自描述，在 _meta 中携带协议版本、客户端身份和客户端能力；
  • 新增可选的 server/discover RPC，客户端可在正式调用前查询服务端能力，但不强制；
  • 任意请求可落在轮询负载均衡器后的任意实例上，无需共享存储。

一个无状态请求的完整 HTTP 示例：

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"}}}}

注意：协议无状态不代表应用必须无状态。如果 Server 需要在调用间携带状态，官方建议”由工具显式签发一个 handle，让模型作为参数传回”，这比藏在传输层的会话状态更透明、更可控。

二、MRTR：用”多轮往返”替代”常开流”

有状态时代，服务端需要向客户端要东西（比如向用户要确认、要模型采样、要 roots 列表）时，靠的是保持打开的流反向推送。无状态化之后这条路走不通了，MRTR（SEP-2322）给出了新范式：

  1. 服务端处理工具调用中途需要补充信息（如用户确认、缺失参数）；
  2. 服务端返回 resultType: "input_required"，并附带需要回答的请求；
  3. 客户端收集答案后，在 inputResponses 中携带答案重试原调用。

MRTR 替换了原先服务端主动发起的 elicitation/create、sampling/createMessage 和 roots/list，不再需要任何常开的双向流。

MRTR 请求-响应流程示意：

客户端                      服务端
  │  tools/call (step 1)      │
  │ ────────────────────────> │
  │                           │  处理中需要用户确认
  │  resultType:"input_required" + 待回答请求
  │ <──────────────────────── │
  │  用户完成确认，重试原调用  │
  │  tools/call + inputResponses
  │ ────────────────────────> │
  │  最终工具结果             │
  │ <──────────────────────── │

三、旧版 vs 新版：关键差异一览

维度 旧版（2025-11 及之前） 新版（2026-07-28）
连接模型 双向有状态，常开流/SSE 请求/响应无状态
握手 initialize / initialized 必需 已移除（SEP-2575/2567）
会话标识 Mcp-Session-Id 头 已移除，状态由显式 handle 传递
服务端主动交互 保持流反向推送（sampling/elicitation/roots） MRTR：input_required + inputResponses 重试
HTTP 路由 需解析 JSON body Mcp-Method / Mcp-Name 头直接路由计量
List 结果缓存 无缓存提示 ttlMs + cacheScope，可缓存工具目录
能力发现 握手阶段协商 可选 server/discover RPC
Tasks 实验性核心 移入 io.modelcontextprotocol/tasks 扩展，新增 tasks/update
传输层 HTTP+SSE 旧 HTTP+SSE 正式弃用（12 个月缓冲）
授权 弱 iss 校验 RFC 9207 iss 校验 + 凭据绑定 issuer + CIMD 取代 DCR

四、缓存、授权与生态：生产化的另一半拼图

List 可缓存（SEP-2549）：tools/list、prompts/list、resources/list、resources/read 的响应携带 ttlMs 和 cacheScope，客户端可以缓存工具目录、减少重复拉取；同时返回确定性顺序，让上游提示缓存跨重连保持稳定。

授权强化：授权服务器按 RFC 9207 返回 iss 参数，客户端在兑换 code 前必须校验（SEP-2468），堵住授权服务器混淆漏洞；DCR 期间客户端设置 application_type（SEP-837），解决 CLI 桌面应用 OAuth 的 redirect_uri 报错；客户端凭据绑定到签发它的 issuer，禁止跨授权服务器复用（SEP-2352）；DCR 正式弃用，转向 Client ID Metadata Documents（CIMD）。

弃用清单：Roots、Sampling、Logging 弃用（至少 12 个月缓冲期）；旧 HTTP+SSE transport 正式弃用；DCR 弃用。新实现不应再采用这些能力。

生态支持：TypeScript / Python / Go / C# 四个 Tier 1 SDK 已同步更新，Rust SDK 以 beta 支持；AWS Bedrock AgentCore、Cloudflare Agents SDK、Microsoft Foundry、Google Cloud 等均已跟进。生态规模上，Tier 1 SDK 月下载量已接近 5 亿次，TypeScript 与 Python SDK 累计下载均突破 10 亿。

总结要点

  1. 无状态核心：移除握手与会话头，每个请求自描述，可水平扩展，这是本次升级的最大变化。
  2. MRTR 范式：input_required + inputResponses 重试取代常开流，服务端交互在无状态协议下依然完整。
  3. 头路由：Mcp-Method / Mcp-Name 让网关、限流器、WAF 直接基于头路由计量。
  4. 缓存与授权：List 结果可缓存，授权侧补齐 iss 校验与 CIMD 迁移。
  5. 迁移窗口：弃用项有至少 12 个月缓冲，但新项目应立即按新版规范构建。

延伸阅读：官方发布公告《The 2026-07-28 Specification》；SEP-2322（MRTR）与 SEP-2549（List 缓存）提案；MCP 官方 SDK 迁移说明；本站 guide-109（MCP Tasks）与 guide-21（MCP 基础）可配合理解扩展框架与协议演进脉络。