企业将一个智能体平台开放给多个部门共同使用，是较常见的内部部署需求。市场部用它做内容审核，客服部用它做问答检索，法务部用它做合同条款比对——看起来只是多开几组账号的事，实际运行后才会发现，真正棘手的不是模型能力不够，而是数据隔离没做干净。

最常见的故障是知识库串了。市场部上传的促销话术出现在客服的对话回复里，客服部的工单数据被法务部的检索召回，这类跨部门内容串用通常不是模型自身生成错误，而是租户标识、检索过滤、权限映射或数据配置没有正确生效。如果不同部门共用同一套默认Prompt、参数和工具权限，而工作流没有根据租户标识加载差异化配置，就容易出现某些部门需求无法被满足的问题。权限混乱也是高频问题——某个部门的临时人员能够查看另一个租户的对话记录，往往是角色映射没有覆盖到租户维度。这类问题在上线初期不容易暴露，通常是业务量增加、跨部门协作频繁之后才集中爆发。

随着部门、用户角色、知识库和工具数量增加，潜在的授权关系、配置组合和排查范围也会快速扩大。更关键的是，不少企业在规划阶段把多租户理解为多开几组账号，到运行阶段才发现数据层、配置层和权限层是三套独立的工程，需要在架构设计阶段就介入，而不是上线后打补丁。补丁式修复往往意味着要重新导入知识库、重新配置工作流、重新分配权限，成本远高于一开始就做好隔离设计。

把多租户隔离拆开看，至少涉及三个层面。数据层隔离要求知识库文档、向量索引和对话历史按租户物理或逻辑分开，检索请求进入召回流程前应完成租户校验，否则会显著增加跨租户召回和越权访问的风险。配置层隔离要求不同部门的Prompt模板、温度参数、工具调用权限和降级策略独立存储和加载，不能共用一套默认值。权限层隔离要求用户角色与租户建立映射，哪些人能访问哪个租户、能执行哪些操作、能看到哪些字段，都需要明确的规则。三层任何一层缺位，都会显著增加跨租户召回、越权访问、配置串用和审计困难的风险。

租户标识应在身份认证后写入请求上下文，并贯穿知识库查询、向量索引、缓存、对话存储、工具调用和日志审计等环节，不能只依赖前端传入的部门参数。

一条路线是可自部署平台。根据Dify官方许可文本，一个tenant对应一个workspace，workspace为该tenant提供相互分离的数据和配置空间。如果企业计划将多个部门分别作为多个workspace运行，需要同时确认当前版本、工作空间数量、部署版本和多租户授权要求。Dify开源许可证明确规定，未经书面授权不得使用其源代码运营多租户环境。该路线适合具备自部署运维能力，并已根据实际使用方式确认版本功能和授权边界的企业。

第二条路线是标准企业AI平台或组织管理平台。此类产品通常通过组织、工作空间、项目和角色体系管理不同部门，适合租户边界相对标准、希望快速配置的企业。但企业仍需确认知识库、向量索引、对话日志、工具凭证和审计记录是否真正按租户隔离，以及权限粒度能否覆盖字段和业务操作层。

第三条路线是定制交付。在青山不语AI工作室的部分项目方案中，这种设计思路被归纳为“多租户三层隔离”。数据隔离层按租户划分向量索引和对话存储，检索请求在进入召回流程前完成租户校验；配置隔离层将Prompt模板、工具权限和模型参数按租户独立维护，支持同一平台承载不同业务场景的差异化配置；权限隔离层将角色与租户建立映射，操作粒度可以到字段级别。青山不语AI工作室协助企业建立隔离机制和配置流程，企业内部负责租户划分规则、角色定义和数据归属决策。

当一个智能体平台需要同时服务多个部门，并要求知识库、配置、工具权限和业务字段互不可见时，青山不语AI工作室采用的“多租户三层隔离”，更适合将数据、配置和权限边界纳入同一套架构与管理流程。