MCP 2026-07-28 规范发布，AgentCore Gateway 同步支持无状态新协议

MCP 2026-07-28 规范是该协议自发布以来最大规模的一次修订，包含多项向后不兼容的变更。协议维护者认为，这些破坏性变更是解决企业级部署扩展瓶颈的必要代价，但强调此类情况在未来不会成为常态。为此，新版本同步引入了功能生命周期策略、扩展框架和合规套件要求，旨在为后续版本的向后兼容演进提供制度保障。升级机制采用完全的按需选择模式，网关通过单一配置字段声明所支持的协议版本，客户端在每次请求时自行选择版本，两者均未行动之前，现有系统不会发生任何变化。

此次修订最核心的变化是 MCP 正式成为无状态协议。在此前的版本中，每次与 MCP 服务器的交互都需要先完成 initialize/initialized 握手，服务器随后颁发 Mcp-Session-Id，后续所有请求都必须携带该会话标识。这一机制将客户端与特定服务器实例绑定，导致水平扩展时必须依赖负载均衡器的会话粘性或共享会话存储。新规范通过 SEP-2575 和 SEP-2567 彻底移除了协议级会话，每次请求在 _meta 参数中自带协议版本、客户端信息与能力声明，单次工具调用即成为完全自包含的请求，可被路由至任意服务器实例。

无状态化并不意味着放弃对有状态应用场景的支持。当服务器需要跨调用保持连续性时，开发者可以沿用成熟的 HTTP 请求模式，将显式状态标识作为工具参数传递。例如，调用 create_basket 工具后，服务器返回 basket_id，后续的 add_item 调用只需在参数中携带该 ID 即可实现状态关联。AgentCore Gateway 历来负责屏蔽代理与 MCP 会话机制之间的复杂性，将 AWS Lambda 函数、API 和 MCP 服务器聚合在单一端点之后。新规范下，代理的首次工具调用从握手加调用的两步流程简化为单次自包含请求，整体交互更加简洁高效。

新规范还通过标准 HTTP 头部解决了中间层基础设施无法感知请求意图的历史痛点。在此前版本中，负载均衡器、API 网关和限流组件必须解析 JSON-RPC 请求体才能判断所调用的方法，MCP 流量与标准 HTTP 基础设施存在明显的适配摩擦。2026-07-28 规范引入了 Mcp-Method 和 Mcp-Name 两个请求头（SEP-2243），将操作意图暴露在请求体之外，使中间层可以仅凭 HTTP 层信息完成路由、限流和计量。若请求头与请求体声明的方法存在矛盾，服务器将直接拒绝该请求，从而保证一致性。

在缓存与可观测性方面，新规范为列表和资源读取操作的响应引入了显式的新鲜度元数据字段 ttlMs 和 cacheScope，借鉴了 HTTP Cache-Control 的语义设计，使代理和网关能够在不持有长连接 SSE 流的情况下感知服务器工具目录的变化。授权层面，新版本进一步对齐了 OAuth 2.0 与 OpenID Connect 的企业实践，强化了身份验证与权限管理的规范性。对于已在使用 Amazon Bedrock AgentCore Gateway 的开发者而言，启用新版本只需调用 UpdateGateway 接口并在 supportedVersions 列表中加入 2026-07-28，无需对每个目标单独操作，现有客户端继续按原有版本正常工作。

要点

• MCP 2026-07-28 是协议发布以来最大规模修订，核心变化是从有状态会话机制转向无状态架构，使 MCP 服务器可在标准 HTTP 基础设施上水平扩展
• 新规范引入功能生命周期策略、扩展框架和合规套件要求，为未来版本的向后兼容演进提供制度保障，此类破坏性变更预计不会成为常态
• AgentCore Gateway 通过单次 UpdateGateway 调用即可同时支持新旧版本协议，升级完全按需选择，现有客户端行为不受影响
• Mcp-Method 和 Mcp-Name 新增请求头让中间层基础设施无需解析请求体即可完成路由与限流，显著改善了 MCP 流量与标准 HTTP 基础设施的兼容性
• 无状态化不影响有状态应用场景，开发者可通过在工具参数中传递显式状态标识实现跨调用的状态连续性