共享基础设施，隔离租户：使用 Amazon Bedrock AgentCore 实现池模型多租户

构建多租户 AI 应用面临新的架构挑战。您需要在客户之间实现完全的租户隔离，提供不同功能的服务层级，进行细粒度的成本追踪，并确保每个租户的可观测性。缺少这些，可能会暴露客户数据、无法提供适当的服务质量或产生不可预见的成本。

在本文中，您将学习使用 Amazon Bedrock AgentCore 实现生产级多租户系统的模式。这些模式将通过服务多个诊所和医院的医疗 AI 助手来展示。虽然本文以医疗领域为例，但架构模式和实施技术广泛适用于各种多租户 AI 应用。无论您是在构建 SaaS 平台、服务多个业务部门的企业解决方案，还是为不同客户组织提供托管服务，都可以使用这些架构模式来构建您的解决方案。

您将学习的内容包括：如何利用原生 AWS 能力在智能体应用中实现完整的租户隔离；如何通过最小化自定义代码实现服务层级差异化；每个租户的精细成本归属技术；以及可扩展多租户 AI 架构的最佳实践。

本文是系列文章“使用 Amazon Bedrock AgentCore 构建多租户智能体”的第二部分。第一部分探讨了架构多租户智能体应用的设计考虑因素，以及应对 Amazon Bedrock AgentCore 的 SaaS 架构挑战所需的框架。

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

解决方案概述

该解决方案演示了如何利用 Amazon Bedrock AgentCore 的原生能力，通过 AWS 托管服务实现完整的租户隔离。架构实现了三级层次结构：层级 → 租户 → 用户，并通过知识库中的文档、记忆、模型访问和成本追踪在每个层级实施隔离。层级策略是 SaaS 应用中的常见模式，租户根据其需求（如基础版和高级版）、使用模式或定价计划被分组到不同的服务层级。每个层级定义了一组功能和可用服务质量，使 SaaS 提供商能够以差异化的体验服务多样化的客户群，同时保持运营效率。

医疗 AI 助手示例

为了展示实际应用，示例解决方案实现了两个服务层级：

基础版：面向小型诊所，主要需要简单的文档搜索和检索。由于这些任务适合较小且成本效益高的模型，该层级使用 Mistral Ministral 3 8B Instruct，在保持低成本的同时为简单查询提供准确结果。

高级版：面向需要复杂临床分析的医院和专科中心。该层级使用 OpenAI GPT OSS 120B，具有高级推理能力以实现准确的工具选择，包括仅对高级版客户可用的网络搜索工具。

在每个层级内，解决方案使用池隔离模型，即租户共享相同的基础设施和计算资源，而不是每个租户拥有专用的隔离资源。池模型最大化资源利用并简化操作，同时通过逻辑分离机制（如作用域标识符、访问策略和数据分区）实施租户隔离。将层级策略与池模型相结合，可以在成本效率和提供差异化服务级别之间取得平衡。

架构

以下是如何利用 AgentCore 的原生能力解决这些多租户挑战。架构图展示了请求如何从经过身份验证的用户流经特定层级的智能体到达隔离的文档存储。

该解决方案包括以下关键组件：

• Amazon Cognito：管理用户身份验证，并将租户元数据（层级、诊所 ID、角色）存储在 JWT 声明中。这些声明被提取并作为租户上下文通过请求负载传播，使每个下游组件能够将其操作范围限定到正确的租户。
• Amazon API Gateway：路由请求并通过使用计划实施基于层级的速率限制。
• AWS Lambda：提取租户上下文并调用对应的 Amazon Bedrock AgentCore 智能体。
• AgentCore 组件：运行时（智能体执行）、记忆（对话状态）、身份（智能体身份管理）、网关（工具服务器）和策略（智能体操作边界）。
• Amazon S3：在按层级分隔的存储桶中存储临床文档，并使用分层前缀结构实现租户隔离。
• Amazon Bedrock Knowledge Bases：提供语义搜索，并通过元数据过滤将查询范围限定到请求租户的文档。
• Amazon Bedrock project：通过成本分配标签实现每个层级的成本追踪。

解决方案详解

本节描述解决方案的关键方面。您需要运行部署脚本来设置基础设施和应用程序。本文中的代码片段仅用于描述架构关键方面如何被解决方案组件处理，无需运行任何命令。

Amazon Bedrock AgentCore 组件

架构利用六个核心 Bedrock AgentCore 能力实现多租户：

AgentCore Runtime：为解决方案中的智能体提供计算，每个智能体会话在隔离的微虚拟机中执行，实现租户级计算隔离。每个层级托管独立的智能体实例，配置适合该层级的模型和能力。

AgentCore Identity：通过统一的基于 JWT 的身份验证模型保护多租户架构。Cognito ID 令牌在运行时和网关边界验证用户，而工具 Lambda 为下游数据访问生成自己的作用域凭证。

AgentCore Memory：会话历史不能在租户之间或同一租户的不同用户之间泄露。解决方案在应用层和基于 IAM 的属性访问控制（ABAC）层实施记忆隔离。应用层使用复合 actor_id 的分层命名空间结构组织每个租户的对话数据。

AgentCore Gateway：通过模型上下文协议（MCP）将静态 Lambda 函数转换为动态、上下文感知的智能体工具。MCP 是连接 AI 智能体到外部工具的开源标准。

每个运行时配置了入站 JWT 授权器，在智能体代码执行前验证 Cognito ID 令牌。ID 令牌携带租户元数据作为自定义声明，例如 sub（用户唯一标识符）、iss（令牌颁发者）、aud（Web 客户端 ID）、token_use（令牌类型）、cognito:username（登录用户名，用于记忆隔离）、custom:tier（层级）、custom:clinic_id（租户 ID）和 custom:role（角色）。

网关也配置了 JWT 授权，使用相同的 Cognito 发现 URL 和受众。当智能体调用网关时，它将用户的原始 JWT 作为 Bearer 令牌转发，并附上租户上下文头。网关验证令牌后，将租户头传播到目标 Lambda。

目标 Lambda 从不直接接收或处理用户的 JWT。相反，它读取受信任的租户头，并假设一个 TVM（令牌自动售货机）角色，其会话标签源自这些头。TVM 角色的 ABAC 策略使用 dynamodb:LeadingKeys 条件限制 DynamoDB 访问，确保每个租户只能在 IAM 级别查询自己的诊所数据，而不仅仅是应用层过滤。

电视机制：运行时，智能体假设一个 TVM 角色，其 Tier、ClinicId 和 UserId 作为会话标签，接收限定到该租户命名空间的临时凭证。TVM 角色的信任策略确保只有智能体执行角色可以假设它，并且所有三个会话标签都存在。

通过这种组合，解决方案在不牺牲安全性的前提下实现了池模型多租户的灵活性和效率。