你部署了一个 MCP 服务器功能都跑通了本地测试也没问题。然后用户量上来发现响应越来越慢偶尔还丢连接。查了半天问题出在会话管理上。旧版 MCP 协议要求每个客户端必须先完成initialize 握手拿到一个Mcp-Session-Id后续所有请求都得带着这个 ID。服务端靠这个 ID 把请求路由到正确的会话状态。听起来没问题但一旦你把服务部署到多个节点麻烦就来了。要么配sticky sessions让同一个用户的请求永远打到同一台机器。要么搭个 Redis 集群把会话状态存到共享存储里。前者浪费资源后者增加运维复杂度和故障点。不是因为你的代码写得差其实是旧的 MCP 协议设计的锅。说实话很多团队都被这个问题坑过。2026 年 7 月 28 日MCP 发布了一次大规模架构重构彻底解决了这个问题。这是 MCP 自诞生以来最大的一次变化值得每个用 MCP 的开发者关注。三个数字感受一下这次更新的分量6 项规范增强提案协同落地。不是修修补补是从底层重新设计了协议的工作方式。4 个官方 SDK同步发布 Beta。Python、TypeScript、Go、C# 都有覆盖主流开发语言。企业托管成本预计降低40% 到 60%。这个数字来自行业测算核心原因就是不再需要 sticky sessions 和共享会话存储。核心变化一无状态化这次更新最根本的变化就一句话MCP 服务器从**「有状态守护进程」变成了「纯函数」**。以前的服务器得记住每个客户端的会话状态请求进来先查 Session ID找到对应的会话上下文再处理。现在不用了每个请求都是完全自描述的协议版本、客户端能力、身份信息全都在请求的 _meta 字段里。用伪代码表示就是(Request, Token) → Response服务器不需要在内存里保存任何会话状态。任何请求可以发到任何实例标准的轮询负载均衡就能搞定。具体长什么样看官方给的 Before and after。旧版协议你得先发一个 initialize 请求建立会话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 } } }服务端返回一个 Mcp-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 } } }新版协议同样的调用变成一个自包含的请求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 } } } }没有 initialize没有 Mcp-Session-Id。任何一台服务器都能处理这个请求。这带来什么好处第一可以直接部署到 Serverless 平台。Cloudflare Workers、AWS Lambda、Vercel Functions 都能跑 MCP 服务器了。以前这些平台根本没法用因为它们不支持长连接和会话状态。第二可以部署到边缘节点。用户请求就近处理延迟更低。第三水平扩展变得 trivial。加机器就行不需要任何额外的会话同步机制。核心变化二MRTR 多轮次请求这是这次更新里最巧妙的设计。旧版协议里如果服务端在处理请求时需要用户输入比如确认操作、提供参数它会通过持久的 SSE 连接反过来向客户端发请求。这要求客户端一直保持连接网络一断整个流程就崩了。新版协议换了个思路。服务端不再**「回调」客户端而是「返回等待」**。具体来说服务端返回一个 InputRequiredResult里面包含需要什么输入还有一个 requestState 令牌。官方示例长这样{resultType:input_required,inputRequests:{confirm:{type:elicitation,message:Delete 3 files?,schema:{type:boolean}}},requestState:eyJzdG...iXX0}客户端收集到用户输入后把输入和令牌一起发回来重新调用同一个工具。服务端拿到令牌就能恢复上下文继续执行。这个设计的好处是什么网络中断不影响长推理链。客户端可以断开连接过一会儿再带着令牌回来继续。状态显式化了。以前状态藏在服务端内存里LLM 看不到。现在状态是一个令牌可以被传递、组合、甚至被 LLM 推理。为跨天、跨 Agent 的复杂流程打下基础。你想想这个场景Agent 需要等用户确认一个操作但用户可能第二天才回复。在旧协议里这几乎不可能实现现在只要保存好令牌就行。核心变化三扩展框架解耦MCP 生态发展很快如果把所有功能都塞进核心协议规范会越来越臃肿。这次更新引入了扩展框架把可选功能从核心协议剥离出去。两个官方扩展已经发布。MCP Apps允许服务器向客户端返回可交互的 HTML 界面组件。数据看板、交互表单、可视化图表都能直接在宿主应用的沙盒 iframe 里渲染。MCP Tasks把长运行任务标准化了。客户端发起调用后拿到一个任务句柄可以轮询状态、补充输入、或者取消任务。扩展用反向 DNS 标识比如 io.modelcontextprotocol/apps独立版本迭代。核心协议保持稳定UI 和任务逻辑可以快速演进。开发者需要做什么如果你在用 Python SDK升级到 v2.0.0b1。安装时要指定精确版本pipinstallmcp[cli]2.0.0rc1不指定版本号会装到最新的 v1.x因为 pip 默认不装预发布版本。v2 的主要变化FastMCP改名成了MCPServer所有字段改成 snake_caseHTTP 客户端从 httpx 换成了 httpx2。如果你用装饰器写工具基本就是改个类名的事。TypeScript SDK 变化更大拆分成了 server 和 client 两个包只支持 ESM 模块。官方提供了 codemod 脚本自动迁移。Go 和 C# 的 SDK 变化相对平滑。Go 需要显式开启 Stateless 模式C# 默认就是无状态旧 API 标记了 Obsolete。旧版协议里有几个功能正式进入废弃期。Roots改用工具参数传递目录路径Sampling改为直接调用模型 APILogging改用 OpenTelemetry。这些功能还有12 个月的过渡期不会突然不能用。实际收益部署成本下降是最直接的。不需要 sticky sessions不需要 Redis 集群标准的负载均衡器就行。如果你用 Serverless按需付费空闲时几乎不花钱。LLM 的推理成本也可能下降。新规范要求工具列表确定性排序加上客户端缓存机制LLM 端的 Prompt Cache 命中率会提升。缓存命中意味着更少的 Token 解析更快的响应更低的账单。可观测性也改善了。新规范标准化了 W3C Trace Context跨服务的请求可以端到端追踪。Python SDK v2 内置了 OpenTelemetry 支持一行 logfire.configure() 就能看到完整的调用链路。行动建议如果你在开发新的 MCP 服务器直接用 SDK Beta 开发避免基于即将废弃的旧架构产生技术债务。如果你有生产环境的 MCP 服务重点检查负载均衡配置移除针对 Mcp-Session-Id 的 sticky 路由逻辑。Python SDK 的 streamable_http_app() 可以同时响应新旧协议过渡期不用担心兼容性问题。如果你在开发客户端或 Agent 框架重点测试 MRTR 模式下的重试逻辑。这是新协议里最重要的交互模式变化。MCP 从**「能用」进入「好用」**阶段。无状态化不是削弱是解放。协议变简单了开发者能做的事情反而更多了。参考来源The 2026-07-28 SpecificationThe 2026-07-28 MCP Specification Release CandidateBeta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here