Amazon Bedrock AgentCore 多租户架构：池模型实现租户隔离与成本追踪

一句话看懂

AWS 发布基于 Bedrock AgentCore 的多租户架构方案，用池模型实现租户隔离、服务分层和成本追踪，以医疗 AI 助手为例展示生产级实现。

详细发生了什么

AWS 官方博客发布了一篇关于使用 Amazon Bedrock AgentCore 构建多租户 AI 应用的技术文章。文章以医疗 AI 助手为例，展示了如何实现生产级的多租户系统，支持多个诊所和医院共享同一套 AI 基础设施，同时保证数据隔离和服务差异化。

核心架构采用三层层级：Tier（服务层）→ Tenant（租户）→ User（用户），每一层都通过知识库文档、记忆、模型访问和成本追踪实现隔离。方案使用池模型（Pool Model），即租户共享底层计算资源，通过逻辑隔离机制（如作用域标识、访问策略、数据分区）保证安全。

方案区分两个服务层：Basic 层面向小型诊所，使用 Mistral Ministral 3 8B Instruct 模型，主要提供文档检索；Premium 层面向医院，使用 OpenAI GPT OSS 120B 模型，支持复杂临床分析和网页搜索工具。

关键组件包括：Amazon Cognito 管理认证并携带租户元数据（JWT claims）、API Gateway 做路由和限流、Lambda 提取租户上下文、AgentCore 的 Runtime/Memory/Identity/Gateway/Policy 组件协同工作、S3 按层和租户隔离文档、Bedrock Knowledge Bases 通过元数据过滤实现语义搜索隔离。

中文圈视角

这个架构对国内 SaaS 开发者和 AI 应用构建者很有参考价值，但需要注意几点：

国内替代方案：AWS Bedrock AgentCore 目前在国内无法直接使用，但类似思路可以用在阿里云百炼、百度千帆等平台。这些平台也提供 Agent 框架和知识库，但多租户隔离的成熟度不如 AWS。
池模型 vs 隔离模型：国内很多 AI 应用采用“每租户独立部署”的隔离模型，成本高、管理复杂。池模型通过逻辑隔离降低基础设施成本，但要求平台原生支持租户上下文传递。目前国内平台对 JWT 租户 claims 的支持还不够完善，可能需要自建中间件。
成本归因：AWS 通过 Bedrock project 和 cost allocation tags 实现按租户成本追踪，国内平台（如阿里云）也支持标签分账，但需要开发者主动设计。
模型选择：方案中 Basic 层用 Mistral、Premium 层用 OpenAI，国内可替换为 Qwen 系列（如 Qwen2.5-7B 和 Qwen2.5-72B），同样实现成本与能力的梯度。
合规盲点：医疗场景下数据出境是红线。国内用户若采用类似架构，必须确保知识库和模型推理都在国内节点完成，且租户数据不跨域。

几条值得记住的细节

架构采用三层层级：Tier（服务层）→ Tenant（租户）→ User（用户），每层通过 JWT claims 传递租户上下文。
Basic 层使用 Mistral Ministral 3 8B Instruct，Premium 层使用 OpenAI GPT OSS 120B，模型按层隔离。
池模型下，每个 Agent 会话在隔离的 micro-VM 中执行，实现计算级租户隔离。
成本追踪通过 Bedrock project 和 cost allocation tags 实现，每个租户的资源消耗可独立核算。
示例代码在 GitHub：https://github.com/aws-samples/sample-agentcore-and-multitenancy-blog

一句话总结

多租户 AI 应用不必每户一套基础设施，池模型加逻辑隔离就能兼顾成本和安全，国内平台可借鉴但需适配。