多租户 AI Agent 平台架构设计与实践

摘要

随着大语言模型技术的成熟，AI 应用的需求正从"功能验证"转向"规模化落地"。在这一进程中，多租户架构成为不可回避的核心挑战------如何在保障数据隔离、资源公平与成本可控的前提下，让多个业务部门或外部客户安全、高效地共享同一套 AI 基础设施？

本文提出了一套涵盖 AI 网关、Agent 编排、RAG 检索、人工干预、可观测性等模块的完整架构方案。方案引入多租户语义缓存以平衡成本与安全，设计了 Supervisor / Peer-to-Peer / 层次化拓扑三种多 Agent 协作模型，并通过 GPU 资源池化与熔断隔离机制，将单租户故障控制在最小范围。

1. 架构全景图

整个系统划分为四个逻辑平面 和一个纵向支撑体系，这是云原生架构在 AI 应用领域的典型实践：

graph TB subgraph ControlPlane["🛡️ 控制面 - 策略与运营"] direction LR Admin["多租户管理后台
策略配置 / 配额 / 计费"] Billing["计费服务
消费Kafka Token记录"] Eval["效果评估
用户反馈 / 回归测试"] end subgraph DataPlane["⚡ 数据面 - 请求处理主链路"] direction TB subgraph UserLayer["🌐 用户接入层"] Web["Web App (Vue/React)"] Mobile["Mobile (Flutter)"] end subgraph GatewayLayer["🔐 AI 网关层"] Auth["身份认证
JWT + Tenant_ID"] GW["AI网关数据面
路由 / 语义缓存"] Safety["内容审核"] RL["分布式限流"] CB["熔断控制器"] end subgraph AppLayer["🧠 应用逻辑层"] Agent["Agent 编排引擎
Supervisor / P2P / 层次化"] Approval["审批工作流 HITL"] RAG["RAG 检索服务"] Tools["工具集成 MCP"] end subgraph DataLayer["🗄️ 数据与存储层"] VectorDB["向量数据库"] RelDB["业务数据库"] Cache["Redis 缓存"] ObjStore["对象存储"] end subgraph ModelLayer["🤖 模型服务层"] ExtLLM["外部模型 API"] SelfHost["自建推理集群
GPU 隔离节点 / Spot 池"] MCPSvr["MCP 服务器群"] end UserLayer --> Auth Auth --> GW GW --> Safety GW --> RL GW --> CB CB --> Agent Agent --> Approval Agent --> RAG Agent --> Tools Agent --> DataLayer Agent --> ModelLayer end subgraph AsyncPlane["⏳ 异步处理管道"] MsgQueue["消息队列 Kafka"] DocWorker["文档摄入 Worker"] end subgraph Observability["📊 可观测性"] Tracing["链路追踪"] Monitoring["指标监控"] Logging["日志中心"] Cost["成本看板"] end DataPlane --> MsgQueue MsgQueue --> DocWorker MsgQueue --> Billing MsgQueue --> Eval DataPlane -.-> Observability AsyncPlane -.-> Observability ControlPlane -.-> Admin

表1: 四大平面职责一览

平面	核心职责	比喻
控制面	策略配置、计费运营、效果评估	"大脑"：决定系统如何运行
数据面	请求处理主链路，从用户接入到模型响应	"躯干"：执行每一次 AI 调用
异步管道	耗时任务解耦、事件驱动处理	"消化系统"：后台消化重活
可观测性	全链路追踪、指标监控、日志、成本	"神经系统"：感知运行状态

2. AI 网关层：多租户的第一道防线

AI 网关是整个架构的安全中枢。所有请求必须依次通过身份认证 → 内容审核 → 限流控制 → 熔断保护四道关卡，才能进入下游服务。

flowchart LR Request["用户请求"] --> Auth["① 身份认证
JWT 验证 + 注入 Tenant_ID"] Auth --> Safety["② 内容安全审核
租户级敏感词 / 脱敏"] Safety --> RL["③ 分布式限流
Redis 滑动窗口
租户级 TPM / RPM"] RL --> CB["④ 熔断控制器
Step Count 循环检测"] CB --> Agent["放行至 Agent 引擎"] CB -.-> |"超阈值中断"| Alert["告警 / 转入审批流"]

2.1 身份认证：OAuth2 + JWT

选择 JWT 的核心考量在于其自包含特性------网关无需查询数据库即可验证真伪并解出租户 ID，高并发下性能优势显著。

工作流程：

用户登录后，授权服务器签发 JWT，其 Payload 中包含：

json 复制代码

{
  "sub": "user_123",
  "tenant_id": "tenant_A",
  "roles": ["agent_user"],
  "exp": 1718250000
}

后续所有 API 请求在 Header 中携带 Authorization: Bearer <JWT>。
AI 网关验证签名和过期时间后，将 X-Tenant-ID 注入请求头，全链路透传给下游所有服务。

🔑 关键设计：上下文透传构成租户隔离的第一道防线。若此环节失效------租户 ID 未注入或注入错误------下游所有隔离措施将失去锚点。

2.2 内容安全审核：租户级差异化策略

不同客户对内容的容忍度存在显著差异。如金融行业租户需要严格过滤投资建议类内容，制造业租户更关注工艺参数与物料信息的防泄露。

实现方式：

审核策略存储在 PostgreSQL 的租户配置表中。
网关的审核模块启动时加载一次，之后定期轮询或监听变更。
修改策略后无需重启服务即可实时生效，实现配置热更新。

2.3 分布式限流：Redis 滑动窗口

网关采用多实例部署的架构下，仅靠各实例内存计数无法准确统计全局流量------实例 A 放行 100 个请求、实例 B 放行 80 个，总和可能已超过租户配额。

Redis 滑动窗口原理：

sequenceDiagram participant GW as 网关实例 participant Redis as Redis (Sorted Set) GW->>Redis: 执行 Lua 脚本 Note over Redis: ① 清理过期记录
(Score < now-60s 的成员) Note over Redis: ② 添加新记录
(Score=当前时间戳) Note over Redis: ③ 统计窗口内记录数 Redis-->>GW: 返回计数结果 alt 计数 > 限额 GW-->>Client: 429 Too Many Requests else 计数 ≤ 限额 GW-->>Client: 放行 end

采用 Lua 脚本实现原子化操作："清理过期记录 → 添加新记录 → 统计窗口内数量"三步合并执行，避免高并发下的竞态条件导致计数偏差。

2.4 熔断控制器：Agent 安全气囊

大模型幻觉可能导致 Agent 陷入循环调用------针对同一子问题反复请求工具却无任何实质进展。

核心机制：

网关监控每个请求的 Step Count（推理步数/工具调用轮次）。
当 Agent 循环调用工具超过阈值（默认 5 次）时，强制中断请求。
中断后可选择直接返回错误，或自动转入人工审批流程。

阈值按租户差异化：

数据分析类工具：阈值设高（10 次），为模型提供充分试错空间。
删除数据/发布代码等高危操作：阈值设低（2 次），倾向于保守中断。

2.5 语义缓存：降本增效的平衡术

为降低 LLM 重复调用成本，架构在网关层引入基于 Redis + Embedding 的语义缓存。在多租户环境下，缓存策略分为两级：

租户私有缓存 ：默认策略。缓存 Key 包含 Tenant_ID，对相似度超过阈值（Cosine Similarity > 0.98）的查询直接返回历史结果，确保敏感业务数据的绝对隔离。

全局公共缓存 ：针对通用知识（如"如何导出 PDF"），跨租户共享缓存。通过在 Embedding 向量中附加 Visibility: Global 标签实现。命中公共缓存后，响应结果需经过内容安全模块二次校验，防止通用答案在特定租户上下文中产生合规风险。

flowchart LR Query["用户查询"] --> Embed["向量化"] Embed --> PrivateCheck["检索私有缓存
Key: tenant_id:hash"] PrivateCheck --> |"命中"| Return1["直接返回"] PrivateCheck --> |"未命中"| GlobalCheck["检索公共缓存
Visibility: Global"] GlobalCheck --> |"命中"| SafetyCheck["内容安全二次校验"] SafetyCheck --> Return2["返回"] GlobalCheck --> |"未命中"| LLM["调用 LLM"] LLM --> CacheWrite["结果写入缓存"]

3. 应用逻辑层：Agent 编排与人工干预

3.1 编排引擎：从单兵作战到多 Agent 协同

架构基于 LangGraph 实现状态图编排，支持三种多 Agent 协作拓扑：

Supervisor 模型：由一个主 Agent 接收请求，根据租户权限配置将子任务分发给对应的专家 Agent（如 SQL 分析专家、文档处理专家）。这是生产环境中最常用的模式，便于集中管控和审计。

Peer-to-Peer 模型：利用 AutoGen 实现 Agent 间的对等对话协作。例如，一个 Agent 负责生成代码，租户配置的"质检 Agent"同步审计，发现问题后直接发起修正对话。

层次化拓扑：在大规模企业应用中，根据部门（Sub-tenant）划分 Agent 组，形成树状结构。子部门的 Agent 先在本组范围内求解，无法解决时逐级上溯到父级 Agent 组，层层递归处理复杂问题。

flowchart TB subgraph SupervisorPattern["Supervisor 模型"] S_Super["Supervisor Agent"] --> S_Expert1["SQL 专家"] S_Super --> S_Expert2["文档专家"] S_Super --> S_Expert3["代码专家"] end subgraph P2PPattern["Peer-to-Peer 模型"] P_Agent1["代码生成 Agent"] <--> |"对话协作"| P_Agent2["质检 Agent"] end subgraph Hierarchical["层次化拓扑"] H_Root["根 Agent 组"] --> H_Dept1["部门A Agent 组"] H_Root --> H_Dept2["部门B Agent 组"] H_Dept1 --> H_Sub1["子部门 Agent"] end

3.2 审批工作流：人机协同的最后一关

触发条件（按租户可配置）：

删除数据、修改生产配置
执行付费操作、发布代码上线
调用超过一定金额的模型推理

步骤	动作	技术实现
① 挂起	Agent 在执行高危工具前暂停，上下文存入 Redis	`SET approval:{task_id} {context} EX 3600`
② 通知	通过 WebSocket 向用户推送审批卡片	含操作类型、参数、风险等级
③ 等待	用户审查后点击"允许"或"拒绝"	前端调审批回调 API
④ 执行	审批结果返回 Agent，继续或终止任务	Redis 读取上下文恢复执行
⑤ 审计	审批记录写入 PostgreSQL	谁、何时、批准/拒绝了什么

3.3 RAG 检索：架构级数据隔离

RAG 服务最核心的安全设计是强制注入租户过滤。无论 Agent 传入什么查询条件，RAG 服务层都会在向量数据库的检索请求中附加：

python 复制代码

filter = {"tenant_id": "${TENANT_ID}"}

这一设计形成独立于应用代码的安全屏障------即使 Agent 存在逻辑漏洞，数据边界也不会被突破。存储层的多租户隔离是系统的合规底线，需构建防穿透的数据围栏。

4. 数据与存储层：多重隔离策略

存储层是租户隔离最容易出现短板的环节。本方案为每种存储类型都设计了明确的隔离机制：

flowchart LR subgraph StorageIsolation["存储层隔离策略"] VectorDB_ISO["向量数据库
Partition + Metadata Filter
双重保障"] RelDB_ISO["业务数据库
PostgreSQL RLS
数据库级强隔离"] Cache_ISO["Redis 缓存
Key 前缀隔离
tenant_id:module:hash"] ObjStore_ISO["对象存储
目录路径隔离
bucket/tenant_id/"] end

表2: 存储隔离策略对比

存储类型	隔离策略	安全性	实现复杂度
向量数据库	Partition + Metadata Filter	⭐⭐⭐⭐⭐	中
业务数据库	Row-Level Security (RLS)	⭐⭐⭐⭐⭐	低（PG 原生支持）
Redis 缓存	Key 前缀隔离	⭐⭐⭐⭐	极低
对象存储	目录路径隔离 + IAM	⭐⭐⭐⭐	极低
图数据库	子图 / 数据库级隔离	⭐⭐⭐⭐	低

向量库采用双重保障的设计考量：Partition 提供物理隔离，Metadata Filter 提供逻辑隔离兜底。即使运维操作将两个租户数据误写入同一 Partition，查询时 Metadata Filter 仍能起到隔离作用。

5. 模型服务层与资源调度

flowchart LR Agent["Agent 引擎"] --> GW["AI 网关
模型路由"] GW --> |"通用任务"| ExtAPI["外部 API
GPT / Claude / DeepSeek
租户级 Key 映射"] GW --> |"涉密任务"| Self["自建推理集群
vLLM + KServe"] Self --> GPU_Isolated["核心租户
专用 GPU 节点
NodeSelector 隔离"] Self --> GPU_Spot["普通租户
共享 Spot 实例池"]

5.1 资源隔离与"爆炸半径"控制

GPU 资源昂贵且稀缺，多租户场景下必须解决资源争抢与故障隔离两个核心问题。

GPU 资源池化：针对核心租户，利用 Kubernetes 的 NodeSelector 将流量调度至专用 GPU 节点，提供确定性算力保障。普通租户共享 Spot 实例池，通过优先级调度实现弹性伸缩，在波谷时自动缩容以节省成本。

熔断保护与爆炸半径控制：当 A 租户的 Agent 因 Bug 产生无限循环时，熔断控制器不仅中断当前请求，还会触发隔离策略------临时限制该租户的并发数。此举防止单个租户的异常流量耗尽外部 API 配额或 GPU 显存，将故障影响控制在最小范围，保护系统整体可用性。

sequenceDiagram participant Agent as Agent (租户A) participant CB as 熔断控制器 participant Quota as 配额管理器 participant Pool as GPU 资源池 Agent->>CB: 连续 5 次循环调用 CB->>CB: 触发熔断 CB->>Agent: 中断请求,返回错误 CB->>Quota: 触发隔离策略 Quota->>Pool: 临时降低租户A并发配额 Note over Pool: 租户B/C 不受影响
爆炸半径被控制

6. 异步管道：Kafka 事件驱动架构

核心设计原则：主推断链路采用异步非阻塞设计，将计算密集型与 I/O 密集型后处理任务离线化。

表3: Kafka Topic 定义

Topic	生产者	消费者	数据示例
`token.billing`	AI 网关	计费服务	`{tenant_id, model, 1500 tokens, ts}`
`doc.ingestion`	上传 API	文档 Worker	`{tenant_id, file_path, file_type}`
`user.feedback`	应用层	评估服务	`{tenant_id, session_id, rating: 0/1}`
`agent.alert`	熔断控制器	告警服务	`{tenant_id, agent, reason, step_count}`

以计费为例的时序流程：

sequenceDiagram participant Client as 用户 participant GW as AI 网关 participant Model as 大模型 participant Kafka as Kafka participant Billing as 计费服务 Client->>GW: 发起请求 GW->>Model: 调用模型 Model-->>GW: 返回结果 (消耗 1500 Tokens) GW-->>Client: 返回结果 (立即,不等待计费) GW->>Kafka: 发布事件 {tenant_A, gpt-4, 1500 tokens} Note over Kafka: 消息持久化,等待消费 Kafka->>Billing: 异步消费 (可能延迟数秒) Billing->>Billing: 聚合计算,生成账单

即使计费服务宕机，Kafka 消息仍持久化存储，不会丢失。这是异步事件驱动架构的韧性价值。

7. 可观测性：四维监控体系

flowchart TB subgraph ObsDimension["可观测性四维度"] Trace["① 链路追踪
LangSmith + Jaeger
Tenant_ID + Step 透传"] Metrics["② 指标监控
Prometheus + Grafana
租户级 QPS / 延迟 / 熔断次数"] Logs["③ 日志中心
ELK / Loki
按租户标签索引"] CostPanel["④ 成本看板
多维度租户级成本分摊与归因分析"] end Trace --> |"定位"| Question["这次调用慢在哪个环节？"] Metrics --> |"发现"| Question2["哪个租户的 QPS 异常？"] Logs --> |"取证"| Question3["这次异常请求的完整日志？"] CostPanel --> |"核算"| Question4["各租户的月度成本分摊明细？"]

可观测性体系需确保每个问题都能快速定位到具体的租户、服务和推理步骤。所有 Trace、Metrics、Logs 均携带 tenant_id 标签，形成统一的租户维度分析能力。

8. 核心能力总结

多租户 AI 平台核心能力矩阵

能力维度	核心措施	关键技术 / 实现价值
租户隔离	身份认证、向量库强制过滤、数据库行级安全、对象存储路径隔离	JWT 透传 `Tenant_ID`；Milvus Metadata Filter；PostgreSQL RLS；MinIO 目录策略------构建防穿透的数据围栏
安全防护	内容审核、熔断机制、人工审批	租户级敏感词库动态加载；Step Count 循环检测（阈值可配置）；高危操作 HITL 挂起→审批→审计闭环
资源公平	分布式限流、GPU 分级调度、爆炸半径控制	Redis Sorted Set + Lua 滑动窗口；K8s NodeSelector 专用节点 + Spot 池；单租户故障隔离，保护全局可用性
成本可控	双级语义缓存、异步计费	租户私有缓存（默认）+ 全局公共缓存（二次审核）；Kafka 事件驱动，精确到租户/模型的 Token 成本归因
系统韧性	异步非阻塞解耦、模型 Fallback	主推断链路离线化耗时任务；AI 网关自动切换备用模型，应用侧无感知
持续优化	效果评估、用户反馈闭环	LangSmith / Langfuse 全链路追踪；自动化回归测试 + 用户点踩/点赞数据驱动 Prompt 与模型迭代

9. 结语

Agent 项目从demo验证走向多租户生产环境，普遍面临三大核心挑战：数据隔离失效导致的合规风险、资源争抢引发的服务抖动，以及 Token 成本无法精确归因造成的商业化障碍。本文基于这些生产实践中的真实痛点，系统分析了多租户 AI 平台在身份透传、存储隔离、流量控制、安全防护、成本治理五个维度的架构需求，并提出了以 AI 网关为统一管控入口、以 Kafka 事件驱动实现异步解耦、以双级语义缓存平衡成本与安全、以 Supervisor/P2P/层次化拓扑覆盖多元协作场景的完整技术方案。

本架构的核心设计理念------租户上下文全链路透传、存储层多重隔离兜底、熔断与审批双保险、GPU 资源池化与爆炸半径控制------在 Agent 项目开发具有借鉴意义。

随着 MCP 协议与 A2A 通信标准的演进，Agent 间的协同将更加紧密，多租户架构也将向更细粒度的安全治理和更智能的资源调度方向持续进化。而我们今天在隔离、熔断、缓存、计费等方面建立的工程基础，正是承载未来更复杂 Agent 生态的坚实基石。