Amazon AWS 支持无状态 MCP，但兼容性如今才是真正的考验

在该规范最大规模的架构修订正式稳定发布两天后，Amazon AWS 为 AgentCore Gateway 添加了 MCP 2026-07-28 支持。一次 UpdateGateway 调用即可在现有网关上启用新协议版本。然而，这项看似简单的控制平面变更，背后却隐藏着客户端、服务器和企业安全团队更棘手的过渡挑战。

新版 Model Context Protocol 移除了协议层会话，并要求每个请求自行描述其版本和客户端能力。MCP 是一项开放标准，用于将 AI 应用与工具、数据源及其他服务连接起来。其无状态设计有望让网关更易于扩展、路由和恢复。

这一优势也带来了兼容性考验。客户端必须采用新的请求元数据，服务器必须实现发现机制，旧有的会话假设也不再成立。Amazon Bedrock AgentCore Gateway 现处于这两个协议时代之间：它将企业服务转换为 MCP 工具，同时在一个托管端点实施访问控制。

因此，真正的故事远不止于勾选一个版本选项。Amazon AWS 正在押注：托管网关能够在协议变化波及每个应用团队之前将其吸收。这一策略能否奏效，取决于版本协商、授权正确性，以及混合客户端群体的实际行为。

Amazon AWS 将 MCP 的重大重写变成一次网关更新

AWS 将基础设施步骤缩减为一次 API 操作，但应用仍需正确使用修订后的协议。

MCP 维护者于 7 月 28 日发布稳定版 2026-07-28 规范，此前其候选发布阶段始于 5 月。稳定版 MCP 发布替换了该协议早期发展阶段形成的若干假设。

随后，AWS 在 Amazon Bedrock AgentCore Gateway 中推出支持。根据该公司的 AgentCore 更新说明，网关所有者可通过 UpdateGateway 添加这一新版本。该请求会更新网关的 MCP 协议配置及其支持的版本列表。

相关的控制平面对象是 protocolConfiguration.mcp.supportedVersions。AWS 将该字段记录为网关可使用的 MCP 版本数组。当服务接受更新时，UpdateGateway 会返回 HTTP 状态码 202，之后网关将进入更新状态。

这一差异在运维层面很重要。调用被接受，并不意味着每个已连接客户端都已成功完成请求。团队应等待网关恢复到就绪状态，再针对实际端点运行一致性和工作负载测试。

这一变更并不要求组织重建网关背后的每个 Lambda 函数、OpenAPI 服务或 Smithy 服务。AgentCore Gateway 已可将这些资源转换为兼容 MCP 的工具。根据目标配置，它还支持远程 MCP 目标及其他 HTTP 服务。

这种架构让 AWS 能够改变面向协议的层，而无需对每个下游业务服务做出完全相同的改动。例如，客户支持 API 可以继续作为 API 存在，同时由网关将其操作暴露为供兼容智能体使用的工具。

AgentCore Gateway 还负责入站认证、出站凭证、工具发现、路由和策略执行。当一个端点面向由多个内部团队负责的服务时，这些控制能力会更具价值。

然而，UpdateGateway 调用只会变更网关声明的支持范围。使用 2026 版本的客户端仍必须发送所需元数据和请求头。较旧的客户端则必须协商一个双方都支持的版本，或采用兼容的回退路径。

这是 AWS 简化升级信息背后的第一个限制。托管服务可以减少平台工作量，但无法让过时的 SDK 自动生成新的线格式。

第二个限制涉及测试。网关所有者需要在每个受支持版本下验证工具列表、工具调用、认证失败、流式行为和缓存控制。一个现代客户端的成功，并不能证明整个企业客户端群体均具备兼容性。

因此，务实的推广应从盘点开始。团队需要识别哪些智能体应用连接到网关、它们使用哪些 SDK 版本，以及这些 SDK 是否支持 MCP 2026-07-28。

在可搜索的工程知识库中维护技术决策和测试证据的组织，可以按客户端和协议版本记录结果。当故障只出现在某个框架或部署渠道时，这些记录将变得尤为重要。

