Axonius 在 AWS Bedrock AgentCore 上构建多租户 AI 代理的架构实践

AWS 近日在官方机器学习博客上发布了 Axonius 基于 Amazon Bedrock AgentCore 构建多租户 AI 代理的实践案例。资产管理平台 Axonius 在 AWS 上以 SaaS 形式管理数百个隔离的客户环境，计划在其产品中引入 AI 代理以辅助数据分析与运维，同时必须保持现有的租户隔离与成本管理机制。

多租户 AI 代理的三种部署模式

面向 SaaS 厂商，AWS 总结了三种常见的多租户架构模式：

隔离模式（Silo）：每个租户拥有独立资源，对应到 AgentCore 运行时中即每个租户一个专用代理。
共享模式（Pool）：所有租户共享资源，通过为每个用户会话分配唯一 Session ID 实现隔离。
桥接模式（Bridge）：部分组件隔离部署，部分组件共享，例如专用代理配合共享的 Bedrock Knowledge Bases。

Axonius 面临的核心挑战

Axonius 现有部署采用严格的隔离模式，每个客户运行在独立的 Amazon VPC 中，包含 ALB、NLB、数据库与通用计算资源。在引入 AI 代理时，团队明确了若干关键需求：

租户隔离：代理只能访问所属客户的数据。
身份集成：代理身份流程需复用现有 EC2 上的认证授权模块，避免破坏既有体系。
成本追踪：模型调用是主要成本来源，需要按租户粒度计量。
服务集成：代理需安全访问对应租户工作负载的 API。
生命周期管理：代理的发布需并入现有的持续交付流程。
可观测性：在大规模代理集群下，需要支持告警与链路追踪的可观测方案。

候选方案对比

Axonius 评估了两种可行方案。

方案一：Pool 模式 + JWT 路由。AgentCore 运行时为每个会话分配独立 microVM，单一运行时服务多租户，由应用层通过 JWT 中的租户声明实现数据路由。优势是运维简单、新客户接入快；缺点是租户隔离完全依赖应用代码，定制化能力受限。
方案二：Bridge 模式 + 网关隔离。结合共享运行时的运维便利与基础设施层的工具隔离能力，介于完全隔离与完全共享之间。

选型与价值

综合隔离强度、运维成本与扩展性，Axonius 最终选择桥接模式，在保留每租户专用代理的同时复用共享的模型与知识库能力。该实践为同样需要在 SaaS 架构中安全落地 AI 代理的 ISV 提供了一套可参考的范式。