MCP 新规范（2026-07）：无状态+授权强化

MCP 新规范（2026-07）：无状态+授权强化 | 前端进阶之旅

Full translation

完整中文译文

今天，模型上下文协议（MCP）发布了其 2026-07-28 规范，这是该协议启动以来规模最大、最重要的修订。在这个版本中，MCP 成为了一个无状态协议，可以在普通 HTTP 基础设施上扩展。除了传输层的变化，这个新版本引入了受治理的扩展系统，通过更紧密地与 OAuth 2.0 和 OpenID Connect 的企业实践对齐来加强授权，并建立了限制未来破损的生命周期保证。

你可以今天就通过调用 UpdateGateway 并指定网关要支持的版本列表，在 AgentCore Gateway（Amazon Bedrock AgentCore 的一项功能）上开始使用最新协议。现有客户端继续完全按照之前的方式工作，不需要对每个目标进行特殊步骤。在本文中，我们将详细介绍协议中的变化及其原因、对你的 AI 智能体和工具的影响，以及如何在网关上启用新版本。

已经熟悉规范变化了？直接跳到更新 AgentCore Gateway。

新规范的变化及其重要性

此版本包含对 MCP 协议的向后不兼容的更改。向无状态的转变是协议维护者认为有必要解决企业部署中的扩展挑战的基础性改变。然而，在新版本中引入破坏性更改预计不会成为常态。为了帮助在未来修订中促进向后兼容的更新，维护者在协议规范中引入了新的治理增强（功能生命周期策略、扩展框架和一致性测试套件要求）。这些增强的设计目的是支持协议演进，同时不破坏核心功能。

升级也是可选的，只有你和你的客户端都采取行动时，才会产生变化。AgentCore Gateway 通过单一配置字段声明它支持的协议版本。客户端在每个请求上选择一个版本。向同时声明 2025-11-25 的网关添加 2026-07-28 不会改变请求旧版本的客户端的任何内容。只有请求 2026-07-28 的客户端才会获得新的行为。7 月 28 日不会有任何损坏。

1. MCP 现在是无状态的

在协议的早期版本中，每个与 MCP 服务器的可流式 HTTP 交互都从 initialize/initialized 握手开始，在该握手中，客户端和服务器交换协议版本和功能。服务器随后发出一个 Mcp-Session-Id 标头，随后的每个请求都需要携带这个标头：

POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json
Accept: application/json

