用 AgentCore Gateway 和 MCP 构建多账户 AI 智能体

企业越来越希望 AI 智能体能够对分散在多个 AWS 账户中的数据进行推理，而无需复制或集中这些数据。每个团队都将数据保留在自己的账户中，这是有充分理由的：明确的所有权、范围隔离以及独立的部署生命周期。但是，只能看到一个账户数据的智能体所能提供的价值有限，而将其连接到分布式数据源通常意味着复制数据或理清跨账户的 AWS Identity and Access Management (IAM)。目标是让数据留在它原本所在的位置，即每个业务线 (LOB) 账户中。只有请求所需的特定数据会在查询时流出，因此底层数据集不会离开其所属账户。

在本文中，您将构建一个多账户架构，使每个团队的数据保留在自己的账户中，同时通过 Amazon Bedrock AgentCore Gateway 和 Model Context Protocol (MCP) 为智能体提供跨账户查询的统一方式。Amazon Bedrock AgentCore 是一项智能体服务，用于安全地大规模构建、部署和运营高效的智能体。中央平台账户托管智能体层，并通过 Amazon Bedrock 进行大语言模型 (LLM) 推理。LOB 团队将其数据和工具作为 MCP 服务器公开，平台账户的 AgentCore Gateway 为智能体提供单一端点，用于跨已注册的 LOB 进行工具发现和调用。在此过程中，您将设置跨账户 MCP 集成、使用 AgentCore Identity（Amazon Bedrock AgentCore 的一项能力）和 Okta 进行身份验证、使用 Policy in Amazon Bedrock AgentCore 进行细粒度授权，以及支持生产就绪的治理控制。

解决方案概述

该架构采用多账户模型，分为三层：中央平台账户、分布式 LOB 账户，以及作为连接它们的集成层的 AgentCore Gateway。

平台账户——智能体控制平面

平台团队拥有平台账户，该账户在 AgentCore Runtime（Amazon Bedrock AgentCore 的一项能力）上运行智能体。AgentCore Runtime 是一个无服务器、框架无关的环境，在专用微虚拟机中实现会话隔离，采用基于用量的定价，并内置身份验证。为保持演练清晰，本文使用单个智能体，但同一模式支持平台账户中的多个智能体。智能体连接到平台账户的 Gateway，而不是各个 LOB MCP 服务器。

LLM 推理通过 Amazon Bedrock 在平台账户中运行。平台团队控制可用的基础模型 (FM)，应用 Amazon Bedrock Guardrails，并通过单一计费边界跟踪成本，避免在数十个 LOB 账户中管理模型配额的额外开销。随着需求增长，一些组织会将推理分布到多个专用推理账户，并将 AgentCore Gateway 置于前端作为推理网关，在模型提供商之间路由流量，根据请求选择提供商并应用按团队限流。

平台账户中的 AgentCore Gateway 充当智能体的单一 MCP 端点。它将每个 LOB 账户的 MCP 服务器注册为目标，并从这一个端点提供统一的工具发现（含语义搜索）、通过 AgentCore Identity 的集中式身份验证、使用 Policy in AgentCore 的细粒度授权以及可观测性。

除了聚合 MCP 服务器和充当推理网关之外，AgentCore Gateway 还支持其他目标类型，使其成为中央集成点。HTTP 目标将 AgentCore Runtime 智能体、智能体到智能体 (A2A) 服务和其他 HTTP 端点纳入同一个受治理的端点，每个目标均可通过各自的子路径访问。平台团队还可以应用 Amazon Bedrock Guardrails 以确保内容安全，并配置 Policy in AgentCore (Cedar) 以实现细粒度访问控制，两者均在智能体代码之外的 Gateway 层强制执行。

LOB 账户——数据和工具

每个 LOB 团队不是直接公开原始 AWS 资源（Amazon Simple Storage Service (Amazon S3) 存储桶、数据库、Amazon Bedrock Knowledge Bases），而是将其数据和工具打包为 MCP 服务器。零售银行团队公开 get_balance 和 get_profile 等工具。贷款团队提供 get_credit_score 和 search_lending_policies，其中后者通过 Amazon Bedrock Knowledge Bases 中完全托管的检索增强生成 (RAG) 能力对银行政策 PDF 进行查询。此参考架构将独立的 Amazon Bedrock Knowledge Base 封装在 MCP 服务器内，以便对检索管道进行细粒度控制。对于新的实现，您也可以改为将 Amazon Bedrock Managed Knowledge Base 作为原生连接器直接附加到 Gateway，这样智能体便可通过标准 MCP 调用查询它，而您无需运营任何检索基础设施。

