可易

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

可易团队阅读约 17 分钟

在平台账户用 AgentCore Gateway 聚合各业务线 MCP 服务器，数据留在原账户，并以 OAuth、Cedar 策略和清理脚本完成部署与回滚。

目录

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

企业越来越希望 AI 智能体能够对分散在许多 AWS 账户中的数据进行推理，而不必复制或集中这些数据。每个团队把数据留在自己的账户中是有充分理由的：所有权清晰、范围隔离，以及相互独立的部署生命周期。但只能看到一个账户数据的智能体价值有限，而把它接到分布式来源上，通常意味着复制数据，或理清跨账户的 AWS 身份与访问管理（Identity and Access Management，IAM）。目标是让数据留在它已经所在的地方，也就是每个业务线（line-of-business，LOB）账户。只有某次请求所需的特定数据在查询时流出，底层数据集不会离开其所属账户。

在本文中，你将构建一种多账户架构：每个团队的数据仍留在自己的账户中，同时让智能体有统一的方式跨账户查询。使用的是 Amazon Bedrock AgentCore Gateway 和模型上下文协议（Model Context Protocol，MCP）。Amazon Bedrock AgentCore 是一项智能体服务（agentic service），用于大规模地安全构建、部署并运行高效智能体。一个中心平台账户承载智能体层，并通过 Amazon Bedrock 进行大语言模型（large language model，LLM）推理。LOB 团队把数据和工具暴露为 MCP 服务器，平台账户的 AgentCore Gateway 为智能体提供单一端点，用于在已注册的 LOB 之间发现并调用工具。在此过程中，你会设置跨账户 MCP 集成，使用 AgentCore Identity（Amazon Bedrock AgentCore 的一项能力）和 Okta 做身份验证，使用 Amazon Bedrock AgentCore 中的 Policy 做细粒度授权，并设置支持生产就绪的治理控制。

方案概览

该架构遵循三层多账户模型：中心平台账户、分布式 LOB 账户，以及把它们连接起来的集成层 AgentCore Gateway。

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

平台团队拥有平台账户，并在 AgentCore Runtime（Amazon Bedrock AgentCore 的一项能力）上运行智能体。AgentCore Runtime 是无服务器、与框架无关的环境，在专用微虚拟机（microVM）中做会话隔离，按消耗计价，并内置身份验证。为使讲解清楚，本文使用单个智能体，但同一模式支持在平台账户中运行多个智能体。智能体连接到平台账户的 Gateway，而不是逐个连接 LOB 的 MCP 服务器。

LLM 推理在平台账户中通过 Amazon Bedrock 运行。平台团队控制可用的基础模型（foundation model，FM），应用 Amazon Bedrock Guardrails，并通过单一计费边界跟踪成本，从而避免在数十个 LOB 账户中管理模型配额的开销。随着需求增长，一些组织会把推理分散到若干专用推理账户，并把 AgentCore Gateway 放在前面作为推理网关（Inference Gateway），按请求选择提供方并在各模型提供方之间路由流量，同时施加按团队的速率限制。

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

除了聚合 MCP 服务器并充当推理网关之外，AgentCore Gateway 还支持更多目标类型，使它成为中心集成点。HTTP 目标把 AgentCore Runtime 智能体、智能体到智能体（agent-to-agent，A2A）服务以及其他 HTTP 端点纳入同一个受治理的端点，每个都可通过自己的子路径寻址。平台团队还可以应用 Amazon Bedrock Guardrails 做内容安全，并配置 AgentCore 中的 Policy（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，后者针对银行政策 PDF，查询 Amazon Bedrock Knowledge Bases 中的全托管检索增强生成（Retrieval Augmented Generation，RAG）能力。该参考架构把一个独立的 Amazon Bedrock Knowledge Base 包在 MCP 服务器内部，以便对检索流水线做细粒度控制。对于新的实现，你也可以把 Amazon Bedrock Managed Knowledge Base 作为原生连接器直接挂到 Gateway 上，这样智能体用标准 MCP 调用即可查询，而你不必运行检索基础设施。

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

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

该架构遵循中心辐射（hub-and-spoke）模式：每个 LOB 使用基于可流式 HTTP（Streamable HTTP）的 MCP 部署一个独立 MCP 服务器（辐射端），而 AgentCore Gateway（中心）把它们聚合在单一端点之后。智能体把 Gateway 当作一个 MCP 服务器来连接，Gateway 则在已注册的 LOB 目标之间联合调用工具。当智能体调用某个工具时，Gateway 从 AgentCore Identity 取得 OAuth 2.0 机器对机器（machine-to-machine，M2M）凭据，把它们附加到出站请求上，并路由到正确的 LOB MCP 服务器；该服务器在本地处理请求之前，对照 Okta 的 OpenID Connect（OIDC）端点验证令牌。

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

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

