扩展 Amazon Bedrock AgentCore Gateway 对 MCP 的支持

标题：扩展对 Amazon Bedrock AgentCore Gateway 的 MCP 支持 | 亚马逊云科技

来源网址：https://aws.amazon.com/blogs/machine-learning/extending-mcp-support-for-amazon-bedrock-agentcore-gateway-2/

发布时间：2026-06-01T10:35:03-08:00

Markdown 内容： 在生产环境中部署 模型上下文协议（MCP） 服务器时，企业需要跨服务器实现细粒度访问控制、了解哪些团队使用了哪些工具的可观测性、防止数据泄露的安全保障，以及集中化的凭证管理，且所有这些功能都需具备可扩展性。Amazon Bedrock AgentCore Gateway 位于 MCP 服务器与消费它们的客户端之间，将凭证管理、可观测性和安全连接整合为一个可信的统一入口点。

今天，我们通过新增功能进一步扩展了 AgentCore Gateway，以强化对企业级 MCP 部署的支持。本文涵盖扩展的 MCP 工具模式 支持、将 MCP 提示 和 MCP 资源 作为一等原语、用于运行时发现 MCP 服务器的 动态列表、支持有状态实时交互的流式传输和会话管理、用于执行中输入请求的 引导机制，以及用于委托身份验证的 OAuth 2.0 代为令牌交换。如需动手实践示例，请访问 GitHub 示例仓库。

通过 AgentCore Gateway 统一企业级 MCP 服务器

若无集中式网关，组织内每个构建的 MCP 服务器都必须独立处理凭证、策略实施、私有连接和日志记录。这意味着法务团队的合同审查 MCP 服务器、财务团队的数据检索 MCP 服务器以及运维团队的事件响应 MCP 服务器各自承担相同的基础设施负担。安全团队需逐一审核每台服务器，开发人员等待审批，且无人能全面掌握整个组织内 MCP 基础设施的使用情况。

AgentCore Gateway 通过建立单一入口点来避免这种重复，所有 MCP 流量均经由该入口点流动。下图展示了 AgentCore Gateway 的主要特性，支持集中治理与管控。

各团队只需为其 MCP 服务器构建业务逻辑，其余均由 AgentCore Gateway 处理。它聚合了多种目标类型的能力，包括 MCP 服务器、REST API、AWS Lambda 函数及其他 更多类型。基于资源的策略 (RBP) 控制谁可以调用 AgentCore Gateway，例如限制仅允许从 Amazon Virtual Private Cloud (Amazon VPC) 内部调用。服务控制策略 (SCP) 则规范 AgentCore Gateway 在您的 AWS 组织内的维护方式。

为实现网络隔离，AgentCore Gateway 支持 AWS PrivateLink，用于控制平面和数据平面操作，确保流量保留在您的 Amazon VPC 边界内。您还可以通过 托管 VPC 资源模式 连接到私有 API 端点或 MCP 服务器。集中化的 应用 和 身份 日志有助于您满足审计与合规要求。

借助 拦截器 功能，AWS Lambda 函数可自定义请求与响应，从而实现细粒度访问控制、数据清理、自定义授权逻辑等更多功能（详见）。与 AgentCore 策略（预览版） 集成后，可在集中式平面上围绕您的工具定义代理防护机制，以实现确定性的策略执行。AgentCore 网关还支持 OAuth 2.0 授权码流程，使代理在调用工具前代表用户完成身份验证。

接下来，您将了解我们为 AgentCore 网关新增的功能，这些功能将进一步强化企业级 MCP 支持。

通过单一网关暴露您的 MCP 服务器原语

AgentCore 网关将成为一个聚合组织内所有 MCP 服务器能力的单一 MCP 端点。客户端只需面对一个统一的工具目录、一个提示词库和一个资源命名空间，而无需管理多达 20 个独立连接。在底层，AgentCore 网关支持全部三种 MCP 原语：工具、提示词和资源。MCP 中的工具定义包含可选的 outputSchema（用于定义预期输出结构）和 annotations（描述行为属性，如工具是否只读或具有破坏性），以及标准字段 name、icons、description 和 inputSchema。网关还通过完整的 MCP 方法支持提示词、资源及资源模板：tools/list、tools/call、prompts/list、prompts/get、resources/list、resources/read 和 resources/templates/list。下图架构示意图展示了 AgentCore 网关如何协调列表与调用操作。