{"jsonrpc":"2.0","id":2,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"}}}

该会话将客户端固定到发出它的服务器。因此，为了水平扩展 MCP 服务器，运营者需要在负载均衡器处使用粘性会话、服务器集群后面的共享会话存储，或两者兼有。

通过移除会话，远程 MCP 服务器有效地成为标准 HTTPS 端点，可以与企业工作负载良好扩展。随着协议变为无状态，握手和协议级会话都不再需要（SEP-2575 和 SEP-2567 从新协议版本中移除了这些要求）。使用 2026-07-28，每个请求现在在其 _meta 参数中携带协议版本、客户端信息和客户端功能，消除了对一次性初始化握手的需要。需要了解服务器支持什么的客户端可以随时调用新的 server/discover 方法。净效果是单个工具调用是完全自包含的。它不需要前置会话上下文，可以被路由到任何服务器实例。移除协议会话不排除对有状态应用程序的支持。当服务器需要跨调用的连续性时，你可以通过将显式 ID 作为工具参数来遵循 HTTP 请求的既定模式，该参数应来自你自己的工具之一。

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_basket
Content-Type: application/json
Accept: application/json,text/event-stream

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

{"jsonrpc":"2.0","id":1,
"result":{"resultType":"complete","content":[{"type":"text","text":"Created basket bsk_a1b2c3"}],"structuredContent":{"basket_id":"bsk_a1b2c3"},"isError": false}}

随后，你可以使用 AI 智能体自身的功能来将此状态句柄通过后续请求传递：

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: add_item
Content-Type: application/json
Accept: application/json,text/event-stream

{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"add_item","arguments":{"basket_id": "bsk_a1b2c3", "sku": "shoes"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

AgentCore Gateway 一直对 AI 智能体隐蔽了许多 MCP 的会话机制。它将你的 AWS Lambda 函数、API 和 MCP 服务器聚合在单个 MCP 端点后面，并代表你管理与每个目标的协议对话。使用 2026-07-28，这在两个方面都变得更简单：AI 智能体的第一个工具调用是一个自包含的请求，而不是握手后跟调用。每个请求都携带一个 Mcp-Protocol-Version 标头。当版本出现在 supportedVersions 中时，网关在该版本中提供请求，或当不在时以 HTTP 400（代码 -32022）和支持的版本列表拒绝它。省略标头的请求默认为 2025-03-26。

2. 无需解析正文的路由、缓存和追踪

在协议的早期版本中，请求执行的操作对位于客户端和服务器之间的任何东西都是不透明的。负载均衡器、API 网关和速率限制器都必须解析 JSON-RPC 正文来确定调用了什么方法。检测服务器工具目录的更改意味着保持长期的 SSE 流打开并等待推送通知。总之，MCP 流量与标准 HTTP 基础设施的配合并不好。

2026-07-28 通过三种方式弥补了这一差距。首先，每个可流式 HTTP 请求现在在标准标头中表明其意图：Mcp-Method 和 Mcp-Name（SEP-2243）在正文外传输，为中介者提供足够的信息来仅在 HTTP 层进行路由、节流和计量。接收到声明的标头与正文矛盾的请求的服务器会直接拒绝它。其次，对列表和资源读取操作的响应现在包括显式的新鲜度元数据，ttlMs 和 cacheScope，借用了 HTTP Cache-Control（SEP-2549）的语义。客户端可以在已知的持续时间和范围内缓存 tools/list 响应，而无需维持持久连接只是为了监视失效。第三，规范现在在 _meta（SEP-414）内保留了 W3C Trace Context 密钥（traceparent、tracestate、baggage），将几个 SDK 已经在实践中采用的内容正式化。源自你的应用程序的分布式追踪现在可以通过完整的调用链传播，从 AI 智能体到 MCP 客户端到网关到下游服务，并在任何与 OpenTelemetry 兼容的收集器中呈现为统一的跨度树。

在 2026-07-28 路径上，AgentCore Gateway 直接表面这些原语。来自你网关的每个工具结果都携带新的结构化结果信封，可缓存的结果包括对符合标准的客户端 SDK 的 TTL 和范围提示。网关还强制执行自定义标头绑定：当工具的输入架构将字段标记为标头绑定时，网关拒绝任何标头缺失或与正文矛盾的请求（HTTP 400，代码 -32020）。

3. 无需持久连接的服务器到客户端交互

无状态协议仍然需要一种方式让服务器在调用中间与客户端通话。MCP 有三种这样的交互：引出，其中服务器向最终用户请求输入（"此工具即将删除三个文件。确认吗？"），根，其中服务器请求文件系统中可用的目录和文件，以及采样，其中服务器要求客户端的模型生成响应。在早期版本中，传送这些请求意味着服务器保持 SSE 流打开回客户端。

在最新的协议版本中，服务器初始化的请求现在仅允许在服务器积极处理客户端请求时进行 (SEP-2260)。用户看到的每个提示都可以追溯到他们或他们的 AI 智能体开始的操作。多轮往返请求 (SEP-2322) 取代了之前的长期流。这里，服务器将问题嵌入 InputRequiredResult 中，并通过不透明的 requestState 令牌来外部化状态，而非通过 SSE 推送问题。只有声明了引出或采样输入的工具才会触发多轮往返交换，且仅当客户端声明支持该功能时才会进行。

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "method": "elicitation/create",
      "params": {
        "mode": "form",
        "message": "Delete 3 files?",
        "requestedSchema": {
          "type": "object",
          "properties": {
            "confirm": {
              "type": "boolean"
            },
            "required": ["confirm"]
          }
        }
      }
    },
    "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
  }
}

客户端收集用户的答案，并使用响应和 requestState 重新发送原始调用。服务器所需的所有信息都在有效负载中，因此任何服务器实例都可以处理重试。

另外，进度通知和日志交付现在是请求范围内的。网关仅在客户端在原始请求上提供进度令牌时才转发进度更新，仅在客户端在每个请求的元数据中设置 io.modelcontextprotocol/logLevel 时才交付日志消息。

4. 将扩展与核心规范解耦