下面的走查跟踪一个用户问题如何跨越账户边界、调用分布式工具并返回统一答案：

  • 用户通过 React Web 应用登录，应用重定向到 Okta 做身份验证。
  • Okta 验证用户凭据，并返回包含身份声明（sub、groups、audience）的 JSON Web 令牌（JSON Web Token，JWT）。
  • 用户通过 Web 应用提交提示，该请求经 HTTPS 到达 Amazon CloudFront。
  • CloudFront 把请求转发到运行在带 AWS Fargate 的 Amazon Elastic Container Service（Amazon ECS）上的 FastAPI 后端。
  • 后端对用户输入应用 Amazon Bedrock Guardrails，在输入到达智能体之前做个人可识别信息（personally identifiable information，PII）脱敏，并在智能体输出到达用户之前再做一次。
  • 后端调用 AgentCore Runtime 上的 Strands 智能体，并在 Authorization 头中转发用户的 JWT，以传播身份。
  • 智能体把提示发送到 Amazon Bedrock 进行推理。根据模型的响应，智能体决定调用哪些工具。
  • 智能体把用户的 JWT 转发到 AgentCore Gateway，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）对于贷款与财富（Lending & Wealth）LOB，还针对存放在 Amazon S3、并由 Amazon OpenSearch Serverless 建立索引的银行政策 PDF，对 Amazon Bedrock Knowledge Bases 做 RAG 检索。

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

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

技术实现

下面各节逐层说明该架构：LOB 团队如何构建并部署 MCP 服务器，平台团队如何为 AgentCore Gateway 配置 OAuth 出站身份验证和 AgentCore 中的 Policy 授权，以及持续评估如何在工具和模型演进时帮助智能体保持可靠。要获得完整实现，请克隆随附的存储库并运行部署脚本。该脚本在四个账户中引导 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。
  • LOB 数据源（Amazon Bedrock Knowledge Bases、Amazon DynamoDB 表、Amazon S3 存储桶或 API 端点），由 MCP 服务器加以封装。

在 LOB 账户中设置 MCP 服务器

每个 LOB 团队用 FastMCP 构建 MCP 服务器，并用 AgentCore CLI 把它部署到 AgentCore Runtime，把团队的数据暴露为带类型化输入和输出的结构化工具。每个 LOB 团队用 customJWTAuthorizer 配置其服务器，对照 Okta 的 OIDC 发现端点验证入站 OAuth 令牌，因此请求必须出示有效令牌才能调用该 LOB 的工具。为了生产加固，把 Runtime 上的 allowedWorkloadConfiguration 设为 Gateway 的 Amazon 资源名称（Amazon Resource Name，ARN），从而将其配置为仅当身份链包含该 Gateway 时才接受请求。本示例以 OAuth 受众验证作为主要访问控制。增加 allowedWorkloadConfiguration 有助于把调用限制为经 Gateway 到达的请求，降低绕过 Gateway 策略而直接访问的风险。

下面的片段展示贷款与财富 LOB 的 MCP 服务器，它把 Amazon DynamoDB 查找与 Amazon Bedrock Knowledge Bases 检索结合在一起。

REGION = os.environ.get("AWS_REGION", "us-east-1")
dynamodb = boto3.resource("dynamodb", region_name=REGION)
bedrock_agent_runtime = boto3.client("bedrock-agent-runtime", region_name=REGION)
KNOWLEDGE_BASE_ID = os.environ.get("KNOWLEDGE_BASE_ID", "")

mcp = FastMCP("lending-wealth", host="0.0.0.0", stateless_http=True)

@mcp.tool()
def get_credit_score(customer_id: str) -> dict:
    """Get credit score and contributing factors for a customer."""
    table = dynamodb.Table("CreditScores")
    resp = table.get_item(Key={"customer_id": customer_id})
    item = resp.get("Item")
    if not item:
        return {"error": f"No credit score found for customer {customer_id}"}
    return item

@mcp.tool()
def search_lending_policies(query: str) -> str:
    """Search the bank's lending policy documents for guidelines,
    eligibility criteria, and regulatory requirements."""
    if not KNOWLEDGE_BASE_ID:
        return json.dumps({"error": "KNOWLEDGE_BASE_ID not configured"})
    resp = bedrock_agent_runtime.retrieve(
        knowledgeBaseId=KNOWLEDGE_BASE_ID,
        retrievalQuery={"text": query},
        retrievalConfiguration={"vectorSearchConfiguration": {"numberOfResults": 5}},
    )
    chunks = []
    for r in resp.get("retrievalResults", []):
        text = r.get("content", {}).get("text", "")
        source = r.get("location", {}).get("s3Location", {}).get("uri", "")
        if text:
            chunks.append({"text": text, "source": os.path.basename(source)})
    return json.dumps({"results": chunks}, default=str)