MCP 服务器运行在 LOB 账户中的 AgentCore Runtime 上，这是一个无服务器、与框架无关的环境，在专用 microVM 中实现会话隔离，采用按用量计费，通过 AgentCore Identity 提供内置身份验证，并具备针对智能体的可观测性。这让 LOB 团队对其工具面拥有完全所有权：他们决定要公开哪些工具以及每个工具背后运行什么业务逻辑，并且只要 MCP 工具接口保持一致，就可以更改实现而不影响平台智能体。

跨账户集成：Gateway 和 Identity 连接各层

此架构遵循中心辐射模式：每个 LOB 使用基于 Streamable HTTP 的 MCP 部署一个独立的 MCP 服务器（辐射点），而 AgentCore Gateway（中心）将它们聚合在单一端点之后。智能体将 Gateway 作为单个 MCP 服务器连接，Gateway 则在已注册的 LOB 目标之间联合工具调用。当智能体调用工具时，Gateway 从 AgentCore Identity 检索 OAuth 2.0 机器对机器（M2M）凭证，将其附加到出站请求，并路由到正确的 LOB MCP 服务器，后者在本地处理请求之前会针对 Okta 的 OpenID Connect（OIDC）端点验证令牌。

LOB 的数据保留在其自己的账户中：MCP 服务器仅返回工具产生的特定结果，而不是原始数据集，该结果作为推理上下文流向平台账户。源数据不会被复制或迁移。

图 1：使用 AgentCore Gateway 和 MCP 的多账户 AI 智能体架构

以下演练追踪用户的问题如何跨越账户边界、调用分布式工具并返回统一答案：

用户通过 React Web 应用登录，该应用重定向到 Okta 进行身份验证；Okta 验证用户凭证并返回包含身份声明（sub、groups、audience）的 JSON Web Token（JWT）；用户通过 Web 应用提交提示，该提示通过 HTTPS 到达 Amazon CloudFront；CloudFront 将请求转发到运行在 AWS Fargate 上的 Amazon Elastic Container Service（Amazon ECS）中的 FastAPI 后端；后端在用户输入到达智能体之前应用 Amazon Bedrock Guardrails 对个人可识别信息（PII）进行脱敏，并在智能体输出到达用户之前再次应用；后端调用 AgentCore Runtime 上的 Strands Agent，在 Authorization 头中转发用户的 JWT 以进行身份传播；智能体将提示发送到 Amazon Bedrock 进行推理。根据模型的响应，智能体确定要调用哪些工具；智能体将用户的 JWT 转发到 AgentCore Gateway，后者使用语义搜索在 LOB 目标之间进行工具发现。AgentCore 中的 Policy（当策略引擎与 Gateway 关联时）根据 Cedar 规则评估 JWT 声明，并按用户身份、角色或操作允许或拒绝每个工具调用。由于出站调用使用 M2M，用户级授权在此处由 Gateway 强制执行；对于被允许的调用，Gateway 从 AgentCore Identity 检索 OAuth 2.0 M2M 凭证，将其附加到出站请求，并转发到正确的 LOB MCP 服务器。每个 LOB MCP 服务器在处理之前验证入站 OAuth 令牌；LOB MCP 服务器运行其工具逻辑：(a) 针对本地 Amazon DynamoDB 表进行结构化数据查找，(b) 对于贷款与财富 LOB，还针对存储在 Amazon S3 中、由 Amazon OpenSearch Serverless 建立索引的银行政策 PDF，通过 Amazon Bedrock Knowledge Bases 执行 RAG 检索

结果沿同一链路返回（LOB 到 Gateway 到 Agent 到后端），示例应用中的跟踪面板显示访问了哪些 LOB 以及 Policy in AgentCore 的拒绝情况。每个 LOB 运行时都会验证入站 OAuth 令牌。在生产环境中，LOB 团队配置 allowedWorkloadConfiguration，将运行时调用限制为身份链中包含 Gateway 的请求，从而降低绕过 Gateway 策略和 Cedar 授权的直接访问风险。