直至现在，MCP 扩展还是一个没有治理的非正式概念。SEP-2133 改变了这一点。每个扩展都带有一个反向 DNS 标识符，通过客户端和服务器功能中的扩展映射进行协商，存放在由委派维护人员管理的专用仓库中，并按照独立于核心规范的自有发布周期进行演进。SEP 流程中新增的扩展轨道定义了扩展如何从实验状态升级到官方状态，这改变了协议的演化方式。与其让每个新想法都争夺核心规范中的空间并强制进行破坏性版本升级，现在能力可以作为可选扩展在各自的时间表上逐步成熟。没有协商给定扩展的客户端和服务器不受影响。

5. 授权加固

六个 SEP 将 MCP 的授权规范与生产环境中的 OAuth 2.0 和 OpenID Connect 部署更加紧密对齐。你的网关的入站授权（无论是 IAM 还是 OAuth/JWT）不受协议版本变更的影响。你的出站凭证提供者也是如此。升级协议版本不需要更改凭证或授权器配置。

6. 错误处理和弃用

在较早的协议版本中，几乎所有内容都以 HTTP 200 返回，并在 JSON-RPC 主体内隐藏错误，包括传输级别的故障。在 2026-07-28 上，传输层和应用层被清晰分离。传输故障返回真实的 HTTP 状态代码。应用级别的结果保留在主体中：

这些变化仅对检查错误响应的代码有影响。它们允许你的 HTTP 级别监控、告警和重试逻辑在不解析主体的情况下区分路由问题和应用级别的问题。规范还将"资源未找到"错误代码从 MCP 特定的 -32002 重新分配给 JSON-RPC 的标准 -32602 Invalid Params (SEP-2164)。如果你的客户端在任何地方都与 -32002 匹配，请审计这些代码路径。另外，在 2026-07-28 路径上：logging/setLevel 已弃用，调用它的客户端将被拒绝。要选择进行日志交付，可以设置每个请求的元数据字段 io.modelcontextprotocol/logLevel。

协议的新功能生命周期策略 (SEP-2577) 下弃用了三个核心功能：Roots（由工具参数、资源 URI 或服务器配置取代）、Sampling（由 LLM 提供商 API 的直接集成取代）和 Logging（由 stdio 传输的 stderr 和结构化可观测性的 OpenTelemetry 取代）。这些弃用是建议性的。这个版本以及在其发布后十二个月内发布的任何规范版本中，方法、类型和功能标志仍然有效。但我们强烈建议新的实现不要依赖它们。

工具 inputSchema 和 outputSchema 现在支持完整的 JSON Schema 2020-12 词汇 (SEP-2106)。输入架构保留了 type: "object" 根要求，但获得了组合关键字 (oneOf、anyOf、allOf)、条件语句和内部引用 ($ref、$defs)。输出架构没有根类型限制，structuredContent 可以是任何有效的 JSON 值。实现不得自动跟随外部 $ref URI，应在验证期间强制执行深度和时间限制。

决定你是否准备好更新

在启用新版本之前，请回答三个问题：

你的客户端准备好了吗？ 你的 AI 智能体通过 MCP 客户端 SDK 到达网关。检查你的 AI 智能体框架和主机应用程序使用的 SDK 是否已支持 2026-07-28。第 1 级 SDK 应在十周发布候选窗口期间发货支持，因此大多数主流堆栈现在已准备好。请参阅 MCP SDK 文档了解当前层列表。在生产网关上发布支持之前，测试支持 2026-07-28 的客户端。

你运行的任何东西是否依赖于已删除或更改的行为？ 审计以下内容：协议会话用于携带应用状态、logging/setLevel、匹配文字 -32002 错误代码的客户端代码，以及对 Roots、Sampling 或 Logging 的任何依赖。如果你的工具使用引出或采样，请注意网关通过 2026-07-28 上的新的每个请求机制而非持久会话来执行这些操作。确认你的客户端声明了匹配的功能。省略它的客户端将被以代码 -32021 拒绝。

你是否控制双方？ 你不需要。版本选择按请求进行，因此双版本网关可以同时为旧客户端和新客户端提供服务。你可以在独立的时间表上升级客户端和网关，任何顺序都可以。

有关完整详情，请参阅 MCP 2026-07-28 规范、针对 2025-11-25 的更改日志，以及 MCP 博客的候选版本发布公告

更新你的 AgentCore 网关

