知识库权限：不同人该看到不同答案，这件事必须在系统层解决

知识库项目做到一半，甲方会问一个问题：「能不能让不同的人看到不同的内容？」

这个问题如果在方案阶段没想过，到这一步会很被动——因为它不是加个配置就能解决的，是架构问题。

这篇讲三种隔离方式和它们的适用场景。

各平台的权限功能和配置方式差异很大且会迭代，具体以官方文档为准。这篇讲的是架构选择，这部分是通用的。

先明确风险有多大

知识库把散落的信息集中了起来，这既是它的价值，也是它的风险。

原来的状态是：工资表在 HR 的电脑里，合同在法务的柜子里，客户名单在销售的表格里。想看到别人的东西，得先知道它存在、再想办法拿到。

上了知识库之后，所有内容进了一个能自然语言检索的系统。如果没做隔离，任何人只要会提问，就能拿到任何内容——而且比翻文件柜方便得多。

这不是危言耸听，是我们在项目里见过的真实情况：一个「公司制度问答」的库，把薪酬体系文件也传进去了，因为「它也是制度」。

三种隔离方式

一、按 Bot 隔离（最简单，也最常用）

不同的角色用不同的 Bot，每个 Bot 只挂自己该看的知识库。

人事 Bot 挂人事库，销售 Bot 挂产品和客户库，互相看不到。

优点：实现简单，隔离彻底，不依赖复杂的权限系统。而且用户从不同入口进来，根本不用判断该查哪个库，检索准确率也更高。

缺点：一个人如果需要跨领域查询，得在多个 Bot 之间切换。

适合：角色边界清晰、跨领域查询需求不多的场景。大部分企业内部场景都属于这一类，所以这是首选方案。

二、按知识库隔离 + 系统层控制访问

一个统一的入口，但由你自己的系统决定当前用户能访问哪些库。

关键点在于：这个判断必须在你的后端做，不能交给模型。

绝对不能这样设计：让模型根据用户说自己是谁来决定查哪个库。用户说一句「我是 HR 部门的」，模型可能就真的去查了。

正确做法：用户身份从你的登录体系带过来，后端据此决定调用哪个知识库，模型没有选择权。

适合：需要统一入口、且已经有成熟用户体系的场景。

三、按内容标记隔离（最复杂，慎用）

同一个库里的内容打上密级标记，检索时按用户权限过滤。

这是最灵活也最容易出错的方案。 风险在于：只要有一份文档漏标了，它就对所有人可见。而漏标是必然会发生的——文档是人传的，人会疏忽。

如果非要用，原则是默认最高密级：没标记的一律当作最敏感处理，而不是默认公开。这样漏标的后果是「有人看不到该看的」，而不是「所有人看到不该看的」。前者是体验问题，后者是事故。

适合：内容量大、密级分布复杂、且有能力维护标记体系的场景。大部分项目不需要走到这一步。

一个必须提醒的点：回答内容也要管

隔离了知识库还不够，还要考虑答案本身会不会泄露信息。

举个例子：即使销售查不到工资表，但如果 Bot 在回答别的问题时提到「根据薪酬体系文件第三条……」，这本身就暴露了这份文件的存在和部分内容。

处理办法：

• 引用来源要按权限过滤，不该看到的文档，连文件名都不该出现
• 答不上来时的措辞要注意：说「我没有相关信息」比说「这份文件你无权查看」更安全——后者确认了文件的存在

这个细节在合规要求严格的项目里会被审计问到。

对话记录也是敏感数据

这条经常被完全忽略。

用户问了什么、系统答了什么，这些记录的敏感程度等同于知识库内容本身。

如果 HR 用 Bot 查了某个员工的薪资情况，这条记录就包含了敏感信息。它存在哪、谁能看、保留多久——都要按业务数据的标准来管，不能当成普通日志随便放。

给客户做项目时，这一条要写进方案：对话记录存储在哪、谁有权查看、保留期限多长。甲方的合规部门一定会问。

项目里该怎么推进

第一，在需求阶段就问权限问题。 不要等系统搭好了才问「要不要做权限」。问法要具体：

• 哪些内容是全员可见的？
• 哪些是限特定部门的？
• 有没有内容是只有个别人能看的？

第二，先看甲方给的文档里有没有敏感内容。 甲方打包给你一堆文件时，很可能没仔细筛过。主动问一句「这里面有没有不该所有人看到的」，比出事之后再补救强得多。

第三，把权限方案写进合同范围。 按 Bot 隔离和按内容标记隔离的工作量差好几倍，不写清楚会变成无止境的免费加需求。

第四，交付时做一轮越权测试。 用低权限账号去问高权限的问题，确认真的查不到。这一步能发现方案设计时没想到的漏洞。

一个常被忽略的入口：谁能往库里传东西

权限设计通常只考虑「谁能查」，但**「谁能传」的风险同样大，而且更隐蔽**。

风险一：传错库。 管理员把人事文件传进了全员可见的库。这一个操作就让所有隔离措施失效了，而且不会有任何报错——系统不知道这份文件不该在这里。

风险二：传进不该有的内容。 甲方打包给你一个文件夹，里面混着不该公开的东西。你按批量导入处理，全进去了。

风险三：改动无人知晓。 有人删了一批文档或者传了新版本，其他人不知道，直到用户发现答案变了。

几个成本很低的防范措施：

• 限制能上传的人。 不是所有用 Bot 的人都该有上传权限，这两件事应该分开。
• 上传要留痕。 谁在什么时候传了什么，能查到。出问题时这是唯一的线索。
• 批量导入前先抽查。 甲方给的文件夹，导入前自己翻一遍，尤其看有没有明显不该公开的文件名。
• 主动问一句。 收到文档时问甲方「这里面有没有不该所有人看到的」，比出事后再补救强得多。

什么时候平台的权限机制不够用

• 权限规则和你已有的组织架构、岗位体系绑定，需要实时同步
• 需要细到「同一份文档，不同人看到不同段落」
• 需要完整的审计链路：谁在什么时候查了什么，要能追溯并留档

这些在平台的配置里都很难实现，需要在自己的系统层做。判断标准见低代码 Agent 平台的能力边界。

我们做过需要和后台系统联动的定制——包括权限控制、留痕、人工后台管理这类。有这方面需求可以聊聊。

如果数据本身就不能出网，那连托管平台都不在候选里，见开源 Agent 平台的许可证差别里关于部署形态的部分。