Strands Agent 通过 Gateway 的 tools/list 方法发现 LOB 工具，并在启动时查询 AWS Agent Registry（预览版）以发现已注册的 LOB MCP 服务器。接入新的 LOB 只需添加一个 Gateway 目标。智能体将在下一次 tools/list 调用时发现新工具。

技术实现

以下各节逐一介绍架构的每一层：LOB 团队如何构建和部署 MCP 服务器，平台团队如何配置带 OAuth 出站身份验证的 AgentCore Gateway 以及 Policy in AgentCore 授权，以及持续评估如何帮助在工具和模型演进时保持智能体的可靠性。如需完整实现，请克隆随附的代码仓库并运行部署脚本，该脚本会在四个账户中引导 AWS Cloud Development Kit（AWS CDK），预置平台和 LOB 资源，部署 MCP 服务器和 Gateway 目标，并在 CloudFront 之后的 Amazon ECS 上启动 React Web 应用。

先决条件

随附的代码仓库假定以下条件：

通过 AWS Organizations 管理的 AWS 多账户设置，平台账户和 LOB 账户位于同一组织中；平台账户中具有 Amazon Bedrock 模型访问权限；在平台账户（用于智能体、Gateway 和 Registry）和每个 LOB 账户（用于在 Runtime 上托管 MCP 服务器）中均配置了 AgentCore；一个兼容 OIDC 的身份提供程序（例如 Okta、Amazon Cognito 或 Microsoft Entra ID），并具有用于 OAuth 2.0 客户端凭证授予的 M2M 应用客户端。该代码仓库使用 Okta；MCP 服务器将要封装的 LOB 数据源（Amazon Bedrock Knowledge Bases、Amazon DynamoDB 表、Amazon S3 存储桶或 API 端点）

在 LOB 账户中设置 MCP 服务器

每个 LOB 团队使用 FastMCP 构建一个 MCP 服务器，并使用 AgentCore CLI 将其部署到 AgentCore Runtime，将该团队的数据以具有类型化输入和输出的结构化工具形式对外暴露。每个 LOB 团队为其服务器配置一个 customJWTAuthorizer，该授权器会针对 Okta 的 OIDC 发现端点对入站 OAuth 令牌进行身份验证，因此请求必须出示有效令牌才能调用该 LOB 的工具。为进行生产环境加固，请将 Runtime 上的 allowedWorkloadConfiguration 设置为 Gateway 的 Amazon Resource Name（ARN），这会将其配置为仅当身份链中包含该 Gateway 时才接受请求。此示例依赖 OAuth 受众验证作为其主要访问控制。添加 allowedWorkloadConfiguration 有助于将调用限制为通过 Gateway 到达的请求，从而降低绕过 Gateway 策略进行直接访问的风险。

此代码片段展示了 Lending & Wealth LOB 的 MCP 服务器，它将 Amazon DynamoDB 查找与 Amazon Bedrock Knowledge Bases 检索相结合。

使用 AgentCore CLI 将 MCP 服务器部署到 AgentCore Runtime。configure 步骤设置入口点和协议。deploy 步骤将其打包并推送：

部署后，CLI 会返回一个运行时 ARN，平台团队使用该 ARN 将 MCP 服务器注册为 Gateway 目标。

配置 AgentCore Gateway

在平台账户中，使用指向 Okta 的 OIDC 发现 URL 并验证受众（aud）声明的 Custom JWT 授权器创建 Gateway，以限制哪些应用程序可以连接：

对于向 LOB MCP 服务器的出站身份验证，Gateway 使用 OAuth 2.0 客户端凭证授予（M2M）。平台团队在 AgentCore Identity 中注册一个 OAuth 凭证提供程序，用于存储 Okta M2M 客户端凭证。当 Gateway 调用 LOB MCP 服务器时，AgentCore Identity 会从 Okta 获取新的访问令牌，并将其放在 Authorization 标头中传递。注册该凭证提供程序并将其附加到每个 Gateway 目标：

