B 端SaaS 一接入 Agent就会遇到一个比模型效果更硬的问题同一套 Agent 引擎同时服务很多企业时任何一次上下文串租、知识库串租、工具权限串租都可能直接变成数据事故。传统多租户系统通常把隔离重点放在数据库、缓存、对象存储和权限表上。Agent 场景会把隔离面继续拉长。模型上下文、工具调用、向量检索、Prompt 模板、记忆、审批和审计日志都必须知道当前请求属于哪个租户。为适配多租户的生产场景租户上下文需要从入口开始贯穿整条执行链。Agent 引擎可以共享但计算沙箱、RAG 检索面、Prompt 装载和工具授权必须按租户收口。多租户 Agent 需要让每一次推理、检索和行动都带着可验证的租户边界。一、Agent 把多租户隔离从数据层推到执行层多租户也就是 Multi-Tenant指的是同一套软件平台同时服务多个客户组织。对 SaaS 来说这本来是基础能力。一个租户通常对应一家企业、一个部门集团或一套独立业务空间。Agent 进入 SaaS 后租户边界不再只存在于数据库查询条件里。Agent 会读文档、查向量库、调用业务工具、生成草稿、触发审批还会把中间推理结果放进上下文或任务状态里。任何一个环节忘记租户边界都会让原本隔离良好的 SaaS 变成高风险自动化系统。多租户 Agent 设计需要先扩大隔离对象。数据库里的 tenant_id 只是起点完整方案还要覆盖执行、检索、Prompt 和审计。隔离面扩大之后架构上需要先建立一个租户控制面。没有控制面后面的计算隔离、RAG 隔离和 Prompt 装载都会变成散落在各个模块里的临时判断。二、租户控制面负责把身份、配置和策略装进每次执行多租户 Agent 的入口必须先解析租户上下文。这个上下文来自域名、组织 ID、用户会话、API Key、企业微信应用、SAML/OIDC 登录态或内部网关签名。入口层要把它变成统一的 tenant_context后续所有模块只认这一份上下文。租户控制面存三类信息。第一类是身份与权限说明用户属于哪个租户、哪个角色、能调用哪些工具。第二类是资源与配额说明这个租户能使用哪些模型、多少并发、多少向量索引、多少任务队列。第三类是运行策略说明默认 Prompt、知识库范围、审批规则、审计要求和数据保留周期。控制面统一之后执行层才能做到“共享引擎隔离运行”。这也是大规模 B 端 SaaS 最常见的取舍引擎不一定为每家企业单独部署但每次执行都要带着租户边界运行。三、计算隔离要按租户等级分层Agent 的计算隔离包含模型调用、工具执行、代码沙箱、异步任务和缓存状态。隔离强度需要和成本约束一起评估。给所有租户都做独立集群安全边界最清楚但资源利用率低。所有租户完全混跑成本最低但风险会集中到调度器、缓存和插件运行时。按租户风险等级选择隔离模型是兼顾安全边界和资源利用率的基础做法。普通租户走共享池大客户或高合规租户走独立队列、独立索引或独立执行空间。极高合规租户再进入专属集群或私有化部署。计算隔离还要特别处理长任务。Agent 任务可能运行几十分钟期间会暂停、等待审批、重试或恢复。任务状态、检查点和临时文件都要按租户分区并在恢复、重试和回放时持续校验租户边界。如果 Agent 允许执行代码或插件沙箱边界要再收紧一层。每次执行都应注入租户级临时目录、网络访问策略、工具允许名单和资源限额。模型可以共享执行副作用必须隔离。四、RAG 隔离需要在检索前完成租户过滤RAG也就是检索增强生成通常会把企业文档切块、向量化再按用户问题召回相关内容给模型回答。多租户 RAG 的主要风险集中在召回阶段跨租户。答案生成出来以后再做文本过滤已经太晚了。向量隔离通常有三种做法。第一种是每个租户一个独立索引或集合边界清楚成本较高。第二种是共享索引用 namespace、partition 或 tenant 分区隔离。第三种是共享索引加元数据过滤用 tenant_id 作为必选过滤条件。实际架构可以混合使用但检索请求进入向量库之前就要带上租户范围。向量数据库厂商给出的多租户能力名称不同但工程目标一致。Pinecone 常用 namespace 隔离租户。Weaviate 有 collection 级多租户能力。Qdrant 可以通过 payload 过滤与分片策略处理多租户。Milvus 常见做法是按 database、collection、partition 或分区键拆分租户。--------------------------目前市面上主流的向量数据库可以根据其原生性和托管方式分为以下四大类1. 托管式云原生向量数据库Serverless/Managed这类数据库专为云端设计用户无需维护基础设施开箱即用。Pinecone:特点目前商业化最成功的闭源向量数据库。全托管模式支持实时索引更新和高并发查询。适用场景追求极致部署速度和易用性的企业级 AI 应用。Zilliz:特点基于开源 Milvus 构建的公有云版本提供强大的自动扩缩容能力。2. 专业开源向量数据库Open Source Dedicated这类数据库是目前技术选型的主流通常具有极高性能的索引算法如 HNSW。Milvus:特点全球最受欢迎的开源向量数据库之一。采用分布式架构能够处理海量的十亿级向量数据。适用场景具有自建机房需求、对数据隐私敏感且数据量巨大的项目。Weaviate:特点支持 GraphQL 查询深度集成了多种模型。它不仅能存向量还擅长处理向量与对象之间的关系。Qdrant:特点使用 Rust 编写以高性能和低内存占用著称非常受开发者欢迎。Chroma:特点轻量化、易安装是很多 LLM 开源项目如 AutoGPT的默认推荐。3. 传统数据库的向量插件Vector Plugins如果你已经在用传统数据库可以通过扩展插件实现向量检索无需引入新的架构。pgvector (PostgreSQL):特点极其流行。通过在 Postgres 中安装插件让关系型数据库瞬间具备处理向量的能力。Elasticsearch (KNN):特点许多公司已有 ES 集群利用其内置的近似最近邻ANN搜索功能可以直接上手。Redis:通过RedisSearch模块提供高性能的向量存储和检索。4. 嵌入式/轻量级向量库这类主要用于本地开发或小型应用通常不作为独立的数据库服务运行。Faiss (Meta 开源):严格来说它是一个库Library而非数据库是目前许多高性能向量索引算法的底层实现标准。LanceDB:一个专为 AI 设计的嵌入式、无服务器向量数据库直接读写磁盘。--------------------------具体选型取决于租户数量、单租户数据量、查询延迟、删除要求和成本。如果租户特别多、每个租户数据量不大共享索引加强制过滤更经济。如果少数大客户数据量大、合规要求高独立索引更容易审计、迁移和删除。五、Prompt 动态装载要走版本化配置系统多租户 Agent 的 Prompt 会同时承载业务规则、品牌口吻、审批门槛、知识库范围、禁用动作和合规要求。不同企业之间的这些差异进入配置系统之后后期维护、灰度和审计才有稳定依据。Prompt 需要由可版本化的模板和租户配置共同生成。平台提供基础系统 Prompt行业包提供行业规则租户配置提供企业专属约束运行时再根据 tenant_context 装配成最终提示词。版本记录决定了后续审计能否复原当时的执行条件。每次 Agent 回复和工具调用都要记录使用了哪一版 Prompt、哪一版租户策略、哪一组检索结果。否则一旦客户质疑“为什么它这么回答”团队只能去猜当时到底装载了什么配置。动态装载还要有回退策略。租户配置缺失时可以回到平台默认规则租户配置校验失败时应该拒绝执行高风险动作Prompt 版本灰度时要能按租户、部门或任务类型逐步放量。六、综合图多租户 Agent 的隔离架构多租户 Agent 架构可以分成入口鉴权、租户控制面、共享 Agent 引擎、隔离执行面、隔离知识面和审计回放面。编排能力由平台共享上下文、资源、权限和副作用按租户隔离。租户控制面位于共享 Agent 引擎之前。Agent 在选择工具、调用知识库、生成 Prompt 和写入状态之前已经拿到了租户策略。后面每一层都沿用这份策略避免在各模块里重复推断请求来源。这种结构让平台保持统一产品能力同时允许不同租户采用不同隔离等级。普通租户可以复用共享池大客户可以独立知识库和队列强合规客户可以进一步走专属部署。七、上线检查清单租户边界验证优先于智能能力扩展多租户 Agent 的上线风险常来自隔离边界滞后于模型能力扩展。上线前的检查标准需要落到每一次执行它只看到了当前租户允许看的数据只调用了当前租户允许调用的工具只使用了当前租户对应的策略和 Prompt。多租户 SaaS 的优势来自规模复用但 Agent 的生产可信度来自边界清楚。引擎可以越来越强租户边界必须一直可验证。参考文档https://mp.weixin.qq.com/s/WBnObOk10GCNbNEVGCH05A