AWS 已将控制平面操作压缩到很小的范围。应用层验证仍是实际迁移项目的核心。

为什么无状态 MCP 改变了网关的计算方式

无状态 MCP 将兼容性信息置于每个请求中，使水平路由更简单，同时要求每条消息都能独立成立。

早期 MCP 版本通过初始化交换来建立协议细节和能力。客户端发送 initialize，服务器作出响应，客户端再以 notifications/initialized 完成序列。Streamable HTTP 还可以使用 Mcp-Session-Id 请求头，将后续流量关联到协议层会话。

MCP 关键变更移除了新版本中的这一生命周期，同时也移除了协议层会话标识符。需要跨调用保存状态的服务器，必须签发显式句柄，由客户端将其作为常规工具参数传递。

每个新式请求都会在 _meta 中携带其协议版本和客户端能力。客户端也应在其中标识自身。服务器则在结果元数据中返回自身标识，使每次交换都具有更强的自描述性。

新的 server/discover 方法允许客户端在开始其他工作前检查支持的版本、能力和服务器身份。使用 2026-07-28 版本的服务器必须实现这一远程过程调用。

这一设计改变了网关需要记住的内容。它不再需要依赖通过单一连接完成的初始化交换，也不再需要将后续协议流量关联到不透明的 MCP 会话。

负载均衡器可以路由各个独立请求，而无需保持协议层亲和性。接收第十次调用的网关实例，可以检查与第一个实例收到的同样关键的兼容性信息。

这一模型适合托管云网关。无状态服务可以跨工作进程扩展、替换不健康的容量，并在无需恢复 MCP 会话记录的情况下分配流量，再解释每个请求。

它也减少了短生命周期云基础设施与面向连接协议行为之间的不协调。无服务器函数和分布式网关通常在请求包含独立处理所需信息时表现最佳。

不过，无状态并不意味着智能体的工作没有状态。采购工作流仍可能需要审批信息、交易引用，或此前交换中收集的数据。该规范将这些状态转移为显式的应用层句柄，而非隐藏在传输会话中。

这种转变可以提升可见性。工具参数和服务器签发的句柄，比从连接中推断的状态更能形成清晰的所有权边界。但它们也要求谨慎设计，因为客户端可能重试请求或提交旧句柄。

新版本取消了通过 Last-Event-ID 和服务器发送事件标识符实现的 Streamable HTTP 可恢复性。如果请求期间响应流中断，客户端必须发送带有新请求 ID 的新请求。

这一规则带来了一个重要的运维问题。如果工具在流失败前已执行副作用，盲目重试可能会重复该操作，除非应用实现幂等性。

设想一个创建支持工单的智能体。工单服务可能已成功存储记录，但响应流却消失了。重试应携带应用层幂等键，或在创建另一张工单前查询此前的操作。

AWS 无法在协议边界解决所有下游幂等性问题。网关日志和追踪可以显示重复调用，但目标服务必须定义安全的重试行为。

该版本还以多轮往返请求取代了独立的服务器发起调用。在这种模式下，服务器返回描述其仍需信息的 input_required 结果。客户端使用所请求的响应重试原始请求。

这种方法将控制保留在一个请求和重试序列之内。它避免了独立的服务器到客户端请求通过某个可能不属于同一网关实例的连接到达。

现在所有结果都包含 resultType，通常为 complete 或 input_required。与旧服务器通信的客户端必须将省略该值视为已完成的结果，从而保留有限的兼容性桥梁。

这一机制显然更倾向于分布式基础设施。代价是 SDK 和应用必须采用更明确的元数据、重试逻辑和状态处理。

压力落在 SDK 和混合客户端群体上

AgentCore Gateway 可以支持两个协议时代，但每个组织都必须证明其客户端协商到了正确的版本。

直接承受压力的目标并非隐藏在网关后的 API，而是连接到 MCP 端点的客户端软件。

声称支持 2026-07-28 版本的客户端必须在每个请求中发送协议版本及其能力。它必须理解 server/discover、必需的结果类型，以及多步骤交互的修订处理方式。

