本博客日IP超过2000，PV 3000 左右，急需赞助商。
极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
【腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云
之前，我们说 MCP 就是 AI 界的 http，虽然不恰当，但是现如今两者越来越像了。
这不，最近 MCP 协议也迎来了大更新，向 http 靠拢，迎来可能是史上最大的一次重构，从“有状态连接”到“无状态核心”，MCP 正在完成一次面向企业级生产的成人礼。
核心协议大瘦身
时间来到 2026 年 7 月 28 日，Model Context Protocol（MCP）发布了自 2024 年 11 月诞生以来规模最大的一次规范更新，迎来了 2026-07-28 版本。
这不是一次普通的版本迭代。如果说之前的 MCP 更像一个“好用的开发工具”，那么这次更新后，它正在向“企业级基础设施”进化。
官方用了一个很形象的词来形容这次变革，pay-as-you-go complexity（按需付费的复杂度）。核心协议被大幅瘦身，所有“有状态”的负担都被剥离；而那些真正需要状态管理的场景，则被推到了应用层，由开发者自己决定如何实现。
简单来说，新版本的 MCP 不再帮你管状态了，但它也再也不限制你怎么扩展了。
三大核心看点
文章配图参见我的公众号：https://mp.weixin.qq.com/s/S0oZEQcU2jQ3gj8jGrB2Gw。
彻底无状态化
这是本次更新最重磅的变化，就是彻底无状态化，告别 Session，告别握手。
旧版 MCP（2025-11-25 及之前）的工作方式在客户端和服务器建立连接时，必须先完成一次 initialize / notifications/initialized 双向握手，交换协议版本、能力列表和身份信息。随后，服务器会颁发一个 Mcp-Session-Id，后续所有请求都必须带上这个 ID，且必须路由到同一个服务器实例。
这种模式在本地桌面应用（比如 Claude Desktop 调用本地进程）时毫无问题，连接稳定、实例单一。但一旦 MCP 服务器被部署到远程、需要水平扩展的生产环境，问题就来了。
- 负载均衡器必须配置“粘性路由”（sticky sessions），确保同一个 Session ID 的请求始终落到同一台机器；
- 需要额外的共享会话存储（比如 Redis）来同步多实例间的状态；
- 滚动部署时，旧实例下线会导致会话中断，客户端被迫重连。
正如 The New Stack 的评述所说，A team shipping an MCP server was paying to solve a distributed-systems problem the protocol had created for them.（每个部署 MCP 服务器的团队，都在为协议自己制造的分布式问题买单。）
而新版 MCP（2026-07-28）的工作方式带来了改变。
initialize握手被彻底移除；Mcp-Session-Id头部被彻底移除；- 每个请求都是自包含的（self-contained），协议版本、客户端身份、能力信息全部放在请求体
_meta字段中； - 新增
server/discoverRPC，客户端可以在调用前查询服务器支持的能力和版本。
这意味着，任何请求可以落到任何实例上。三台副本 behind 一个最普通的轮询负载均衡器，不需要粘性会话，不需要 Redis，不需要网关深度解析 JSON 报文来路由。
用官方博客的比喻来说，以前每个包裹必须由同一个快递员全程配送，因为他记得所有信息；现在每个包裹自带完整的运输标签，任何快递员都能接手。
扩展框架正式化
MCP 的核心被瘦身了，但功能并没有减少，它们被移到了扩展（Extensions）中。
新版规范引入了正式的扩展框架，Tasks 和 MCP Apps 成为“官方插件”。
- 扩展使用
反向 DNS 命名空间（如io.modelcontextprotocol为官方扩展，第三方使用自己拥有的域名）； - 扩展拥有独立的仓库和发布节奏，不再与核心协议绑定；
- 客户端和服务器通过能力协商（capability flags）来启用扩展。
首批正式扩展包括两个下面这两个“官方插件”。
- Tasks（任务扩展）：将之前实验性的”长时间运行任务”从核心协议中剥离，重新设计为带生命周期管理的扩展。服务器通过显式句柄（handle）来管理异步任务，客户端通过句柄查询状态或获取结果。
- MCP Apps（应用扩展）：允许服务器返回沙盒化的 HTML 界面（通过
ui://协议），在客户端的 iframe 中渲染交互式 UI。这在 2026 年 1 月已经作为独立扩展发布，此次只是被纳入正式框架。
这个设计的妙处在于，核心协议可以稳定演进，而创新功能可以独立迭代。写过 Kubernetes CRD 的开发者会对这个模式感到熟悉。
过渡策略
对于企业技术决策者来说，比新功能更重要的是，旧功能什么时候会消失？
此次更新引入了三阶段功能生命周期，Active（活跃）→ Deprecated（弃用）→ Removed（移除），并做出了以下规定。
- 从功能被标记为 Deprecated 到正式移除，
最短 12 个月； - 只有存在活跃安全漏洞且已发布安全公告时，才能缩短至
90 天； - 所有弃用功能会在公开注册表中列出，并标注预计移除时间。
这意味着企业可以有计划地安排迁移，而不是被突然的破坏性更新打个措手不及。
首批被标记为 Deprecated（但仍有 12 个月缓冲期）的功能包括：
- Roots：客户端文件系统根目录声明；
- Sampling：服务端请求客户端代为调用模型采样；
- Logging：协议级结构化日志消息；
- 旧版 HTTP+SSE 传输层；
- OAuth 2.0 动态客户端注册。
新 MCP 好在哪里？
总结来看，共有 4 点可供大家参考。
运维成本大幅降低
无状态化带来的最直接好处是基础设施的简化。
GitHub 已经率先移除了他们的 Redis 会话存储。对于任何想将 MCP 服务器部署到 AWS Lambda、Cloudflare Workers、Vercel Edge 等无服务器环境的团队来说，这是一个里程碑式的解放。之前因为 Session 亲和性的限制，这些平台几乎无法优雅地托管 MCP 服务。
现在，MCP 服务器的运维模式与普通 REST API 几乎无异，水平扩展、蓝绿部署、自动伸缩，全部可以复用现有的成熟方案。
缓存效率提升，Token 成本下降
新版规范要求列表类接口（tools/list、resources/list 等）的返回结果不再因连接而异，并且必须包含 ttlMs 和 cacheScope 缓存元数据（类似 HTTP 的 Cache-Control）。
同时，工具列表必须按确定性顺序返回。这意味着：
- 客户端可以安全地缓存工具目录，减少重复请求；
- 大模型侧的系统提示（system prompt）缓存命中率提高，直接降低 Token 成本。
网关减负控流
新版 Streamable HTTP 传输层强制要求两个新头部：
Mcp-Method：表示 JSON-RPC 方法名；Mcp-Name：表示工具名、资源名或提示词名（针对具名操作）。
这意味着，网关可以在不解析请求体的情况下，对特定工具进行限流、授权或路由。对于需要严格审计和访问控制的企业环境，这是一个关键的安全增强。
企业级身份认证落地
此次更新进一步对齐了 OAuth 2.0 和 OpenID Connect 的最佳实践，支持企业身份系统（如 Microsoft Entra、Okta）的集成。动态客户端注册被弃用，取而代之的是更安全的 Client ID Metadata Documents。
迁移是个大问题
MCP 的这次大幅更新或重构带来的功能迁移是一个大问题，尽管官方提供了 12 个月的弃用缓冲期，但无状态化本身是“移除”而非“弃用”，这意味着它不提供向后兼容的过渡期。如果你现有的 MCP 服务器依赖会话状态，你必须重写传输层。
状态不会消失，只是转移了
MCP 不再在协议层管理会话，但应用状态（购物车、任务记录、工作流上下文）依然存在。现在，服务器需要显式地返回句柄（handle），由客户端在后续请求中作为普通参数传回。
比如，旧版可能依赖 Session 来记住“当前正在编辑的文档”；新版则需要工具返回一个 document_handle，下次调用时客户端主动带上。
这实际上是“更好的架构”，因为状态对模型可见了。以前隐藏在传输元数据中的会话状态，模型永远无法理解和推理；现在作为普通参数的句柄，可以被模型在不同工具间传递和组合。
但代价是，需要重写代码。
Sampling 的移除
Sampling 是旧版中一个很有争议的功能。服务器可以请求客户端（如 Claude Desktop）代为调用底层模型进行采样，服务器无需持有 API Key，也无需支付模型费用。
新版中 Sampling 被弃用，替代方案是服务器直接调用模型提供商的 API。
这意味着：
- 服务器必须自己管理模型凭证；
- 服务器成为独立的计费主体和数据处理方；
- 对于依赖 Sampling 来降低成本的场景，这是一个不小的冲击。
主动请求变为多轮请求
旧版中，服务器可以主动向客户端发起请求（如要求确认、请求额外输入）。新版引入了 Multi Round-Trip Requests（MRTR） 模式，服务器返回一个 input_required 类型的中间结果，说明还需要什么信息；客户端收集后，重新发起原请求并附上 inputResponses。
服务器需要在 requestState 中编码自己的状态来关联两次请求，并且必须验证任何可能影响授权或业务逻辑的 echoed 状态。
SSE 可恢复性没了
Server-Sent Events 的流式传输不再支持通过 Last-Event-ID 恢复中断的流。连接断了，客户端需要完全重新发起请求。
对于长连接订阅场景（如资源变更通知），这增加了实现的复杂度。
写在最后
MCP 的这次重构，本质上是一次架构上的成人礼，但变更确实有些大。
它承认了早期设计在分布式场景下的局限性，选择用最“不性感”但最务实的方式回归无状态 HTTP 的成熟模式来解决规模化部署的痛点。这不是创新，而是“克制”；不是增加功能，而是“删除负担”。其实就是撞南墙了。
当然，任何架构的简化都意味着将复杂度“推给”上层。状态管理从协议层转移到应用层，需要开发者更仔细地设计自己的状态模型。但正如一位评论者所说，The protocol stopped managing state, which is not the same as the state going away.（协议不再管理状态，不等于状态消失了。）
对于那些已经运行在生产环境的 MCP 服务器来说，这不是一次轻松的升级。但对于整个 AI Agent 生态来说，这或许是 MCP 从“有趣的实验”走向“可靠的基础设施”最关键的一步。
MCP 协议的这次更新，又给程序员带来了新需求，当然也可以是让 AI 来重构。
最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！
本文原文出处：业余草： » MCP 协议大更新更像 Http 了，无状态化是解药，也是挑战