MCP 变无状态了：2026-07-28 新规范深度解读

TL;DR — MCP 2026-07-28 砍掉了 session。不再需要 initialize 握手、不再需要 Mcp-Session-Id、不再需要 sticky 路由。每个请求自描述。MCP Server 现在可以放在普通的 round-robin 负载均衡后面。还有：工具能在执行中途问用户问题（MRTR）、网关可以按 header 路由不解析 body、列表响应可缓存。四大 SDK 已更新。

Sticky Session 问题终于死了

六月份花了两周调一个 MCP 部署的 bug。工具调用在 pod 重启后会随机失败。原因很蠢：Kubernetes Service 在 round-robin，但 MCP 需要 session 亲和性——因为有 initialize 握手。请求没打到对的 pod，就报 “session not found”。

解决方案是在 Ingress 层加 sticky session。能用，但丑陋、脆弱，而且一个慢 pod 会拖死所有绑定在它上面的请求。

7 月 28 日，Anthropic 发布了新版 MCP 规范。这整类问题直接消失了。协议层的 session 没了。每个请求自带上下文。负载均衡后面任何实例都能处理任何请求。

这不是小版本更新。这是 MCP 发布以来最大的架构变更。如果你在生产跑 MCP Server，部署方式、扩展方式、可靠性模型全部要重新想。

改了什么

2026-07-28 规范引入了六个主要变化：

1. 无状态核心（Session 移除）

之前：

Client → initialize → Server（拿 session ID）
Client → tools/call + Mcp-Session-Id → Server（必须打到同一个实例）

现在：

Client → tools/call + _meta{clientInfo, protocolVersion} → Server（任何实例）

initialize/initialized 没了。Mcp-Session-Id header 没了。每个请求在 _meta 里带协议版本和客户端信息。想提前知道 Server 能力？有个新的 server/discover RPC——但它是可选的。

实际意义：MCP Server 现在跟 REST API 一样无状态。随便什么负载均衡都行。水平扩展。不需要共享 session store。

2. 多轮请求（MRTR）

以前工具需要用户确认？Server 得持有一个双向 stream 然后发反向请求。这让 serverless 部署根本不可能。

现在：工具返回 resultType: "input_required" 加上需要回答的问题。Client 收集答案后重试同一个调用。无状态。普通 HTTP POST 就行。

// Server 要求确认：
{
  "resultType": "input_required",
  "inputRequests": [
    {"id": "confirm-1", "type": "confirmation",
     "message": "删除匹配 *.tmp 的 47 个文件？"}
  ]
}

// Client 带着答案重试：
{
  "method": "tools/call",
  "params": {
    "name": "cleanup",
    "arguments": {"pattern": "*.tmp"},
    "inputResponses": [{"id": "confirm-1", "value": true}]
  }
}

交互式工具可以跑在 serverless 上了。不需要 websocket，不需要长连接。

3. Header 路由

每个 Streamable HTTP 请求现在必须带：

Mcp-Method：JSON-RPC 方法名（如 tools/call）
Mcp-Name：具体的工具/资源/prompt 名

网关、WAF、限流器可以按 header 路由和计费，不用解析 JSON body。大规模部署下性能提升明显。

4. 列表响应可缓存

tools/list、prompts/list、resources/list 的响应现在带 ttlMs 和 cacheScope。Client 可以缓存工具目录，不用每次重连都重新拉。

对频繁初始化的 Agent（serverless 函数、短生命周期进程），这显著降低了冷启动延迟。

5. Auth 加固

RFC 9207 iss 验证（防授权服务器混淆攻击）
DCR 里加 application_type（CLI/桌面应用不再被拒绝 localhost 重定向）
凭证绑定到发行方（不能跨授权服务器复用）
DCR 正式废弃，改用 Client ID Metadata Documents（CIMD）

6. Tasks 正式化

Tasks 从实验性移到正式 extension（io.modelcontextprotocol/tasks），有标准的 tasks/get 和 tasks/update。长时间操作有标准化生命周期了。

怎么迁移

如果你维护 MCP Server：

今天不会 break。 SDK 处理了向后兼容：

Python v2 Server 从一个端点同时响应两个协议版本
TypeScript v2 只有你显式配置时才启用 2026-07-28
老 Client 用 initialize 仍然能连新 Server

升级到无状态模式：

pip install "mcp[cli]==2.0.0b1"

from mcp.server import MCPServer

mcp = MCPServer("my-tool")

@mcp.tool()
def search(query: str) -> str:
    """搜索知识库"""
    return do_search(query)

如果你 Server 之前在 session 里存状态：改用显式 handle。从一个工具返回 handle，让模型把它作为参数传给后续调用。模型能看到 handle 并在工具间传递——比隐藏在 transport 里的 session state 更可靠。

生产部署调整：

去掉 sticky session 配置
去掉为 MCP session 维护的共享存储（Redis 等）
在网关层加 Mcp-Method/Mcp-Name header 路由
对 tools/list 启用响应缓存

生态数据

指标	数值
SDK 月下载	~5 亿
Python + TypeScript 总下载	各超 10 亿
Spec 贡献者	384 人
GitHub Stars（spec repo）	8.9K

主流 Host 更新状态：Claude Desktop ✅、Claude Code ✅、Cursor 进行中、Kiro 进行中。

SandBase Store 有 1900+ 个 MCP Server。随着这些 Server 升级新规范，整个生态都能享受无状态扩展。

对 Agent 架构的影响

之前：Agent runtime 需要管理 MCP session、工具 Server 需要 sticky 负载均衡、serverless 很尴尬、水平扩展需要共享 session store。

现在：工具 Server 是无状态微服务、标准 HTTP 负载均衡即可、serverless 友好、scale-to-zero 可行、网关路由不需要解析 body。

对正在用 MCP 基础设施的团队，这是 MCP 发布以来最大的部署简化。

测试范围说明

我已经把两个内部 MCP Server（搜索工具和代码分析工具）迁移到 Python v2 beta。在普通 Kubernetes Service 后面工作正常。但：

Beta SDK 还不适合生产。稳定版即将发布
MRTR 很强但还新。Client 支持还在铺开中
Auth 迁移需要规划。DCR 给了 12 个月过渡期，但别等到最后
Legacy HTTP+SSE transport 已废弃。一年过渡期

FAQ

现有的 MCP Server 会 break 吗？

不会。SDK 自动处理向后兼容。新 Client 连老 Server 会回退到 initialize。老 Client 连新 Server 也行，因为新 Server 仍然响应老握手。

MCP Server 可以跑 serverless 了吗？

可以。每个请求独立——invocation 之间不需要维护 session。冷启动只影响第一个请求，tools/list 缓存意味着不用每次重新发现工具。

双向 streaming 怎么办？

Server 发起的请求（elicitation、sampling、roots）被 MRTR 替代。通知走 subscriptions/listen，Client 按需 opt-in。

什么时候应该迁移？

稳定版 SDK 即将发布。生产负载等稳定版。新项目现在就可以用 beta——API 形状基本定了。