Shared 带来 AI Agent 新信号

构建多租户 AI 应用会带来新的架构挑战。你需要在不同客户之间实现完全的租户隔离，为不同服务层级提供不同能力，进行细粒度的成本跟踪，并按租户提供可观测性。没有这些能力，你可能会面临客户数据泄露、无法为客户提供合适服务质量，或产生意料之外的成本风险。

在这篇文章中，你将了解如何使用 Amazon Bedrock AgentCore 实现可投入生产的多租户系统的设计模式。你会通过服务多个诊所和医院的医疗 AI agent 来看到这些模式的实际演示。虽然本文以医疗作为示例领域，但其中的架构模式和实现技术可广泛应用于各种多租户 AI 应用。无论你是在构建 SaaS 平台、面向多个业务单元的企业解决方案，还是面向不同客户组织的托管服务，都可以使用这些架构模式来构建你的方案。

如何使用原生 AWS 能力在 agentic 应用中实现完全的租户隔离。

以尽量少的自定义代码实现服务层级差异化的模式。

按租户进行精细化成本归因的技术。

可扩展多租户 AI 架构的最佳实践。

这篇博文是系列文章《使用 Amazon Bedrock AgentCore 构建多租户 agent》的第二部分。第一部分探讨了为多租户 agentic 应用进行架构设计时需要考虑的因素，以及借助 Amazon Bedrock AgentCore 应对 SaaS 架构挑战所需的框架。

示例代码的 GitHub 仓库：https://github.com/aws-samples/sample-agentcore-and-multitenancy-blog

该方案展示了如何利用 Amazon Bedrock AgentCore 的原生能力，借助 AWS 托管服务实现完全的租户隔离。该架构实现了三级层次：层级 → 租户 → 用户，并通过知识库、记忆、模型访问和成本跟踪中的文档，在每一层都执行隔离。分层策略是 SaaS 应用中的常见模式，通常会根据租户的需求、使用模式或定价方案，将租户划分到不同的服务层级中，例如 Basic 和 Premium。每个层级都会为该组中的租户定义一组可用功能和服务质量。借助这种方式，SaaS 提供商可以在保持运营效率的同时，为不同客户群体提供差异化体验。

为了直观展示这一机制，示例方案实现了两个用于按层级区分的服务层：

Basic Tier：面向主要需要简单文档搜索和检索的小型诊所和门诊设计。由于这类任务非常适合更小、成本更低的模型，该层级使用 Mistral Ministral 3 8B Instruct，在保持低成本的同时，也能为简单查询提供准确结果。

Premium Tier：面向需要复杂临床分析的医院和专科中心设计。该层级使用具备高级推理能力的 OpenAI GPT OSS 120B，以便准确选择工具，其中包括仅向 Premium 层级客户开放的 web search 工具。

在每个层级内，该方案采用池化隔离模型，也就是说，不同租户共享同一底层基础设施和计算资源，而不是为每个租户配置独立、隔离的资源池。池化模型能够最大化资源利用率并简化运维，同时通过作用域标识符、访问策略和数据分区等逻辑隔离机制来确保租户隔离。将分层策略与池化模型结合，可以在成本效率与差异化服务能力之间取得平衡。

下面来看 AgentCore 的各项原语如何组合起来解决这些多租户挑战。下图展示了该方案的多租户架构，说明请求如何从经过身份验证的用户，经由按层级划分的 agent，流向隔离的文档存储：

图 1：采用层级隔离（Tier → Tenant → User）的多租户架构。

该方案由以下关键组件构成：

Amazon Cognito：负责用户身份认证，并将租户元数据（tier、clinic_id、role）存储在 JSON Web Token（JWT）声明中。这些声明会被提取出来，并作为租户上下文通过请求负载向下传递，使每个下游组件都能将其操作范围限定到正确的租户。

Amazon API Gateway：路由请求，并通过 usage plans 按 tier 级别实施限流

AWS Lambda：提取租户上下文，并调用对应的 Amazon Bedrock AgentCore agent

AgentCore 组件：Runtime（agent 执行）、Memory（会话状态）、Identity（agent 身份管理）、Gateway（工具服务器）以及 Policy（agent 行为边界）

Amazon Simple Storage Service（Amazon S3）：以分层前缀结构的分层隔离桶存储临床文档，实现租户隔离

Amazon Bedrock 知识库：通过带元数据过滤的语义搜索，将查询范围限定在发起请求的租户文档内

Amazon Bedrock 项目：通过成本分配标签实现按层级的成本跟踪

本节介绍该解决方案的关键方面。你运行部署脚本来为该解决方案搭建基础设施和应用程序。本节中的代码摘录仅用于说明解决方案的各个组件如何应对架构中的关键方面。这里没有必要运行任何命令或执行所示的任何代码片段。

该架构利用六项核心的 Bedrock AgentCore 能力来实现多租户：

