AgentCore Gateway 如何支持 MCP 2026-07-28 规范

今天，模型上下文协议（Model Context Protocol，MCP）发布了 2026-07-28 规范，这是该协议自推出以来规模最大、也最重要的一次修订。随这次发布，MCP 成为一种无状态协议，可以在普通的 HTTP 基础设施上扩展。除传输层变化外，这一新版本引入了受治理的扩展体系，通过更贴近企业在开放授权（OAuth 2.0）与 OpenID Connect 上的做法来加强授权，并建立了用于限制未来破坏性变更的生命周期保证。

你今天就可以在自己的 AgentCore Gateway（Amazon Bedrock AgentCore 的一项能力）上使用最新协议：调用 UpdateGateway，并传入希望网关支持的版本列表。现有客户端仍按原样工作，也不需要针对每个目标单独操作。本文说明协议改了什么、为什么要改，这对你的智能体（agent）和工具意味着什么，以及如何在网关上启用新版本。

已经熟悉规范变更？直接进入「更新你的 AgentCore Gateway」。

新规范改了什么，以及为什么重要

这次发布包含对 MCP 协议不向后兼容的变更。转向无状态是一项基础性改变。协议维护者认为，要应对企业部署中的扩展挑战，这一改变是必要的。不过，随新版本引入破坏性变更，并不被预期为常态。为便于今后的修订保持向后兼容，维护者在协议规范中加入了新的治理增强（功能生命周期策略、扩展框架，以及一致性套件要求）。这些增强旨在支持协议演进，同时不破坏核心能力。

升级也是选择加入（opt-in）的：在你和你的客户端都采取行动之前，什么都不会改变。AgentCore Gateway 通过单一配置字段公布它所使用的协议版本。客户端在每一次请求上选择版本。把 2026-07-28 加到一个同时公布 2025-11-25 的网关上，不会改变那些请求旧版本的客户端的任何行为。只有请求 2026-07-28 的客户端才会得到新行为。7 月 28 日当天不会有任何东西被破坏。

1. MCP 现为无状态

在先前版本的协议中，与 MCP 服务器的每一次可流式 HTTP（Streamable 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 服务器，运维人员需要在负载均衡器上使用粘性会话（sticky session），或者在服务器集群后面放置共享会话存储，或者两者都做。

去掉会话之后，远程 MCP 服务器实际上成为标准 HTTPS 端点，可以随企业工作负载干净地扩展。随着协议变为无状态，握手和协议级会话都不再需要（SEP-2575 与 SEP-2567 从新协议版本中移除了这些要求）。在 2026-07-28 中，每一个请求都在其 _meta 参数内携带协议版本、客户端信息和客户端能力，从而不再需要一次性的初始化握手。需要了解服务器支持内容的客户端，可以在任意时刻调用新的 server/discover 方法。净效果是：单次工具调用是完全自包含的。它不需要事先的会话上下文，并且可以被路由到任意服务器实例。移除协议会话，并不排除对有状态应用的支持。当服务器需要在多次调用之间保持连续性时，你可以沿用 HTTP 请求的既有模式，把一个显式 ID 作为工具参数传入；这个 ID 应来自你自己的某一个工具。

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}}

然后，你可以利用智能体自身的能力，把这个状态句柄贯穿到后续请求中：

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 一直把智能体与 MCP 会话机制的大部分隔离开。它把你的 AWS Lambda 函数、API 和 MCP 服务器聚合在单一 MCP 端点之后，并代表你与每一个目标进行协议对话。到了 2026-07-28，两边都更简单：智能体的第一次工具调用是一个自包含请求，而不是先握手再调用。每个请求携带 Mcp-Protocol-Version 头。当该版本出现在 supportedVersions 中时，网关按该版本处理请求；否则以 HTTP 400（代码 -32022）拒绝，并附上支持的版本列表。省略该头的请求默认使用 2025-03-26。

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

在先前版本的协议中，一个请求所执行的操作，对位于客户端与服务器之间的任何组件都是不透明的。负载均衡器、API 网关和速率限制器都必须解析 JSON-RPC 正文，才能判断正在调用的是什么方法。要发现服务器工具目录的变化，就必须保持一条长期打开的服务器发送事件（Server-Sent Events，SSE）流，并等待推送通知。简言之，MCP 流量与标准 HTTP 基础设施配合得并不好。

2026-07-28 从三个方面补上这一缺口。第一，每一个 Streamable HTTP 请求现在都在标准头中表明意图：Mcp-Method 与 Mcp-Name（SEP-2243）位于正文之外，使中间层仅凭 HTTP 层就有足够信息来做路由、限流和计量。如果服务器收到的请求里，所声明的头与正文相互矛盾，就会直接拒绝该请求。第二，列表操作和资源读取操作的响应现在包含显式的新鲜度元数据 ttlMs 与 cacheScope，其语义借自 HTTP Cache-Control（SEP-2549）。客户端可以在已知的时长和范围内缓存一次 tools/list 响应，而不必只为观察失效而维持持久连接。第三，规范现在在 _meta 内保留万维网联盟追踪上下文（W3C Trace Context）的键（traceparent、tracestate、baggage）（SEP-414），把若干 SDK 已经在实践中采用的做法正式化。从你的应用中发起的一次分布式追踪，现在可以贯穿完整调用链：从智能体到 MCP 客户端，到网关，再到下游服务，并在任何兼容 OpenTelemetry 的收集器中呈现为一棵统一的跨度树（span tree）。

