使用Amazon Bedrock AgentCore构建多租户代理

软件即服务（SaaS）提供商在构建多租户代理应用时，需要解决超出典型安全、治理和响应准确性之外的架构挑战。这些挑战包括租户隔离、身份识别、可观测性、数据隔离、成本归因和噪声邻居缓解。从可行演示到生产部署的过渡需要为多租户环境构建基础设施。Amazon Bedrock AgentCore 是一项托管的无服务器服务，用于在 AWS 上构建、部署和安全运行代理应用。它提供了部署代理和托管 MCP 服务器的构建模块，并内置了身份管理、内存、可观测性和评估功能，所有设计均旨在简化多租户代理架构的构建。

本文是博客系列的第一部分，探讨了构建多租户代理应用的设计考量，并介绍了如何利用 Amazon Bedrock AgentCore 解决 SaaS 架构挑战的框架。

构建多租户代理的设计考虑因素

构建具有强隔离性的安全多租户代理应用需要在关键组件中做出谨慎的架构决策，如图 1 所示。每个组件必须在租户隔离、运营效率和成本优化之间取得平衡，同时满足安全性和合规性标准。这些设计考量围绕三种租户隔离模式展开：Silo、Pool 和 Bridge，分层策略是选择这些模式时的关键考虑因素。

_图1：多租户代理的设计考虑因素_

在以下部分，我们将详细说明多租户如何影响这些组件。

1. 代理运行时部署：专用与共享

多租户代理架构的关键决策之一是代理运行时相对于租户的部署方式。专用运行时为每个租户实例化独立的执行环境，包括各自的容器镜像、进程空间和生命周期。这种 Silo 模式提供了最强的噪声邻居保护，并简化了合规性审计。共享运行时将所有租户的代理托管在同一容器镜像和进程池中，降低了基础设施成本和运营开销，但需要严格的进程内租户上下文传播。

Amazon Bedrock AgentCore 运行时通过基于会话隔离的微虚拟机（microVM）计算解决了这一矛盾。AgentCore 运行时按会话启动轻量级 microVM，无需为每个租户启动完整虚拟机带来的成本和延迟。每个会话携带其自身的持久化文件系统，代理可以在会话范围内读写文件、维护中间计算工件，并在多步骤交互中保留状态，从而降低跨会话数据泄露的风险。这种架构非常适合托管多租户 MCP 服务器、代理和 AG-UI 服务器。

租户上下文通过自定义 HTTP 标头流入隔离的执行环境。当 SaaS 平台将请求转发到 AgentCore 运行时会话时，会附加携带租户特定元数据的标头，例如租户标识符、层级、区域偏好、功能标志或权限，同时包含标准授权令牌。代理在调用时读取这些标头以建立完整的租户感知能力，从而能够运行针对该租户业务逻辑优化的工作流、仅调用已授权的工具，并调用特定于租户的 API 终端节点，而无需硬编码路由逻辑。

2. 共享与层级特定与精细调整模型

共享基础模型（FMs）是大多数多租户部署的推荐起点，通过单模型维护实现精简的运营。租户通常可以受益于无需逐租户定制的自动模型更新。根据租户层级选择模型（层级特定模型）提供了灵活性，可在不同层级的租户之间平衡成本、性能和准确性。针对需要特定术语、监管合规或性能 SLA 的专用用例，租户特定精细调整模型变得必要，尽管它们会引入更高的运营复杂性和逐租户管道。混合方法——为标准层级使用能力较弱的模型，为高端企业客户使用精细调整或更强大的模型——可以在成本效益与定制需求之间取得平衡。

Amazon Bedrock 提供了领先供应商的多种大型语言模型（LLMs），允许 SaaS 提供商根据租户和层级需求选择合适模型。Amazon Bedrock 的模型微调支持使用自有标记数据集定制 FMs，以提升特定领域任务的性能。借助 Amazon Bedrock 自定义模型导入功能，您可以将自有微调模型导入，并通过 Amazon Bedrock 的托管基础设施进行部署。

3. 工作流：Silo、Pool 和 Bridge 模式

多租户代理应用需要灵活的工作流管理，每个代理可根据租户需求和业务逻辑执行不同的步骤序列。工作流可通过多种机制实现：作为封装分步流程的 MCP 工具、定义业务逻辑流的 API 终端节点，或嵌入领域特定工作流模式的代理技能。

