MCP 无状态化：以删基础设施为回报的协议升级

Agent 基础设施正在发生一件反直觉的事：一次协议升级，回报是你删掉的东西。2026 年 7 月 28 日发布的 MCP 规范修订——协议发布以来最大的一次——把核心改成无状态。客户端不再握手、不再被会话 ID 绑死在某个服务实例上；任何实例都能响应任何请求。对架构师而言，这意味着一整类为了补偿协议缺陷而存在的基础设施——粘性路由、session store、握手兼容层——从「必需」变成「可删」。把话说得更直白：这是第一次，协议升级的收益清单里写的是删除，而不是新增。

无状态化到底改了什么

事实清单（来源：MCP 官方 changelog — https://modelcontextprotocol.io/specification/2026-07-28/changelog ；AWS 架构博客 — https://aws.amazon.com/blogs/architecture/mcp-went-stateless-is-your-aws-mcp-server-deployment-well-architected/ ）：

initialize 握手与 Mcp-Session-Id 头移除。每个请求自带协议版本与客户端上下文，第一个消息可以是实际的工具调用。新增 server/discover 方法，单次响应返回支持的协议版本、能力与身份，客户端可调可不调。工具列表缓存字段 ttlMs 与 cacheScope 内建——客户端不必每次运行都重新拉取工具目录。W3C Trace Context（traceparent、tracestate）随请求 _meta 传播，分布式追踪协议原生；MCP 专有协议日志弃用，改为 stderr 或 OpenTelemetry。

一个必须读的警告：面向旧客户端的向后兼容 lane 保留会话语义。还在服务 2025 时代客户端的部署，粘性路由与 session store 必须继续保留。无状态描述的是协议，不是你的应用——需要跨调用连续性的用例，用工具参数里的标识符指向存在你数据存储里的状态，这是普通的 REST 纪律，只是这次标识符住在模型上下文里，模型可以推理它。

收益被低估了，因为它不在账单上

AWS 给了个看似小到不值得迁移的算式：两节点 ElastiCache cache.t4g.micro 会话存储约 23 美元/月。用这个数字衡量这次升级，等于用错误的计量单位做决策。同一篇 AWS 文章自己承认：粘性路由也在消耗容量——它让负载分配不均，而节省随舰队规模放大（savings scale with the size of your fleet）。真正的收益不是省掉的 23 美元，而是：部署不再需要粘性会话的运维心智、session store 的补丁与扩容窗口、以及握手失败这一类故障的整个排障类别（来源：https://aws.amazon.com/blogs/architecture/mcp-went-stateless-is-your-aws-mcp-server-deployment-well-architected/ ）。

LangChain 团队 9 月 3 日的重构说明把这一点说得最清楚：无状态之后，重新部署不再杀死活会话，因为根本没有会话（来源：https://www.langchain.com/blog/mcp-in-langchain-stateless-protocol-elicitation-and-more ）。删除清单 = session store（DynamoDB/ElastiCache）、ALB 粘性规则、握手基础设施。每删一项，都是减少一个「凌晨两点的故障面」。

网关从有状态代理变成纯路由器

无状态化改变了网关能做什么。以前网关要解析请求体才能按方法路由、限流；现在 Mcp-Method 与 Mcp-Name 头直接暴露操作类型，每个响应都带 resultType（complete 或 input_required）——路由、限流、观测可以全部在头部完成，不碰 body。观测从「每个实现各接一套」变成「协议原生」：W3C Trace Context 在 _meta，直接接 OpenTelemetry 与 CloudWatch（来源：https://aws.amazon.com/blogs/architecture/mcp-went-stateless-is-your-aws-mcp-server-deployment-well-architected/ ）。

我们的判断：这验证了控制面架构的方向，而且是行业用行动确认的。最近记录过一个信号：Broadcom、Citrix、CrowdStrike、ServiceNow、Genesys 五家厂商在两周内独立收敛到同一套三层 agent 基础设施栈——连接层（MCP）、安全与治理层、可观测层（来源：https://forkast.news/five-enterprise-vendors-just-shipped-the-same-three-layer-agent-infrastructure-stack-and-none-of-them-coordinated/ ）。MCP 无状态化正是把连接层做成 commodity 的那一步：当连接本身变成标准件，网关退化为纯路由器，治理与观测成为差异化层。谁把治理与观测做成可测量、厂商中立的能力，谁就站在这一层增值的位置。

锁定的位置变了