当 LOB 工具必须自行实施按用户访问控制时（例如行级安全性），AgentCore Identity 还提供代表（OBO）令牌交换，其中 Gateway 将入站用户令牌交换为下游作用域令牌，该令牌同时携带智能体和用户的身份。此实现使用 M2M，因为用于示例的 Okta 开发者账户不支持 OBO 流程。AgentCore Gateway 还支持授权码授予和 API 密钥。有关示例，请参阅 AgentCore Gateway 出站身份验证示例。

部署智能体

使用用于入站身份验证的 Custom JWT 授权器将 Strands 智能体部署到 AgentCore Runtime。部署脚本在初始部署后通过 AgentCore 控制平面 API 应用授权器配置。在请求时，智能体将用户的 JWT 转发给 Gateway，以便 Policy in AgentCore 在路由每个工具调用之前评估用户的声明：

部署后，智能体从入站请求标头中读取用户的 JWT，并将其传递给 AgentCore Gateway。这样可将最终用户身份传播到 Cedar 策略引擎，而智能体无需解析或修改令牌：

运行智能体

智能体部署后，平台团队通过持续评估、安全的版本发布和可观测性来保持其可靠性。

持续评估

在智能体跨多个 LOB 编排工具的多账户架构中，平台团队需要确信随着工具、模型和提示的演进，智能体仍能正确运行。AgentCore Evaluations 提供了一个托管框架，有助于在回归问题到达客户之前将其捕获。

在线评估使用内置评估器（例如工具选择准确性、正确性和目标成功率）持续对实时生产流量样本（例如 10% 的会话）进行评分。评分会显示在 AgentCore Observability 仪表板中，该仪表板是由 Amazon CloudWatch 提供支持的 Amazon Bedrock AgentCore 的一项能力；当质量下降时会发出警报，并且如果智能体已经发出 OpenTelemetry 跟踪，则无需更改代码。这可以揭示延迟和错误率监控所遗漏的隐性退化，例如智能体将贷款查询路由到错误的 LOB。

按需评估是用于开发和持续集成与持续交付（CI/CD）的实时 API。团队只需定义一次评估数据集（场景与预期响应、工具轨迹和目标断言配对），AgentCore Evaluations 就会使用数据集评估在每次更改时重放它。由于两种模式共享相同的评估器，团队在部署前所把关的内容正是其在生产中所监控的内容。为形成闭环，AgentCore Optimization 会分析生产跟踪并推荐提示和工具描述改进，并在发布前进行验证。

版本管理与安全发布

你将智能体部署在 AgentCore Runtime 上，并使用指向特定版本的端点（prod、staging、dev）。当平台团队更新智能体的提示或模型时，它会发布新版本并更新端点，而各业务线（LOB）的 MCP 服务器不受影响，因为工具接口没有变化。在推广变更之前，团队可以通过 AgentCore Gateway 运行 A/B 测试，在当前版本和候选版本之间分配实时流量。一旦结果达到统计显著性，平台团队就会推广获胜的配置。

监控与观测

AgentCore 通过 Amazon CloudWatch 和 OpenTelemetry 提供内置可观测性。平台团队监控调用延迟、错误率和令牌用量，并通过 CloudWatch 跨账户可观测性查看 LOB MCP 服务器的指标和日志，无需切换账户。

安全、治理与成本管理

在分散数据的同时集中管理智能体，会产生特定的治理要求：控制谁可以调用哪些工具、审计跨账户调用、执行负责任的 AI 策略，以及将成本归因回触发这些成本的 LOB。

最小权限访问与数据所有者审批

LOB 团队通过其 AgentCore Runtime 部署上的 JWT 授权器配置，控制谁可以调用其 MCP 服务器。只有当 LOB 团队已将其 MCP 服务器配置为接受来自平台身份提供商的令牌后，来自平台账户 Gateway 的请求才能到达 LOB 的工具。此审批独立于平台团队。即使 Gateway 添加了新目标，LOB MCP 服务器也会拒绝未经身份验证的请求。

AgentCore 授权中的策略

Gateway 以 ENFORCE 模式运行 AgentCore 中的策略，在路由每个工具调用之前，根据用户的 JWT 声明（来自智能体转发的令牌）评估规则。AgentCore 中的策略使用 Cedar 策略语言，因此规则是明确的 permit 和 forbid 语句。例如，策略可以允许所有经过身份验证的用户使用 get_balance 等只读工具，同时将 transfer_funds 等写入操作限制为特定角色，或者完全阻止 delete_customer 等破坏性操作：

