MCP 协议升级：Stateless 化对开发者的影响

你在生产环境部署过 MCP 服务器吗？最近我读到一份 Arcade 工程师的解析，把 session 的痛点讲得很透------本地跑 demo 很简单，但放到负载均衡后面扛 10,000 个用户时，session 管理谁用谁知道。

今年 5 月，MCP 团队丢出了 2026-07-28 协议版本 RC------发布以来最大修订。7 月 28 日正式发布，核心变化：Stateless（无状态）。

本文帮你判断：这个升级对你意味着什么、你的 MCP 服务器需要改什么。

一、session 是怎么成为瓶颈的

MCP 当前的协议（2025-11-25）工作方式很简单：

客户端连上服务器 → 发送 initialize 握手 → 服务器分配一个 session ID → 后续每次请求都带上这个 ID。

本地跑完全没问题。一台机器上两个进程互相喊话，session 在内存里一存就完事。

但放到生产环境就不一样了：

bash 复制代码

旧协议：
Client → initialize(握手) → 服务器返回 Mcp-Session-Id
      → 每次请求带 Mcp-Session-Id 头
      → 服务器必须在内存里维护会话状态
      → 负载均衡必须配置 sticky session 或共享 session store

你的服务器部署在负载均衡后面，N 个实例轮询处理请求。第一个实例发了 session ID，第二个实例也得认得------要么共享 session store，要么 sticky session 把同一客户钉在同一台机器上。两种方案都不便宜，而且跟负载均衡的设计哲学拧着来。

Arcade.dev 工程师 Nate Barbettini 说得直白：

"Picture a real deployment. You're running a server for millions of users, behind a load balancer... every one of those machines has to know about a session ID that some other machine handed out."

这个痛点，是大厂迟迟不上 MCP 生产集成的核心原因。

二、新协议：握手消失，session 消失

2026-07-28 协议最核心的变化，就是彻底移除握手和 session。

新协议不再需要 initialize/initialized 两步握手（SEP-2575）。客户端信息、协议版本、能力声明，这些以前只在连接开始时交换一次的东西，现在通过 _meta 字段随每次请求一起发。Mcp-Session-Id 头也一并移除（SEP-2567）。

对比一下就清楚了。

旧协议（2025-11-25）：

json 复制代码

// 第一步：握手
POST /mcp HTTP/1.1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25","capabilities":{},
           "clientInfo":{"name":"my-app","version":"1.0"}}}

// 后续每次请求带 session ID
POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

新协议（2026-07-28）：

json 复制代码

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

注意几个关键变化：

没有握手了------直接发请求就行
没有 session ID 了------每条请求自包含
新增三个 HTTP 头 ：MCP-Protocol-Version、Mcp-Method、Mcp-Name，负载均衡器和网关可以直接按方法路由，不用拆包解析 JSON
客户端身份信息通过 _meta 里的 io.modelcontextprotocol/clientInfo 键携带

这意味着任意服务器实例都可以处理任意请求。轮询负载均衡就行了，不用 sticky session，不用共享 session store。

三、配套变化不止 stateless

Stateless 是头号新闻，但这次升级还带了几个同样重要的配套变化。

3.1 缓存控制

List/resource 响应携带 ttlMs 和 cacheScope（SEP-2549），跟 HTTP Cache-Control 一个道理。客户端知道结果能缓存多久、能否跨用户共享。

3.2 分布式追踪

W3C Trace Context（traceparent、tracestate）正式写进规范（SEP-414）。一条追踪可以从宿主应用穿过客户端 SDK、MCP 服务器再到下游服务，在 OpenTelemetry 后端展示完整调用链。

3.3 授权强化

六个 SEP 对齐了 OAuth 2.0 / OpenID Connect 最佳实践：验证 iss 防混淆攻击、声明 application_type 避免桌面客户端被误判为 web、凭证绑定到签发服务器。

3.4 Roots、Sampling、Logging 废弃

特性	替代方案
Roots	工具参数或服务器配置
Sampling	直接接 LLM 供应商 API
Logging	stdio 用 stderr，结构化用 OpenTelemetry

这些在当前版本依然可用，往后至少 12 个月内不会移除------MCP 正式引入特性生命周期策略：Active → Deprecated → Removed 至少间隔一年。

3.5 MCP Apps 和 Tasks

Extensions 有了正式框架：reverse-DNS 标识、独立版本管理。两个官方扩展：

MCP Apps：服务器渲染 HTML 界面，沙箱 iframe 展示，UI 操作走 MCP JSON-RPC
Tasks：从实验特性升级为扩展，返回 task handle 驱动生命周期

3.6 JSON Schema 2020-12

Tool 的 inputSchema 和 outputSchema 升级到完整 JSON Schema 2020-12（SEP-2106）。输入支持 oneOf、anyOf、$ref，输出去掉类型限制。以前只能定义简单 JSON，现在可以做组合约束和条件校验。

四、Breaking changes------你的代码要改什么

看了上面这些变化，你的第一反应可能是：「听起来不错，但我要改多少？」

需要明确改的：

改动项	影响范围	迁移难度
移除 `initialize`/`initialized` 握手	所有 MCP 服务端和客户端	⭐⭐
移除 `Mcp-Session-Id`	所有依赖 session 的代码	⭐⭐⭐
新增 `MCP-Protocol-Version`/`Mcp-Method`/`Mcp-Name` 头	服务端实现 + 中间件	⭐
错误码 `-32002` 改为 JSON-RPC 标准 `-32602`	匹配 `-32002` 的客户端	⭐
Tasks API 生命周期重构	使用了 Tasks 的开发者	⭐⭐⭐
Server-initiated requests 只能在工作处理期间发起	所有 MCP 服务端	⭐⭐

好消息是：版本协商机制已经内置了。

旧客户端（2025-11-25）声明自己的协议版本，支持多版本的服务端可以同时跟新旧两端通信。这意味着你不需要一次性把整个生态翻新。服务端先升级支持双版本 → 客户端逐步升级 → 最终下线旧协议。

坏消息是：协议层不向后兼容。一个只认识 2025-11-25 的客户端，无法直接跟仅支持 2026-07-28 的服务端对话。中间需要 Arcade 这样的网关做协议转换，或者你自己维护版本兼容层。

五、对开发者的影响

这次升级对不同类型的 MCP 开发者，影响是不一样的。

如果你是 MCP 服务端开发者，这是最直接的受益者。去掉 session 处理后，你的服务器从「需要 sticky session + 共享 session store」简化成了普通 HTTP 服务，部署和维护成本都降低。新协议比旧的简单得多。

如果你是 MCP 客户端开发者，你的应用需要注意版本兼容问题。如果你依赖的服务器还没升级，你可能需要保持旧协议支持或者通过兼容层过渡。

如果你只是使用 MCP 的普通用户，这个升级基本透明。你会看到更稳定的连接和更少的「会话过期」错误。

7 月 28 日正式发布。如果你已经在跑 MCP 服务端，现在打开官方 draft 规范开始研究迁移路径，时间刚刚好。协议的变化挺大，但方向是对的------让 MCP 终于像 Web 一样工作了。不用 sticky session、不用共享存储、任何实例都能接手任意请求，这才是生产级的协议该有的样子。

协议规范：modelcontextprotocol.io/specificati...

变更日志：modelcontextprotocol.io/specificati...

Arcade 深度解读：www.arcade.dev/blog/mcp-go...

MCP 官方 RC 公告：blog.modelcontextprotocol.io/posts/2026-...