扩展 Amazon Bedrock AgentCore Gateway 对 MCP 的支持

在企业中部署模型上下文协议（MCP）服务器时，需要跨服务器的细粒度访问控制、团队使用工具的可见性、防止数据泄露的安全保障以及集中式凭证管理，所有这些都需要大规模实现。Amazon Bedrock AgentCore Gateway 位于 MCP 服务器和消费它们的客户端之间，将凭证管理、可观测性和安全连接集中到一个可信入口点。

今天，我们为 AgentCore Gateway 增加了新功能，进一步强化了对企业 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 VPC。服务控制策略（SCP）管理如何在 AWS 组织中维护 AgentCore Gateway。

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

借助拦截器功能，AWS Lambda 函数可以自定义请求和响应，实现细粒度访问控制、数据清洗、自定义授权逻辑等。与 AgentCore Policy（预览版）的集成提供了以工具为中心的智能体护栏，在集中平面上实现确定性策略执行。AgentCore Gateway 还有助于促进 OAuth 2.0 授权码流程，其中智能体在调用工具之前代表用户进行身份验证。

现在，我们将介绍 AgentCore Gateway 新增的功能，进一步加强企业 MCP 支持。

通过单一网关展示你的 MCP 服务器原语

AgentCore Gateway 成为一个单一的 MCP 端点，聚合组织中每个 MCP 服务器的能力。客户端看到一个统一的工具目录、一个提示库和一个资源命名空间，无需管理 20 个单独连接。在底层，AgentCore Gateway 支持所有三种 MCP 原语：工具、提示和资源。MCP 中的工具定义包括可选的 outputSchema 用于定义预期输出结构，以及描述行为属性（如工具是只读还是破坏性）的注释，此外还有标准名称、图标、描述和 inputSchema。该网关还通过其完整的 MCP 方法集支持提示、资源和资源模板：tools/list、tools/call、prompts/list、prompts/get、resources/list、resources/read 和 resources/templates/list。下图展示了 AgentCore Gateway 如何促进列表和调用操作。

在默认列表模式下，AgentCore Gateway 发现并缓存来自连接的 MCP 服务器目标的工具、提示和资源。此缓存在您调用 CreateGatewayTarget 或 UpdateGatewayTarget 时会隐式刷新，并可以使用 SynchronizeGatewayTargets API 显式刷新。当客户端进行列表调用（如 tools/list、prompts/list 或 resources/list）时，AgentCore Gateway 直接从该缓存返回响应，而不调用 MCP 服务器目标。与 MCP 服务器目标的实际交互仅发生在调用操作期间：tools/call、prompts/get 和 resources/read。此时，AgentCore Gateway 将请求路由到正确的目标。

AgentCore Gateway 返回的工具和提示会以目标名称前缀 targetName___ 的形式出现。与工具和提示不同，资源 URI 返回时不带目标名称前缀，直接传递来自下游 MCP 服务器的原始 URI。在创建公开资源的 MCP 服务器目标时，您可以选择指定 resourcePriority 值（1–1000），以控制当多个目标公开相同资源 URI 时 AgentCore Gateway 如何解决冲突。如果未定义优先级，则应用默认值 1000。当发生冲突时，AgentCore Gateway 返回 resourcePriority 值最低的目标中的资源。如果两个冲突资源具有相同优先级，则返回首先同步的目标中的资源。

由于资源 URI 由下游 MCP 服务器目标提供，且 AgentCore Gateway 不进行验证或清理，因此对不受信任的目标需谨慎。恶意或被攻破的 MCP 服务器可能返回指向内部端点或本地文件系统路径的 URI。在遵循资源 URI 之前，请验证并清理它们，不要自动从不受信任的 MCP 服务器目标获取或渲染 URI。

用于运行时灵活性的动态列表

某些 MCP 服务器会根据用户个性化其能力。权限感知服务器可能只向管理人员公开 approve_expense，或多租户服务器可能仅为医疗保健客户公开符合 HIPAA 的工具。动态列表允许您在仍通过 AgentCore Gateway 路由的同时保留服务器端访问控制。

创建目标时，您可以在两种列表模式之间选择：默认和动态。在默认列表模式下，AgentCore Gateway 在 CreateGatewayTarget 或 UpdateGatewayTarget 操作期间调用 MCP 服务器，以发现并缓存工具、提示和资源。此缓存可以使用 SynchronizeGatewayTargets API 显式刷新。当客户端进行列表调用时，AgentCore Gateway 直接从该缓存提供响应，而无需联系后端服务器。在动态列表模式下，AgentCore Gateway 在 CreateGatewayTarget 或 UpdateGatewayTarget 操作期间不调用 MCP 服务器。相反，列表调用会在请求时使用调用用户的身份实时转发到 MCP 服务器。在两种模式下，调用操作（如 tools/call、prompts/get 和 resources/read）都直接路由到 MCP 服务器目标。下图说明了两种模式如何协同工作。

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

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

流式传输、会话管理和请求获取

许多企业 MCP 工作流超越了简单的请求-响应工具调用。MCP 服务器可能需要在生成报告时流式传输进度更新，在执行敏感操作前暂停以请求用户批准，或者在跨越多个工具调用的多步骤对话中维护上下文。AgentCore Gateway 支持 Streamable HTTP 传输、MCP 会话管理和请求获取，从而支持有状态、实时、人在回路的交互。

Streamable HTTP

没有流式传输时，耗时 45 秒的工具调用直到完成才返回任何内容，用户只能盯着转圈图标。有了流式传输，他们可以实时看到进度事件。当客户端发送带有 Accept: application/json, text/event-stream 的 tools/call 请求时，AgentCore Gateway 打开一个 SSE 流，并实时转发来自 MCP 服务器目标的事件，包括进度通知、日志消息和最终工具结果。仅发送 Accept: application/json 的客户端继续接收单个 JSON 响应，保持完全向后兼容。

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

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

在考虑 AgentCore Gateway 的流式传输用例时，请记住以下几点。AgentCore Gateway 根据流中的第一个事件确定 HTTP 状态码。如果流中间发生错误，它将以 SSE 帧内的 JSON-RPC 错误对象形式传递，而不是 HTTP 状态码，因为状态码已经发送。流前的错误（如身份验证失败、限流或验证错误）将作为标准 JSON-RPC 错误响应返回，不带 SSE 帧。

会话管理

会话管理为 AgentCore Gateway 引入了有状态的多轮工作流。启用会话后，AgentCore Gateway 在第一个 initialize 请求时生成 Mcp-Session-Id，并将其作为响应头返回。客户端在后续请求中包含此头，使 AgentCore Gateway 能够跟踪客户端交互、维护与下游 MCP 服务器会话的映射，并在工具调用之间关联请求获取。

要启用会话，请在 CreateGateway 或 UpdateGateway API 调用中添加 sessionConfiguration 块。您可以将会话超时配置为最少 15 分钟到最长 8 小时。默认是 1 小时。

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

会话范围限定为经过身份验证的用户。AgentCore Gateway 从授权上下文、OAuth 入站的 JWT 承载令牌或 AWS_IAM 入站的 IAM 凭证派生用户身份，并验证会话中的每个请求是否来自同一用户。这有助于防止会话劫持。