在 2026-07-28 路径上，AgentCore Gateway 直接提供这些原语。来自网关的每一个工具结果都携带新的结构化结果封套；可缓存的结果包含供符合规范的客户端 SDK 使用的存活时间（TTL）与范围提示。网关也强制执行自定义头绑定：当某个工具的输入模式把一个字段标记为头绑定时，网关会拒绝头缺失、或头与正文矛盾的任何请求（HTTP 400，代码 -32020）。

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

无状态协议仍然需要一种方式，让服务器在一次调用的处理过程中把信息传回客户端。MCP 有三类这样的交互：引出（elicitation），即服务器向最终用户索取输入（“这个工具即将删除三个文件。确认吗？”）；根（roots），即服务器询问文件系统中可用的目录和文件；抽样（sampling），即服务器要求客户端的模型生成一段响应。在先前版本中，传递这些请求意味着服务器向客户端保持一条打开的 SSE 流。

在最新协议版本中，由服务器发起的请求现在只允许发生在服务器正在处理某个客户端请求的期间（SEP-2260）。用户看到的每一条提示，都可以追溯到他们或他们的智能体所发起的某件事。多往返请求（Multi Round-Trip Requests，SEP-2322）取代了先前的长生命周期流。在这里，服务器把问题嵌入一个 InputRequiredResult，并通过一个不透明的 requestState 令牌把状态外置，而不是通过 SSE 推送问题。只有那些声明了 elicitation 或 sampling 输入的工具才会触发多往返交换，并且仅当客户端声明支持该能力时才会发生。

{
  "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 引入了这种治理。每一个扩展带有反向域名标识（reverse-DNS ID），通过客户端与服务器能力中的 extensions 映射进行协商，存放在由受托维护者负责的专用仓库中，并遵循独立于核心规范的发布节奏。提案流程（SEP）中新增的扩展轨道（Extensions Track）定义了一个扩展如何从实验状态进入正式状态，这改变了协议的成长方式。新的想法不必再去争夺核心规范里的位置，并因此迫使一次破坏性的版本提升；能力现在可以作为选择加入的扩展，按自己的时间表成熟。不去协商某个扩展的客户端和服务器，不会受到影响。

5. 授权加固

六项 SEP 使 MCP 的授权规范更贴近生产环境中的 OAuth 2.0 与 OpenID Connect 部署。你的网关的入站授权，无论是身份与访问管理（IAM）的签名版本 4（SigV4），还是 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，由与大语言模型提供方 API 的直接集成取代），以及日志（Logging，在标准输入输出传输上由 stderr 取代，在结构化可观测性上由 OpenTelemetry 取代）。这些弃用是建议性的。相关方法、类型和能力标志在本版本中仍然可用，在本版本之后十二个月内发布的任何规范版本中也同样可用。不过，我们强烈建议新的实现不要依赖它们。

7. 模式支持

工具的 inputSchema 与 outputSchema 现在支持完整的 JSON Schema 2020-12 词汇（SEP-2106）。输入模式仍然要求根为 type: "object"，但增加了组合关键字（oneOf、anyOf、allOf）、条件，以及内部引用（$ref、$defs）。输出模式没有根类型限制，structuredContent 可以是任何有效的 JSON 值。实现不得自动跟随外部 $ref URI，并应在校验期间强制执行深度限制与时间限制。

判断你是否准备好更新

在启用新版本之前，先处理下面三个问题：

1. 你的客户端准备好了吗？你的智能体通过 MCP 客户端 SDK 到达网关。请检查你的智能体框架和宿主应用所使用的 SDK 是否已经交付 2026-07-28 支持。第一级 SDK 预期在为期十周的发布候选窗口内交付支持，因此今天大多数主流技术栈已经就绪。当前的分级列表见 MCP SDK 文档。在生产网关上公布 2026-07-28 之前，先测试那些支持 2026-07-28 的客户端。

2. 你所运行的任何组件，是否依赖已经移除或已经改变的行为？请审计这些项：被用来携带应用状态的协议会话、logging/setLevel、对字面错误码 -32002 做匹配的客户端代码，以及对 Roots、Sampling 或 Logging 的任何依赖。如果你的工具使用 elicitation 或 sampling，请注意：在 2026-07-28 上，网关通过一种新的按请求机制来承载它们，而不是通过持久会话。请确认你的客户端声明了相匹配的能力。省略该能力的客户端会以代码 -32021 被拒绝。

3. 你是否同时控制两边？你并不需要。版本选择发生在每一次请求上，因此一个双版本网关可以同时服务旧客户端和新客户端。你可以按各自的时间表升级客户端和网关，顺序也可以任选。

完整细节见 MCP 2026-07-28 规范、相对于 2025-11-25 的变更日志（changelog），以及 MCP 博客的发布候选公告。

更新你的 AgentCore Gateway

对 AgentCore Gateway 的客户而言，采用 2026-07-28 是一次配置变更。你的 AgentCore Gateway 可以同时支持多个协议版本。你可以用一次 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 Gateway 可以使用下列任一协议版本：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 目标上调用普通工具，并按其期望的格式收到结果，而无需自行升级。不过，这种转换目前不支持从服务器到客户端的 elicitation 与 sampling 调用。如果一个 2025-* 客户端在 2026-* 服务器上调用了需要 elicitation 或 sampling 的工具，它会收到一个错误。

结论

MCP 2026-07-28 是该协议有史以来最大的一次修订，并且它被设计成最后一次破坏兼容性的修订。无状态为 MCP 提供了一个可以在通用 HTTP 基础设施上扩展的基础，而 MCP 扩展（MCP Extensions）让新能力有空间按自己的时间表演进。

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

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/how-agentcore-gateway-supports-the-mcp-2026-07-28-spec