HTTP 客户端还必须使用标准 MCP 请求头，包括 Mcp-Method 和 Mcp-Name。这些请求头让基础设施无需解析每个 JSON-RPC 请求体即可检查和路由流量。

这一变化对网关、可观测性系统和安全控制很有用。它也新增了一个验证点：不完整的客户端可能在工具执行前就失败。

MCP 为这一新边界定义了特定错误。请求头不匹配使用代码 -32020，缺少必需客户端能力使用 -32021，不支持的协议版本使用 -32022。

这些代码为平台团队提供了更清晰的故障分类。-32022 响应增加表明版本协商存在问题，而 -32020 则指向 HTTP 请求头与其中所含请求之间的不一致。

SDK 的过渡不会在所有语言中同步发生。官方实现可能按照不同的节奏采用稳定规范，而应用往往会在新版本发布很久后仍固定使用旧版库。

企业还拥有一些无法完全控制的客户端。员工可能会使用获批准的桌面助手、内部命令行智能体，以及由其他团队开发的 IDE 扩展。它们各自协商 MCP 的方式可能不同。

AgentCore 的受支持版本列表为这一混合客户端群体提供了桥梁。网关可以声明多个版本，而不是强迫所有客户端同时转向新的线格式。

这种支持应被视为一种迁移机制，而非行为完全一致的证明。2026 核心中移除的功能仍存在于旧版协议流程中。在协商使用较早修订版后通过的测试，对无状态路径的说明意义不大。

Roots、Sampling 和 Logging 现已被弃用，而非立即从整个规范中移除。新的实现应避免采用这些功能，现有实现则获得明确的过渡期。

MCP 的新功能生命周期政策规定，弃用期至少为 12 个月。这项治理变更为实施者提供了比非正式弃用措辞更可预测的通知。

该协议给出了替代方案。应用程序可以通过工具参数或资源标识符传递目录，而不是使用 Roots。服务器可以直接调用模型提供商 API，而非依赖 Sampling。实现可以使用 OpenTelemetry 或标准错误流，而非协议 Logging。

这些替代方案改变的是架构，而不只是语法。此前通过 MCP 客户端请求模型采样的服务器，可能需要直接集成提供商、使用独立凭据，并制定新的成本控制政策。

因此，压力也延伸至安全和财务团队。将模型访问权限从客户端能力迁移到服务器，会改变凭据的存放位置和使用情况的呈现位置。

网关所有者应将客户端分为三组。第一组完全支持 2026 修订版。第二组仅适用于先前的稳定版本。第三组行为尚不明确，在测试完成前需要隔离。

测试不应只覆盖 tools/list。一套实用的测试矩阵应包括发现、已认证的工具调用、被拒绝的范围、响应流、中断请求、列表缓存，以及需要额外用户输入的应用程序。

团队还应在遥测中验证协商出的版本。没有这一信号，一次成功请求可能会掩盖意外降级到早期协议版本的情况。

当新路径承载了具有代表性的生产工作负载时，迁移才算成功。仅仅因为网关接受了更新后的 supportedVersions 字段，并不代表迁移成功。

随着扩展脱离核心，授权规则变得更严格

MCP 2026-07-28 在减少凭据歧义的同时，将可选能力转入受治理、可协商的扩展系统。

修订后的授权规则聚焦于这样一种身份边界：当代理连接到多个服务器时，这些边界会带来风险。一个 MCP 客户端可能从多个授权服务器获取凭据，每个服务器保护着不同的工具和数据。

该规范现规定，客户端必须将已存储的凭据绑定到创建它们的颁发者。客户端不得将凭据复用于另一授权服务器，并且在颁发者发生变化时必须重新注册。

该规则旨在解决凭据混淆问题。相似的服务器名称、重定向或变化的元数据，不应导致某项服务的客户端凭据被传递到另一授权边界。

授权服务器还应在其授权响应中包含 iss 值。当该字段存在时，客户端必须在交换授权代码前，依据之前记录的颁发者对其进行验证。

