知识库这东西很多人第一反应就是搭个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和腾讯乐享这套组合最大的意义就是让知识从躺着变成干活。工具是死的怎么编排是活的多试几次你会找到适合自己团队的用法。