MCP 放弃会话,使代理服务器像普通 HTTP 一样可扩展
这一重大不兼容修订将持久传输状态替换为自包含的请求、头部路由以及显式的应用句柄。
By Ryan Merket · Published
Primary source: Model Context Protocol Blog
Why it matters
MCP is becoming basic agent infrastructure. Stateless requests reduce deployment complexity, while the breaking migration shows the cost of standardizing technology that spread before its production model settled.

由维护者 David Soria Parra 和 Den Delimarsky 领导的 Model Context Protocol 项目于 7 月 28 日 发布了其最终的 2026-07-28 规范,将代理集成标准的握手和传输层会话替换为自包含的 HTTP 请求。
此更改使 MCP 更接近 Soria Parra 最初希望开发者能够自行扩展的基础设施。他在 2025 年的一次采访中回顾 表示,这一想法源于他加入 Anthropic 后在 Claude Desktop 和代码编辑器之间复制材料时的挫败感。Soria Parra 将该概念带给了 Justin Spahr-Summers,二人对客户端和服务器进行了原型开发,随后 Anthropic 在 2024 年 11 月发布了 MCP。
该协议的应用远远超出了本地桌面使用场景。远程服务器引入的需求使其早期有状态设计处理起来笨拙:粘性路由、共享会话存储和持久连接。在 MCP 的 2026 路线图 中,维护者将这些约束识别为横向扩展的障碍。
他们对这些问题的回答就是 最终的 2026-07-28 规范。规范移除了 initialize 和 initialized 交换,并弃用了 Mcp-Session-Id 头。每个请求现在都携带其协议版本、客户端身份和能力。客户端在需要在调用服务器之前检查服务器时可以调用可选的 server/discover 方法。
围绕负载均衡器重新设计的协议
其运行后果很直接:MCP 请求可以落到位于轮询负载均衡器后面的任何可用服务器实例上。运营者不再需要协议层记住哪个实例处理了客户端的前一次请求,也不需要在集群间维护共享会话存储。
随着 MCP 从开发者实验走向托管代理基础设施,这一区别变得重要。有状态连接会使自动扩缩、恢复和流量分配复杂化。某个服务器失败可能会带走它的会话状态,而无状态请求则可以在周边应用允许的情况下重试到另一个实例。
MCP 并未消除应用状态。需要连续性的服务器可以发出显式的句柄,例如 basket 或 browser 标识符,并要求模型在随后的工具调用中传入该句柄。状态成为模型可以检查和重用的参数,而不是隐藏的传输元数据。
该设计遵循 Soria Parra 对 MCP 的更广泛方法:保持规范精简,并使有用的行为在其之上组合。在 2025 年的采访中,他将 MCP 描述为一个故意“无聊的规范”,旨在支持类似于针对涉及语言模型交互的 API 经济体。
困难的部分上移到堆栈之上
移除持久会话要求维护者重新设计以前依赖于打开的双向流的流程。Multi Round-Trip Requests,缩写为 MRTR,现在处理服务器在工具调用期间需要更多输入的情况。服务器可以返回一个 input_required 结果,客户端则在附上所请求的答案后重试原始请求。
该机制涵盖了用户确认和缺失参数的情况,同时不允许服务器随时发起无关的请求。
修订还要求提供 Mcp-Method 和 Mcp-Name HTTP 头。网关、速率限制器和 Web 应用防火墙可以使用这些字段来路由、授权或计量流量,而无需解析每个 JSON 正文。工具、提示和资源的列表响应现在包括缓存范围和生存时间提示,减少了重复的目录请求并帮助客户端保留稳定的提示输入。
这些选择使 MCP 更容易适配公司已经运行的基础设施。它们也提高了诚实的方法命名、正确的授权策略以及对在工具之间传递的标识符谨慎处理的重要性。无状态传输移除了某一类运行时依赖;但它并未消除当代理可以调用外部系统时所产生的信任决策。
随着采用而跟进的安全工作
在 7 月的发布文章 中,MCP 的维护者表示其 Tier 1 SDKs 的月下载量接近 5 亿次,而 TypeScript 和 Python SDKs 的累计下载量都已超过 10 亿次。这些是包检索计数,而非唯一开发者、活跃服务器或生产客户,但它们显示了 MCP 组件在开发和部署系统中被移动的频率。
随着这种分发,安全暴露也在增长。National Security Agency 已警告,MCP 部署在信任边界、序列化、上下文共享和代理滥用方面引入了风险,尤其是在代理接触敏感数据或执行工具时。
Delimarsky 在 2026 年 1 月加入 Anthropic,此前他曾在 MCP 的指导小组工作并担任专注于授权与安全的核心维护者。在 他关于这一举动的说明中,他将这份工作描述为一项押注,旨在使代理与外部服务之间的互操作性更安全、更易于扩展。
7 月的规范在 RFC 9207 之下增加了发行者验证,将客户端凭证绑定到颁发它们的授权服务器,并正式弃用 Dynamic Client Registration,转而采用 Client ID Metadata Documents。变更解决了具体的 OAuth 部署问题。但它们并未解决更广泛的问题,例如某个工具是否应被信任、代理应看到哪些数据,或运营者应如何遏制被入侵的集成。
一次破坏以减少未来破坏
维护者将传输重写与旨在减少未来迁移冲击的规则配对。Roots、Sampling 和 Logging 已被弃用,旧的 HTTP 与 server-sent events 传输也被弃用,但项目承诺在弃用与移除之间至少保留 12 个月。
任务已从实验核心移入带有轮询和更新方法的扩展。扩展框架为 Tasks、MCP Apps 和企业管理的授权等功能提供了演化空间,而无需强制每个实现将它们吸收到基础协议中。
TypeScript、Python、Go 和 C# SDKs 支持新规范。依赖会话标识符的开发者仍需进行迁移工作,广泛兼容性将取决于客户端和服务器在维护者更新其实现时协商版本。
MCP 的治理也已超越 Anthropic 的直接所有权。Anthropic 于 2025 年 12 月将该项目捐赠给位于 Linux Foundation 下的 Agentic AI Foundation。项目的治理页面 将 Soria Parra 与 Delimarsky 列为首席维护者,并将 Spahr-Summers 列为首席维护者名誉职。
该结构为协议提供了一个中立的归属,同时仍将最终技术权威保留给个人。无状态重写是迄今为止对该安排最清晰的考验:这是一个由社区主导的标准,为了适应围绕它发展起来的生产系统而接受近-term 的破坏。