这项验证遵循 RFC 9207——一项旨在防止授权服务器混淆攻击的互联网工程任务组标准。当一个客户端与多个颁发者交互，或动态发现授权元数据时，这项检查尤为重要。

动态客户端注册也获得了更严格的指导。MCP 客户端必须指定恰当的应用程序类型，以减少原生应用和 Web 应用在重定向 URI 规则上的冲突。

这些要求并不会自动让每一次部署变得安全。SDK 选项仍需要正确配置，已存储的凭据记录需要正确的键控方式，身份提供商也必须返回一致的颁发者信息。

AgentCore Gateway 提供了一个有用的执行点，因为它可以对入站调用方进行身份验证，并单独管理出站凭据。AWS 文档称，该服务支持自定义 JSON Web Token 授权、AWS Identity and Access Management，以及其他已配置的授权模式。

这种分离至关重要。被允许调用网关的身份，不应自动获得针对其背后每个目标的不受限制凭据。

AgentCore 还可以将策略引擎关联到网关。该引擎会评估代理的工具调用，并根据已配置的策略决定允许或拒绝每项操作。

网关模型并不能消除最小权限原则的必要性。即使凭据存储在托管身份服务中，范围过宽的目标凭据依然是范围过宽的。

团队应像测试成功调用一样仔细测试负面场景。权限范围不足的客户端应收到受控的授权响应，而不是无关的协议错误，或意外访问到相邻工具。

扩展系统带来了并行的治理变革。可选功能现在可以在核心协议之外演进，同时使用标准化标识符、能力声明和协商机制。

根据扩展框架，官方标识符使用 io.modelcontextprotocol 前缀。第三方应使用自己拥有的反向域名，从而减少无关功能之间的冲突。

客户端会在其每请求能力中声明支持的扩展。服务器则通过 server/discover 声明自身支持的扩展。双方都必须明确选择启用，扩展默认保持禁用状态。

官方扩展包括异步 Tasks、交互式 MCP Apps、OAuth 客户端凭据以及企业托管授权。核心协议不再需要在实施者使用每项专用功能之前，先将其吸收到核心中。

这种结构可以限制核心复杂性。但它也会形成一个支持矩阵，平台团队必须跨客户端、服务器、网关和 SDK 版本进行跟踪。

支持交互式界面扩展的客户端，在服务器能够优雅降级时，仍应处理有意义的文本响应。要求特定授权扩展的服务器，则可以拒绝不兼容的客户端。

AgentCore Gateway 的首要义务是正确实现核心协议行为。对 2026 修订版的支持不应被解读为对当前或未来所有扩展的普遍支持。

这是 AWS 公告中的一个关键不确定性。该网关可以携带扩展能力信息，但客户需要针对其工作流所依赖的任何扩展，获得明确的文档和测试支持。

授权变更和扩展框架遵循同一原则：无论是凭据颁发者、客户端能力还是可选行为，隐藏的假设正在变得明确。

这种明确性有利于企业控制。但它也意味着，不完整的配置将比在宽松集成模式下更明显地失败。

Amazon AWS 客户仍需证明什么

接下来需要关注的三个信号是：协商版本遥测、授权失败质量，以及真实工作负载下的扩展支持。

第一个信号是生产客户端是否确实协商使用 MCP 2026-07-28。仅凭网关配置无法回答这个问题。

团队应在分阶段发布后监控请求元数据和协议相关错误，并按客户端名称、客户端版本、框架和部署渠道比较结果。

不受支持版本和请求头不匹配错误的发生率下降，将加强 AWS 的托管迁移论证。持续存在的错误则表明，瓶颈仍是客户端 SDK 的采用，而不是网关的可用性。

降级同样值得重视。静默回退到较早修订版的客户端，可以让工作流继续运行，却掩盖了尚未解决的迁移问题。

组织应为每个已测试客户端定义预期修订版。这样，告警就能区分经过批准的兼容性回退与非预期降级。

第二个信号是授权失败在多个身份提供商和目标之间的表现。团队需要测试颁发者变更、无效的 iss 值、过期令牌、权限范围不足，以及尝试复用凭据等情形。

