MCP 史上最大更新：RC 重写移除了整个基础设施层，开发者必须知道的 5 个变化

发布时间：2026/7/27 19:42:49

深度解读。
一句话：MCP 协议发布以来最大手术——Session 和初始化握手被移除，Server 不再需要 Session Affinity、分布式 Session Store 等额外基础设施。这个变更在 2026 年 5 月 21 日冻结 RC，7 月 28 日发布正式规范。

§1 开篇钩子

2026 年 7 月 28 日，MCP 协议将迎来它发布以来最大的一次变更。但和大多数协议更新不同——这次不是加功能，而是大量删东西。

Session 没了。初始化握手取消了。三个核心特性被标记为废弃。如果你在过去一年里搭建过远程 MCP Server，那套基于Mcp-Session-Id的会话亲和性、外部分布式 Session Store、以及为 Capability Negotiation 做的路由逻辑——全都不需要了。

这篇文章来自 The New Stack，作者 Janakiram MSV 以架构师视角解读了这次 RC 重写的设计逻辑。简单说，MCP 之前给自己创造了一个分布式系统难题，然后让所有 Server 开发者买单。这次重写就是还债。

§2 MCP 协议是什么，为什么它值得关注

Model Context Protocol（MCP）是 Anthropic 在 2024 年底推出的一套开放协议，目标是给 AI 模型（特别是 Agent）和外部工具、数据源之间定一个标准化的通信方式。

类比一下：如果说 HTTP 是浏览器和服务器之间的协议，那 MCP 就是 AI Agent 和工具之间的协议。Claude Code、Cursor、各种 AI IDE 和 Agent 框架都在用 MCP 来连接代码仓库、数据库、API 网关这些外部系统。

MCP 的核心设计是 Client-Server 架构：

MCP Client：AI 模型或 Agent 框架
MCP Server：对外暴露工具、资源、提示词
传输层：本地用 stdio，远程用 SSE（Server-Sent Events）

协议在 2024 年底推出后迅速成了 AI Agent 工具集成的实际标准。但也正因为推得快，一些设计上的取舍在远程部署场景下暴露出了问题。

§3 RC 重写到底改了啥

这次 RC 重写涉及 6 个规范增强提案，核心变更可以归纳为3 删 2 加 1 保底。

3 删：Session、握手、Capability 协商

Session 被移除，是这次变更中最有冲击力的一条。之前的 MCP Server 在建立连接时会生成一个Mcp-Session-Id，客户端后续请求都带上它。这在桌面端场景没问题——一个进程对应一个长期连接。但到了远程场景，问题就来了：

一个 Server 需要 Session Affinity（粘性会话），把同一个 Session 的请求固定到同一台实例上。或者搞一套外部分布式 Session Store。或者让网关解析 JSON Body 来做路由。

一句话：协议给自己创造了一个分布式系统难题，然后让所有 Server 开发者买单。

初始化握手被移除。之前连接建立时 Client 和 Server 要互相交换 Capability 信息。现在这些信息被移到_meta字段里，每个请求都带上协议版本和客户端能力。

Capability 协商被简化。之前 Capability 只在连接时协商一次，不同连接拿到的结果可能不一样，缓存和中间件很难推理。现在 Server 通过server/discover方法独立暴露能力，可以按需查询。

2 加：Handle 模式和 TTL 缓存

Handle 模式是 Session 移除后的替代方案。逻辑很简单：如果一个工具需要记住状态，就自己返回一个 Handle（比如basket_id），模型在后续调用中把 Handle 当作参数传回来。

这个模式的精妙之处在于：Handle 对模型是可见的。之前藏在传输元数据里的 Session 状态，模型完全没法感知和推理。现在 Handle 出现在 Tool Result 中，模型可以跨工具组合、在工作流步骤之间传递。

TTL 缓存机制被引入。List 和 Read 操作的结果现在必须包含ttlMs和cacheScope字段，类似 HTTP 的 Cache-Control。客户端可以在指定时间内缓存目录结果，不用每次都重新拉取。Server 还被要求按确定顺序返回工具列表——这有助于提升 Prompt 缓存的命中率，在那些按缓存 Token 定价的提供商那里直接省成本。

1 保底：特性生命周期政策

每个 MCP 特性现在都有明确的 Active → Deprecated → Removed 三阶段生命周期，最短 12 个月的废弃窗口（安全风险除外可缩短到 90 天）。还有一个公开注册表列出哪些特性正在退出以及退出时间。

对于需要向平台审批委员会证明 MCP 集成可靠性的团队来说，一纸书面弃用保证比任何新功能都有价值。

§4 对开发者的实际影响

Server 作者

你的远程 MCP Server 现在可以像普通无状态 HTTP 服务一样运营了。三个副本跑在 Round-Robin 后面，不需要 Session Affinity 配置，不需要跑 Session Store 也不需要做故障恢复。滚动部署不会再让 Session 失效或者把客户端挂在已下线的实例上——虽然还在处理中的请求和订阅流还是会中断，但客户端只需要在新请求 ID 下发起重试。

对于平台团队，新的Mcp-Method和Mcp-Name头意味着网关可以按操作类型做限流和鉴权，不需要解析请求 Body。当然这只有在传输层校验开启时才成立——Backend 会拒绝任何 Header 和 Body 不一致的请求。

使用 Tasks API 的开发者

Tasks 在 2025 年 11 月作为实验性核心特性发布，实际生产使用暴露了设计问题。现在它被重构为扩展，移出核心规范。这是一个破坏性规范变更，但下一个迭代不再是了——因为扩展通过 Capability Flag 或设置级版本演进，只在不得不破坏时才换标识符。

使用 Sampling 和 Logging 的 Server

废弃的特性需要迁移路径。Sampling 是最尖锐的例子——之前 Server 通过 Client 做模型采样不需要 Provider 凭据，也不承担账单。现在直接调用 Provider API，Server 成了凭据持有者、账单承担者和独立的数据处理器。

Logging 也是。之前通过 stderr 给远程 Client 发结构化日志流，现在 Operator 观察性交给 OpenTelemetry。

§5 影响与展望

从框架到标准

MCP 这次 RC 重写传递了一个清晰的信号：它在从一个框架变成一个标准。框架可以加功能，标准必须做减法——移除不必要的抽象层，让协议更贴合已有的基础设施。

扩展机制是一个佐证。扩展现在有命名空间 ID（官方用io.modelcontextprotocol，第三方用反域名），有自己的仓库和发布节奏。写过 Kubernetes CRD 的人会立刻认出这个模式——能力在核心发布周期之外独立演进。

无状态化不是万能药

需要指出一点：协议层的无状态买的是可路由性，不是确定性。两个副本接受同一个请求不需要查询协议状态——但如果它们跑着不同版本或者读取了不同的下游数据，返回的结果还是不一样。

迁移窗口

维护者给了 10 周的验证窗口，以及 Python、TypeScript、Go、C# 四个语言的 Beta SDK。迁移路径设计得很务实：Client 先用server/discover探测，遇到仅支持旧协议的 Server 时回退到initialize。这是一个线缆级的破坏性变更，但用协商路径跨了过去，不是生态层面的 Flag Day。