在默认列表模式下，AgentCore 网关会发现并缓存来自已连接 MCP 服务器目标的工具、提示词和资源。每当您调用 CreateGatewayTarget 或 UpdateGatewayTarget 时，该缓存会隐式刷新；也可通过 SynchronizeGatewayTargets API 显式刷新。当客户端发起 tools/list、prompts/list 或 resources/list 等列表请求时，AgentCore 网关直接从缓存返回响应，无需调用后端 MCP 服务器目标。实际与 MCP 服务器目标的交互仅发生在调用操作阶段：tools/call、prompts/get 和 resources/read。此时，AgentCore 网关会将请求路由至正确的后端目标。

AgentCore 网关返回的工具和提示词名称均以目标名称为前缀，格式为 targetName___。与工具和提示词不同，资源 URI 不带目标名称前缀，而是直接透传下游 MCP 服务器提供的原始 URI。当创建暴露资源的 MCP 服务器目标时，您可以选择性指定 resourcePriority 值（1–1000），用于控制当多个目标暴露相同资源 URI 时，AgentCore 网关如何解决冲突。若未指定优先级，则默认值为 1000。发生冲突时，AgentCore 网关将返回 resourcePriority 值最低的目标所对应的资源。若两个冲突资源优先级相同，则返回最先同步的目标所提供的资源。

由于资源 URI 由下游 MCP 服务器目标提供，且未经过 AgentCore 网关的验证或清理，请谨慎对待不可信目标。恶意或被攻陷的 MCP 服务器可能返回指向内部端点或本地文件系统路径的 URI。在使用这些 URI 前，请务必进行验证与清理，切勿自动获取或渲染来自不可信 MCP 服务器目标的 URI。

动态列表以支持运行时灵活性

部分 MCP 服务器会根据用户个性化其能力。例如，具备权限感知的服务器可能仅向经理暴露 approve_expense 工具，或多租户服务器可能仅向医疗客户展示符合 HIPAA 标准的工具。动态列表功能让您在仍通过 AgentCore 网关路由的同时，保留此类服务器端访问控制。

创建目标时，您可选择两种列表模式之一：_默认_ 模式和 _动态_ 模式。在默认列表模式下，AgentCore 网关会在 CreateGatewayTarget 或 UpdateGatewayTarget 操作期间调用 MCP 服务器，以发现并缓存工具、提示词和资源。此缓存可通过 SynchronizeGatewayTargets API 显式刷新。当客户端发起列表请求时，AgentCore 网关直接从缓存返回响应，无需联系后端服务器。在动态列表模式下，AgentCore 网关不会在 CreateGatewayTarget 或 UpdateGatewayTarget 操作期间调用 MCP 服务器，而是在请求时实时将列表请求转发至 MCP 服务器，并使用调用用户的标识。在两种模式下，调用操作（如 tools/call、prompts/get 和 resources/read）均直接路由至 MCP 服务器目标。下图架构示意图说明了两种模式如何协同工作。

MCP Server 1 配置为动态列表模式，而 MCP Server 2 和 3 使用默认列表模式。AgentCore 网关缓存仅包含来自默认模式服务器的能力信息。在列表调用期间，响应是分页的；缓存内容和 MCP Server 1 的能力原语会分别返回在不同页面上。由于动态列表目标的能力未在 AgentCore 网关中建立索引，因此无法使用语义工具搜索功能。

这种双模式架构还为您提供了多租户和细粒度访问控制（FGAC）的灵活性。对于两种列表模式，您都可以通过 AgentCore 策略或 AWS Lambda 响应拦截器集中强制执行策略，根据租户身份过滤能力。例如，您可以限制某个租户只能看到只读工具。对于动态列表模式，您可以在 MCP 服务器本身直接管理访问控制，因为列表操作是在最终用户的身份下执行的，且 MCP 服务器目标仅返回该用户被授权访问的能力。

流式传输、会话管理和引导

许多企业级 MCP 工作流超越了简单的请求-响应式工具调用。MCP 服务器可能需要在生成报告时流式传输进度更新，在执行敏感操作前暂停并征求用户批准，或在跨越多个工具调用的多步骤对话中保持上下文。AgentCore 网关支持可流式传输的 HTTP 协议、MCP 会话管理和引导功能，从而实现有状态、实时、人机协作的交互。

可流式传输的 HTTP

