腾讯的这个 AI 知识库，做得还是相当扎实。

企业知识库已升级为 Agent 的 Context 中枢

腾讯乐享的 AI 知识库做得真心不错。这两天上手体验了一下，感觉这个产品应该可以解决很多企业在使用 AI 时遇到的问题。

其实，叫它知识库，已经不够准确。

毕竟过去我们一提到知识库，想到的就是把一堆文件放进去，方便搜索和查阅。但现在企业级知识库一个很重要的作用，是为 Agent 提供企业的 Context。

所以，更准确地说，可以把企业知识库理解成 Agent 的 Context 中枢。这就是腾讯乐享正在做的事情。

为何不能仅靠系统直连或基础 RAG？

可能很多人会和我一样，刚开始会觉得，现在 Codex、Claude Code、WorkBuddy 这样的 Agent 已经很强大了，直接通过 MCP、CLI 等方式就能够获取企业内部的 Context，为什么还需要独立的知识库层？

是这样，如果一家公司的知识来源比较单一，文档结构也很清晰，那确实没必要再单独建设一套企业知识库。

但只要公司规模稍微大一些，就会发现很多知识其实分散在不同的系统中。

有些来自企业微信、飞书这样的 IM 和办公平台，有些来自内部的研发管理系统，还有些来自 CRM、财务系统、OA 等等。

而且，在不同的系统里，同一件事可能还存在不同的版本。

比如同样一款产品，针对不同的客户、地区和销售渠道，可能有不同的报价。一份文档里写着 388 元，另一份写着 488 元。

这俩价格可能都没错，但 AI 在给客户准备报价时，到底应该使用哪一个？

其实这就是企业知识库的价值。

一方面，它可以连接企业内部不同的知识来源，把这些分散的信息统一组织起来。另一方面，它会对这些信息进行加工和治理。

否则，连接的系统越多，Agent 拿到的资料反而可能越混乱。

基础 RAG 的局限：切片丢失结构，相似度不等于适用性

理解到这之后，接下来还有一个问题。

既然企业知识库这么重要，那我们自己做一套不就行了吗？这不就是 RAG 吗？

我之前其实也这么想过，而且自己还动手搭过类似的系统。

如果按照比较基础的 RAG 方案，我们通常会先把企业文档导入知识库，解析出其中的内容，再切成一个个片段，转换成向量，建立检索索引。

等 AI 需要查询某个问题时，再通过关键词或者向量检索，根据相似度找到最相关的几个片段，交给模型生成答案。

这个办法当然能够解决不少问题，但它有一个挺大的局限。

因为文档一旦被切成很多片段，就可能丢失原来的结构和上下文关系。

比如一份产品手册，里面有不同型号的价格、使用条件和适用地区。如果切片处理得不好，价格可能被分到一个片段，适用条件又在另一个片段里。

等 AI 检索的时候，可能只找到了价格，却遗漏了对应的使用条件。

而且，向量检索主要依赖语义相似度。但大家想想，我们在实际工作中查找资料，需要考虑的往往远远不止相似度。

比如一份资料是不是最新的，来自哪个部门，有没有经过正式审批，适不适用于当前的客户。

很多时候，最相似的那份资料，未必就是最应该使用的。

所以，如果只依赖基础的切片和相似度检索，处理复杂的企业知识，有时候就像盲人摸象。

它可能找到了大象的一条腿、一只耳朵，却没有把这些信息之间的关系弄明白。最后拼凑出来的答案，看起来有理有据，实际上可能并不完整。

乐享的可信索引：本体、知识图谱与 LLM Wiki 三层治理

这也是腾讯乐享这样的企业知识库，重点解决的问题。

研究了他们的技术方案之后，我发现，乐享在传统 RAG 的基础上，又增加了一整套知识加工和治理的流程。

通过 API、连接器等方式接入企业知识后，乐享会先对资料进行解析和清洗，再进一步理解这些知识背后的业务含义，以及它们之间的关系。

为此，他们设计了一套叫可信索引的技术方案，主要涉及本体（Ontology）、知识图谱和 LLM Wiki。

这三个东西，可以顺着知识的加工过程来理解。

本体主要解决业务概念的统一问题。 比如一家企业有哪些业务对象，各自有什么属性，以及它们之间遵循什么关系和规则。

举个例子，在腾讯云内部，同样一种云服务器产品，在不同系统中可能有不同叫法，有的叫 CVM，有的叫云主机。

对于熟悉业务的员工，这些名称很容易理解。但对 AI 来说，如果没有明确的业务定义，就可能把它们当成不同的东西。

所以，乐享会利用 AI 辅助提取企业内部的业务概念，再由相关的业务人员确认和调整，形成一套统一的定义。

有了这些定义，下一步就是构建知识图谱。

比如企业内部有哪些产品、型号、客户和销售渠道，不同产品分别对应哪些价格和版本，它们之间有什么关联。

乐享会从不同的资料中提取这些信息，把原本分散在不同文档里的知识关联起来。

这就有点像，原来我们只有一堆相互独立的文档，现在不仅知道每份文档里写了什么，还能知道它们之间存在什么关系。

不过，知识图谱虽然方便 AI 理解和检索，但对于普通员工来说，一张包含大量节点和关系的图，还是很难看懂。