最安全的结果是在目标执行前作出明确拒绝。日志应识别所涉及的策略或授权边界，同时不向调用方暴露机密。

干净的负面测试结果将支持 AgentCore 减少自定义安全工作量的说法。令人困惑的失败或不一致的颁发者处理会削弱这一说法，尤其是在网关覆盖多个业务单元时。

第三个信号是扩展互操作性。使用 Tasks、MCP Apps 或授权扩展的工作流，应在调用扩展特定行为前验证能力。

测试必须包括优雅降级。当服务器承诺提供回退方案时，不具备 UI 支持的客户端仍应收到有用的核心内容。

反向情形也同样重要。如果某项扩展是安全运行的必要条件，服务器应明确拒绝请求，而不是尝试执行不完整的工作流。

在这三项优先事项之下，还有更广泛的运营信号。团队应监控被中断的带副作用调用是否产生重复操作，因为新修订版移除了流可恢复性。

他们还应检查缓存。列表和资源结果现在包含 ttlMs（以毫秒计的时效提示）以及 cacheScope，后者用于区分公共与私有的可缓存性。

确定性的工具排序可以改善客户端和模型提示词缓存。然而，过期的工具描述可能导致代理调用过时的模式，因此在目标更新期间需要测试缓存行为。

可观测性应包括分布式追踪上下文。该规范记录了 traceparent、tracestate 和 baggage 的 _meta 约定，帮助团队跨客户端、网关和目标跟踪工作。

这种追踪在重试期间尤其有用。运营人员需要将最初失败的流与新发出的请求关联起来，而不应将它们视为同一个 JSON-RPC 请求 ID。

当这些问题汇聚时，托管网关的最大价值便会显现。一个端点可以对调用方进行身份验证、应用策略、转换协议流量、选择工具、注入目标凭据，并生成审计证据。

其主要风险也同样显现在这里。网关成为一个高杠杆控制点，因此一次配置错误可能同时影响许多代理和服务。

谨慎的发布应从非关键网关或有限的客户端群组开始。团队可以添加新的支持版本，等待就绪状态，并运行针对特定版本的测试套件。

下一阶段应引入使用显式句柄的代表性有状态工作流，其中应包含一次中断请求和一次安全重试的副作用操作。

随后应进行授权测试，同时覆盖成功和被拒绝的调用。依赖扩展的工作流应最后进入测试，在核心协议行为稳定之后再进行。

回滚规划仍然必要。将先前的稳定修订版保留在支持版本列表中，可在团队调查缺陷期间为兼容客户端提供回退选项。

不过，回退不应演变为永久性的模糊状态。组织需要设定日期，审查剩余的旧客户端，并为仍在使用的已弃用功能制定计划。

开发者应关注这一点，因为该修订版改变了他们存放状态的方式以及重试方式。平台团队应关注这一点，因为兼容性在网关边界变得可观测。

企业采购方应关注这一点，因为托管协议支持可以减少重复的基础设施投入。但他们仍应询问：哪些扩展、SDK、区域、身份配置和目标类型已经完成生产验证。

知识工作者将间接受益。其助手或许能够连接更多工具，并减少连接失败，但前提是这些工具之间的身份与授权仍然清晰明确。

Amazon AWS 将首次迁移动作设得异常轻量。更重要的问题是，团队能否让每个请求都自包含，同时不牺牲安全性、兼容性或可观测性。

未来一到三个月，应关注协商版本数据、授权拒绝的质量，以及主要 SDK 对扩展的符合性。这些信号将显示，无状态 MCP 是否已成为生产标准，还是仍只是一个等待客户端跟进的网关功能。

对于已经在运行 AgentCore Gateway 的团队而言，下一步的实际行动是进行一次受控的兼容性审计。更新一个网关，测试所有受支持的客户端，记录协商出的版本，并在扩大访问范围前强制触发失败场景。

这些证据比一次 API 调用表面上的简洁更重要。Amazon AWS 现已提供通往 MCP 2026-07-28 的桥梁，但每个组织都必须证明，其智能体能够安全地跨越它。