本文永久链接 – https://tonybai.com/2026/07/30/mcp-2026-07-28-stateless-core-claude

大家好，我是Tony Bai。

【导读】

北京时间2026年7月28日，Model Context Protocol（MCP）官方发布了协议历史上“最大的一次修订”——2026-07-28规范正式版。这是MCP自诞生以来的第五个正式版本，也是迄今改动最激进的一次：协议核心从“有状态”彻底转向“无状态”，握手与会话双双被砍掉；MCP Apps、Tasks、企业级鉴权被正式纳入统一的扩展框架；OAuth鉴权体系全面对齐生产环境标准。与此同时，Anthropic宣布Claude系产品将率先跟进适配。这场“协议大手术”，到底动了哪里？

【文章要点】

  • MCP 2026-07-28是协议自诞生以来最大规模的一次规范修订，核心从有状态改为无状态，握手与会话机制被彻底移除；
  • 新增多轮往返请求（MRTR）机制，替代原有的服务器发起式elicitation/sampling/roots调用；
  • MCP Apps、Tasks、企业级鉴权（EMA）正式纳入统一的扩展框架，协议新能力从此可以先在扩展里验证再考虑并入核心；
  • 鉴权体系全面向OAuth 2.0/OIDC生产标准看齐，DCR被正式标记弃用，转向CIMD；
  • Roots、Sampling、Logging等能力被弃用，但均有至少12个月的缓冲迁移期；
  • Claude率先宣布跟进，目前MCP连接器目录已收录950+服务器，SDK月下载量逼近5亿。

刚刚，MCP协议的维护团队按下了发布按钮。

新版本号：2026-07-28。

用官方博客的原话说，这是“协议自诞生以来最大的一次修订”。而促成这次修订的，是一组听起来朴素、做起来极难的目标：把MCP从一个“有状态”的双向协议，改造成彻底的“无状态”请求/响应协议。

要理解这次改动有多大，看一组数字就够了：MCP的Tier 1 SDK月下载量已经逼近5亿，TypeScript和Python两个SDK的总下载量都已突破10亿大关。而在Claude这一侧，连接器目录里收录的MCP服务器已经超过950个，每天被数百万用户使用。

协议火了，但架构上的老问题也暴露得越来越明显——这正是这次“大手术”的起因。

为什么非动不可：有状态架构的老账

MCP最早的设计，是一个双向、有状态的协议：客户端和服务器要先完成initialize/initialized握手，协议版本、能力集在这个阶段“谈妥”；之后所有请求都挂在同一个会话（Mcp-Session-Id）上，服务器还可能反过来向客户端发起请求（比如要求用户确认、或调用模型采样）。

这套设计在早期够用，但放到生产环境里，会带来一堆“运维负担”：

  • 负载均衡必须做粘性路由（sticky routing），同一个会话的请求必须打到同一台实例；
  • 服务器要维护共享会话存储（比如Redis），横向扩容变得麻烦；
  • 网关想做限流、鉴权，得解析请求体才能知道调用的是哪个方法、哪个工具；
  • 服务器到客户端的反向请求，依赖一条长期保持打开的双向流。

换句话说，MCP服务器很难像普通的无状态HTTP服务那样，随便扔到Serverless或者边缘节点上一键扩容。这也是过去一年里开发者反馈最集中的痛点之一。

于是，2026-07-28版本的核心目标只有一个：把状态从传输层里彻底拿掉。

核心变化一：握手没了，会话也没了

新版本里，initialize/initialized握手流程被正式移除，Mcp-Session-Id请求头也一并退休（对应SEP-2575、SEP-2567两项提案）。

取而代之的是：每一个请求都是自描述的。协议版本、客户端身份、客户端能力，全部塞进请求的_meta字段里随请求一起发送，不再依赖前置的握手协商。如果客户端确实想提前了解服务器的能力，可以调用一个新增的、可选的server/discover方法，但这不再是强制步骤。

一个典型的请求长这样：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

这样一来，任何一个请求都可以随便落到负载均衡后面的任意一台实例上，不再需要共享存储，普通的轮询负载均衡就能work。

但这不代表MCP服务器从此不能“记事”。如果业务上确实需要跨调用保留状态，官方给出的方案是：由服务器主动铸造一个显式的handle，把它当作普通参数返回给模型，模型在后续调用里把这个handle当作工具参数传回去。

MCP团队解释说，这种做法比“藏在传输层里的隐式会话状态”效果更好——因为模型能看见这个handle，可以在多个工具调用之间显式地传递它，而不是依赖一套模型完全不可见的黑盒机制。

核心变化二：没了会话，怎么做二次确认？

这里有个现实问题：MCP里有不少场景需要服务器“反过来”问客户端要东西——比如工具执行到一半，需要用户确认一下、或者少了个必填参数。过去这靠的是elicitation/create、sampling/createMessage、roots/list这类服务器发起的请求，而这些请求都依赖一条常驻的双向流。