若无流式传输，一个耗时 45 秒的工具调用需等待完成才返回结果，用户只能盯着加载动画。启用流式传输后，用户可实时看到进度事件。当客户端发送带有 Accept: application/json, text/event-stream 的 tools/call 请求时，AgentCore 网关将打开 SSE 流，并实时转发来自 MCP 服务器目标的事件，包括进度通知、日志消息及最终工具结果。仅发送 Accept: application/json 的客户端仍接收单一 JSON 响应，确保完全向后兼容。

当在 AgentCore 网关上启用响应流式传输时，响应拦截器的行为会发生变化，必须检查 gatewayResponse 中的 isStreamingResponse 字段以区分流式与非流式响应。响应拦截器仅对包含 JSON-RPC id 字段的事件触发。对于 notifications/progress、notifications/message 和 pings 事件，不会触发响应拦截器。要启用流式传输，请在 CreateGateway 或 UpdateGateway API 调用期间设置 enableResponseStreaming 块。

"protocolConfiguration": {
  "mcp": {
    "streamingConfiguration": {
      "enableResponseStreaming": true
    }
  }
}

JSON

在考虑 AgentCore 网关的流式传输使用场景时，请注意以下几点：AgentCore 网关从流中的第一个事件确定 HTTP 状态码。如果流传输中途发生错误，它将以 JSON-RPC 错误对象的形式通过 SSE 帧传递，而非作为 HTTP 状态码，因为状态码已提前发送。预流式错误（如认证失败、限流或验证错误）将以标准 JSON-RPC 错误响应形式返回，不带 SSE 封装。

会话管理

会话管理为 AgentCore 网关引入了有状态的多轮次工作流。启用会话后，AgentCore 网关会在首次初始化请求时生成 Mcp-Session-Id，并将其作为响应头返回。客户端在后续请求中需包含此头信息，以便 AgentCore 网关跟踪客户端交互、维护与下游 MCP 服务器会话的映射关系，并关联跨工具调用的引导请求。

要启用会话，请在 CreateGateway 或 UpdateGateway API 调用期间添加 sessionConfiguration 块。您可以配置会话超时时间，范围从最少 15 分钟到最多 8 小时，默认为 1 小时。

"protocolConfiguration": {
  "mcp": {
    "sessionConfiguration": {
      "sessionTimeoutInSeconds": 3600
    }
  }
}

JSON

会话作用域限定于经过身份验证的用户。AgentCore 网关从授权上下文（OAuth 入口的 JWT 持有者令牌或 AWS_IAM 入口的 IAM 凭证）推导用户身份，并验证会话内每个请求均源自同一用户，从而防止会话劫持——即一个客户端试图使用另一个客户端的会话标识符。若启用了会话的网关接收到不含 Mcp-Session-Id 头的请求，AgentCore 网关将返回 HTTP 400；对于过期或不存在的会话，则返回 HTTP 404。

在幕后，AgentCore 网关会将会话 ID 持久化存储在一个完全托管的持久化存储中，以管理跨请求的会话。当 AgentCore 网关在某个会话内首次接收到针对特定 MCP 服务器目标的工具调用时，它会初始化与该目标的连接，代表客户端协商能力，并存储目标会话标识符。在同一会话内后续对该目标的工具调用将复用此映射关系，避免重复初始化开销。由于这一行为，AgentCore 运行时无需在每次请求时冷启动新的微虚拟机，从而实现更快的响应速度。

在考虑 AgentCore 网关的会话功能时，请注意以下几点：启用会话是触发“引导”（elicitation）的前提条件。如果您当前正在使用头部传播方式将 Mcp-Session-Id 转发至目标服务器，则不能同时启用会话管理，因为网关需要自主掌控会话生命周期。如果下游 MCP 服务器会话在网关会话超时前已过期，网关将透明地重新初始化目标并继续为客户端提供服务。

引导（Elicitation）

引导功能使位于 AgentCore 网关后的 MCP 服务器能够在执行过程中暂停，并向最终用户请求输入。这对于高风险操作尤其有价值——服务器在继续执行前需获得用户的明确确认、结构化数据收集或带外身份验证。

AgentCore 网关支持以下引导模式：

• 表单模式：MCP 服务器发送一个扁平化的 JSON Schema，描述其所需字段，客户端据此渲染表单供用户填写。
• URL 模式：服务器发送一个 URL，客户端打开该链接供用户访问，通常用于 OAuth 授权页面或外部审批流程。
• URL 异常模式：服务器返回包含 URL 的 URLElicitationRequiredError，提示客户端重定向用户，在用户完成外部流程后重试工具调用。

