← 返回洞察
2026 年 8 月 · 6 分钟阅读
MCP升级为无状态协议：从双向流到可扩展的企业Agent基座
关键定义
无状态协议核心（Stateless Protocol Core） MCP从双向有状态流转向请求/响应无状态协议，每个请求自描述，可落在轮询负载均衡器后的任意实例上，无需共享存储。
多轮往返请求（MRTR） Multi Round-Trip Requests，替代需要保持连接的服务端发起请求，让无状态协议也能实现「调用中途向用户确认」等交互场景。
2026年7月28日，MCP官方正式发布了下一版规范2026-07-28，并同步更新了TypeScript、Python、Go与C#四套Tier 1 SDK。本次发布的重头戏是协议核心的无状态化：MCP正从双向有状态协议转变为一个请求/响应无状态协议。
为什么要无状态化
过去一年多，MCP以惊人的速度增长：Tier 1 SDK每月接近5亿次下载，TypeScript与Python SDK各自累计下载突破10亿。MCP已成为Agent工作流的数据与交互基座。但协议的有状态核心（依赖持久的双向流与会话ID）限制了服务器的可靠性与可扩展性，让水平扩展变得困难。
无状态化是开发者最强烈要求的功能。它让MCP服务器可以部署在标准、可扩展的基础设施上，无需管理会话或持久连接。每个请求自描述，可以落在轮询负载均衡器后面的任意实例上，不需要共享存储。用MCP联合发明人David Soria Parra的话说，这是MCP发布远程协议以来最重要的一次演进，吸收了过去18个月的全部经验，为MCP的未来提供了稳健基础。
无状态协议如何工作
新版规范正式退役了initialize/initialized握手与Mcp-Session-Id头。每个请求独立传输，在_meta中携带协议版本、客户端身份与客户端能力。如果客户端想提前获知服务器能力，可用新的server/discover远程过程调用——但这不是必须的。任何请求现在都可以落在轮询负载均衡器后的任意实例上。
放弃协议级会话并不强制应用变成无状态。如果你的服务器需要跨调用携带状态，可以从工具处铸造一个显式句柄，让模型把它作为参数传回。MCP团队发现这比把状态藏在传输层更好——模型能看到句柄并在工具之间串联它。
让交互在无状态协议上成为可能
无状态化最大的挑战是如何处理"调用中途需要输入"的交互，例如确认或补参数。新版用MRTR（多轮往返请求）解决：服务端返回resultType为"input_required"的结果，附带它需要回答的请求，客户端带着inputResponses中的答案重试原始调用。这取代了此前需要保持连接的服务端发起请求（elicitation/create、sampling/createMessage、roots/list）。
这对企业意义重大。例如Supabase的MCP以无状态方式运行，此前很难实现"在创建项目前向用户确认成本"或"在删除数据前确认查询"这类交互；MRTR让它们成为可能。确认成本、防误删等场景不再需要持久的双向连接。
面向网关与规模的架构升级
新版引入基于头部的路由：Streamable HTTP请求现在必须包含Mcp-Method与Mcp-Name头。你的网关、限流器或WAF可以直接基于这些头部做路由与计量，而无需解析JSON请求体。这显著降低了Agent流量进入企业安全基础设施的门槛。
列表结果现在可缓存：tools/list、prompts/list、resources/list与resources/read的响应携带ttlMs与cacheScope，客户端可据此决定缓存策略，减少不必要的重复拉取，并保持跨重连的上游提示词缓存稳定。对大规模部署，这能显著降低流量与成本。
授权加固与扩展框架
授权是实施者投入整合时间最多的地方。新版规范继续演进MCP的授权与安全态势：授权服务器按RFC 9207返回iss参数且客户端必须校验，封堵授权服务器混用漏洞；客户端凭据绑定签发的issuer，禁止跨授权服务器复用；动态客户端注册（DCR）正式弃用，转向客户端元数据文档（CIMD）。
扩展框架正式确立。Tasks从实验核心移入io.modelcontextprotocol/tasks扩展，采用基于轮询的tasks/get与新增的tasks/update。连同MCP Apps与Enterprise Managed Authorization（EMA）等扩展，MCP形成了正式的扩展机制，让特定能力按需演进而非阻塞协议核心。
Roots、Sampling、Logging被弃用
新版正式弃用了Roots、Sampling与Logging（SEP-2577），它们至少再工作十二个月，但新实现不应再采用。legacy的HTTP+SSE传输也被视为正式弃用，提供一年的退出期。同时建立了正式的弃用政策，承诺最低十二个月的窗口期，让企业可以规划升级而非仓促应对。
对企业来说，这一版本的落地意味着：如果你正在建设Agent基础设施，现在就可以采用2026-07-28规范的SDK，把MCP服务器当作普通可扩展的Web服务来部署——这不仅是技术演进，更是把MCP纳入企业级运维与安全体系的重要一步。
参考来源：Model Context Protocol官方博客, "The 2026-07-28 Specification", 2026-07-28, https://blog.modelcontextprotocol.io/posts/2026-07-28
常见问题
MCP 2026-07-28版规范最核心的变化是什么？+
协议核心从有状态双向流转向无状态的请求/响应。每个请求自描述，携带协议版本、客户端身份与能力，可以落在轮询负载均衡器后的任意实例上而不需要共享存储。这是开发者最强烈要求的功能，旨在提升MCP服务器的可靠性与可扩展性。
为什么需要无状态化？+
此前MCP依赖持久的双向流（STDIO或WebSocket）和会话ID，难以在标准基础设施上水平扩展。无状态化让MCP服务器可以部署在普通、可扩展的基础设施上，无需管理会话或持久连接，可像其他Web服务一样缓存、路由与全局扩展。
无状态协议如何处理需要用户确认的交互？+
通过新的MRTR（多轮往返请求）机制：服务端返回resultType为「input_required」的结果并附带需要回答的请求，客户端带着输入答案重试原始调用。这让确认、补参数等场景在无状态协议上也能实现。
新版规范在授权与安全上做了什么？+
授权服务器按RFC 9207返回iss参数且客户端必须校验，以封堵授权服务器混用漏洞；客户端凭据绑定签发它的issuer，禁止跨授权服务器复用；动态客户端注册（DCR）正式弃用，转向客户端元数据文档（CIMD）。
这对企业Agent架构意味着什么？+
头部路由让网关、限流器、WAF可直接按Mcp-Method与Mcp-Name头做路由与计量，无需解析JSON请求体；列表结果带缓存提示与确定性顺序，可缓存工具目录。Tasks成为正式扩展，配合无状态核心，MCP正变得更适合企业级规模化部署。