现在协议是无状态的，这条常驻流也没了，这些场景怎么办？

答案是新引入的多轮往返请求（Multi Round-Trip Requests，简称MRTR，对应SEP-2322）。

它的工作方式很直白：服务器在这类场景下，不再“反向发起请求”，而是直接把原始调用的响应标成resultType: “input_required”，并附上需要客户端回答的问题；客户端拿到问题、收集完用户输入之后，带着答案重新发起一次原始调用，答案放在inputResponses字段里。

数据库服务商Supabase的产品负责人Inian Parameshwaran在官方博客里提到，“支持elicitation”这件事，此前在他们的路线图上放了很久——因为Supabase MCP本身是无状态运行的，一直没法轻松接入需要常驻连接的elicitation机制。MRTR解决了这个问题，让他们能在删除数据这类高风险操作前，先跟用户确认一次。

核心变化三：三个“边角料”级但很实用的改动

除了上面两个大改动，这次版本还带来三处容易被忽略、但对生产落地很关键的调整：

1. 请求头路由

Streamable HTTP的请求现在必须携带Mcp-Method和Mcp-Name两个HTTP头（SEP-2243）。网关、限流器、WAF从此可以直接根据请求头做路由和鉴权，不用再解析JSON请求体。

2. 列表结果可缓存

tools/list、prompts/list、resources/list、resources/read这几个接口的返回结果，现在都带上了ttlMs和cacheScope字段（SEP-2549）。客户端可以据此自行决定缓存策略，减少不必要的重复拉取，也让上游的prompt缓存在断线重连后依然保持稳定。

3. 错误码对齐JSON-RPC标准

“资源未找到”的错误码，从MCP自定义的-32002，改成了JSON-RPC标准里的-32602（Invalid Params，对应SEP-2164）。如果你的客户端代码里有硬编码匹配-32002的逻辑，这次升级需要重点排查。

扩展框架转正：MCP Apps、Tasks、企业级鉴权

这次修订还正式锁定了一套扩展框架（Extensions Framework）机制——协议新能力从此不再必须挤进核心规范，而是可以先作为一个带版本号的独立扩展上线、验证、迭代，成熟后再考虑是否并入核心协议。

在这个框架下，目前已经转正、或者作为扩展正式发布的能力包括：

  • MCP Apps：让服务器可以直接在对话内渲染交互式UI，用户不用跳出对话窗口就能看到连接器在做什么、并直接操作它；
  • Tasks：从实验性功能正式迁入io.modelcontextprotocol/tasks扩展，改为基于轮询的tasks/get加新增的tasks/update，处理长时间运行的后台任务；变更通知也从旧的HTTP GET端点，统一改成一个客户端按需订阅的subscriptions/listen流；
  • 企业级鉴权（Enterprise Managed Authorization，简称EMA）：作为同一扩展框架下的又一个扩展，服务于企业身份系统的托管接入场景。

值得一提的是，这次还配套推出了三项治理性提案，目的是让协议以后能“温和地”演进，而不是每次大版本都伤筋动骨：

  • 功能生命周期政策：每个功能都有Active、Deprecated、Removed三个阶段，从标记弃用到真正移除，至少留出12个月缓冲期；
  • 扩展框架本身：新能力可以先在扩展里跑，稳定了再考虑并入核心规范；
  • 一致性测试门槛（SEP-2484）：一个标准轨道提案要走到Final状态，必须先在一致性测试套件里落地对应的测试场景——这也是官方SDK分级评分所依赖的同一套测试体系。

鉴权体系加固：向生产级OAuth看齐

MCP团队在博客里说了句大实话：过去一年跟各家实现方交流下来，鉴权是开发者花时间最多的集成环节，没有之一。这次版本在这块下了不少功夫：

  • Issuer校验（RFC 9207）：授权服务器要返回iss参数，客户端必须在兑换授权码前完成校验（SEP-2468），堵上一个“授权服务器混淆”的安全漏洞；
  • 动态客户端注册（DCR）新增application_type：解决了桌面端、CLI客户端此前常见的localhost重定向被拒问题（SEP-837）；
  • 凭证与签发者绑定：客户端凭证只能在签发它的授权服务器上使用，不允许跨服务器复用（SEP-2352）；
  • DCR正式标记为弃用，官方标准转向客户端ID元数据文档（Client ID Metadata Document，简称CIMD）。DCR暂时仍可用，作为向后兼容手段保留，但会在未来版本中移除。

对Anthropic官方的表述来说，这一整套变化意味着MCP服务器可以更顺畅地对接Entra、Okta这类企业身份系统，不再需要绕开标准流程“打补丁”。

被废弃的那些：Roots、Sampling、Logging

这次一并被正式标记为弃用的，还有Roots、Sampling、Logging三项能力（SEP-2577），以及HTTP+SSE这一legacy传输方式。