4. 多租户RAG

检索增强生成（RAG）系统需要针对数据隔离做出决策。隔离模式为每个租户提供专用的向量数据库，提供最高安全性及完全的数据隔离。此模式推荐用于受监管行业及需要专用基础设施的企业客户。池化模式使用共享向量数据库，通过元数据过滤和命名空间访问控制实现成本效益的运营，适用于为大量中小型租户提供服务的SaaS平台。检索操作应包含自动租户过滤注入和结果净化，以防止跨租户数据泄露。

Amazon Bedrock知识库提供完全托管的RAG能力，将大模型连接至您的数据源，自动处理数据摄入、分块、嵌入生成及向量存储。它支持多种向量数据库，并允许创建隔离的或共享的向量数据库（通过元数据过滤）。

如需详细了解如何使用Amazon Bedrock知识库实现多租户RAG架构，请参阅多租户RAG与Amazon Bedrock知识库（涵盖隔离、池化和桥梁部署模式），以及通过元数据过滤在单一Amazon Bedrock知识库中实现RAG应用的多租户（共享知识库中基于元数据的租户隔离）。

5. 租户上下文、代理代表模式及令牌传播

多租户身份管理需要在整个服务链中谨慎处理租户上下文。代表用户身份和请求特定状态的租户上下文，必须通过所有架构层以可靠且安全的机制传递。与执行路径可预测的确定性软件API不同，AI代理具有非确定性且可能具备自治性，导致安全考量存在本质差异。流氓或被入侵的代理可能对下游服务发起未经授权的调用，引发凭证窃取、权限提升及Confused Deputy问题。当代理以完整用户凭证（即冒充模式）运行时，单一被入侵代理将获得跨所有下游系统的完全访问权限。这一风险随着代理的自主性增强而加剧，尤其当代理独立决策调用工具、调用时机及参数时。代理代表模式至关重要，因为它明确区分用户与代理，代理以用户名义发起调用时使用显式限定作用域的权限。

通过JSON Web Tokens（JWT）编码租户上下文，需涵盖三个维度：安全上下文（标准声明：iss、sub、exp、aud）、租户上下文（tenant_id及租户特定作用域）、请求上下文（业务逻辑相关的领域特定属性）。这种编码方式为多租户操作提供了强大且灵活的基础。

需在两种模式间选择，其安全影响截然不同：

• 冒充模式允许代理以完整用户身份和权限运行，实现简单但违反最小权限原则并带来安全风险。
• 代理代表模式（委托）是推荐方案，通过真实委托实现：在每个服务边界转换令牌，使用作用域限定的凭证，并通过OAuth 2.0 RFC 8693定义的act声明标识代理。使用AgentCore Identity的On-behalf-of令牌交换功能，允许代理及MCP服务器等其他工作负载，将传入的用户访问令牌交换为针对下游资源服务器的新作用域访问令牌。由于该交换直接将面向某一受众的令牌转换为面向另一下游受众的令牌，代理可代表已认证用户访问受保护资源，无需触发额外的同意流程。交换后的令牌同时携带代理自身身份和原始调用者的身份，使资源服务器能在每一步执行细粒度零信任授权。

6. MCP工具与API的细粒度访问控制

7. 内存：分层命名空间隔离

多租户内存管理需要精心的架构设计，以确保代理能够维护上下文和学习信息，同时防止跨租户数据泄露。内存系统应实现五个逻辑层级：

• 全局（跨租户共享知识）
• 策略（特定代理类型的模式和行为）
• 租户（租户范围内的对话历史和偏好）
• 用户（租户内单个用户的上下文）
• 会话（活跃对话的临时短期记忆）

访问控制通过基于属性的策略验证主体身份与请求的命名空间路径，确保代理只能在其授权范围内读写内存。池化模式通过基于分层命名空间的逻辑隔离使用共享基础设施，实现运维和成本效率，将所有租户数据存储在通用数据存储中，并基于命名空间前缀进行严格过滤。隔离模式为每个租户部署专用内存存储以实现最大隔离，通过增加运维成本降低跨租户访问风险。实现涉及从租户和用户信息构造复合标识符（例如tenant_123:user_456），使用携带租户上下文声明或标签的受限凭证进行认证，并在所有内存操作前添加适当的命名空间路径前缀。