协议开放，生态却在硬化。Forkast 的观察值得每个架构师读两遍：协议本身在 Linux Foundation 治理下保持开放，但价值正在迁入实现层的专有件——安全原语（fingerprintTools、detectToolDrift 这类）、工作流范围的凭据、技能库。一个为 CIQ 计算环境优化的 agent，带着它的凭据与安全策略，不能直接搬进 Vercel 管理的部署面。协议中立不等于生态中立（来源：https://forkast.news/mcp-is-becoming-the-universal-interface-layer-and-the-lock-in-is-happening-at-the-ecosystem-level/ ）。

我们的判断：把「协议中立」当作采购终点的团队，会在 18 个月后发现自己换了一种形式的供应商依赖。评估 MCP server 与网关供应商时，真正要问的不是「它支持 MCP 吗」——这是起点——而是「它把什么放进了实现层」。那才是你未来迁移时的真实账单。

迁移窗口有钟，但现在是审计时刻

迁移不是今天必须完成，但窗口有钟。2025-11-25 版协议已冻结，新能力只落在 2026-07-28 及以后。被弃用的特性（Roots、Sampling、Logging、HTTP+SSE）有 12 个月地板，最早 2027 年 7 月移除；Tasks 从实验性 API 变成官方扩展，接口重新设计。AWS 给的迁移顺序是四步：① 升级 SDK 并 opt-in——说新协议从来不是自动的；② 审计会话依赖，迁移 Tasks API；③ 规划弃用退出路径，资源不存在错误码从 -32002 改为 -32602；④ 删基础设施——session store、粘性规则、握手逻辑（来源：https://aws.amazon.com/blogs/architecture/mcp-went-stateless-is-your-aws-mcp-server-deployment-well-architected/ ）。

我们的判断：向后兼容 lane 不是「可以再拖一年」的许可证，而是设计给有节奏迁移的缓冲。现在最值得做的一件事是审计：你的 server 有多少会话假设、多少客户端还在 2025 协议、多少基础设施纯粹是为会话存在。审计结果出来之前，任何「等有空再迁」的决策都是没有信息支撑的。

我们的判断

第一，用错误的计量单位衡量这次升级，会得出错误的迁移决策。23 美元/月是诱饵数字；复杂度、容量不均、故障面才是账单。第二，无状态化把连接层商品化，网关变成纯路由器——这验证了「治理与观测是 agent 基础设施的差异化层」这一判断，而不是否定它。第三，锁定的位置从协议层移到实现层：协议中立是起点，不是终点。第四，迁移窗口 12 个月，但现在唯一正确的动作是会话依赖审计——不是「等」，也不是「立刻全量迁」。

给买方的行动清单

第一步，盘点客户端协议版本。还有多少客户端在 2025-11-25 或更早？这决定你的兼容 lane 要活多久。第二步，找出为会话存在的基础设施。session store、粘性路由、握手兼容层——每一项都标一个所有者与删除日期。第三步，新 server 直接 target 2026-07-28。SDK opt-in、server/discover、W3C Trace Context，从第一天就按新协议写。第四步，规划弃用退出。Roots、Sampling、Logging、HTTP+SSE 在 2027-07 前退出，Tasks API 迁到官方扩展。第五步，给网关加头级路由与追踪策略。Mcp-Method 头限流、W3C Trace Context 传播——在第一个 MCP 应用上线之前定策略，这是 AWS 的原话：set a policy for MCP Apps before the first server in your fleet ships one。

留给你的决策问题：你的 MCP 服务器里，有多少代码行数的存在理由只是「协议曾经要求握手」？

参考来源: MCP 官方 changelog（2026-07-28）— https://modelcontextprotocol.io/specification/2026-07-28/changelog ；MCP 官方发布公告 — https://blog.modelcontextprotocol.io/posts/2026-07-28/ ；AWS《MCP went stateless: Is your AWS MCP server deployment well-architected?》(2026-09-01) — https://aws.amazon.com/blogs/architecture/mcp-went-stateless-is-your-aws-mcp-server-deployment-well-architected/ ；LangChain《MCP in LangChain: Stateless Protocol, Elicitation, and More!》(2026-09-03) — https://www.langchain.com/blog/mcp-in-langchain-stateless-protocol-elicitation-and-more ；Forkast《Five Enterprise Vendors Just Shipped the Same Three-Layer Agent Infrastructure Stack》(2026-09) — https://forkast.news/five-enterprise-vendors-just-shipped-the-same-three-layer-agent-infrastructure-stack-and-none-of-them-coordinated/ ；Forkast《MCP Is Becoming the Universal Interface Layer》(2026-09) — https://forkast.news/mcp-is-becoming-the-universal-interface-layer-and-the-lock-in-is-happening-at-the-ecosystem-level/