由于 AgentCore 中的策略采用默认拒绝模型，只有具有明确 permit 的操作才能成功。这使平台团队能够集中控制智能体在已注册 LOB 中可执行的操作，同时各个 LOB 团队在 MCP 服务器层面保留自己的授权。

网络连接与 VPC 注意事项

此参考实现为 AgentCore Runtime 使用默认的公共网络模式，流量通过 HTTPS 和 OAuth 经由公共互联网传输。这适合开发环境，但不适合生产环境。对于生产环境，AgentCore Runtime 支持通过弹性网络接口（ENI）实现虚拟私有云（VPC）连接以访问私有资源，支持通过 AWS PrivateLink 的接口 VPC 端点实现到 Gateway 的私有入站，以及使用 allowedWorkloadConfiguration 将运行时调用限制为你的 Gateway。有关配置步骤，请参阅 AgentCore Runtime 的网络连接模式以及使用接口 VPC 端点安全入站到 AgentCore Gateway。

护栏

在平台账户中应用 Amazon Bedrock Guardrails，以实现内容过滤、PII 脱敏和主题限制。由于推理是集中式的，一个护栏配置即可适用于跨 LOB 工具的智能体交互。作为更新的选项，你可以直接在 AgentCore Gateway 上将 Guardrails 作为策略应用，这样检查就在 Gateway 层运行，位于智能体代码之外，覆盖通过 Gateway 路由的工具和上下文来源。

审计与合规

要启用数据平面日志记录，请在 Gateway 上配置日志交付到 Amazon CloudWatch Logs，它会捕获工具调用和请求元数据。AWS CloudTrail 默认捕获控制平面操作（创建和更新网关、运行时、目标和策略）。要同时在 CloudTrail 中捕获单个工具调用，请使用高级事件选择器为 AgentCore Gateway 资源启用数据事件日志记录。对于集中式审计，请配置组织级 CloudTrail 跟踪，将平台账户和 LOB 账户的日志聚合到专用日志账户中。

成本归因

此架构提供了自然的成本边界。每个 LOB 的数据平面成本（Amazon DynamoDB、Amazon Bedrock Knowledge Bases、MCP 服务器计算）保留在其自己的账户中，并直接显示在 AWS Cost Explorer 中。LLM 推理和 Gateway 调用计入平台账户。要将这些成本归因回发起它们的 LOB，智能体的执行角色带有标签（例如 lob 或 costCenter 标签）。在 AWS Billing 控制台中激活成本分配标签后，这些标签会流入 AWS 成本和使用情况报告，用于按 LOB 分摊费用。智能体的工具跟踪记录每个 LOB 调用了哪些工具，以便按比例分配。如需更深入的方法，请参阅 Amazon Bedrock 的细粒度成本归因。

清理

为避免在部署随附仓库后产生持续费用，请运行包含的清理脚本。它会删除四个账户中已部署的资源，包括 AgentCore 组件（智能体、Gateway、Registry、凭证提供程序）、Okta 配置（授权服务器、M2M 应用客户端）、MCP 服务器部署、CDK 堆栈（Amazon DynamoDB 表、Amazon S3 存储桶、Amazon Elastic Container Registry 仓库、Amazon ECS 集群）以及示例数据源。

请从仓库根目录运行该脚本：

该脚本按部署的逆序运行，先删除智能体和 MCP 服务器，然后删除 AgentCore 配置中的 Gateway 目标和 Policy，最后删除所有四个账户中的 CDK 基础设施堆栈。

结论

本文展示了如何构建多账户架构：通过 Amazon Bedrock 和 AgentCore 在中心位置运行智能体，同时将数据分散保留在各 LOB 账户中。LOB 团队将其数据作为 MCP 服务器公开，平台账户的 Gateway 提供单一经过身份验证的端点用于工具发现和调用，而 AgentCore 中的 Policy 在 Gateway 层强制执行按用户授权。该模式可自然扩展：要接入新的业务线，平台团队只需添加一个 Gateway 目标，智能体便会在下次调用时发现新工具。

要自行尝试此模式，请克隆随附仓库并部署四账户参考实现。

主题

标签

正文 · AI 翻译