AgentCore Memory在全局、策略、租户、用户和会话层级提供分层命名空间隔离，支持结合短期对话记忆和跨会话持久化长期记忆的上下文感知代理体验。它支持基于资源的策略和基于属性的访问控制，实现细粒度访问控制。

8. 代理身份、信任与发现

当代理应用跨组织边界与其他代理交互时，三个基础问题会浮现：代理身份、代理信任和代理发现。虽然相关但各自解决不同问题。

代理身份回答 _“这是哪个代理？它能证明身份吗？”_ ——建立与组织绑定的可验证唯一身份。

代理信任回答 _“我应该信任这个代理吗？”_ ——基于多种信号而非单一凭证评估可信度。

代理发现回答 _“如何找到正确的代理？”_ ——无需预先了解端点即可通过能力或隶属关系定位代理。

#### AgentCore Identity实现代理身份

Amazon Bedrock AgentCore Identity将代理身份实现为工作负载身份，这是云原生安全中成熟的模式。每个代理获得基于加密的可验证身份，其锚定于组织的AWS账户和IAM基础设施。代理可通过OAuth 2.0流代表用户安全访问AWS资源和第三方工具，并与现有企业身份提供商（如Okta、Microsoft Entra ID、Amazon Cognito）集成，无需迁移用户账户。

#### 代理信任

使用 AgentCore 实现 Silo 模型

如以下图所示，_Silo 模型_允许每个租户在完全隔离的堆栈中运行，配备专属于自己的 Bedrock AgentCore 运行时、Bedrock AgentCore 网关和 Bedrock AgentCore 内存，所有组件均通过独立的 AWS IAM 边界进行范围限定。支持多种类型的内存（如长期、短期和情景记忆），需根据租户需求进行配置。

**关键架构组件**

• 隔离的代理层 – 每个租户专属的 AgentCore 运行时，通过独立的 IAM 执行角色实现租户级权限隔离。
• 隔离的网关 – 专属的 AgentCore 网关，用于通过 MCP 协调工具，其对数据层的访问权限由执行角色限定。
• 隔离的代理内存 – 专属的 AgentCore 内存，通过层级命名空间隔离实现租户数据隔离，无需在每个命名空间路径中显式包含租户 ID。代理通过运行时 IAM 执行角色访问特定租户的内存。
• 隔离的数据层 – 专属的工具、知识库、数据库和后端资源，确保最高级别的数据隔离。

**请求流程**

1. 身份验证 – 用户通过身份提供商进行认证，获取包含租户上下文（租户 ID 和订阅层级）的 JWT 令牌。
2. SaaS 应用程序代理路由 – SaaS 应用程序代理根据租户上下文决定调用哪个代理。这需要预先配置租户与代理部署的映射关系，通常由 SaaS 控制平面管理。该代理将应用程序级请求转换为 AgentCore 运行时 API 调用（InvokeAgent），并附加租户的 JWT 令牌。
3. 代理执行 – AgentCore 运行时通过 AgentCore Identity 验证 JWT，创建隔离的微虚拟机（microVM）会话并启动代理推理。此外，它会通过 AgentCore Identity 的 JWT 授权器中的自定义声明，验证租户 ID 是否被授权调用该代理（例如“仅允许租户 A 调用”）。代理通过运行时 IAM 执行角色访问特定租户的 AgentCore 内存。
4. 通过 AgentCore 网关访问工具 – 当代理需要调用工具时，会调用 _专属的 AgentCore 网关_，该网关仅限于访问特定租户的 MCP 工具。网关执行以下操作：
5. 使用 AgentCore Identity 验证 JWT 令牌。
6. 从验证后的令牌中提取租户上下文，并通过自定义拦截器验证网关是否与当前上下文中的租户映射关联。
7. 集成隔离的租户专属后端资源（API、数据库、知识库）。

1. 响应流程 – 工具响应通过网关回传给代理，完成其推理过程。隔离式代理在返回给SaaS应用代理前，会应用租户特定的格式化处理。代理将响应返回给用户。

Silo模式设计使得每个客户的代理会话、工具访问和内存完全隔离，且成本可直接归因于触发工作的告警客户。其权衡在于更高的运维开销，因为每个客户需运行专用资源而非资源共享。但在安全关键和合规敏感的工作流中，有限的影响范围使其成为正确选择。

图2：带有AgentCore的隔离模型