AgentCore Runtime：AgentCore Runtime 为本方案中的智能体提供计算能力，每个智能体会话执行都运行在独立的 micro-VM 中，以实现租户级计算隔离。它按层级托管独立的智能体实例，并为每一层配置相应的模型和能力。

AgentCore Identity：AgentCore Identity 通过统一的基于 JWT 的认证模型，为多租户架构提供安全保障。Cognito ID token 会在 Runtime 和 Gateway 两层边界验证用户身份，而工具 Lambda 会自行签发作用域受限的凭证，用于后续数据访问。

每个 AgentCore Runtime 都配置了入站 JWT authorizer，在智能体代码执行前验证 Cognito ID token。该 ID token 通过自定义 claim 携带租户元数据：

该 authorizer 在 agent 部署期间进行配置：

AgentCore Gateway 也配置了 JWT 授权，使用相同的 Cognito discovery URL 和 audience。当 agent 调用 gateway 时，它会连同 tenant 上下文头（X-Tier、X-Clinic-ID、X-S3-Prefix）一起，将用户原始的 JWT 作为 Bearer token 转发以供验证。gateway 验证 token 后，会通过 metadataConfiguration 将 tenant 头继续传递给目标 Lambda。

目标 Lambda 从不直接接收或处理用户的 JWT。相反，它读取受信任的 tenant 头（之所以受信任，是因为只有经过认证的请求才能通过 gateway 的 CUSTOM_JWT authorizer），并假设一个 TVM（Token Vending Machine）角色，其 session tags 由这些头部派生而来。TVM 角色的 ABAC policy 使用 dynamodb:LeadingKeys 条件限制对 DynamoDB 的访问，确保每个 tenant 只能在 IAM 层面查询自己诊所的数据，而不只是依赖应用层过滤。

AgentCore Memory：会话历史不能在不同 tenant 之间泄漏，也不能在同一 tenant 内的多个用户之间泄漏。该方案通过两层实现内存隔离：应用层作用域控制，以及由 IAM 支持的属性基于访问控制（ABAC）。

在应用层，AgentCore Memory 使用层级化命名空间结构，并通过复合 `actor_id` 按租户组织会话数据：

命名空间用于区分不同类型的内存：

为在基础设施层面强制隔离，该方案采用带有 ABAC 的 Token Vending Machine（TVM）模式。运行时，agent 以 Tier、ClinicId 和 UserId 作为会话标签来假定 TVM 角色，并接收仅限于该租户命名空间的临时凭证：

TVM 角色的信任策略确保只有 agent 执行角色可以假定该角色，并且三项会话标签全部存在：

AgentCore Gateway：AgentCore Gateway 使用模型上下文协议（MCP），将静态 Lambda 函数转换为动态的、具备上下文感知能力的智能体工具。模型上下文协议是一项开源标准，用于连接 AI 智能体与外部工具。

AgentCore Gateway 消除了构建自定义工具编排逻辑的需要。若没有它，你就需要手动将 API 集成到智能体工作流中。这包括编写自定义代码来解析 API 规范、处理身份验证、管理转换、实现错误处理，以及传递租户上下文。

该 Lambda 函数通过 Gateway 暴露两个工具：

patient_context：从 PatientMetadata DynamoDB 表中检索患者的人口统计信息和病史。

clinic_config：从 `ClinicConfig` DynamoDB 表中获取诊所配置和提供方信息。

如前所述，租户标识会在各个组件之间传递。智能体在初始化其 MCP Gateway 客户端时，会使用租户作用域的请求头（`X-Tier`、`X-Clinic-ID`、`X-S3-Prefix`），因此通过网关发起的每次工具调用都会自动携带租户上下文，并在网关层面强制执行数据隔离，而无需为每个工具单独编写过滤逻辑。此链接提供了有关网关请求头的更多信息。

该网关支持三种身份验证机制：

IAM 角色：用于 AWS 服务集成。

自定义 JWT：用于感知租户的工具（我们正在使用的方案）。

OAuth：用于第三方 API 集成。

AgentCore Policy：AgentCore Policy 使用 Cedar 授权策略，对网关工具强制执行按层级划分的操作边界。该方案创建了一个共享策略引擎，并将其附加到 ENFORCE 模式下的基础版网关和高级版网关上。对于基础层级，一条 Cedar 策略会根据工具输入中的 `request_hour` 字段，将 `patient_context` 工具限制在工作时间内（上午 8 点到下午 6 点）。智能体必须先调用 `current_time` 并传入当前小时；如果该小时落在允许窗口之外，策略引擎就会拒绝这次调用。对于高级层级，策略无条件允许 `patient_context`，从而为医院提供 24/7 访问。由于 `clinic_config` 工具暴露的是非敏感配置数据，因此两个层级都获得了对它的显式许可。这种方法把访问控制从应用代码中移出，交给在网关层执行的声明式 Cedar 策略，因此在 Lambda 函数真正执行之前，就已经完成了层级差异化强制控制。

