知识库这东西，很多人第一反应就是"搭个RAG，把文档塞进去，然后问答"。我一开始也是这么想的，直到我把WorkBuddy和腾讯乐享接在一起用了一段时间，才发现原来知识库还能这么玩——它不只是"查资料的地方"，而是能变成一个真正会干活的工作台。这篇就聊聊我是怎么把这两个东西拼起来用的，踩了哪些坑，以及为什么我觉得这套组合比单纯堆一个RAG流水线要实用得多。
先说清楚这套组合到底解决什么问题。WorkBuddy本质上是一个Agent工作台，你可以把它理解成一个能调用工具、能执行多步任务的智能体运行环境；腾讯乐享则是一个企业级的协作与知识管理平台，文档、wiki、公告、培训材料都能往里放。单独用乐享，它是一个"静态的知识仓库"，你得自己去翻、去搜；单独用WorkBuddy，它是一个"有手有脑但缺粮"的Agent，工具能力有了，但缺少一个稳定、结构化、持续更新的知识来源。把两者接起来，乐享负责"存粮"，WorkBuddy负责"用粮干活"，这才是这套组合的真正价值。
适合谁来参考这篇内容？如果你已经在用WorkBuddy做Agent编排，但苦于知识来源零散、每次都要手动喂文档，那这篇对你有用；如果你团队在用腾讯乐享沉淀了大量文档，但除了搜索之外没别的用法，那这篇也能给你一些新思路；如果你只是刚听说"知识库"这个词，想搞清楚RAG、LLM Wiki、Agent这几样东西到底怎么串起来，那这篇可以当作一个落地视角的入门参考。我不打算讲太多概念，重点放在"怎么接、怎么用、哪里会翻车"。
1. 为什么我不再满足于"纯RAG知识库"
1.1 RAG的天花板在哪里
RAG（检索增强生成）这套东西，逻辑很直白：把文档切块、向量化、存进向量库，用户提问时先检索相关片段，再把片段塞进大模型的上下文里让它回答。听起来完美，但实际用下来，它的天花板比想象中低。
第一个问题是检索的"碎片化"。文档被切成一块一块之后，块与块之间的逻辑关系就丢了。你问一个需要跨章节综合的问题，检索出来的往往是几个孤立的片段，模型只能靠这些碎片拼答案，拼出来的东西经常"看着对，细看漏"。我试过拿一份几十页的技术方案去问"这个方案的风险点有哪些"，检索回来的全是零散的句子，模型硬凑出来的答案把三个不同章节的风险混在一起，还漏了最关键的一条。
第二个问题是它只会"答"，不会"做"。RAG的终点是生成一段文字，它没法去调用一个接口、没法去更新一条记录、没法去触发一个流程。你问它"这个季度的培训完成率是多少"，它能从文档里找到数字念给你听，但它没法自己去把数据拉出来算一遍。这就是纯RAG和Agent的本质区别——前者是"问答机器"，后者是"执行机器"。
第三个问题是知识的新鲜度。文档更新了，向量库得重新索引；索引没跟上，模型答的就是旧知识。这个同步问题在小规模下不明显，一旦文档量大、更新频繁，维护成本就上来了。
1.2 LLM Wiki思路带来的启发
后来我接触到LLM Wiki这个概念，思路一下子打开了。LLM Wiki的核心想法是：不要让模型去"检索碎片"，而是让它像人翻wiki一样，沿着结构化的页面链接去"读"。wiki的页面是有组织的、有链接关系的、有层级结构的，模型可以顺着这些结构去导航，而不是在一堆切碎的文本块里捞。
这个思路的好处在于，它保留了知识的结构信息。一个页面讲什么、它链接到哪些相关页面、它在整个知识体系里的位置，这些都是RAG切块时会丢掉的东西。模型沿着结构走，拿到的上下文更完整，推理也更靠谱。
腾讯乐享本身就是一个wiki形态的知识平台，它的文档是有层级、有目录、有相互引用的。这让我意识到：与其把乐享的文档导出来切块喂给向量库，不如让WorkBuddy直接以"读wiki"的方式去访问乐享。这样既保留了结构，又省去了维护向量库的麻烦。
1.3 Agent需要的是"能干活的知识"，不是"能背诵的知识"
最关键的一点认知转变是：Agent要的不是一个"什么都记得"的大脑，而是一个"知道去哪查、查完能用"的工作方式。
打个比方，一个熟练的员工不是把所有公司文档背下来，而是知道"这个事该查哪个系统、那份文档在哪、找谁确认"。Agent也一样，它需要的是可靠的知识获取路径和把知识转化为行动的能力。WorkBuddy提供行动能力（工具调用、任务编排），腾讯乐享提供知识路径（结构化的文档体系），两者一接，Agent就有了"查得到、用得上"的闭环。
这也是为什么我觉得"WorkBuddy + 腾讯乐享"这个组合比"再搭一套RAG"更值得投入——它不是在重复造一个问答系统，而是在给Agent配一个真实可用的知识后台。
2. 把腾讯乐享变成WorkBuddy的"知识后台"
2.1 先想清楚：哪些知识该放乐享，哪些不该
在动手接之前，有个前置问题必须先想明白：不是所有东西都适合往乐享里塞。我踩过的第一个坑就是"什么都往里放"，结果乐享变成了一个垃圾场，Agent去查的时候反而被噪音干扰。
我的经验是分三类处理：
- 稳定型知识：产品文档、技术方案、流程规范、培训材料。这类东西更新频率低、结构清晰、复用率高，最适合放乐享，也是Agent最常查的。
- 时效型知识：项目周报、会议纪要、临时通知。这类东西更新快、生命周期短，放乐享可以，但要有明确的归档和过期机制，否则Agent会查到一堆过时信息。
- 敏感型知识：涉及权限、个人信息、内部决策的内容。这类东西要严格控制访问范围，Agent的访问权限必须和人的权限对齐，不能因为"接了Agent"就开了后门。
提示：乐享的权限体系是分层的，接Agent之前一定要先理清"这个Agent以什么身份访问、能看到哪些空间"。我见过有人图省事用管理员账号接，结果Agent能查到所有东西，这是很危险的。
2.2 用目录结构给Agent"画地图"
乐享的目录结构对Agent来说就是一张地图。目录越清晰，Agent导航越准。我做过一个对比实验：同样一批文档，一种按"部门-项目-文档"三层组织，一种全部平铺在一个空间里。结果前者Agent找对的概率明显更高，后者经常在平铺的列表里"迷路"。
具体怎么组织，我的做法是：
- 顶层按领域分：比如"产品""技术""运营""培训"几个大空间，每个空间职责明确。
- 中层按主题分：每个空间下再按主题建目录，比如技术空间下分"架构""部署""排错"。
- 底层文档命名规范：文档标题要能自解释，别用"新建文档1""会议记录"这种。Agent很多时候是靠标题判断相关性的，标题起得烂，检索质量直接崩。
这套结构看起来是给人用的，其实对Agent同样重要。因为当WorkBuddy去访问乐享时，它拿到的就是这套结构，结构清晰，它的"导航"就顺。
2.3 接入方式的选择：API直连还是中间层
接入方式上，我试过两种：
第一种是API直连。WorkBuddy通过乐享开放的接口直接读取文档内容。这种方式最直接，延迟低，数据实时。缺点是耦合度高，乐享接口一变，WorkBuddy这边就得跟着改；而且每次查询都打接口，量大了对乐享也是压力。
第二种是加一层中间层。中间层定期把乐享的文档同步到本地（可以是文件系统，也可以是轻量数据库），WorkBuddy查本地。这种方式解耦好、查询快、对乐享压力小，缺点是有一点点同步延迟，而且中间层本身要维护。
我最后选的是混合方案：高频访问的稳定文档走中间层缓存，时效性要求高的走API直连。这样既保证了常用知识的查询速度，又保证了关键信息的实时性。具体怎么分，看你的实际访问模式，没有标准答案。
| 接入方式 | 延迟 | 实时性 | 维护成本 | 适用场景 |
|---|---|---|---|---|
| API直连 | 中 | 高 | 低 | 时效性要求高的查询 |
| 中间层缓存 | 低 | 中 | 中 | 高频访问的稳定文档 |
| 混合方案 | 低 | 高 | 中高 | 大多数生产场景 |
2.4 让Agent"读懂"乐享文档的几个处理细节
乐享里的文档格式五花八门，有纯文本、有带表格的、有嵌图的。直接丢给Agent，效果往往不好。我在中间层做了一些预处理：
- 表格转结构化：乐享里的表格如果直接转成文本，会变成一堆空格和竖线，模型很难理解。我把它转成Markdown表格或者JSON，模型读起来清楚多了。
- 图片单独处理：文档里的截图、流程图，纯文本提取是拿不到的。我的做法是把图片单独抽出来，配上说明文字，作为附件关联到文档。
- 长文档分段索引：一份几十页的文档，不要整篇塞给Agent。按章节切分，每段配上所属章节的标题作为上下文，这样Agent拿到的是"带标题的段落"，理解更准。
这些处理看起来琐碎，但实测下来对Agent的准确率影响很大。我做过对比，做了预处理的文档，Agent回答准确率比不处理的高出一截。
3. WorkBuddy侧的Agent编排：让知识真正"动起来"
3.1 给WorkBuddy定几条"全局规则"
WorkBuddy有个很实用的能力，就是可以给它定几条全局规则，后续所有任务都生效。这个功能我用得很多，因为它能把"知识库怎么用"这件事固化下来，不用每次任务都重复交代。
我给自己定的几条规则大致是这样的：
- 查知识先查乐享：任何需要背景信息的任务，第一步先去乐享查，而不是凭模型记忆瞎编。
- 引用要标来源：Agent给出的结论，凡是来自乐享的，要标明是哪份文档，方便我回溯核对。
- 查不到就说查不到：不允许Agent在乐享里没找到的情况下硬编一个答案，宁可说"没找到相关文档"。
- 敏感信息不外传：涉及权限的内容，Agent只能在授权范围内使用，不能出现在对外输出里。
这几条规则一设，Agent的行为就稳多了。尤其是"查不到就说查不到"这条，直接消灭了一大类幻觉问题。
3.2 一个具体的任务编排：从"问问题"到"出结果"
光说规则有点抽象，我拿一个实际任务走一遍。
任务背景：我需要定期整理一份"产品功能变更汇总"，数据来源是乐享里各个产品线的更新文档。
第一步，Agent去乐享定位相关文档。它根据我给的规则，在"产品"空间下按时间范围筛选出最近的更新文档。这一步靠的是乐享的目录结构和文档元数据。
第二步，Agent读取并提取关键信息。它把每份文档里的"变更点""影响范围""上线时间"提取出来。这里用到了前面说的预处理——文档结构清晰，提取就准。
第三步，Agent做汇总和去重。多个产品线可能有重叠的变更，Agent要合并同类项。
第四步，Agent生成汇总文档并回写。它把结果整理成一份新文档，写回乐享的指定目录。
整个流程走下来，我从"手动翻十几个文档"变成了"看一眼Agent的汇总结果"。这就是Agent编排的价值——它把知识库从"查询终点"变成了"任务起点"。
3.3 工具调用的边界：哪些事让Agent做，哪些不让
Agent能调工具是好事，但边界必须划清楚。我的原则是：
- 只读操作放开：查文档、读数据、搜索，这些放开让Agent做，风险低。
- 写操作要确认：回写文档、更新记录，这类操作我一般设成"需要确认"，Agent做完草稿我来点确认，避免它写错东西。
- 删除操作禁止：任何删除类操作，一律不给Agent权限。这个没得商量。
注意：Agent的权限设计要遵循"最小必要"原则。它能干的事越多，出错的破坏力越大。宁可多设几道确认，也别图省事全放开。
3.4 处理"Agent执行中断"这类常见故障
用Agent的人大概率都遇到过"agent execution terminated due to error"这种报错。我踩过几次，总结下来原因主要有几类：
- 工具调用超时：Agent调乐享接口，接口响应慢，超时了。解决办法是设合理的超时时间，加失败重试。
- 上下文超长：Agent读的文档太多，上下文爆了。解决办法是分段处理，别一次性喂太多。
- 权限不足：Agent访问了没权限的资源，被拒了。解决办法是提前核对权限配置。
- 格式解析失败：文档格式Agent解析不了，卡住了。解决办法是做好预处理，或者给Agent加格式兜底逻辑。
这类故障排查的核心思路是：看日志、定位是哪一步断的、针对性修。别一上来就怀疑模型不行，大多数时候是工程问题。
4. 实测下来，这套组合到底强在哪
4.1 对比纯RAG：准确率和可维护性的双赢
我拿同一批文档做过对比测试：一套走纯RAG（切块+向量检索），一套走"WorkBuddy+乐享"（结构化访问+Agent编排）。
结果上，准确率方面，结构化访问在需要跨文档综合的问题上明显更好，因为它保留了文档间的结构关系；在简单的单点查询上，两者差距不大。可维护性方面，结构化访问优势更大——文档更新了，乐享里改一下就行，不用重新索引向量库；而RAG那套，每次更新都要重新切块、重新向量化，维护成本高不少。
当然，结构化访问也不是没缺点。它对文档的组织质量要求高，如果乐享里文档乱七八糟，Agent导航也会乱。所以这套方案的前提是"你得先把知识整理好"。
4.2 几个真实场景的落地效果
场景一：新人培训问答。以前新人问"这个流程怎么走"，得找人问或者自己翻文档。现在直接问Agent，它去乐享查流程文档，给出答案还附上原文链接。实测下来，新人上手速度快了不少。
场景二：技术排错辅助。遇到报错，把错误信息丢给Agent，它去乐享的"排错"目录下找相似案例，给出排查建议。这个场景对知识库的"排错案例"积累要求高，积累得越多，Agent越有用。
场景三：定期报告生成。前面说的"功能变更汇总"就是这类。Agent自动去乐享拉数据、汇总、生成报告，人只需要审核。
这三个场景有个共同点：知识是结构化的、任务是重复的、结果是可验证的。满足这三点，Agent+知识库的组合就能发挥最大价值。
4.3 什么情况下这套组合会"翻车"
不是所有场景都适合。我踩过的翻车情况有：
- 知识库本身质量差：文档过时、结构混乱、命名随意，Agent查出来的东西自然不靠谱。这种时候先别怪Agent，先整理知识库。
- 任务太开放：让Agent"随便看看有什么值得关注的"，这种没有明确边界的任务，Agent容易跑偏。任务定义越清晰，效果越好。
- 权限没理清：Agent查到了不该查的东西，或者该查的查不到。这个前面强调过了，权限是前提。
- 期望过高：指望Agent完全替代人做决策。Agent是辅助，不是替代，关键决策还得人来拍板。
5. 一些实操中的经验与坑
5.1 文档命名和标签，比你想的重要
我一开始觉得文档命名是小事，后来发现Agent的检索质量跟命名强相关。Agent很多时候是靠标题和标签判断相关性的，标题起得含糊，它就得靠内容去猜，准确率就下来了。
我的做法是给文档定一套命名规范，比如"【类型】主题-版本-日期"，标签也统一管理。这套规范执行下来，Agent找文档的准确率提升很明显。
5.2 别让Agent一次读太多
上下文是有上限的，Agent一次读太多文档，要么爆上下文，要么被无关信息干扰。我的经验是按需读取、分段处理：先让Agent定位到最相关的几份文档，再逐份深入，而不是一次性全拉进来。
5.3 定期"体检"知识库
知识库不是建完就完事，得定期体检。我一般每个月做一次：检查有没有过时文档、有没有孤儿页面（没人链接的）、有没有重复内容。这些"垃圾"不清，Agent的准确率会慢慢下降。
5.4 给Agent的规则要"少而精"
全局规则不是越多越好。规则太多，Agent容易顾此失彼，反而不知道该听哪条。我的经验是控制在五条以内，每条都直击要害。前面说的那四条（先查乐享、标来源、查不到就说、敏感不外传），基本覆盖了核心诉求。
5.5 保留人工审核环节
不管Agent多能干，关键输出我都要人工过一遍。尤其是回写文档、对外发布这类操作，人工审核是最后一道防线。这不是不信任Agent，而是对结果负责。
6. 后续可以怎么扩展
这套组合跑顺之后，我还在琢磨几个扩展方向。
一个是把更多数据源接进来。现在主要是乐享，后面想把工单系统、代码仓库的文档也接进来，让Agent的知识面更广。思路是一样的：结构化访问，而不是无脑切块。
另一个是让Agent之间协作。比如一个Agent专门负责查知识，一个专门负责写报告，两者配合。WorkBuddy的编排能力支持这种多Agent协作，我还在摸索阶段。
还有一个是知识库的自动更新。让Agent定期扫描乐享，发现过时文档自动标记提醒，甚至自动生成更新草稿。这个能省不少维护精力。
我个人在实际操作中的体会是：知识库的价值不在于"存了多少"，而在于"能不能被用起来"。WorkBuddy和腾讯乐享这套组合，最大的意义就是让知识从"躺着"变成"干活"。工具是死的，怎么编排是活的，多试几次，你会找到适合自己团队的用法。
