Agent 的「多租户隔离「应该如何实现
1️⃣ 考察意图
面试官想看你的 SaaS 架构设计能力。刁钻点在于：多租户隔离不只是"数据分开"，还涉及计算资源、网络通信、配额管理的全方位隔离。很多人只答"用不同数据库"，但说不清 Agent 间的隔离（不同租户的 Agent 不能互相通信）和配额隔离。
2️⃣ 标准答
多租户隔离从"数据、计算、网络、配额"四个维度实现。
1. 数据隔离
| 隔离模式 | 实现 | 优势 | 劣势 | 适用 |
|---|---|---|---|---|
| 独立数据库 | 每个租户一个 DB | 最强隔离 | 成本高 | 大客户/合规要求 |
| 共享数据库独立 Schema | 每个租户一个 Schema | 中等隔离 | 迁移复杂 | 中型租户 |
| 共享数据库共享 Schema | 用 tenant_id 字段区分 | 成本低 | 隔离弱 | 小型租户 |
Agent 特殊需求：(1) 记忆隔离——不同租户的 Agent 记忆不能共享（如 A 的 Agent 不能看到 B 的对话历史）。用 tenant_id 作为记忆检索的必须过滤条件；(2) 工具配置隔离——不同租户可用的工具不同（如 A 有 send_email 工具，B 没有）。用 tenant_id → tool_whitelist 映射
2. 计算隔离
- K8s Namespace：每个租户一个 Namespace，用 ResourceQuota 限制 CPU/内存/Pod 数量
- Agent 池隔离：VIP 租户有专用 Agent 池（不与其他租户共享），普通租户共享 Agent 池
- cgroup 限制：单个 Agent 的 CPU/内存使用上限，防止一个租户的 Agent 影响其他租户
3. 网络隔离
- NetworkPolicy：限制不同 Namespace（租户）间的网络通信。租户 A 的 Agent 不能直接访问租户 B 的 Agent
- API Gateway：所有外部 API 调用通过 Gateway，Gateway 做 tenant_id 认证和路由
- 消息总线隔离：不同租户用不同的 Redis DB（
SELECT 0for tenant A,SELECT 1for tenant B）或不同的 topic 前缀
4. 配额隔离
- Token 配额：每个租户独立的 Token 配额（如免费版 100k/天，Pro 版 1M/天）
- 并发限制：每个租户最大并发任务数（如免费版 3，Pro 版 20）
- 存储限制：每个租户的记忆/日志存储上限
3️⃣ 答题模板（30 秒电梯版）
"多租户隔离四维度：数据隔离——独立DB/独立Schema/共享Schema+tenant_id，Agent记忆用tenant_id做必须过滤。计算隔离——K8s Namespace+ResourceQuota，VIP专用Agent池。网络隔离——NetworkPolicy限制跨租户通信+API Gateway认证。配额隔离——Token/并发/存储按租户独立计量。选型：大客户独立DB，中型独立Schema，小型共享+tenant_id。"
4️⃣ 高频追问 & 应对
追问 1：共享 Schema 模式下，Agent 记忆检索时不小心漏了 tenant_id 过滤怎么办？
三层防护：(1) ORM 层——在 ORM 模型中设置默认 filter（如 SQLAlchemy 的
query.filter_by(tenant_id=current_tenant)），开发者不显式写 tenant_id 也会自动加；(2) 数据库层——用 PostgreSQL 的 Row Level Security（RLS），在数据库层面强制 tenant_id 过滤，即使 ORM 漏了也安全；(3) 测试层——单元测试中验证每个查询都包含 tenant_id 过滤，用静态分析工具（如 pylint 自定义规则）检查。
追问 2：租户间的 Agent 能力不同（A 有自定义工具，B 没有），怎么管理？
工具注册表按租户隔离：
tool_registry:{tenant_id}存储该租户可用的工具列表。Agent 启动时从注册表加载工具。自定义工具的注册流程：(1) 租户管理员通过 UI 上传工具配置（name/description/parameters/endpoint）；(2) 系统验证工具安全性（沙箱测试）；(3) 注册到该租户的工具注册表；(4) 该租户的 Agent 下次启动时自动加载新工具。其他租户看不到这个工具。
追问 3：如果租户 A 的 Agent 被攻击，会不会影响租户 B？
不会（如果隔离正确）：(1) 计算隔离——A 和 B 的 Agent 在不同 K8s Namespace/Pod 中，A 的 Agent 被攻破无法访问 B 的 Pod；(2) 网络隔离——NetworkPolicy 阻止跨 Namespace 通信，A 的 Agent 无法直接访问 B 的 Agent 或数据库；(3) 数据隔离——A 的 Agent 只有 A 的数据库凭据，无法访问 B 的数据。但风险点：如果 A 和 B 共享同一个 Redis 实例，A 的 Agent 被注入后可能通过 Redis SCAN 命令扫描 B 的数据。解法：不同租户用不同 Redis DB 或不同 Redis 实例。
5️⃣ 避坑 · 常见错误答法
- ❌ "多租户就是给每个用户一个 API key" → ✅ "API key 只是认证层。完整的多租户需要数据/计算/网络/配额的全面隔离，防止一个租户影响其他租户。"
- ❌ "共享数据库用 tenant_id 就够了" → ✅ "共享数据库的隔离最弱——一个 bug（漏了 tenant_id 过滤）就会导致数据泄露。高敏感场景用独立数据库或至少独立 Schema + RLS。"
- ❌ "所有租户共享 Agent 池更高效" → ✅ "共享池有"吵闹邻居"问题——一个租户的大任务占满所有 Agent，其他租户等待。VIP 租户应有专用 Agent 池。"
6️⃣ 简历呼应
- 如果你有 SaaS 经验：从"多租户架构设计"切入，描述你实现的隔离方案和效果
- 如果你只做过单租户：用"单租户的简单性 vs 多租户的隔离挑战"切入
- 如果你是校招无项目：用 K8s 实现一个 3 租户的 Agent 系统，测试不同隔离策略的安全性和性能开销，写一篇博客
- "Multi-Tenant Architecture Patterns" (AWS, 2024)
- "SaaS Isolation Strategies" (Microsoft, 2023)
- "Multi-Tenant AI Systems" (Ji et al., 2024)