先说一个真实场景：公司做了一个 Agent 平台，最初只服务一个部门，跑得挺好。三个月后，市场部、财务部、两个外部客户都接进来了。某天财务问「上季度报销制度怎么改的」，Agent 答的是市场部的口径；再过两天，客户 A 在会话里看到了客户 B 的项目编号。系统没报错，日志里全是成功的绿勾。
这就是多租户要解决的问题：让同一套系统安全地服务多个互相看不见的租户。它不是加一个 tenant_id 字段那么轻——真正要提前定死的，是五个维度上的隔离：数据、权限、密钥、记忆、配额。这篇按这五个维度讲，最后给落地顺序和三个最容易踩的坑。
一、先把「多租户」拆开：到底在隔离什么
很多人以为多租户就是「数据表里加一列 tenant_id」。加完这列之后你会发现，下面这些问题一个都没解决：
（1）数据隔离：租户 A 的检索结果里，会不会掺进租户 B 的文档？这既要靠存储层的过滤，也要靠检索层的强制条件。
（2）权限隔离：同一句「帮我导出所有客户清单」，在租户 A 的会话里是合法动作，在租户 B 的会话里就是越权。
（3）密钥隔离：如果所有租户共用一组模型 API Key 和业务系统凭证，那么租户 A 的一次提示词注入，就可能把整套凭证掏出来。
（4）记忆隔离：Agent 的长期记忆和上下文缓存是最容易串台的地方，因为它天然是「跨会话」的。一旦不按租户分区，别人的偏好和结论就会污染你的回答。
（5）配额隔离：一个租户跑批量任务把额度吃光，其他租户当天全部不可用。这是最常见、也最容易被忽略的故障模式。
五个维度里，数据隔离最容易被想到，密钥和记忆隔离最容易出事。整体安全底线怎么划，可以参考 AI Agent 权限管理怎么做 和 生产级 Agent 的七道安全防线；这一篇专讲「多租户」这个特定切面。
二、数据隔离的四种级别：先选对，再谈优化
从弱到强四种做法，成本也是从低到高：
（1）共享表 + 租户字段。所有租户的数据在同表同库，靠每一条查询都带上租户条件来隔离。成本最低、最容易起步，也最容易出事——只要有一条查询漏了条件，就是跨租户泄露。适合租户少、内部使用、数据敏感度不高的场景。
（2）独立 schema 或独立表。同一个数据库实例内按租户分空间，物理上仍共享实例，但逻辑边界清楚了，查询天然带上隔离维度，漏条件的概率大幅下降。这是多数中型场景的甜点位置。
（3）独立数据库。每个租户一个库，隔离最彻底，备份、恢复、导出都能按租户单独做。代价是运维复杂度和成本随租户数线性上涨。适合客户对数据位置有明确要求、或者要能「整套导走」的场景。
（4）独立实例 + 独立沙箱。每个租户一套完整运行环境，连 Agent 执行代码的沙箱都是独立的。最强隔离、最高成本，通常只有对接大型客户或不同密级场景才这么做。沙箱到底隔离了哪四样东西、有哪几种方案，站内一篇 AI Agent 沙箱是什么 讲得很细。
怎么选：不要一上来就选最强。判断标准是「一旦串台，最坏后果是什么」。如果最坏后果是「客户看到同行数据」，那就必须往上走一级；如果最坏后果只是「内部两个人看到同一份公告」，共享表加严密的条件约束可以接受。但有一条底线：不要把隔离寄托在「代码写得小心」上，要把它做成基础设施层面的强制约束。
三、权限怎么按租户收口：三层结构加一条铁律
权限模型推荐三层：租户 → 角色 → 动作/工具。任何一次工具调用，都要能回答三个问题：是哪个租户发起的、这个租户的哪个角色、这个角色允不允许这个动作。
（1）工具白名单要能下推到租户级。同一个「查数据库」工具，租户 A 只允许读自己的库，租户 B 允许读写但仅限某个 schema。白名单只挂在全局是不够的。
（2）跨租户动作默认禁止，要开就单独开、单独留痕。跨租户操作几乎总是管理动作而不是业务动作，它应该走单独的审批通道，而不是混在普通工具权限里。哪些动作要二次确认，可以参照 客户可见动作怎么管 里的思路。
（3）租户身份要能从会话一路传到工具层。最常见的事故是：入口校验了租户身份，但工具层拿不到这个身份，于是只能「查全部再在结果里筛」——看似没事，其实已经越权。身份必须作为不可伪造的上下文向下传递，不能靠模型自己声明。
四、密钥与凭证：一个租户泄了，不能伤到第二个
（1）一个租户一组凭证。模型 Key、数据库账号、第三方接口令牌都按租户独立。共用的那一组必须只能是「无权限的公共能力」，比如只读的公开检索。
（2）凭证不进提示词、不进日志。Agent 很容易把「我用了哪个 Key」说出来，或者把含密钥的请求原样写进日志。密钥的保管与轮换做法见 AI Agent 凭证轮换怎么做。
（3）出网要有绑定。就算凭证泄漏，也要让它出不去指定目标。配置改完要验、验完要留痕，思路和 变更后验证清单怎么写 一致——安全配置的价值，在于它被验证过。
五、记忆与知识库：最容易串台的地方
（1）记忆分区，读写都带租户命名空间。不要把「用户偏好」「历史结论」放进一个全局池子。记忆该记什么、怎么防污染，AI Agent 记忆怎么设计 里讲的是同一套原则，这里只是把「按租户分区」作为前置约束加上。
（2）检索时的租户过滤必须下推到检索层，不能只在结果里筛。如果先在全部数据里召回十条、再按租户过滤，很可能十条全被筛掉，于是 Agent 拿到空上下文开始瞎编；更糟的是过滤逻辑一旦写错就直接泄露。正确做法是把租户条件作为检索的必选过滤项一起下推。
（3）引用白名单和巡检也按租户设。哪个来源可以被引用，不同租户的答案不一样，做法参考 引用白名单怎么设；资料过期的巡检同样要按租户分别跑，见 知识库陈旧内容怎么巡检。
六、配额与用量：按租户计量，超限降级而不是报错
（1）四个维度一起限：并发数、单位时间请求数、Token 用量、成本上限。只限其中一两个，另外的维度就会成为漏口。
（2）计量要按租户落到明细。每个租户每天用了多少 Token、花了多少钱、失败重试消耗了多少——这些既是对账依据，也是扩容依据。成本核算的完整框架见 AI Agent 成本怎么算、怎么省；限流与配额本身的通用设计原则，另有一篇 AI Agent 限流与配额怎么设计 讲得更系统，这一节只讲「按租户」这一层。
（3）超限的行为要设计好。直接报错、降级到小模型、还是排队等闲时？对多数业务场景，「降级可用」比「干脆不可用」体验好得多；但降级会带来输出质量波动，所以必须通知到人并留痕，不能默默降质。
（4）给突发的批量任务留一个出口。允许租户申请临时额度或把任务挪到闲时，而不是把所有租户一起拖慢。
七、审计：出事之后要能一句话说清「谁在哪个租户做了什么」
多租户系统的审计字段至少要有：租户标识、发起人、会话标识、工具名、动作类型（读/写/外发）、目标资源、结果、时间。这一套字段怎么设计，AI Agent 审计查询字段怎么设计 里有完整清单。
多租户还多一条硬要求：审计要能按租户切分导出。客户来问「我的数据被谁访问过」，你得能只给他自己的记录，而不是给一份混着别人信息的日志——那本身就是一次泄露。
八、落地顺序：五步，别跳
（1）先定隔离级别，并写进架构文档。不要边做边升级，从共享表改成独立库的迁移成本很高。
（2）把租户身份做成不可伪造的上下文，从入口贯穿到工具层。这是所有隔离的前提。
（3）权限、密钥、记忆、索引四样一起按租户分区。只做其中一两样，剩下的就是漏洞。
（4）配额与计量先跑起来，再谈优化。没有计量就没有治理。
（5）上线前做一次「租户越权测试」。用一个租户的身份去问另一个租户的数据，看能不能问出来。这个测试要固化成回归用例，每次权限变更后重跑，思路和 变更后验证清单怎么写 完全一致。
九、三个最常见的坑
坑一：把「共享表 + 租户字段」当成终点。它是个起点，适合验证业务；一旦开始接外部客户，就要评估升级。判断信号很简单：如果一条查询漏写条件就会造成事故，那你依赖的是流程规范，而不是机制。
坑二：只在入口校验租户，没在工具层再校一次。Agent 的调用链是「模型决定调哪个工具」，而模型是会出错的。每一层执行前都应该用不可伪造的租户身份再校一次，而不是相信上游已经查过。工具层面的设计原则见 AI Agent 工具怎么设计才好用。
坑三：忘了「同一个租户内部的隔离」。很多事故不是跨租户，而是同一个大租户内部 A 部门看到了 B 部门的数据。给租户内部再留一层子范围（部门/项目/角色），成本很低，但能挡掉一大类投诉。
十、优缺点与适合人群
做得对的好处：可以放心接外部客户；故障和成本都被关在单个租户里；审计和合规能过；后面加客户基本是配置工作，不是开发工作。
代价和局限：隔离级别越高，运维成本和资源开销越大，独立库、独立实例会显著抬高单位成本；配额与降级策略引入一套需要持续调的参数；租户身份要贯穿全链路，对早期架构有硬要求，事后补代价很大。
适合人群：适合把 Agent 平台对外输出、或要服务多个部门的企业团队；正在把内部工具做成产品的团队；对接了多个客户、且客户对数据位置有要求的场景。不适合：只有单一使用方、数据敏感度不高的内部小工具——这时候把权限和审计做扎实就够了，不必先上独立库。
总结
多租户，一条主线：先承认它是一个架构决策而不是一个字段——数据按租户分到合适的隔离级别；权限按「租户→角色→动作」三层收口，并让身份贯穿全链路；密钥一租户一组，不出网、不落日志；记忆、缓存、知识库索引全部按租户分命名空间，并把过滤下推到检索层；配额在并发、频次、Token、成本四个维度一起限并按租户计量；最后用可切分导出的审计兜底。一句心法：多租户的验收标准不是「功能都能用」，而是「拿一个租户的身份去问另一个租户的数据，问不出来」。