使用AgentCore实现池化模型

如图所示，池化模型允许跨多个租户共享资源，因此可以设计最大化资源利用率并提升运维效率的架构。

**核心架构组件**

• 共享代理层 – 跨多租户共享的AgentCore运行时和代理逻辑。
• 共享网关 – 基于MCP工具编排的中心化AgentCore网关。
• 共享代理内存 – 根据租户上下文分片的AgentCore内存。
• 共享数据层 – 共享的工具、知识库、数据库和后端资源。
• 共享身份管理 – 基于JWT的租户上下文传播共享身份提供商。

**请求流程**

1. 认证 – 用户通过身份提供商认证，获取包含租户上下文（租户ID和订阅层级）的JWT令牌。
2. SaaS应用代理路由 – SaaS应用作为中间层，将携带租户上下文的输入请求路由到池化AgentCore运行时中的代理。应用代理将应用级请求转换为AgentCore运行时API调用（InvokeAgent），并附加租户JWT令牌。
3. 代理执行 – AgentCore运行时通过AgentCore Identity验证JWT，创建隔离的微虚拟机（microVM）会话，从JWT中提取租户上下文并启动代理推理。代理通过命名空间分片机制（例如actor_id:“tenant-a:user-123”）访问租户范围的AgentCore内存。
4. 通过AgentCore网关调用工具 – 当代理需要调用工具时，会调用共享AgentCore网关，该网关专为MCP工具编排设计而非通用路由。网关执行以下操作：
5. 通过AgentCore Identity验证JWT。
6. 从验证后的令牌中提取租户上下文。
7. 将工具调用路由到共享的后端资源（API、数据库、知识库）。
8. 通过租户范围凭证和配置实施工具级隔离。
9. 应用策略执行和拦截器处理横切关注点。

1. 响应流程 – 工具响应通过网关回传给代理，完成推理后，代理响应通过运行时返回给卖家代理。卖家代理应用租户特定格式化处理后返回给用户。

池化模型高度高效，当存在大量小型租户时可能是唯一选择。其权衡在于需要更严格的细粒度访问控制测试，以及更多监控工具来归因租户成本。

图3：带有AgentCore的池化模型

使用AgentCore实现桥梁模型

桥梁模型（混合模型） 是隔离与池化部署模式的战略中间路线。该方案结合了共享基础设施的成本效益与隔离数据资源的安全优势。

根据需求可以选择多种实现方式：

1. 高级订阅层租户使用隔离的AgentCore运行时/网关/工具/内存，标准层租户使用共享资源
2. 隔离运行时搭配共享网关/工具和内存
3. 其他组合方式

核心思想是能够在各层级组件中自由选择隔离策略，而非绑定特定租户隔离模式。例如在安全运营中心分析师用例中，网关可隔离以处理邮件API交互和下游资源，而共享代理运行时托管代理并执行推理——每个调查在独立隔离的微虚拟机中运行。

图4：带有AgentCore的桥梁模型（变体1）

图5：带有AgentCore的桥梁模型（变体2）

What’s next

在本文中，我们探讨了构建多租户代理的基础概念。在后续文章中，我们将深入探讨这些概念的实现细节。具体来说，我们将通过一个端到端的完整实现，演示池化部署模型和隔离部署模型的构建过程，并整合设计考量章节中提到的各项组件。

Conclusion

构建生产级多租户智能代理应用不仅需要功能完备的AI代理，还需要一套全面的架构方案，在每一层解决租户隔离、身份管理、成本归因和安全性问题。Amazon Bedrock AgentCore提供了应对这些挑战的基础构建模块，其通过隔离、池化和桥梁三种可定制的部署模式，能够适配您的分级策略和合规要求。无论您是需要为大型企业提供专用基础设施，还是希望优化数百个小租户的成本，都可以借助AgentCore集成的运行时、网关、记忆、身份和可观测性组件，无需重复造轮子即可构建安全可扩展的多租户智能工作流。这些基础模块协同工作，能够维护租户数据隔离、限定工具访问权限、精准归因成本并建立安全边界，将多租户代理架构的复杂性转化为可管理、可扩展的生产就绪解决方案，与您的SaaS业务共同成长。

我们建议读者通过多租户代理工作坊动手实践使用Amazon Bedrock AgentCore构建多租户代理。

• * *

About the authors