AgentCore Observability：AgentCore 的可观测性集成使用 OpenTelemetry baggage，在整个请求生命周期中传播租户元数据。OpenTelemetry baggage 是一个键值存储，可让你在传播 trace 上下文的同时携带额外数据。该方案在 AgentCore Runtime 入口点将租户标识设置为 baggage，因此每个下游 span 和日志条目都会带有租户归属信息：

例如，你可以使用 Amazon CloudWatch Logs Insights 来跟踪每个诊所的请求量

再结合 Bedrock Projects 做分层级成本归因，以及为每个诊所做结构化使用日志记录，用于跟踪 token，这样就能在模型使用、agent 执行和内存操作三个层面获得 tenant 级可见性。

本节介绍该方案如何实现使用 Amazon Bedrock AgentCore 构建多租户的核心模式。

在医疗解决方案示例中，系统为每个服务层创建一个单独的 S3 bucket，并在每个 bucket 内使用 tenant-specific 前缀。每个层级的 Knowledge Base 都有自己专用的 S3 bucket，从而在层级之间实现 bucket 级隔离。在每个 bucket 内，层级化前缀用于组织 tenant 数据，并通过基于路径的访问控制和 Knowledge Base 元数据过滤实现隔离：

在每个桶内，S3 前缀由从 Cognito JWT 声明（`custom:tier`、`custom:clinic_id`）中提取的租户身份构建而成。随后，这个前缀有两种用途：一是作为 `X-S3-Prefix` 头传递给每次 MCP Gateway 工具调用，用于网关层面的强制执行；二是文档检索工具通过 Amazon Bedrock Knowledge Base 上针对 `clinic_id` 的 metadata filter 来强制隔离：

成本归属分两个层面进行：按服务层级通过 Bedrock Projects 归属，按诊所通过结构化使用日志归属。

按层级归属通过 Bedrock Projects 实现：每个层级都有一个专用的 Bedrock Project，并附带成本分配元数据（CostCenter、Tier、Application）。在每次推理请求中，都会通过 Bedrock Mantle endpoint 传递 project ID，因此所有模型调用成本都会在 AWS Cost Explorer 中按层级自动分组。

在运行时，agent 会通过 Bedrock Mantle（OpenAI 兼容）endpoint 在每次推理请求中传递 project ID。这意味着每一次模型调用都会自动标记上该层级的成本元数据：

一旦你在 AWS Billing 中启用成本分配标签（标签最多可能需要 24 小时才能传播生效），就可以在 AWS Cost Explorer 中按 `CostCenter`、`Tier` 或 `Application` 过滤并分组推理成本。这样你就能按层级查看成本。例如，可以对比在基础层诊所运行 `Ministral 3 8B Instruct` 与在高级层医院运行 `GPT OSS 120B` 的成本差异。

通过结构化用量日志实现按诊所归因：`Bedrock Projects` 每个账户上限为 1,000 个，适合用作应用级边界。为了获得按诊所划分的成本粒度，解决方案会在每次 agent 调用后，将 token 用量以结构化 JSON 的形式记录下来，而租户上下文已经在系统中传递：

`Strands SDK` 会在每次 agent 调用中通过 `AgentResult.metrics` 对象自动跟踪 token 消耗（输入、输出和缓存指标）。将这一点与租户上下文中的 `clinic_id` 结合起来后，每条日志都会把 token 用量归因到具体诊所。这些日志会进入 CloudWatch，并可通过 Logs Insights 查询，以计算每个诊所的用量：

要估算成本，可以将 token 数量乘以各模型公布的按 token 计费价格。

每个层级的限流通过 API Gateway usage plans 进行强制执行。该方案为每个层级分别使用独立的 usage plan，配置如下：

为避免持续产生费用，当你不再需要这些资源时，可以将已部署的资源删除。`scripts/` 文件夹下提供了一个 `cleanup.sh` 辅助脚本，用于帮助清理为该方案创建的资源。

构建多租户 AI 应用，需要仔细关注数据隔离、服务差异化、成本归属以及可扩展性。Amazon Bedrock AgentCore 通过原生平台能力，为满足这些要求提供了稳固基础。这一实现的核心结论是，多租户并不需要复杂的应用层隔离逻辑。通过将 Cognito 等 AWS 服务用于身份认证，使用 S3 前缀实现数据隔离，借助 API Gateway 做限流，利用 Bedrock Projects 和结构化日志进行成本归属，以及使用 Bedrock AgentCore 进行 AI 编排，你可以用极少的自定义代码构建安全、可扩展且具成本效益的多租户 AI 应用。你可以将这些模式应用到正在构建的任何多租户 agentic 应用中。

在 GitHub 上查看完整源代码

了解更多关于 Amazon Bedrock AgentCore

使用 Amazon Bedrock AgentCore 构建多租户智能体