作者：谢晓琴，杭州萌嘉网络科技有限公司产品经理。团队长期专注于企业 AI 落地与 AI 知识引擎实践，是国内较早探索 RAG 企业应用落地的团队之一。产品 TorchV 已成功服务浪潮信息、微众银行、物产中大、台州银行、适途汽车、中汇税务师事务所等客户。

知识空间不是知识库换了个名字

知识按部门来管理，还是按业务来使用？这是企业大规模用上 Agent 之后，绕不开的一道题。

企业在建知识库的时候，经常卡在一个问题上：

知识应该按部门来管理，还是按业务来管理？

看起来很简单，其实不简单。

拿一家银行说。风险管理部有自己的知识库，运营管理部有自己的，科技部、财务部也各有各的。这没什么问题，甚至是大型企业知识体系的基础。

因为企业管知识，基本遵循一条原则：谁拥有，谁管理。

风险部对风控制度的准确性负责，运营部对流程负责，每个部门管好自己那一摊。

但企业开始大量用 AI、尤其是 Agent 之后，问题就来了。

比如银行要做一个「贷款预审批助手」。这个 Agent 需要什么？

贷款产品的准入条件、风险部的授信规则、运营部的办理流程、科技部的接口说明、制度部的最新政策。

这些知识，天然散在不同部门的知识库里。

洞察

知识的管理是按部门划分的，知识的使用却是围绕业务任务展开的。

那这个助手到底该用哪个库？

总不能为了一个 Agent，让几百个知识库的管理员都提前想清楚，未来自己的知识会被谁用、怎么组合。

更别提，同一份制度可能同时被贷款预审批、客户经理助手、贷后管理、合规检查好几个 Agent 用。围着应用各建一套库，就是大量重复建设。

真正的问题，是得把「知识由谁管理」和「知识为谁所用」这两件事分开。

一、知识库管知识，知识空间用知识​

在 TorchV AIS 里，我们把企业知识体系分成了两层。

第一层是知识库，解决知识的归属和管理。

企业照旧按部门、科室、项目组建库，各自负责采集、解析、加工、审核、权限和维护。库怎么分，跟着企业原有的管理结构走就行，不用提前想未来的 AI 应用。

第二层是知识空间，解决知识围绕业务主题怎么协作、怎么用。

它不另起一套管理体系，而是按一个具体业务任务，把散在不同库里的知识聚起来。

还拿贷款预审批说。项目负责人在 AIS 里建一个「贷款预审批」知识空间，邀请风险、运营、科技的人进来。

各人按自己的职责和权限，把本部门库里的相关内容引进来。风险的人引授信规则，运营的人引办理流程，科技的人引接口规范。

知识空间广场，每个空间对应一个业务主题

这里有个关键的变化。

我们不再要求知识库管理员提前预判知识会被谁用，而是让真正用知识的人，在业务发生的时候完成组合。

这跟企业日常做事很像。办一件事，定牵头部门，从各部门抽人调资源，一起干。知识空间干的就是这个，只不过这次协作的对象，除了人，还有知识和用知识的 Agent。

二、知识空间不是把文档重新上传一遍​

有人会问，知识已经在库里了，再放进空间，不是重复建设吗？

——不是。

知识空间可以从库里引入知识，选择引用或复制，并决定后面怎么和源知识保持关系。

知识的归属和维护，还是留在原库。空间关心的，是这些知识适不适合当前业务、谁用、在什么范围内用。

好处很明显。

企业不用为了建几十个 Agent 就建几十套库，已有的知识继续沉淀、维护、反复用。

参与空间的人也不用重新学一套知识工程，大多数时候想清楚三个问题就够了：要完成什么任务、需要哪些知识、该让谁参与。文档怎么解析、切片、建索引，库那边已经做完了。

三、知识被用起来之后，麻烦才刚开始​

前面解决的是知识怎么汇集。接下来还有个更实际的问题：

当知识库里的原始知识变了，正在用它的 Agent 该怎么办？

很多人第一反应是，当然立刻更新，越新越好。但业务里不是总这样。

一个贷款审批项目按某个版本的制度推进，干到一半，源头制度改了。但新制度可能有生效日期、有过渡期，还得业务负责人确认适用范围。Agent 要是立刻切到新版，原来形成的审批依据就乱了。

反过来，如果是一次立即生效的利率调整，还抱着旧知识，又直接影响客户权益。

所以知识更新，不该只有「自动同步」和「不更新」两个选项。

AIS 里我们设计了三种。

第一种 · 只复制一次​

知识引入空间时留一份独立副本，从此和原库脱离。源头之后怎么改、怎么删，都不影响这份副本。

适合要固定历史依据的场景，比如已经启动的项目要保留当时用的合同、需求、技术规范。代价是源头变了，空间不会自动更新。