if __name__ == "__main__":
    mcp.run(transport="streamable-http")

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

# Configure the MCP server
agentcore configure \
    --entrypoint server.py \
    --name lending_wealth_mcp \
    --protocol MCP \
    --disable-memory \
    --non-interactive \
    --authorizer-config '{
      "customJWTAuthorizer": {
        "discoveryUrl": "<OKTA_DISCOVERY_URL>",
        "allowedAudience": ["lobfederation"]
      }
    }'

# Deploy to AgentCore Runtime
agentcore deploy --auto-update-on-conflict \
    --env KNOWLEDGE_BASE_ID=<your-knowledge-base-id>

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

配置 AgentCore Gateway

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

ctrl.update_gateway(
    gatewayIdentifier=gateway_id,
    name="lobfederation-gateway",
    protocolType="MCP",
    protocolConfiguration={
        "mcp": {
            "searchType": "SEMANTIC",
            "supportedVersions": ["2025-03-26"],
        }
    },
    authorizerType="CUSTOM_JWT",
    authorizerConfiguration={
        "customJWTAuthorizer": {
            "discoveryUrl": "https://<your-okta-domain>/oauth2/<auth-server-id>/.well-known/openid-configuration",
            "allowedAudience": ["lobfederation"],
        }
    },
)

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

# Register an OAuth credential provider (M2M / client_credentials)
resp = ctrl.create_oauth2_credential_provider(
    name="lobfederation-okta-m2m",
    credentialProviderVendor="CustomOauth2",
    oauth2ProviderConfigInput={
        "customOauth2ProviderConfig": {
            "oauthDiscovery": {
                "discoveryUrl": "https://<your-okta-domain>/oauth2/<auth-server-id>/.well-known/openid-configuration"
            },
            "clientId": "<M2M_CLIENT_ID>",
            "clientSecret": "<M2M_CLIENT_SECRET>",
            "clientAuthenticationMethod": "CLIENT_SECRET_BASIC",
        }
    },
)
cred_arn = resp["credentialProviderArn"]

# Create a Gateway target for the LOB MCP server with OAuth outbound auth
ctrl.create_gateway_target(
    gatewayIdentifier=gateway_id,
    name="lending-wealth",
    description="Lending & Wealth --- loans, credit scores, eligibility, policy search",
    targetConfiguration={
        "mcp": {
            "mcpServer": {
                "endpoint": f"https://bedrock-agentcore.{REGION}.amazonaws.com/runtimes/{encoded_runtime_arn}/invocations",
            }
        }
    },
    credentialProviderConfigurations=[
        {
            "credentialProviderType": "OAUTH",
            "credentialProvider": {
                "oauthCredentialProvider": {
                    "providerArn": cred_arn,
                    "scopes": ["lobfederation.invoke"],
                    "grantType": "CLIENT_CREDENTIALS",
                }
            },
        }
    ],
)

当某个 LOB 工具必须自行强制按用户访问时（例如行级安全），AgentCore Identity 也提供代表用户（on-behalf-of，OBO）的令牌交换：Gateway 把入站用户令牌交换为下游范围的令牌，同时携带智能体和用户的身份。本实现使用 M2M，因为示例所用的 Okta 开发者账户不支持 OBO 流程。AgentCore Gateway 也支持授权码授权和 API 密钥。示例见 AgentCore Gateway 出站身份验证示例。

部署智能体

把 Strands 智能体部署到 AgentCore Runtime，并用自定义 JWT 授权器做入站身份验证。部署脚本在初次部署之后，通过 AgentCore 控制平面 API 应用授权器配置。在请求时，智能体把用户的 JWT 转发到 Gateway，以便 AgentCore 中的 Policy 在路由每次工具调用之前评估用户声明：

{
  "agents": [
    {
      "name": "lobfederation-agent",
      "authorizerType": "CUSTOM_JWT",
      "authorizerConfiguration": {
        "customJwtAuthorizer": {
          "discoveryUrl": "https://<your-okta-domain>/oauth2/<auth-server-id>/.well-known/openid-configuration",
          "allowedAudience": ["lobfederation"]
        }
      },
      "requestHeaderAllowlist": ["Authorization"]
    }
  ]
}

部署之后，智能体从入站请求头读取用户的 JWT，并把它传给 AgentCore Gateway。这样就把最终用户身份传播到 Cedar 策略引擎，而智能体不必解析或修改该令牌：