所以，乐享又利用 LLM Wiki，把同一主题下的知识整理成结构清晰的知识卡片。

这样，员工可以直接查看和修改，Agent 也可以从中获取相关知识。

动态治理：让知识库随业务实时演进

当然，不同场景不一定需要用上全部能力。简单的知识问答，基础 RAG 可能就已经足够了。

但对于复杂的企业业务，这种知识组织方式确实有价值。

还是前面那个产品报价的例子。即使使用最聪明的模型，但如果它拿到的资料只有 388 元，没有对应客户的正确报价和适用条件，最后照样可能犯错。

问题就出在一开始提供的 Context 不完整。

相比只依靠文字相似度检索，这样有机会找到更完整、更适用的信息。

不过，还有一个问题。

企业的知识是不断动态更新的。

如果知识库没有及时更新，即使前面的知识图谱建得再好，Agent 最后拿到的也可能是过期信息。

所以，乐享还对应做了一套持续的知识治理机制。

第一，通过 AI 巡检，发现知识库中重复、冲突、过期或者敏感的内容，再交给相关负责人确认和处理。

第二，员工在日常使用 Agent 时，如果发现某些信息不准确，或者找不到本来应该存在的资料，也可以把这些问题反馈回来，推动知识库更新。

比如系统发现同一款产品存在两份不同的报价，就可以结合资料来源、版本和有效期，把差异呈现给管理员。

毕竟，AI 不能简单地认为最后更新的那份资料就一定正确。最近修改的可能只是还没有批准的草稿，而之前的正式报价仍然有效。

确认之后，相关知识和索引也需要同步更新，避免 Agent 下次继续使用错误信息。

Context 质量决定 Agent 实际效能

在沙利文最新发布的《中国企业级 AI 知识库市场研究报告》中，腾讯乐享的综合竞争力位居国内行业第一，技术力和产品力也都排名第一。

腾讯乐享做的事情，就是把企业原本分散、混乱的资料，整理成有明确关系、版本、来源和适用条件的知识。

这样 Agent 每次执行任务时，就不用反复从大量原始资料中寻找和判断，也能减少因为拿错信息而犯错的概率。

我现在越来越强烈的一个感觉是，对于企业里的很多日常任务，目前的模型能力其实已经够用了。真正影响 Agent 工作质量的，很多时候是它能不能拿到准确、完整的 Context。

比如前面提到的产品报价。假设 AI 拿到的资料只有 388 元，却没有拿到针对特定客户的 488 元报价，那即使使用最聪明的模型，也很难凭空知道这个差别。

最后给客户报错了价格，你很难说这是模型能力不够。问题很可能在于，一开始提供给它的信息就不完整。

比如潮宏基这样的连锁珠宝企业，门店导购每天需要掌握大量的产品知识、公司制度和销售经验。

尤其是刚入职的新人，遇到不熟悉的产品或者业务问题，往往需要反复查找资料，或者向有经验的老员工请教。

所以，潮宏基通过腾讯乐享，把原来分散的制度和门店经验整理起来，让一线员工在需要时可以随时查询和使用。

这样一下子就降低的知识的流通门槛，新员工在短时间内就可以快速熟悉业务。

你想想，就潮宏基这个 Case，即便公司给大家配备了世界上最聪明的 Agent，但如果没有这些企业的知识库，那也是巧妇难为无米之炊。

所以我觉得，腾讯乐享这类企业知识库产品，接下来会越来越重要。

硅谷有一家叫 Glean 的创业公司，做的也是企业 Context。它在今年 5 月宣布，年化收入已经达到 3 亿美元，而 15 个月前才刚刚突破 1 亿美元。

毕竟，随着越来越多的工作交给 Agent，企业对 AI 的要求也会越来越高。

模型能力当然还会继续提升，但每家企业自己的业务规则、客户信息和长期积累的经验，不会自动出现在模型里。

模型可以越来越聪明，但如果它不了解你的公司，很多工作依然做不好。

只有把企业的知识和经验准确的提供给 Agent，这样它才可能逐渐接近企业内部资深员工的工作水平。

JOTO 企业落地观察

• 企业部署知识库时，需在「即插即用」与「深度治理」间权衡。腾讯乐享的三层架构表明：当业务规则复杂、知识源异构且版本敏感时，单纯依赖向量检索的轻量方案难以支撑关键决策，必须引入本体建模与人工协同治理环节。
• 这类系统的取舍核心在于知识新鲜度与权威性的平衡。乐享将AI巡检与员工反馈并重，说明企业无法仅靠自动化完成知识生命周期管理；必须设计可追溯的审批流与版本控制机制，否则‘最新’不等于‘可用’。
• 对RAG知识工程而言，本文揭示了一个关键前提：切片策略必须服从业务实体边界。当产品价格、适用条件、客户类型构成不可分割的业务单元时，传统按段落或页码切分的方式必然失效，需以本体驱动的语义切分替代纯文本切分。
• AI安全治理在此类系统中体现为‘Context可信链’建设。乐享通过来源标注、审批状态、有效期等元数据约束检索结果，意味着企业不能仅关注模型输出合规，更要确保输入Context本身具备可验证的治理凭证。