以下是表单模式引导在 AgentCore 网关中的工作流程：步骤 1–6 涵盖会话初始化和工具发现。之后，客户端发送带有 Mcp-Session-Id 头部的 tools/call 请求。AgentCore 网关将工具调用转发至 MCP 服务器目标。目标服务器开启 SSE 流并发送 elicitation/create 请求。AgentCore 网关通过 SSE 流将 elicitation/create 请求转发给客户端。客户端向用户展示表单并收集响应。随后，客户端使用相同的 Mcp-Session-Id 发送引导响应（接受或拒绝）。AgentCore 网关将响应转发至 MCP 服务器目标，后者返回 HTTP 202 Accepted 确认。目标服务器继续使用新信息处理请求。

引导功能要求网关同时启用流式传输和会话功能。AgentCore 网关尊重能力协商机制：仅当连接的客户端在初始化阶段声明支持引导时，网关才会向下游 MCP 服务器声明支持该功能。这意味着，若客户端不支持引导，MCP 服务器不会尝试发送引导请求，从而避免意外行为。AgentCore 网关还支持每个会话内存在多个活跃的引导请求，因此客户端可同时发起多个工具调用，每个调用均可拥有独立待处理的引导请求。

在考虑 AgentCore 网关的引导功能时，请注意以下几点：引导超时由 AgentCore 网关的连接超时控制。若用户响应表单或完成 URL 流程的时间超过连接超时，请求将超时。请根据涉及人工交互的工作流合理设置连接超时时间。若在引导过程中客户端与 AgentCore 网关之间的连接中断，网关不支持恢复该特定工具调用，客户端应重试原始的 tools/call 请求。网关仅支持对 MCP 服务器目标进行引导透传；对于 REST API 或 AWS Lambda 函数等非 MCP 目标类型，引导功能不适用，因为这些目标不会主动发起引导请求。

OAuth 2.0 代用户令牌交换

当您的代理需要代表已认证用户访问下游资源时，AgentCore 网关通过 AgentCore Identity 支持 OAuth 2.0 代用户（OBO）令牌交换。这实现了零信任认证模型：原始用户的身份在整个请求链路中得以保留并逐跳传递，而每一层均获得精确作用域限定于其预期受众的令牌。

MCP 客户端通过 /mcp 可流式传输的 HTTP 连接，使用作用域为网关受众（aud: gw）的 JWT A 向 AgentCore 网关进行身份验证。当 AgentCore 网关需要调用下游 MCP 服务器目标时，它会调用 AgentCore 身份服务，将 JWT A 交换为作用域为 MCP 服务器受众（aud: mcp）的 JWT B。如果 MCP 服务器随后需要调用更下游的 API，它可以使用 GetResourceOAuth2Token 获取作用域为下游 API 受众（aud: api）的 JWT C。在每一跳中，原始用户身份（sub: X）都会被传递下去，因此下游服务可以在无需触发额外同意流程的情况下实施细粒度的、基于用户的授权。本流程中使用的声明仅用于示例目的，应仅用于理解此图。

AgentCore 身份服务在此整个流程中充当中央令牌代理。它提供一个安全的令牌保险库，用于存储 OAuth 凭据和客户端密钥，从而使 AgentCore 网关和 MCP 服务器无需直接管理凭据，并支持使用 AWS 工作负载身份而非长期有效的密钥进行服务间认证。它根据身份提供商支持标准令牌交换（RFC 8693）或 JWT 授权许可（RFC 7523）。

结论

借助本次发布，您可以通过单一托管端点构建具有实时进度流、可暂停与恢复执行的人工审批关卡以及零信任身份传播功能的状态化多轮代理工作流。无需自定义会话存储、无需手动搭建流式基础设施、无需共享服务账户凭据。您的 MCP 服务器可专注于业务逻辑，而 AgentCore 网关负责其余部分：发现、流式传输、状态、身份和策略，集中管理且可逐步采用。

要开始使用，请查阅 Amazon Bedrock AgentCore 网关文档，了解本文涵盖各项功能的配置详情。如需动手实践示例，请访问 GitHub 示例仓库。如果您已在 AgentCore 网关后运行 MCP 服务器，则可在不更改现有 AgentCore 网关或目标配置的前提下逐步采用这些功能。

• * *

关于作者