2026-07-28版本规范中的无状态MCP：对代理基础设施有哪些变化？
新版MCP更新去掉了会话功能，增加了路由头部、input_required往返机制以及更严格的OAuth验证。这对网关、扩展能力及安全性有何影响。
来源: MCP Goes Stateless: Why the New Spec Changes Agent Infrastructure
模型上下文协议发展迅速。最初，讨论的重点是将人工智能应用与工具及数据相连。此后，该协议经历了OAuth授权、远程服务器、大规模协议修订、注册系统、客户端ID元数据文档以及企业级授权等演变。2026-07-28版本的规范则带来了更为根本的变化：协议本身变成了无状态设计。
初始化握手流程已被取消，协议级会话也不复存在。客户端不再需要绑定到接受其连接的服务器实例。每个请求都包含足够的信息，可以独立处理，任何兼容的实例都能对其作出响应。
这看似只是传输层面的优化，但其对架构的影响更为深远。远程服务器可以表现得像任何云原生HTTP服务，能够部署在普通的负载均衡器、API网关、WAF、无服务器平台以及可扩展的容器集群之后，无需使用专门针对MCP的会话处理机制。
此次修订还带来了其他改进：标准化的路由头部、可缓存的任务发现结果、多轮请求支持、更严格的授权规则、OpenTelemetry规范以及正式的扩展模型。作为基础设施，MCP显得不再那么特殊，这或许是它成熟度最高的体现之一。接下来的内容将介绍这些变更、为什么无状态设计在生产环境中如此重要，以及它对安全性、网关和更广泛的代理运行时所带来的影响。
为何会话机制有害
MCP最初是为了解决一个简单的问题：为人工智能应用提供一种标准方式来处理工具、资源以及外部系统。对于本地客户端和服务器而言，这种方式运作得相当顺畅。但远程MCP改变了这一状况。当服务器分布在容器、Kubernetes集群、无服务器平台以及云基础设施中时，协议层面的会话引发了常见的分布式系统难题。
客户端发起初始化握手后，服务器会分配一个Mcp-Session-Id，此后所有的请求都必须保持这种关联。在大规模应用中，这可能意味着：
- 负载均衡器的粘性配置
- 共享的会话存储机制
- 能够理解会话状态的故障转移机制
- 长生命周期的连接
- 额外的生命周期管理功能
这些都不是无法管理的，因为分布式系统早已处理了数十年。值得探讨的是，MCP是否真的有必要制造这些问题，而随着2026-07-28的到来，答案越来越倾向于“不需要”。
新规范完全去掉了initialize和notifications/initialized的握手流程、协议级会话以及Mcp-Session-Id。请求中会包含处理它们所需的所有信息。从概念上讲，架构的变化如下：
任何兼容的实例都能处理下一个请求。这更适用于Kubernetes、容器、无服务器函数、自动扩缩容、边缘基础设施以及普通的轮询负载均衡机制。
这一变革已在实践中实现。Cloudflare已将自身的MCP服务器迁移到该架构，并为每个请求构建全新的无状态服务器。谷歌指出，废弃粘性会话及共享会话基础设施能显著提升扩展能力。AWS AgentCore Gateway现在在原有MCP版本的基础上也支持新协议。因此，这属于当前的部署模式，而非仅限于理论架构。
状态并未消失
此处有一个重要区别需要明确：删除MCP会话并不会阻止应用程序保留状态。这意味着应用程序状态不应隐藏在传输层中。以一个创建工作空间的代理为例：
create_workspace()
|
v
workspace_id = ws_123
后续请求可以明确指定结果名称：
update_workspace( workspace_id = "ws_123" )
第一个请求可能会被发送到服务器A，而第二个请求则会被发送到服务器C。该应用仍然具有状态，但现在有了明确的标识符，不再依赖客户端与某个服务器进程之间的隐式关联。
协议状态与应用状态是不同的概念。明确的应用状态更易于持久化、审计、授权、设置过期时间以及进行分析，而代理系统还能获得进一步的优势：代理可以直接操作该标识符，并在各种工具和工作流步骤之间传递它。
路由头部
无状态特性解决了某个基础设施问题，而对于企业级部署而言，另一个变化可能同样重要。MCP现在标准化了用于描述正在进行的操作的HTTP头部，例如：
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: delete_workspace
过去，中间件可能需要解析 JSON-RPC 数据包才能了解代理的需求。现在这些信息在 HTTP 层即可查看，这为某些应用带来了新的可能。
安全团队有理由关注这一点。由于代理能够使用更强大的工具，网关便成了在意图与实际外部效果之间实施策略的理想位置。不过这并不会取代对代理框架或应用层控制的需求，反而能让协议、网关、代理框架及其背后的系统之间的界限更加清晰。
在无会话状态下请求输入
无状态设计会带来一个明显的问题：如果服务器在完成操作前需要更多信息该怎么办？试想一下一种具有破坏性的调用场景：
delete_environment(“production”)
服务器可能首先需要确认。仅为该次交互保持双向会话开启状态，会削弱无状态设计带来的诸多优势。
规范给出的解决方案是多往返请求（MRTR）。会话不再维持交互的持续状态，服务器而是返回一个input_required结果，说明其所需信息。整个交互过程大致如下：
人工审批、额外身份验证、缺失的参数、策略检查以及类似的交互流程，都可以融入无状态请求模型中。这对于高风险代理操作尤为重要。能够调用工具并不意味着代理就拥有无限权限，敏感操作在执行前还可以增加决策环节。
缓存与可观测性
一些看似细微的改动在大规模应用中也可能产生重要影响。具体包括操作列表的整理：
tools/list
prompts/list
resources/list
resources/read
现在可以返回诸如 ttlMs 和 cacheScope 这样的缓存详细信息，且工具列表会以确定的顺序返回。这看似只是常规的 HTTP 优化，但实际上 AI 系统也能从中受益：稳定的工具定义有助于在 LLM 端更好地缓存提示词，而以随机顺序到达或需要反复重新发现的工具则会将微小的协议缺陷转化为额外的延迟和令牌成本。
该规范还介绍了如何传递 OpenTelemetry 上下文，其中包含一些常见的字段：
traceparent
tracestate
baggage
这又是MCP向DevOps和平台团队已熟悉的基础设施靠拢的例子。其目标不应是为AI协议单独构建一套可观测性技术栈，而应在组织已运行的系统中让代理活动清晰可见。
身份认证愈发重要
无状态请求并不会降低身份认证的重要性，反而使得每一次请求的身份验证都至关重要。新规范延续了MCP向成熟的OAuth和OpenID Connect实践靠拢的趋势，其中包括用于防范授权服务器混淆攻击的发行方验证机制，以及更严格的凭证绑定机制。
该规范正式明确了此前已逐渐形成的趋势：动态客户端注册已被废弃，取而代之的是客户端ID元数据文档。相比动态客户端注册，客户端ID元数据文档更简洁高效，而动态客户端注册则因兼容性原因仍在使用，现在规范中也明确指出了这一点。这又是MCP成熟度的一个体现，因为它避免了使用私有的身份系统，而是不断向网络已有的标准靠拢。随着MCP从少数用户授权的集成发展为由大量代理、客户端、网关和工具构成的系统，对于企业级代理部署而言，这一点愈发重要。
注册仅是授权流程中的一小部分。在企业规模层面，更棘手的问题是哪些代理可以访问哪些功能：数百个代理调用数百项服务，会带来N×M级别的治理难题。企业管理授权（EMA）与身份断言授权授权机制（ID-JAG）这两种方案将决策权交由企业中央策略来处理。企业身份提供者负责决定某个代理是否具备访问权限，这样一来，各个MCP服务器就无需逐一征求用户的同意了。
无状态MCP并不会取代这种模式，它只是进一步明确了各组成部分的界限：传输状态、客户端身份、授权策略以及应用状态属于不同的架构考量范畴。
哪些内容不在核心范围内
此次更新中值得关注的一点是MCP放弃了哪些功能或将其移至了其他位置。Roots、Sampling和Logging已从核心模型中移除，而旧的HTTP+SSE传输方式也被Streamable HTTP所取代。与此同时，一个正式的扩展框架也应运而生，这样一来像Tasks这样的功能就可以通过扩展来添加，而不会使协议核心变得臃肿。这就意味着有了更清晰的边界：
MCP无需成为整个代理运行时环境。运行时环境仍然掌控着更广泛的执行环境，而MCP则为该环境提供了与外部功能交互的标准方式。一个成熟的协议不仅取决于它添加了什么功能，还取决于它决定将哪些功能放在其他地方。
无状态并不等同于可信任
无状态MCP服务器的扩展更为简单，但无状态并不意味着安全可靠：每个请求仍需跨越安全边界。提示注入或被污染的上下文仍可能操控智能体。工具仍可能拥有过度权限，凭证仍可能配置错误，供应链漏洞仍可能引入恶意服务器或工具。
变化在于架构变得更加清晰。防御措施不再将传输会话视为安全模型的一部分，而是聚焦于能够验证的调用者身份、网关执行的策略以及每个工具授予的权限。通过添加明确的授权机制和资源标识符，对输入进行验证，要求人工审批敏感操作，记录遥测数据以供审计，同时也要控制智能体的使用。
一个需要注意的细节是：客户端元数据并不等同于身份凭证。客户端在请求元数据中声明的信息，无法像通过OAuth或其他可信机制加密验证过的身份那样被视作可靠依据。由于能够更轻松地路由和检查MCP流量，安全团队可以在不将元数据误认为信任依据的情况下，更有效地加强对该协议的管控。
整体视角
2026-07-28日的核心变化很简单：MCP是无状态的。更重要的在于这一特性所带来的可能性。MCP请求的行为更接近于普通的HTTP工作负载。服务器可以无需会话绑定即可实现水平扩展。网关通过标准头部信息来理解MCP操作。发现功能可以被缓存。交互式工作流可通过多轮往返请求来持续进行。授权机制正逐步采用经过验证的OAuth方案，可观测性功能可使用OpenTelemetry，而扩展机制则能为后续发展留出空间，同时不会让核心部分变成整个代理运行时环境。
单独来看，这些似乎只是协议的改进，但综合起来则意义更为深远。MCP最初是为解决连接问题而诞生的。远程MCP则迫使整个生态系统面对身份认证与授权问题。CIMD和企业授权机制如今着眼于治理层面，而无状态MCP则致力于提升可操作性与扩展性。这一协议正逐渐变得不再那么复杂，能够适配那些人们已经熟悉其构建、安全防护、监控及运行方式的基础设施。对于发展如此迅速的技术而言，变成一种普通的基础设施或许正是其最终目标。
相关阅读
- 实用笔记：“MCP：将AI从聊天机器人转变为AI智能体的协议” —— 该实用笔记的详细操作指南，包括合同定义、校验规则以及供开发MCP系统的团队直接使用的代码模板。
- 利用四台MCP服务器在LM Studio中构建本地研究智能体 —— 将文件系统、GitHub、SearXNG和Camofox的MCP服务器整合到同一个LM Studio聊天界面中，简化工具架构，添加研究计划提示功能，并通过演示验证其功能完整性。