按照前面提到的生命周期政策，它们目前仍然可以正常工作，且至少还会再稳定运行12个月，新项目不建议再基于它们做开发。日志相关的logging/setLevel方法，在2026-07-28这条路径上已经直接被拒绝调用，如果需要接收日志，改用请求元数据里的io.modelcontextprotocol/logLevel字段。

对四大Tier 1 SDK（TypeScript、Python、Go、C#）来说，新规范已经同步上线；Rust SDK目前以Beta形式支持新版本。据MCP团队透露，最大的迁移成本会出现在那些深度依赖会话标识符的既有实现上，不过官方表示已经把Beta阶段收集到的反馈吸收进了正式版，尽量把迁移路径修得平滑一些。

Claude这边，同步做了什么

这次协议升级发布的同一天，Anthropic也发了一篇对应的博客，宣布Claude系产品将率先跟进适配2026-07-28规范，目前正在各个产品线陆续上线中。

在此之前，Claude这一年里围绕MCP已经陆续补齐了几块能力，正好和这次协议改动严丝合缝地对上了：

  • MCP Apps：连接器可以直接在对话里渲染交互式界面，用户能看到、也能操作连接器正在做的事情，不用切标签页；
  • 企业托管鉴权：管理员通过身份提供商（IdP）为全组织统一开通MCP连接器，用户凭现有IdP组权限自动继承访问权，首次登录即完成连接，做到端用户“零操作”接入；
  • 面向开发者的可观测性看板：已发布到连接器目录的服务，可以查看跨产品线的性能表现，追踪采用率、诊断错误与延迟；
  • MCP隧道（研究预览）：让Claude能连接内网里的MCP服务器，不需要暴露公网端点，不需要开放入站防火墙规则，也不需要给源站做IP白名单。

Anthropic在博客里的表述是，2026-07-28版本带来的无状态核心、标准化扩展和加固后的鉴权体系，将帮助更多开发者以“更低摩擦、更一致的终端体验”把应用接入Claude。

生态反应：一众大厂怎么说

这次协议升级不是MCP团队闭门造车，而是联合了一批生态伙伴一起做了长期的联调验证。发布当天，来自不同领域的公司都给出了表态，摘几条有代表性的：

  • Figma（VP of Engineering Josh Clemm）表示，越来越多开发者通过Figma的MCP服务器把生成结果带入画布协作，无状态架构能更好地支撑这部分用量增长；
  • Netlify（VP of Applied AI Sean Roberts）认为，新规范让MCP第一次成为“一等HTTP工作负载”，不再需要额外的会话管理去“绕开”平台本身的简单性；
  • PostHog（Product Engineer Paul D’Ambra）提到，无状态化让他们更容易做横向扩容，也更容易为客户的MCP服务器接入分析能力；
  • Xero（VP of AI Andrew Goodman）表示，无状态核心降低了自身要维护的复杂度，能把更多精力放到给客户交付新功能上；
  • AWS（VP of Agentic AI Swami Sivasubramanian）指出，Amazon Bedrock AgentCore Gateway已经支持新规范，一次UpdateGateway调用即可完成升级；
  • Cloudflare（Senior Director Brendan Irvine-Broque）表示Agents SDK从第一天起就支持新规范，开发者可以直接在Workers里跑MCP服务器。

一句话总结这些反馈：降复杂度、能扩容、好接入，是被提及最多的三个关键词。

小结：这次升级对开发者意味着什么

把这次修订放在MCP这一年半的发展脉络里看，会更清楚它的位置。

MCP团队自己的说法是，这是协议“从少年走向成年”的一步——早期为了快速验证场景，架构上留了不少妥协；跑起来之后，生产环境暴露出的问题（粘性路由、共享会话存储、网关解析成本）反过来倒逼了这次架构重写。

而这次连带推出的生命周期政策和扩展框架，本质上是在为协议装上一套“以后不用每次都伤筋动骨”的演进机制。

对正在用MCP的开发者，几件实操层面的事值得留意：

  • 如果代码里硬编码依赖了Mcp-Session-Id或旧的会话语义，这次升级需要认真评估迁移成本；
  • 如果用到了服务器发起的elicitation、sampling、roots调用，需要按照MRTR的新模式改造；
  • 错误码从-32002改成了-32602，如果客户端里有对应的匹配逻辑，记得一并排查；
  • Roots、Sampling、Logging、legacy HTTP+SSE传输，至少还有12个月缓冲期，不用现在就慌，但新项目不建议再往这些能力上堆代码；
  • 如果计划把自己的MCP服务器提交到Claude连接器目录，官方文档里已经给出了对应的提交流程说明。

MCP从最初的“能跑就行”，到现在开始认真补齐生产级基础设施的每一块短板，某种程度上正是agentic应用真正走向规模化落地的一个缩影。这场“协议大手术”完成得如何，接下来几个月生态的实际反馈，会是更真实的答卷。

参考资料：

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。