对于 AgentCore 网关客户，采用 2026-07-28 是一个配置变更。你的 AgentCore 网关可以同时支持多个协议版本。你可以通过单个 UpdateGateway 调用将 2026-07-28 添加到网关的 supportedVersions 列表中。无需重新创建网关或对个别网关目标配置进行更改。MCP 版本是网关的属性，而非其目标的属性，该属性的更新在原地执行。工具定义、目标配置和入站认证（IAM 和 OAuth）都不受版本变更的影响。

UpdateGateway 将 supportedVersions 替换为你发送的集合。它不会附加。首先读取当前配置，然后发送你想要网关宣传的完整列表：

# 1. Read the current configuration.
aws bedrock-agentcore-control get-gateway \
    --gateway-identifier <gateway-id>

# 2. Advertise 2026-07-28 alongside the existing version.
aws bedrock-agentcore-control update-gateway \
    --name <gateway-name> \
    --role-arn <gateway-role-arn> \
    --protocol-type MCP \
    --authorizer-type <gateway-authorizer-type> \
    --gateway-identifier <gateway-id> \
    --protocol-configuration '{
  "mcp": {
    "supportedVersions": ["2025-11-25", "2026-07-28"]
  }
}'

AgentCore 网关支持以下任何协议版本：2025-03-26、2025-06-18、2025-11-25 和 2026-07-28。

通过使用新标头调用网关来确认新版本处于活动状态：

curl -s https://<your-gateway-endpoint>/mcp \
    -H "Authorization: Bearer $TOKEN" \
    -H "Content-Type: application/json" \
    -H "Accept: application/json,text/event-stream" \
    -H "MCP-Protocol-Version: 2026-07-28" \
    -H "Mcp-Method: tools/list" \
    -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

成功的响应确认网关以 2026-07-28 版本为该请求提供了服务。代码 -32022 的拒绝表示该版本还不在网关的 supportedVersions 中，响应主体列出了网关当前宣传的版本。

supportedVersions 是网关宣传的完整集合，因此回滚是相同的逆向操作。即，发送不包含 2026-07-28 的列表。指定已删除版本的请求将被拒绝，响应主体列出了网关仍然支持的版本。在删除他们请求的版本之前，请确保你已迁移的客户端可以回退。

版本选择如何工作

客户端在每次请求时选择版本，而不是通过一次性握手。每个MCP请求在MCP-Protocol-Version头中声明其版本，当该版本在supportedVersions中时，网关会遵守该版本：

一个声明网关公布的版本的请求会使用该版本进行服务。在双版本网关上（例如，2026-07-28和2025-11-25），一个2026-07-28请求会获得新行为，而一个2025-11-25请求会获得早期行为。

一个声明网关不公布的版本的请求会被拒绝，返回HTTP 400和代码-32022。响应体列出网关支持的版本。

一个省略该头的请求会获得默认版本2025-03-26。如果该默认值不在网关的supportedVersions中，请求会被拒绝。

只要现有客户端请求网关的supportedVersions中列出的协议版本，它们就会继续工作。这为你提供了一个干净的三阶段部署：在现有版本旁添加2026-07-28，按自己的节奏迁移客户端，只有在所有客户端都请求新版本后，才能缩减列表。

如果你的网关代理的MCP服务器目标在你的客户端之前升级到2026-07-28，它会在版本之间进行转换，因此2025-*客户端可以在2026-07-28目标上调用普通工具并以其期望的格式接收结果，而无需升级。但是，此转换目前不支持从服务器到客户端的交互式调用和采样请求。如果2025-*客户端在2026-*服务器上调用需要交互或采样的工具，它会收到错误。

MCP 2026-07-28是该协议有史以来最大的修订，旨在成为最后一个破坏兼容性的修订。无状态性为MCP提供了在通用HTTP基础设施上扩展的基础，而MCP扩展为新功能提供了按自己的日程表演进的空间。

通过Amazon Bedrock AgentCore Gateway，添加对最新协议版本的支持只需一个UpdateGateway调用。要开始，请参阅AgentCore Gateway文档，查看MCP 2026-07-28规范及其变更日志，并尝试在今天在网关上启用新版本。如果你对规范本身有反馈，维护者欢迎在MCP规范仓库中提交问题。关于AgentCore Gateway的问题，请通过AWS re:Post或你常用的AWS支持渠道联系。