MCP 史诗级架构升级：从有状态彻底转向无状态

最近 AI 工程圈迎来一件大事：MCP（Model Context Protocol）发布诞生以来最大一次架构重构。

2026年7月28日正式落地的全新协议规范，彻底推翻了沿用已久的 2025-11-25 旧版核心设计，完成了从双向有状态会话到纯无状态核心的跨越式升级。

很多同学只看到“无状态”三个字，却不清楚这次改动到底改了什么、为什么要改、对 AI 工具开发、Agent 部署、服务扩容有哪些实际影响。

这篇文章我用由浅入深的逻辑，从零讲透本次 MCP 重大更新，兼顾入门理解与工程落地细节。

先搞懂：旧版 MCP 为什么是「有状态」的？

在新版更新之前，所有主流 MCP 服务都是强会话、有状态模型，和我们日常用的 REST 接口完全不同。

旧版 MCP 的核心运行逻辑很简单：

连接建立后必须先握手：客户端必须先发 initialize 请求，和服务端协商协议版本、客户端信息、能力清单，完成初始化流程。
全局绑定会话 ID：握手成功后会生成唯一的 Mcp-Session-Id，后续所有工具调用、资源读取、提示词请求，全部绑定这一个会话。
服务端需要“记住你”：服务端会缓存当前会话的客户端能力、工具列表、连接状态，所有请求必须落在同一台服务实例上。

这种设计在早期原型、单机部署场景很友好，但一旦上生产、做集群扩容、适配云原生架构，就会暴露出致命短板。

简单说：旧版 MCP 天生不适合大规模分布式部署。

本次核心变革：协议层彻底「无状态化」

本次 2026-07-28 规范的核心灵魂，一句话总结：删掉所有协议级会话，让每一次请求自给自足、独立可运行。

这也是官方定义的「架构级破坏性更新」，新旧版本完全不互通，需要两端同步升级适配。

1. 彻底移除两大有状态核心机制

新版直接废弃了旧版的核心依赖：

删除 initialize / notifications/initialized 握手流程，不再需要初始化环节
彻底取消 Mcp-Session-Id 请求头，协议层完全消除会话概念

这意味着：服务端不需要记住任何客户端历史信息，没有会话缓存、没有连接状态、无需绑定实例。

2. 所有请求「自包含上下文」

既然没有了握手与会话，客户端、版本、能力信息如何传递？

新版引入了 每请求独立 _meta 元数据 机制：

每一次工具调用、资源请求，都会自带完整的协议版本、客户端信息、客户端能力清单。

不再是「连接初期协商一次，全程复用」，而是一次请求、一次完整上下文。

服务端拿到任意一条请求，就能独立完成版本校验、权限识别、能力匹配，不依赖任何前置状态。

3. 新增轻量能力发现接口 `server/discover`

很多同学会疑惑：没有握手，客户端怎么提前知道服务端支持哪些工具、能力？

官方给出了更灵活的方案：

默认乐观调用：直接发起业务请求，不预查询能力，失败自动感知不支持的功能
需要预加载、UI 渲染、调试场景：主动调用server/discover 主动拉取服务端能力列表

相比旧版强制握手，新版按需发现、无需强制流程，极大简化了短请求链路。

关键认知纠正：无状态 ≠ 业务不能有状态

这是绝大多数人会误解的点，这里重点讲清楚。

本次更新是 协议层无状态，不是业务层无状态。

协议层：不再托管会话、不缓存上下文、不绑定连接，完全无状态
业务层：多轮对话、长任务、数据库游标、文件会话等状态依然可以存在

唯一区别是：旧版靠「底层会话隐式携带状态」，新版靠「业务显式句柄传递状态」。

需要上下文？服务端返回 handle / token，客户端后续请求主动带入参数即可，和传统 Web 业务的 Token 设计完全对齐，逻辑更清晰、可控性更强。

配套升级：架构更干净、扩展性更强

1. 基础协议极简，能力全部插件化

新版正式落地**扩展系统（Extensions）**架构：

所有非核心能力，全部从基础协议剥离，改为版本化可选扩展，彻底解决旧版协议持续臃肿、冗余能力堆积的问题。

官方首批标准扩展覆盖高频刚需场景：

Tasks：长耗时异步任务、轮询结果管理
Apps：MCP 交互式前端 UI 渲染
Authorization：标准化企业级 OAuth/OIDC 授权
Caching：工具、资源、提示词列表标准化缓存策略

基础协议只保留核心调用能力，轻量稳定；高阶能力按需开启、互不干扰。

2. 列表接口行为全局统一

旧版 tools/list / resources/list 是会话隔离的，不同会话看到的工具列表可能不同。

新版默认全局统一，所有客户端查询到的基础能力列表一致。如果需要租户、用户级别的隔离，统一在业务层鉴权过滤，协议层不再做差异化处理。

3. 传输层适配云原生全场景

无状态改造后，MCP 彻底摆脱了「长连接、粘性会话」的束缚：

支持普通轮询负载均衡，彻底告别 sticky session
原生适配 Serverless、边缘函数、云函数短请求场景
网关、代理路由逻辑大幅简化，无需处理会话绑定逻辑

新旧版本核心差异一览（秒懂对比）

对比维度	旧版 2025-11-25（有状态）	新版 2026-07-28（无状态）
会话机制	协议内置 SessionId，强依赖持久会话	无协议会话，业务状态显式传递
连接流程	必须先 initialize 握手初始化	无需握手，直接请求，可选能力发现
元数据传递	连接初期协商一次，全程复用	单次请求 _meta 独立携带，自给自足
负载均衡	必须配置粘性会话，扩容受限	普通轮询 LB 即可，自由横向扩容
部署形态	适配常驻长连接服务	适配 Serverless、边缘短请求、集群部署
能力查询	握手阶段一次性获取	按需调用 discover 接口查询

工程落地：迁移影响与改造要点

这次更新是破坏性不兼容更新，生产环境升级需要重点关注以下几点：

废弃握手逻辑：删除客户端所有 initialize 初始化、会话维持代码
统一请求元数据：所有对外请求统一注入标准 _meta字段
状态逻辑迁移：将会话隐式上下文，全部改造为业务显式 handle/token 传递
运维配置更新：负载均衡、网关关闭粘性会话配置，改为标准轮询
能力查询改造：预加载服务端能力的场景，替换为 server/discover 接口

目前官方 TS、Python、Go、C# SDK 已发布 v2.0 适配新版，Rust SDK 已推出测试版本，可正常接入开发。

最后聊聊：这次重构的终极意义

MCP 作为 AI Agent、AI 工具生态的核心通用协议，早期为了快速落地，选择了简单的有状态会话模型。

但随着 AI 应用规模化、云端化、Serverless 化，有状态协议已经成为规模化落地的最大瓶颈。

本次无状态重构，本质是让 MCP 完成了一次「工业化升级」：

对齐互联网通用分布式架构标准
彻底解决集群扩容、运维复杂、部署受限问题
协议极简稳定，能力可扩展，长期迭代更健康
让 AI 工具调用、Agent 上下文交互，真正适配云原生全场景

未来的 MCP，不再是「AI 原型调试协议」，而是真正可以支撑企业级、大规模、高并发 AI 应用的标准基础设施协议。