MCP史上最大更新：废弃Session后到底改变了什么？

你刚让AI帮你订机票，它说需要先和航空公司的服务器建立一个长期连接，还要求把所有订票状态交给它保管。更要命的是，一旦连接的服务器宕机，整个流程就断了。这种感觉，不就跟用着最智能的AI、却配了一套最笨的后端差不多吗？

现在，Model Context Protocol（MCP）终于把这个包袱甩掉了。

2026年7月28日，Linux基金会旗下的Agentic AI Foundation发布了MCP新规范“2026-07-28”，直接取消了通信会话，把整个协议从“状态化”推成了“无状态”。这被官方称为MCP诞生以来最大规模的一次更新，而它要解决的核心问题，就是老架构那套黏糊糊的会话管理。

先简单回顾一下MCP是什么。它是Anthropic在2024年11月公开的一个开放标准，专门让大模型应用和外部工具、数据、服务之间能用一种统一的方式对接。你不需要为ChatGPT写一套连接代码，再为Claude另写一套，只要服务端实现了MCP，各种AI都能调。后来MCP被越来越多的厂商和工具采用，现在这个项目已经交给Agentic AI Foundation维护——就是本次发布新规范的那个组织。

那么，这次“废弃Session”到底动了哪些地方？我们一条条拆开看。

1. 通信方式从“状态化”变成“无状态”

这是整个更新里最要命的变化。

以前的MCP客户端和服务器一建立连接，就要先走一套“initialize”和“initialized”的握手流程，之后靠一个叫“Mcp-Session-Id”的标识来维持同一个会话。所有后续请求都绑定在这个会话上，服务器得记住你的上下文。

这种方式的坏处很明显：当你运行几十上百台服务器时，必须保证同一个用户的所有请求都落到同一台机器上，也就是所谓的“粘性会话”（sticky session）。要做到这一点，要么给负载均衡器加一堆策略，要么搞一个额外的数据库在服务器之间同步会话信息。服务器弹性伸缩、故障转移，全都变得特别拧巴。原文甚至直接点出，这成了MCP大规模部署的阻碍。

新规范直接把initialize和Mcp-Session-Id一起废除。现在每个请求自己携带协议版本、客户端信息、支撑的能力集，服务器不再需要记住之前的交互。你想知道这台服务器能干什么？可以用新增的“server/discover”接口去问，但这一步也不是必须的。

一句话总结：以前请求之间相互依赖，现在每个请求独立成事。

带来的直接好处就是，MCP服务器终于能像一个普通HTTP服务那样，丢到Kubernetes集群、Serverless平台、边缘节点上，前面随便挂一个负载均衡器就能按忙闲分配流量。官方的推文甚至开心地宣布：“Now that MCP is stateless, you can deploy on serverless and edge infrastructure, or scale horizontally behind any load balancer.”

2. 应用状态不再隐身，靠标识符管理

取消了会话，那购物车里的商品、浏览器的操作进度这些应用状态怎么办？难道每次调用都要从头来过？

并没有。新规范的设计是：需要跨多次调用保持的信息，由服务器生成一个状态标识符，然后让AI代理在下一次工具调用时把这个标识符当作参数显式地传回来。

以前这些状态是“躲”在会话里的，开发者看不到，AI代理也未必清楚自己正在处理哪一堆上下文。现在它变成了工具参数的一部分，谁在用、处理到了哪一步，全部亮在明面上。这让排查问题和调试都简单了不少，对AI代理来说，上下文也变得更透明。

3. 中途需要用户确认？MRTR来了

无状态设计还催生了一个新机制：“Multi Round-Trip Requests（MRTR）”。

想象这样一个场景：AI代理要帮你删一批数据，服务器觉得这事儿风险太高，必须问用户一句。在老架构下，服务器可以直接向保持连接的客户端弹出一个确认请求。但现在连接没了，怎么做？

MRTR的答案是：服务器把“需要输入”的提示和问题内容放在响应里返回。客户端拿到这个结果，向用户询问后，再把用户的回答连同原来的请求再发一次。因为每个请求本身携带着足够的上下文，服务器可以接着上次的步骤继续处理。

这就意味着，用户确认、多步表单填写这类交互，在无状态的通信模型下依然能跑，而且不再需要服务器主动向客户端“推送”消息。对于部署在容器或无服务器环境里的MCP服务来说，这一步非常关键。

4. HTTP头部规范同步翻新

为了让网关、WAF、限流系统更快地识别和分流MCP流量，新规范强制要求在HTTP请求头中加入两个字段：

• Mcp-Method：表示这次要调用哪种功能，比如“tools/call”。
• Mcp-Name：指明具体的工具名称，或者其他操作对象名。

在这之前，这些信息都藏在请求体的JSON里面，基础设施组件要想识别，必须解析整个请求体，又慢又重。现在只看HTTP头部就能做路由、权限控制和速率限制，对运维来说友好多了。

5. 缓存机制也加上了有效期和范围

以前每次查询可用的工具列表、提示模板、资源列表等信息，客户端可能要反复请求，即使内容压根没变过。

新规范为这些资源清单加入了“ttlMs”（缓存有效毫秒数）和“cacheScope”（缓存作用范围），由服务器明确告诉客户端：“这个列表在未来10000毫秒内不会变，你可以放心用。” 客户端不再需要每次都去拉一遍，减少不必要的请求，也降低服务器负载。

看完这五点变化，你会发现这次更新其实在干一件事：把MCP从实验室里的实验性设计，扭成一套真正能在生产环境规模化运行的协议。

事实上，生态已经开始跟上。Anthropic已在Claude的官方博客中宣布，将把MCP 2026-07-28引入Claude；GitHub也发了一张更新日志，表示其MCP服务器已支持新规范。从大模型服务商到代码托管平台，都在用行动表态。

更值得玩味的是，这波更新把MCP的物理形态彻底打开了。以前由于会话状态的约束，MCP服务器总要保持长连接、部署在特定节点上；现在随便往serverless上一扔就能用，运维模型和普通API服务完全一致。对于那些想快速集成多种AI工具的平台来说，这是实打实的降本。

当然，无状态也不是万能药。状态标识符的管理责任部分转移到了上层应用和AI代理身上，安全性和一致性都需要重新审视。但至少目前来说，MCP的这一大步，已经把“AI和外界的连接”这件事，从过去那种黏糊糊的强绑定模式里拽了出来。