第二种 · 固定版本并通知​

空间用某份知识的某个版本，源知识一变，系统通知空间的人，但不直接替换，由空间负责人或有权限的人判断要不要升级。

这在我们看来，是很多企业场景下最实用的一种。风控政策调整了，空间先收到通知，负责人确认新旧差异、是否生效，再决定升不升。既及时知道变了，又不会因为库的一次更新，直接改掉正在跑的 Agent 的依据。

洞察

知识更新的决定权，应该交给真正对业务结果负责的人。

第三种 · 跟随最新版​

空间始终跟着源知识的最新版本走，源知识更新、禁用、到期、删除，空间同步变化。适合税率、价格、营业时间这类实时生效的规则，不及时更新就会直接影响客户。

但风险也在这。五分钟前问一个问题，五分钟后源知识变了，同样的问题给出不同的答案。这不一定是大模型幻觉，可能是底层知识版本变了。所以越是要及时更新，对来源、版本、变更过程的可追溯要求就越高。

三种方式没有绝对优劣，本质是在不同场景里，平衡知识的稳定性、时效性和控制权。这个选择不该由库管理员替所有应用一刀切，而该让具体的业务空间自己配。

四、知识空间不只是给 Agent 用的​

前面例子都是 Agent，但知识空间不专为 Agent 设计。很多时候，员工就是最直接的使用者。

一个「秋季营销活动」空间，产品权益来自产品部，合规来自法务部，方案和排期由项目组共同维护。

成员进空间，就能看到围绕这个主题组织起来的资料，还能直接对着这些资料提问。

空间问答，左侧选资料范围，右侧直接提问

比如问：「这次活动中，客户对权益有争议怎么处理」。

AIS 基于空间知识生成回答，并列出参考来源，点开就能看原文。

回答下方列出参考来源，点击查看原文依据

这功能看着不复杂，但我一直觉得它很重要。

员工用 AI 答业务问题，真正关心的往往不是答案流不流畅，而是答案到底从哪来。

尤其在金融、法律、制造这些行业，很多问题都有明确的制度、规范、合同条款。AI 说得再漂亮，没有依据，还是不敢用。

所以空间问答不但要答，还得让人知道答的依据是哪些知识。

模型上支持通义千问、DeepSeek、智谱，能开深度思考，历史对话自动保存。

历史问答记录，方便接着聊

从产品设计上说，我们不想让知识空间只是个浏览资料的地方。它应该是一个围绕具体业务任务，让人和 AI 一起用知识的工作环境。

五、跨部门协作，权限绕不开​

回到贷款预审批。风险部的人进了这个空间，不代表其他部门的人就能看风险库的全部资料。同样，进了一个空间，也不代表人人权限一样。

AIS 里能按组织、团队、个人加协作者，配不同角色。可见范围也分几档：成员可见、企业内部可见、公开问答但内容不可见，还能支持外部查看和分享。

但知识空间的权限，不能简单理解成对源知识库权限的放开。涉及跨部门引用、复制、对外问答，授权边界、谁能看什么、用什么，还得清楚。

知识空间解决的是跨部门协作，不是绕过知识原有的安全管理。

除了引用已有知识，空间内也支持多人在线编辑，一起改、存草稿、发正式版，还能用 AI 辅助创作。也就是说，空间不光汇集知识，协作过程中还能产生新知识。

六、为什么做知识库 + 知识空间这套双层设计​

回过头看，知识空间不算多复杂的概念，但它不是为加新功能而设计的。

过去我们做企业知识体系，更多想的是怎么把知识管好，怎么收集、分类、加工、维护权限、保证准确。这些当然重要。

但企业开始大规模建 Agent 之后，一个更突出的问题浮出来了：已经管好的知识，怎么真正进到业务场景里。

知识库是相对稳定的。多少部门、多少科室、多少项目组，基本就定了知识体系的划分。

但业务应用是不断变的，今天贷款预审批，明天合规审查，后天客户经理助手。这些 Agent 用的知识高度重叠，又各有侧重。

每加一个 Agent 就让知识体系调一次，复杂度会越来越高；让所有 Agent 都直接面对整个知识库，怎么选对知识、怎么控范围、怎么协调跨部门权限，又成了新难题。

所以在知识管理和知识应用之间，需要加一个更灵活的层次。它不替代原来的管理体系，而是围绕业务主题，把需要的人、知识和 AI 应用连起来。

洞察

知识库继续遵循「谁拥有，谁管理」，知识空间遵循「谁使用，谁组织协作」。

一个更接近企业原有的管理方式，一个更接近企业真实的工作方式。

让知识按照它应该被管理的方式管理，让知识按照业务真正需要的方式使用。

这就是我们设计知识空间最初的想法。