1. 为什么要把 WorkBuddy 和腾讯乐享捏在一起用1.1 一个真实场景引出的需求先说个我自己的经历。团队里做技术文档沉淀已经有两年多了腾讯乐享上攒了大概四百多篇文档覆盖产品说明、接口规范、部署手册、故障复盘。按理说这是个挺像样的知识库了但实际用起来问题特别明显新人来了不知道搜什么关键词老员工找一份三个月前写过的配置说明得翻半天目录树跨部门协作的时候更是各搜各的同一个问题能问出三种答案。后来我接触到 WorkBuddy 这个工具第一反应就是——能不能让它直接吃腾讯乐享里的内容把人找文档变成人问问题Agent 给答案。试了一段时间之后发现这条路不仅走得通而且效果比我预想的好很多。所以这篇就把我踩过的坑、调过的参数、以及最终跑通的方案完整写出来。WorkBuddy 本质上是一个面向个人和团队的 AI 工作台支持接入多种知识源通过 Agent 的方式把知识库变成可对话、可执行任务的能力。腾讯乐享则是企业里常见的知识管理与协作平台文档、wiki、问答、直播回放都能往里塞。两者结合的核心价值在于乐享负责存WorkBuddy 负责用。存得再多用不起来就是死数据用得好四百篇文档能顶四千篇的效能。这套方案适合几类人一是团队里负责知识管理但苦于没人看的同学二是想给自己搭一个第二大脑的个人用户三是正在评估 Agent 落地场景、想找一个低门槛切入点的技术负责人。不管你是刚听说 WorkBuddy 还是已经在用乐享下面的内容都能直接抄作业。1.2 知识库的三种用法你处在哪一层在动手之前得先想清楚一件事你要的知识库到底是哪一种。我观察下来大部分团队的知识库使用水平分三层。第一层是文件柜模式。文档按目录分类靠搜索框找东西。这是最原始的形态乐享默认就是这个样子。问题是搜索依赖关键词匹配你搜部署失败可能搜不到标题叫环境初始化异常处理的文档。第二层是RAG 问答模式。把文档切片、向量化用户提问时检索相关片段喂给大模型生成答案。这是目前最主流的做法Dify 知识库流水线、各种开源知识库方案基本都在这个层面。好处是能理解语义坏处是切片策略没调好就容易答非所问而且它只答不做。第三层是Agent 执行模式。知识库不只是被查询的对象还能被 Agent 调用去完成具体任务——比如根据故障复盘文档自动生成检查清单根据接口规范自动写测试用例。WorkBuddy 的定位就在这一层它把知识库从资料变成了工具。我这次要做的就是把乐享里的第一层内容通过 WorkBuddy 拉到第三层去用。中间会经过第二层的 RAG 处理但终点是 Agent。1.3 整体架构长什么样说人话就是三块数据源、处理层、使用层。数据源就是腾讯乐享。乐享提供了开放接口可以按知识库、按目录、按文档维度拉取内容。我实测下来文档正文、附件、评论区的问答对都能拿到格式上 Markdown 和富文本混着来需要做一层清洗。处理层是 WorkBuddy 的知识库模块。它内部做的事情包括文档解析、分块、向量化、索引构建。这里有个关键选择是用 WorkBuddy 自带的向量模型还是接外部模型。我两种都试过自带模型胜在省事外部模型胜在可控。如果你的文档里有大量专业术语建议接外部 embedding 模型召回率会明显好一些。使用层就是 Agent。WorkBuddy 支持给 Agent 配技能Skill你可以理解成给 Agent 装插件。我配了三个技能一个是查文档一个是生成清单一个是对比差异。配好之后Agent 就能根据用户意图自动选择调用哪个技能而不是傻乎乎地只做问答。整个链路跑通之后最直观的变化是以前新人问这个接口的鉴权怎么做老员工得去乐享搜半天然后截图发过去现在新人直接在 WorkBuddy 里问Agent 不仅给出答案还能附上原文链接和相关的三个注意事项。效率提升不是一点半点。2. 动手之前必须搞清楚的几个核心概念2.1 WorkBuddy 到底是什么和 CodeBuddy 什么关系网上搜 WorkBuddy 的时候经常会看到 CodeBuddy很多人搞混。简单说CodeBuddy 是面向编码场景的助手WorkBuddy 是面向通用工作场景的工作台。两者底层可能共享一些能力但定位完全不同。WorkBuddy 更像是一个什么都能干一点的 Agent 容器你可以往里塞知识库、塞工具、塞规则让它按你的方式工作。我一开始也以为它就是个套壳的聊天界面用下来发现不是。它有几个设计挺关键一是规则系统你可以给 WorkBuddy 定几条规则后续对所有任务都生效比如回答必须引用原文出处不确定的内容必须标注。二是技能系统每个技能是一段可复用的能力封装。三是多知识库挂载可以同时挂乐享、本地文件夹、网页收藏夹Agent 会自己判断该查哪个。提示WorkBuddy 有国际版和国内版功能上略有差异。国内版对腾讯系产品的集成更顺国际版在模型选择上更灵活。选哪个看你的主要数据源在哪。2.2 腾讯乐享的接口能力边界乐享不是完全开放的它的接口需要企业管理员开通权限。我踩的第一个坑就是以为拿到 API Key 就能拉所有文档结果发现只能拉自己有权限访问的知识库。这其实是好事权限隔离做得严但也意味着你得提前规划好——用哪个账号去拉数据这个账号能看到哪些库。乐享接口大致分几类知识库列表、目录树、文档详情、附件下载、搜索。文档详情返回的是结构化数据正文部分可能是 Markdown 也可能是 HTML取决于原文档是怎么创建的。附件需要单独下载WorkBuddy 目前对附件的解析支持有限PDF 和 Word 还行Excel 和 PPT 效果一般。还有一个细节乐享的文档有版本概念。同一篇文档改过五次接口默认返回最新版但你可以指定版本号拉历史版本。我做知识库的时候只拉了最新版因为历史版本会把向量库搞得很乱检索时容易召回过期内容。2.3 RAG 和 LLM Wiki 的区别别被概念绕晕热词里有个LLM Wiki这个概念最近挺火Karpathy 提过类似的想法。它和传统 RAG 的区别在哪我理解是这样的传统 RAG 是切片-检索-拼接把文档切成小块用户问什么就捞最相关的几块拼起来喂给模型。问题是块与块之间的上下文丢了模型看到的是一堆碎片。LLM Wiki 的思路是让模型自己维护一个结构化的知识页面新信息进来时不是简单追加而是理解-整合-更新。有点像人写 wiki新知识要融进已有的条目里而不是另起一页。WorkBuddy 目前更偏 RAG但它的技能系统可以模拟一部分 LLM Wiki 的效果。比如我配了一个知识整合技能当新文档进来时Agent 会先读一遍已有的相关条目然后生成一个更新建议我确认后才写入。这样既保留了 RAG 的检索效率又有了一点 Wiki 的整合味道。注意不要一上来就追求 LLM Wiki 那种全自动整合容易把知识库搞乱。先跑通 RAG稳定之后再逐步加整合能力。2.4 Agent 在知识库场景里到底扮演什么角色很多人对 Agent 的理解还停留在会聊天的机器人。在知识库场景里Agent 的价值不在聊天在于编排。举个例子。用户问上周那个支付超时的问题解决了吗这个问题拆开看包含三个子任务一是找到上周的时间范围二是检索支付超时相关的故障文档三是判断文档里有没有已解决的标记。传统 RAG 只能做第二步Agent 能把三步串起来。WorkBuddy 的 Agent 支持多步推理你可以给它配一个任务分解的规则让它先把复杂问题拆成子问题再逐个去知识库里找答案。我实测下来配了任务分解规则的 Agent回答复杂问题的准确率比不配的高出大概三成。3. 从零搭建完整实操流程3.1 环境准备与 WorkBuddy 安装WorkBuddy 支持 Windows、macOS 和 Linux。我主力机是 Windows也在 Linux 服务器上装过一份做常驻服务。安装过程不复杂官网下载安装包一路下一步就行。Linux 版是命令行安装需要先装好 Node 环境。装完之后第一件事是登录和配置模型。WorkBuddy 支持多家模型我建议至少配两个一个能力强的做主推理一个速度快的做意图识别。意图识别用大模型是浪费用小模型又快又省。配置模型的地方在设置里的模型管理填 API Key 和 Base URL 就行。如果你用的是国内模型注意有些需要额外配置代理地址这个在官方文档里有说明。提示第一次装完先别急着接知识库用默认配置跑几个简单任务确认模型通了再往下走。我见过不少人卡在模型配置上以为是知识库的问题。3.2 腾讯乐享数据导出与清洗这一步是整个流程里最脏最累的但也是最关键的。数据质量不行后面怎么调都是白搭。我的做法是写一个 Python 脚本调乐享接口批量拉文档。核心逻辑是先拉知识库列表再对每个库拉目录树然后遍历目录树拉文档详情。拉下来的原始数据存成 JSON包含文档 ID、标题、正文、更新时间、作者、原文链接。清洗环节做四件事去重同一篇文档可能在多个目录下都有链接按文档 ID 去重。去噪去掉页眉页脚、导航栏、无关的样式标签。乐享导出的 HTML 里经常夹着一堆 div 和 span得用 BeautifulSoup 清一遍。分块按标题层级切一级标题切大块二级标题切小块。我试过固定长度切分效果不如按语义切。一般一块控制在 300 到 500 字比较合适。加元数据每块前面加上来源文档标题 章节标题这样检索出来的时候模型能知道上下文。# 简化的清洗逻辑示意 from bs4 import BeautifulSoup def clean_html(raw_html): soup BeautifulSoup(raw_html, html.parser) # 去掉脚本和样式 for tag in soup([script, style, nav, footer]): tag.decompose() text soup.get_text(separator\n) # 去掉多余空行 lines [l.strip() for l in text.split(\n) if l.strip()] return \n.join(lines) def chunk_by_heading(text, max_len500): # 按标题切分超长再按段落切 chunks [] current for para in text.split(\n): if len(current) len(para) max_len: chunks.append(current) current para else: current \n para if current: chunks.append(current) return chunks这段代码只是示意实际用的时候还得处理表格、代码块这些特殊结构。表格建议转成 Markdown 表格保留代码块要单独标记不然模型分不清正文和代码。3.3 在 WorkBuddy 里挂载知识库数据清洗完接下来是导入 WorkBuddy。它支持直接上传文件也支持通过 API 推送。文件多的话建议走 API我四百多篇文档手动传得传到天亮。导入的时候有几个参数要调参数建议值说明分块大小300-500 字太小丢上下文太大检索不准重叠长度50-80 字防止关键信息被切断向量模型专业领域选外部模型通用场景自带模型够用索引类型混合索引向量加关键词召回更稳导入完成后WorkBuddy 会显示索引状态。等状态变成就绪再开始测试不然检索结果会不全。3.4 给 Agent 配规则和技能这是最能体现 WorkBuddy 价值的一步。规则决定 Agent 的行为边界技能决定它能干什么。我配的规则大概是这样几条回答必须基于知识库内容知识库里没有的必须明说未找到相关文档不许编。引用内容必须附上来源文档标题和章节。涉及操作步骤的必须按顺序列出不许合并。遇到模糊问题先反问澄清不要猜。技能方面我配了三个文档检索技能输入问题输出相关文档片段和来源。清单生成技能输入一个主题输出结构化的检查清单。差异对比技能输入两个文档 ID输出差异点。配好之后Agent 会根据用户问题自动选技能。比如问部署流程是什么走检索技能问帮我生成一份上线检查清单走清单生成技能。提示规则不要一次配太多五条以内最好。规则太多 Agent 会顾此失彼反而变笨。先配最核心的两三条用一段时间再补。4. 实测效果与调优经验4.1 检索准确率怎么从六成提到九成刚跑通的时候检索准确率大概只有六成问十个问题有四个答偏。我花了大概两周时间调优最后稳定在九成左右。关键动作有三个。第一个是改分块策略。原来按固定长度切把一段完整的操作步骤切成了两半检索时只召回一半答案自然不全。改成按标题层级切之后完整步骤能整块召回准确率直接涨了一截。第二个是加关键词索引。纯向量检索对专业术语不敏感比如鉴权和认证在向量空间里很近但用户搜鉴权时期望的是精确匹配。加上关键词索引做混合检索专业术语的召回率明显改善。第三个是调重排。WorkBuddy 支持对检索结果做重排我接了一个重排模型把初步召回的二十条重新排序取前五条。这一步对最终答案质量影响很大因为喂给模型的上下文质量直接决定输出质量。4.2 常见问题速查表问题现象可能原因解决办法回答未找到相关文档但文档明明存在分块太小或索引未完成检查索引状态调大分块答案张冠李戴引用了不相关文档向量模型不匹配领域换专业领域 embedding 模型回答内容过时知识库里有历史版本只导入最新版删除旧版Agent 不调用技能直接瞎答规则没配好或技能描述不清检查技能触发条件描述导入速度极慢文档量太大或接口限流分批导入加延时附件内容检索不到附件未解析单独处理附件转成文本再导入4.3 几个我踩过的坑坑一以为导入就完事了。实际上导入只是开始索引构建需要时间文档越多越久。我四百篇文档大概等了二十分钟。这期间检索结果是不全的别急着测试。坑二忽略了权限。乐享的权限体系会带到 WorkBuddy 里。如果拉数据的账号只能看部分知识库那 Agent 也就只能答这部分。想覆盖全得用有全局权限的账号或者分账号拉多次。坑三规则写得太死。我一开始写了一条所有回答必须控制在两百字以内结果复杂问题答不全。后来改成简单问题简洁答复杂问题分点答效果好多了。坑四没做回归测试。调完参数之后没系统地测导致有些原来能答对的问题反而答错了。后来我建了一个测试集五十个典型问题每次调参都跑一遍确保不退化。5. 进阶玩法让知识库真正活起来5.1 从问答到执行Agent 自动生成文档跑通问答之后我试着让 Agent 做更多事。比如每周五让它读一遍本周新增的故障复盘文档自动生成一份本周问题汇总包括问题现象、根因、解决方案、预防措施。生成完直接推到乐享的一个专门目录里。这个玩法用到的就是 WorkBuddy 的技能编排能力。我配了一个定时任务每周五下午触发Agent 自动执行检索-汇总-生成-推送四步。省了我每周写周报的时间而且格式统一比人写的还规整。5.2 多知识库联动乐享加本地加网页WorkBuddy 支持同时挂多个知识源。我把乐享、本地的一个 Obsidian 库、还有一批网页收藏都挂上了。Agent 会根据问题类型自动选源问公司内部流程走乐享问个人笔记走本地库问行业动态走网页。这里有个技巧给每个知识源加一个领域标签在规则里写明涉及公司业务的优先查乐享。这样 Agent 选源的时候有依据不会乱查。5.3 知识库的自我更新机制最让我惊喜的是 Agent 的知识发现能力。我配了一个技能让它定期扫描知识库找出可能过时的文档——比如引用了已下线接口的、提到的人员已离职的、时间超过一年的。扫出来之后生成一份待更新清单我人工确认后决定改还是删。这个机制让知识库从只进不出变成了有进有出长期来看特别重要。不然知识库越堆越大质量越来越差最后没人用。6. 一些个人体会这套方案我跑了大概三个月最大的感受是知识库的价值不在于存了多少在于被用了多少次。以前乐享上的文档一个月可能被打开几十次现在通过 WorkBuddy每天都有几十次查询。数据没变用法变了价值就出来了。如果你也想试我的建议是从小处着手。别一上来就把所有文档都导进去先选一个最常用的知识库跑通流程调好参数用出效果了再扩展。我见过太多人一上来就搞大而全结果卡在数据清洗上就放弃了。另外Agent 不是万能的。它擅长的是从大量文档里快速找到相关信息并组织成答案不擅长的是判断这个答案对不对。所以关键决策还是得人来把关。把 Agent 当成一个特别勤快但需要复核的助手心态就对了。最后分享一个小技巧给 Agent 配一个不确定时说不确定的规则比配十条要准确的规则都管用。模型知道自己不知道的时候反而更可信。
WorkBuddy 与腾讯乐享集成：从 RAG 到 Agent 的知识库实战
1. 为什么要把 WorkBuddy 和腾讯乐享捏在一起用1.1 一个真实场景引出的需求先说个我自己的经历。团队里做技术文档沉淀已经有两年多了腾讯乐享上攒了大概四百多篇文档覆盖产品说明、接口规范、部署手册、故障复盘。按理说这是个挺像样的知识库了但实际用起来问题特别明显新人来了不知道搜什么关键词老员工找一份三个月前写过的配置说明得翻半天目录树跨部门协作的时候更是各搜各的同一个问题能问出三种答案。后来我接触到 WorkBuddy 这个工具第一反应就是——能不能让它直接吃腾讯乐享里的内容把人找文档变成人问问题Agent 给答案。试了一段时间之后发现这条路不仅走得通而且效果比我预想的好很多。所以这篇就把我踩过的坑、调过的参数、以及最终跑通的方案完整写出来。WorkBuddy 本质上是一个面向个人和团队的 AI 工作台支持接入多种知识源通过 Agent 的方式把知识库变成可对话、可执行任务的能力。腾讯乐享则是企业里常见的知识管理与协作平台文档、wiki、问答、直播回放都能往里塞。两者结合的核心价值在于乐享负责存WorkBuddy 负责用。存得再多用不起来就是死数据用得好四百篇文档能顶四千篇的效能。这套方案适合几类人一是团队里负责知识管理但苦于没人看的同学二是想给自己搭一个第二大脑的个人用户三是正在评估 Agent 落地场景、想找一个低门槛切入点的技术负责人。不管你是刚听说 WorkBuddy 还是已经在用乐享下面的内容都能直接抄作业。1.2 知识库的三种用法你处在哪一层在动手之前得先想清楚一件事你要的知识库到底是哪一种。我观察下来大部分团队的知识库使用水平分三层。第一层是文件柜模式。文档按目录分类靠搜索框找东西。这是最原始的形态乐享默认就是这个样子。问题是搜索依赖关键词匹配你搜部署失败可能搜不到标题叫环境初始化异常处理的文档。第二层是RAG 问答模式。把文档切片、向量化用户提问时检索相关片段喂给大模型生成答案。这是目前最主流的做法Dify 知识库流水线、各种开源知识库方案基本都在这个层面。好处是能理解语义坏处是切片策略没调好就容易答非所问而且它只答不做。第三层是Agent 执行模式。知识库不只是被查询的对象还能被 Agent 调用去完成具体任务——比如根据故障复盘文档自动生成检查清单根据接口规范自动写测试用例。WorkBuddy 的定位就在这一层它把知识库从资料变成了工具。我这次要做的就是把乐享里的第一层内容通过 WorkBuddy 拉到第三层去用。中间会经过第二层的 RAG 处理但终点是 Agent。1.3 整体架构长什么样说人话就是三块数据源、处理层、使用层。数据源就是腾讯乐享。乐享提供了开放接口可以按知识库、按目录、按文档维度拉取内容。我实测下来文档正文、附件、评论区的问答对都能拿到格式上 Markdown 和富文本混着来需要做一层清洗。处理层是 WorkBuddy 的知识库模块。它内部做的事情包括文档解析、分块、向量化、索引构建。这里有个关键选择是用 WorkBuddy 自带的向量模型还是接外部模型。我两种都试过自带模型胜在省事外部模型胜在可控。如果你的文档里有大量专业术语建议接外部 embedding 模型召回率会明显好一些。使用层就是 Agent。WorkBuddy 支持给 Agent 配技能Skill你可以理解成给 Agent 装插件。我配了三个技能一个是查文档一个是生成清单一个是对比差异。配好之后Agent 就能根据用户意图自动选择调用哪个技能而不是傻乎乎地只做问答。整个链路跑通之后最直观的变化是以前新人问这个接口的鉴权怎么做老员工得去乐享搜半天然后截图发过去现在新人直接在 WorkBuddy 里问Agent 不仅给出答案还能附上原文链接和相关的三个注意事项。效率提升不是一点半点。2. 动手之前必须搞清楚的几个核心概念2.1 WorkBuddy 到底是什么和 CodeBuddy 什么关系网上搜 WorkBuddy 的时候经常会看到 CodeBuddy很多人搞混。简单说CodeBuddy 是面向编码场景的助手WorkBuddy 是面向通用工作场景的工作台。两者底层可能共享一些能力但定位完全不同。WorkBuddy 更像是一个什么都能干一点的 Agent 容器你可以往里塞知识库、塞工具、塞规则让它按你的方式工作。我一开始也以为它就是个套壳的聊天界面用下来发现不是。它有几个设计挺关键一是规则系统你可以给 WorkBuddy 定几条规则后续对所有任务都生效比如回答必须引用原文出处不确定的内容必须标注。二是技能系统每个技能是一段可复用的能力封装。三是多知识库挂载可以同时挂乐享、本地文件夹、网页收藏夹Agent 会自己判断该查哪个。提示WorkBuddy 有国际版和国内版功能上略有差异。国内版对腾讯系产品的集成更顺国际版在模型选择上更灵活。选哪个看你的主要数据源在哪。2.2 腾讯乐享的接口能力边界乐享不是完全开放的它的接口需要企业管理员开通权限。我踩的第一个坑就是以为拿到 API Key 就能拉所有文档结果发现只能拉自己有权限访问的知识库。这其实是好事权限隔离做得严但也意味着你得提前规划好——用哪个账号去拉数据这个账号能看到哪些库。乐享接口大致分几类知识库列表、目录树、文档详情、附件下载、搜索。文档详情返回的是结构化数据正文部分可能是 Markdown 也可能是 HTML取决于原文档是怎么创建的。附件需要单独下载WorkBuddy 目前对附件的解析支持有限PDF 和 Word 还行Excel 和 PPT 效果一般。还有一个细节乐享的文档有版本概念。同一篇文档改过五次接口默认返回最新版但你可以指定版本号拉历史版本。我做知识库的时候只拉了最新版因为历史版本会把向量库搞得很乱检索时容易召回过期内容。2.3 RAG 和 LLM Wiki 的区别别被概念绕晕热词里有个LLM Wiki这个概念最近挺火Karpathy 提过类似的想法。它和传统 RAG 的区别在哪我理解是这样的传统 RAG 是切片-检索-拼接把文档切成小块用户问什么就捞最相关的几块拼起来喂给模型。问题是块与块之间的上下文丢了模型看到的是一堆碎片。LLM Wiki 的思路是让模型自己维护一个结构化的知识页面新信息进来时不是简单追加而是理解-整合-更新。有点像人写 wiki新知识要融进已有的条目里而不是另起一页。WorkBuddy 目前更偏 RAG但它的技能系统可以模拟一部分 LLM Wiki 的效果。比如我配了一个知识整合技能当新文档进来时Agent 会先读一遍已有的相关条目然后生成一个更新建议我确认后才写入。这样既保留了 RAG 的检索效率又有了一点 Wiki 的整合味道。注意不要一上来就追求 LLM Wiki 那种全自动整合容易把知识库搞乱。先跑通 RAG稳定之后再逐步加整合能力。2.4 Agent 在知识库场景里到底扮演什么角色很多人对 Agent 的理解还停留在会聊天的机器人。在知识库场景里Agent 的价值不在聊天在于编排。举个例子。用户问上周那个支付超时的问题解决了吗这个问题拆开看包含三个子任务一是找到上周的时间范围二是检索支付超时相关的故障文档三是判断文档里有没有已解决的标记。传统 RAG 只能做第二步Agent 能把三步串起来。WorkBuddy 的 Agent 支持多步推理你可以给它配一个任务分解的规则让它先把复杂问题拆成子问题再逐个去知识库里找答案。我实测下来配了任务分解规则的 Agent回答复杂问题的准确率比不配的高出大概三成。3. 从零搭建完整实操流程3.1 环境准备与 WorkBuddy 安装WorkBuddy 支持 Windows、macOS 和 Linux。我主力机是 Windows也在 Linux 服务器上装过一份做常驻服务。安装过程不复杂官网下载安装包一路下一步就行。Linux 版是命令行安装需要先装好 Node 环境。装完之后第一件事是登录和配置模型。WorkBuddy 支持多家模型我建议至少配两个一个能力强的做主推理一个速度快的做意图识别。意图识别用大模型是浪费用小模型又快又省。配置模型的地方在设置里的模型管理填 API Key 和 Base URL 就行。如果你用的是国内模型注意有些需要额外配置代理地址这个在官方文档里有说明。提示第一次装完先别急着接知识库用默认配置跑几个简单任务确认模型通了再往下走。我见过不少人卡在模型配置上以为是知识库的问题。3.2 腾讯乐享数据导出与清洗这一步是整个流程里最脏最累的但也是最关键的。数据质量不行后面怎么调都是白搭。我的做法是写一个 Python 脚本调乐享接口批量拉文档。核心逻辑是先拉知识库列表再对每个库拉目录树然后遍历目录树拉文档详情。拉下来的原始数据存成 JSON包含文档 ID、标题、正文、更新时间、作者、原文链接。清洗环节做四件事去重同一篇文档可能在多个目录下都有链接按文档 ID 去重。去噪去掉页眉页脚、导航栏、无关的样式标签。乐享导出的 HTML 里经常夹着一堆 div 和 span得用 BeautifulSoup 清一遍。分块按标题层级切一级标题切大块二级标题切小块。我试过固定长度切分效果不如按语义切。一般一块控制在 300 到 500 字比较合适。加元数据每块前面加上来源文档标题 章节标题这样检索出来的时候模型能知道上下文。# 简化的清洗逻辑示意 from bs4 import BeautifulSoup def clean_html(raw_html): soup BeautifulSoup(raw_html, html.parser) # 去掉脚本和样式 for tag in soup([script, style, nav, footer]): tag.decompose() text soup.get_text(separator\n) # 去掉多余空行 lines [l.strip() for l in text.split(\n) if l.strip()] return \n.join(lines) def chunk_by_heading(text, max_len500): # 按标题切分超长再按段落切 chunks [] current for para in text.split(\n): if len(current) len(para) max_len: chunks.append(current) current para else: current \n para if current: chunks.append(current) return chunks这段代码只是示意实际用的时候还得处理表格、代码块这些特殊结构。表格建议转成 Markdown 表格保留代码块要单独标记不然模型分不清正文和代码。3.3 在 WorkBuddy 里挂载知识库数据清洗完接下来是导入 WorkBuddy。它支持直接上传文件也支持通过 API 推送。文件多的话建议走 API我四百多篇文档手动传得传到天亮。导入的时候有几个参数要调参数建议值说明分块大小300-500 字太小丢上下文太大检索不准重叠长度50-80 字防止关键信息被切断向量模型专业领域选外部模型通用场景自带模型够用索引类型混合索引向量加关键词召回更稳导入完成后WorkBuddy 会显示索引状态。等状态变成就绪再开始测试不然检索结果会不全。3.4 给 Agent 配规则和技能这是最能体现 WorkBuddy 价值的一步。规则决定 Agent 的行为边界技能决定它能干什么。我配的规则大概是这样几条回答必须基于知识库内容知识库里没有的必须明说未找到相关文档不许编。引用内容必须附上来源文档标题和章节。涉及操作步骤的必须按顺序列出不许合并。遇到模糊问题先反问澄清不要猜。技能方面我配了三个文档检索技能输入问题输出相关文档片段和来源。清单生成技能输入一个主题输出结构化的检查清单。差异对比技能输入两个文档 ID输出差异点。配好之后Agent 会根据用户问题自动选技能。比如问部署流程是什么走检索技能问帮我生成一份上线检查清单走清单生成技能。提示规则不要一次配太多五条以内最好。规则太多 Agent 会顾此失彼反而变笨。先配最核心的两三条用一段时间再补。4. 实测效果与调优经验4.1 检索准确率怎么从六成提到九成刚跑通的时候检索准确率大概只有六成问十个问题有四个答偏。我花了大概两周时间调优最后稳定在九成左右。关键动作有三个。第一个是改分块策略。原来按固定长度切把一段完整的操作步骤切成了两半检索时只召回一半答案自然不全。改成按标题层级切之后完整步骤能整块召回准确率直接涨了一截。第二个是加关键词索引。纯向量检索对专业术语不敏感比如鉴权和认证在向量空间里很近但用户搜鉴权时期望的是精确匹配。加上关键词索引做混合检索专业术语的召回率明显改善。第三个是调重排。WorkBuddy 支持对检索结果做重排我接了一个重排模型把初步召回的二十条重新排序取前五条。这一步对最终答案质量影响很大因为喂给模型的上下文质量直接决定输出质量。4.2 常见问题速查表问题现象可能原因解决办法回答未找到相关文档但文档明明存在分块太小或索引未完成检查索引状态调大分块答案张冠李戴引用了不相关文档向量模型不匹配领域换专业领域 embedding 模型回答内容过时知识库里有历史版本只导入最新版删除旧版Agent 不调用技能直接瞎答规则没配好或技能描述不清检查技能触发条件描述导入速度极慢文档量太大或接口限流分批导入加延时附件内容检索不到附件未解析单独处理附件转成文本再导入4.3 几个我踩过的坑坑一以为导入就完事了。实际上导入只是开始索引构建需要时间文档越多越久。我四百篇文档大概等了二十分钟。这期间检索结果是不全的别急着测试。坑二忽略了权限。乐享的权限体系会带到 WorkBuddy 里。如果拉数据的账号只能看部分知识库那 Agent 也就只能答这部分。想覆盖全得用有全局权限的账号或者分账号拉多次。坑三规则写得太死。我一开始写了一条所有回答必须控制在两百字以内结果复杂问题答不全。后来改成简单问题简洁答复杂问题分点答效果好多了。坑四没做回归测试。调完参数之后没系统地测导致有些原来能答对的问题反而答错了。后来我建了一个测试集五十个典型问题每次调参都跑一遍确保不退化。5. 进阶玩法让知识库真正活起来5.1 从问答到执行Agent 自动生成文档跑通问答之后我试着让 Agent 做更多事。比如每周五让它读一遍本周新增的故障复盘文档自动生成一份本周问题汇总包括问题现象、根因、解决方案、预防措施。生成完直接推到乐享的一个专门目录里。这个玩法用到的就是 WorkBuddy 的技能编排能力。我配了一个定时任务每周五下午触发Agent 自动执行检索-汇总-生成-推送四步。省了我每周写周报的时间而且格式统一比人写的还规整。5.2 多知识库联动乐享加本地加网页WorkBuddy 支持同时挂多个知识源。我把乐享、本地的一个 Obsidian 库、还有一批网页收藏都挂上了。Agent 会根据问题类型自动选源问公司内部流程走乐享问个人笔记走本地库问行业动态走网页。这里有个技巧给每个知识源加一个领域标签在规则里写明涉及公司业务的优先查乐享。这样 Agent 选源的时候有依据不会乱查。5.3 知识库的自我更新机制最让我惊喜的是 Agent 的知识发现能力。我配了一个技能让它定期扫描知识库找出可能过时的文档——比如引用了已下线接口的、提到的人员已离职的、时间超过一年的。扫出来之后生成一份待更新清单我人工确认后决定改还是删。这个机制让知识库从只进不出变成了有进有出长期来看特别重要。不然知识库越堆越大质量越来越差最后没人用。6. 一些个人体会这套方案我跑了大概三个月最大的感受是知识库的价值不在于存了多少在于被用了多少次。以前乐享上的文档一个月可能被打开几十次现在通过 WorkBuddy每天都有几十次查询。数据没变用法变了价值就出来了。如果你也想试我的建议是从小处着手。别一上来就把所有文档都导进去先选一个最常用的知识库跑通流程调好参数用出效果了再扩展。我见过太多人一上来就搞大而全结果卡在数据清洗上就放弃了。另外Agent 不是万能的。它擅长的是从大量文档里快速找到相关信息并组织成答案不擅长的是判断这个答案对不对。所以关键决策还是得人来把关。把 Agent 当成一个特别勤快但需要复核的助手心态就对了。最后分享一个小技巧给 Agent 配一个不确定时说不确定的规则比配十条要准确的规则都管用。模型知道自己不知道的时候反而更可信。
