中文内容
在生产环境中部署 Model Context Protocol (MCP) 服务器时，企业需要跨服务器的细粒度访问控制、对哪些团队使用哪些工具的可观测性、防止数据外泄的安全保障，以及集中式凭证管理，并且所有这些都要能够规模化实现。Amazon Bedrock AgentCore Gateway 位于 MCP 服务器与使用这些服务器的客户端之间，将凭证管理、可观测性和安全连接集中到一个受信任的统一入口点。
今天，我们为 AgentCore Gateway 扩展了新功能，进一步增强对企业 MCP 部署的支持。本文介绍扩展的 MCP 工具架构支持、作为一等原语的 MCP prompts 和 MCP resources、用于运行时发现 MCP 服务器的动态列表、用于有状态实时交互的流式处理和会话管理、用于执行过程中输入请求的 elicitation，以及用于委托身份验证的 OAuth 2.0 on-behalf-of 令牌交换。如需查看动手示例，请访问 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 Policy（预览版）的集成可提供围绕您的工具定义的代理式防护栏，用于在集中式平面上执行确定性策略。AgentCore Gateway 还有助于促进 OAuth 2.0 授权码流程，在该流程中，代理会在调用工具之前代表用户进行身份验证。
现在，您将了解我们正在为 AgentCore Gateway 添加的新功能，以进一步加强企业 MCP 支持。
通过单一网关公开您的 MCP 服务器原语
AgentCore Gateway 成为一个单一的 MCP 端点，聚合组织中每个 MCP 服务器的能力。客户端看到的是一个统一的工具目录、一个提示库和一个资源命名空间，而不是需要管理的 20 个独立连接。在底层，AgentCore Gateway 支持全部三种 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 Gate
在默认列表模式下，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 Server 1 配置为动态列表模式，而 MCP Server 2 和 3 使用默认列表模式。AgentCore Gateway 缓存仅包含来自默认模式服务器的能力。在列表调用期间，响应会分页；缓存的 primitives 和 MCP Server 1 的 primitives 会在不同页面返回。由于在 AgentCore Gateway 中，动态列表目标的 primitives 未被索引，因此无法使用语义工具搜索能力。
这种双模式架构还为多租户和细粒度访问控制（FGAC）提供了灵活性。对于两种列表模式，你都可以使用 AgentCore Policy 或 AWS Lambda 响应拦截器集中强制执行策略，以根据租户身份筛选能力。例如，你可以限制某个租户只能看到只读工具。对于动态列表模式，你可以直接在 MCP 服务器本身管理访问控制，因为列表操作是在最终用户身份下执行的，并且 MCP 服务器目标只返回该用户有权访问的能力。
流式处理、会话管理和 elicitation
许多企业 MCP 工作流并不只是简单的请求-响应式工具调用。MCP 服务器可能需要在生成报告时流式传输进度更新，在执行敏感操作前于执行过程中暂停以请求用户批准，或者在跨越多次工具调用的多步骤对话中维护上下文。AgentCore Gateway 支持 Streamable HTTP 传输、MCP 会话管理和 elicitation，从而实现有状态、实时、人在回路中的交互。
正文：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 服务器会话的映射，并在工具调用之间关联 elicitation 请求。
要启用会话，请在 CreateGateway 或 UpdateGateway API 调用期间添加 sessionConfiguration 块。您可以将会话超时时间配置为最短 15 分钟、最长 8 小时。默认值为 1 小时。
"protocolConfiguration": {
"mcp": {
"sessionConfiguration": {
"sessionTimeoutInSeconds": 3600
}
}
}会话的作用域限定为经过身份验证的用户。AgentCore Gateway 会从授权上下文中推导用户身份，即 OAuth 入口的 JWT bearer token 或 AWS_IAM 入口的 IAM 凭证，并验证会话内的每个请求都来自同一用户。这有助于防止会话劫持，即一个客户端尝试使用另一个客户端的会话标识符。如果启用会话的网关收到不带 Mcp-Session-Id 标头的请求，AgentCore Gateway 会返回 HTTP 400；对于已过期或不存在的会话，则返回 HTTP 404。
在幕后，AgentCore Gateway 会将会话 ID 持久化到一个完全托管的持久存储中，以跨请求管理会话。当 AgentCore Gateway 在一个会话内收到针对某个给定 MCP 服务器目标的首次工具调用时，它会初始化与该目标的连接，代表客户端协商能力，并存储目标会话标识符。该会话内随后对同一目标的工具调用会复用这一映射，从而避免重复初始化带来的开销。由于这种行为，AgentCore Runtime 不需要在每个请求上冷启动新的 micro-VM，从而实现更快的响应时间。
在考虑 AgentCore Gateway 的会话时，请牢记以下几点。启用会话是 elicitation 的前提条件。如果你目前正在使用标头传播将 Mcp-Session-Id 转发到目标，则不能同时启用会话管理，因为网关需要拥有会话生命周期。如果下游 MCP 服务器会话在网关会话超时之前过期，网关会透明地重新初始化目标，并继续为客户端提供服务。
正文：Elicitation
引导式信息获取使 AgentCore Gateway 后方的 MCP 服务器能够暂停执行，并向最终用户请求输入。这对于高风险操作尤其有价值，在这些操作中，服务器需要在继续之前获得用户的明确确认、进行结构化数据收集，或完成带外身份验证。
AgentCore Gateway 支持以下引导式信息获取模式。在表单模式下，MCP 服务器会发送一个扁平的 JSON Schema，用于描述其所需的字段，客户端则为用户渲染一个表单供其填写。在 URL 模式下，服务器会发送一个 URL，由客户端为用户打开，通常是 OAuth 同意页面或外部审批工作流。在 URL 异常模式下，服务器会返回包含 URL 的 URLElicitationRequiredError，提示客户端将用户重定向，并在用户完成外部流程后重试工具调用。
以下是表单模式引出在 AgentCore Gateway 中的工作方式。步骤 1–6 涵盖会话初始化和工具发现。之后，客户端发送一个带有 Mcp-Session-Id 标头的 tools/call 请求。AgentCore Gateway 将该工具调用转发给 MCP 服务器目标。目标打开一个 SSE 流并发送 elicitation/create 请求。AgentCore Gateway 通过 SSE 流将 elicitation/create 请求转发给客户端。客户端向用户展示表单并收集响应。随后，客户端使用相同的 Mcp-Session-Id 发送引出响应（action: accept 或 decline）。AgentCore Gateway 将响应转发给 MCP 服务器目标，后者确认 HTTP 202 Accepted。目标继续使用新信息处理该请求。
引出要求在您的网关上同时启用流式传输和会话。AgentCore Gateway 遵循能力协商；只有当连接的客户端在初始化期间声明支持引出时，它才会向下游 MCP 服务器声明支持引出。这意味着，如果客户端不支持引出，MCP 服务器就不会尝试发送引出请求，从而避免意外行为。AgentCore Gateway 还支持每个会话有多个活动引出，因此客户端可以有并发的工具调用，每个调用都有各自待处理的引出。
在考虑为你的 AgentCore Gateway 使用引导式信息获取时，请牢记以下几点。引导式信息获取的超时时间由 AgentCore Gateway 连接超时时间控制。如果用户响应表单或完成 URL 流程所用时间超过连接超时时间，请求就会超时。对于涉及人工交互的工作流，请相应地规划连接超时时间。如果客户端与 AgentCore Gateway 之间的连接在引导式信息获取期间中断，AgentCore Gateway 不支持恢复该特定工具调用。客户端应重试原始的 tools/call 请求。网关仅支持 MCP 服务器目标的引导式信息获取透传。对于 REST API 或 AWS Lambda 函数等非 MCP 目标类型，引导式信息获取不适用，因为这些目标不会发起引导式信息获取请求。
OAuth 2.0 代表用户的令牌交换
当你的代理需要代表已认证用户访问下游资源时，AgentCore Gateway 通过 AgentCore Identity 支持 OAuth 2.0 代表用户（OBO）令牌交换。这实现了一种零信任认证模型，在该模型中，原始用户的身份会被保留并在请求链的每一跳中传播，同时每一层都会收到一个作用域精确限定为其预期受众的令牌。
MCP 客户端通过 /mcp 可流式传输的 HTTP 连接，使用 JWT A 向 AgentCore Gateway 进行身份验证，该 JWT A 的作用域限定为网关受众（aud: gw）。当 AgentCore Gateway 需要调用下游 MCP 服务器目标时，它会调用 AgentCore Identity，将 JWT A 交换为 JWT B，此时其作用域限定为 MCP 服务器受众（aud: mcp）。如果 MCP 服务器进而需要调用更下游的 API，它可以使用 GetResourceOAuth2Token 获取作用域限定为下游 API 受众（aud: api）的 JWT C。在每一跳中，原始用户身份（sub: X）都会被向前传递，因此下游服务可以执行精细的、按用户授权，而不会触发额外的同意流程。此流程中使用的声明仅用于示例目的，只应用于理解此图。
AgentCore Identity 充当整个流程的中央令牌代理。它提供安全的令牌保险库，用于存储 OAuth 凭据和客户端密钥，使 AgentCore Gateway 和 MCP 服务器都无需直接管理凭据；并提供工作负载身份，使用 AWS 工作负载身份而非长期有效的密钥来进行服务到服务身份验证。它支持标准令牌交换（RFC 8693）或 JWT 授权授予（RFC 7523），具体取决于身份提供商。
结论
通过此版本，你可以通过单个托管端点构建有状态的多轮智能体工作流，支持实时进度流式传输、可暂停并恢复执行的人类审批关卡，以及零信任身份传播。无需自定义会话存储，无需手工搭建流式传输基础设施，也无需共享服务账户凭证。你的 MCP 服务器可以专注于业务逻辑。AgentCore Gateway 负责其余部分：发现、流式传输、状态、身份和策略，并实现集中治理和渐进式采用。
要开始使用，请查看 Amazon Bedrock AgentCore Gateway 文档，了解本文所涵盖各项功能的配置详情。如需实践示例，请访问 GitHub 示例代码库。如果你已经在 AgentCore Gateway 后运行 MCP 服务器，则可以在不更改现有 AgentCore Gateway 或目标配置的情况下逐步采用这些功能。
关于作者