@app.entrypoint
def invoke(payload, context=None):
    prompt = payload.get("prompt", "Hello")

    # Read the user's JWT from inbound request headers (passed through by Runtime)
    request_headers = context.request_headers if context else {}
    user_jwt = request_headers.get("Authorization", "")

    # Connect to Gateway with the user's JWT --- Cedar evaluates per-user policies
    mcp_client = MCPClient(
        lambda: streamablehttp_client(
            url=GATEWAY_URL,
            headers={"Authorization": user_jwt},
        )
    )

    with mcp_client:
        tools = mcp_client.list_tools_sync()
        agent = Agent(model=MODEL_ID, system_prompt=SYSTEM_PROMPT, tools=tools)
        result = agent(prompt)

运行智能体

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

#### 持续评估

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

在线评估使用内置评估器（例如工具选择准确率 Tool Selection Accuracy、正确性 Correctness 和目标成功率 Goal Success Rate），持续为实时生产流量的一个样本打分（例如 10% 的会话）。分数出现在 AgentCore Observability 仪表盘中。该能力属于 Amazon Bedrock AgentCore，由 Amazon CloudWatch 提供支持；质量下降时会告警。如果智能体已经发出 OpenTelemetry 跟踪，则不需要改代码。这可以发现延迟和错误率监控会漏掉的安静退化，例如智能体把贷款查询路由到错误的 LOB。

按需评估是用于开发和持续集成与持续交付（continuous integration and continuous delivery，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 服务器。来自平台账户 Gateway 的请求，只有在 LOB 团队已将其 MCP 服务器配置为接受来自平台身份提供方的令牌之后，才能到达该 LOB 的工具。这一批准独立于平台团队。即使 Gateway 增加了新目标，LOB MCP 服务器也会拒绝未经验证的请求。

AgentCore 中的 Policy 授权

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

// Permit all authenticated users to invoke read-only tools
permit(
    principal is AgentCore::OAuthUser,
    action in [
        AgentCore::Action::"retail-banking___get_customer",
        AgentCore::Action::"retail-banking___get_accounts",
        AgentCore::Action::"retail-banking___get_balance",
        AgentCore::Action::"tools/list",
        AgentCore::Action::"initialize"
    ],
    resource
);

// Block destructive operations regardless of user
forbid(
    principal,
    action == AgentCore::Action::"retail-banking___delete_customer",
    resource
);

因为 AgentCore 中的 Policy 使用默认拒绝模型，只有带明确 permit 的操作才会成功。这让平台团队集中控制智能体在已注册 LOB 上能做什么，同时各个 LOB 团队仍在 MCP 服务器层保留自己的授权。

网络连通性与 VPC 考量

该参考实现为 AgentCore Runtime 使用默认的公共网络模式，流量经 HTTPS 和 OAuth 穿越公共互联网。这适合开发，不适合生产。对于生产，AgentCore Runtime 支持通过弹性网络接口（elastic network interface，ENI）实现虚拟私有云（virtual private cloud，VPC）连通性，以便私有访问资源；通过 AWS PrivateLink 上的接口 VPC 端点对 Gateway 做私有入站；并用 allowedWorkloadConfiguration 把运行时调用限制为你的 Gateway。配置步骤见 AgentCore Runtime 的网络连通性模式，以及使用接口 VPC 端点安全进入 AgentCore Gateway。

护栏

在平台账户中应用 Amazon Bedrock Guardrails，用于内容过滤、PII 脱敏和主题限制。因为推理是集中的，一套护栏配置就适用于跨 LOB 工具的智能体交互。作为较新的选项，你可以把 Guardrails 作为策略直接应用在 AgentCore Gateway 上，这样检查在 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 成本与使用情况报告（Cost and Usage Report），用于按 LOB 分摊。智能体的工具跟踪记录每个 LOB 调用了哪些工具，以便按比例分配。更深入的方法见 Amazon Bedrock 的细粒度成本归属。

清理

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

从存储库根目录运行：

./cleanup.sh

该脚本按部署的相反顺序运行：先移除智能体和 MCP 服务器，然后是 Gateway 目标和 AgentCore 中的 Policy 配置，再是全部四个账户中的 CDK 基础设施堆栈。

结论

本文说明了如何构建一种多账户架构：通过 Amazon Bedrock 和 AgentCore 集中运行智能体，同时把数据分布在各 LOB 账户中。LOB 团队把数据暴露为 MCP 服务器，平台账户的 Gateway 为工具发现和调用提供单一的已验证端点，AgentCore 中的 Policy 在 Gateway 层强制执行按用户的授权。该模式可以自然扩展：要接入一条新的业务线，平台团队增加一个 Gateway 目标，智能体在下一次调用时发现新工具。

要自己试用这一模式，请克隆随附的存储库，并部署这个四账户参考实现。 PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/build-a-multi-account-ai-agent-with-agentcore-gateway-and-mcp

  • #AgentCore
  • #MCP
  • #多账户
  • #OAuth
  • #Cedar

继续阅读