1. 为什么要把 WorkBuddy 和腾讯乐享放在一起用1.1 一个真实场景引出的需求先说一个我自己的经历。团队里有个做售前支持的小组日常要处理大量客户提问问题五花八门从产品参数到部署细节从报价逻辑到售后流程。以前的做法是每个人自己存文档遇到问题翻聊天记录、翻邮件、翻本地文件夹找一份资料平均要花十几分钟还经常找到过期版本。后来公司上了腾讯乐享把产品手册、FAQ、培训材料、项目复盘都归档进去搜索确实方便了不少但新的问题又来了乐享是一个“人去找知识”的地方你得知道关键词、知道去哪个板块翻才能找到想要的东西。而一线同事最需要的其实是“知识主动来找我”——我在 WorkBuddy 里干活的时候顺手就能把乐享里的内容调出来甚至让 Agent 帮我读完、总结好、直接给答案。这就是 WorkBuddy 加腾讯乐享这个组合的价值所在。WorkBuddy 是一个面向个人和团队的智能工作台核心能力是 Agent 编排和任务执行腾讯乐享是企业级的协作与知识管理平台沉淀的是组织级的文档资产。把两者接起来等于给知识库装了一个“会干活的大脑”乐享负责存WorkBuddy 负责用Agent 负责在中间做检索、理解、加工和输出。1.2 这个组合到底解决了什么问题我把痛点拆成三层来看。第一层是检索效率。传统知识库的关键词搜索对“我知道我要找什么”的场景够用但对“我只知道我要解决什么问题”的场景就很吃力。比如新同事问“客户说部署完访问不了怎么办”他未必知道该搜“网络配置”还是“端口映射”还是“防火墙策略”。Agent 可以先把问题理解成意图再去乐享里做多轮检索把相关文档片段拼起来给出答案。第二层是知识加工。乐享里很多文档是长文一份产品白皮书几十页一线同事没时间通读。WorkBuddy 里的 Agent 可以先把文档拉过来做摘要、做要点提取、做问答对生成甚至把一份操作手册转成步骤清单。这一步的价值在于把“文档”变成“可直接执行的知识”。第三层是任务闭环。找到答案只是第一步真正干活还需要把答案变成动作。比如 Agent 读完乐享里的售后流程文档后可以直接在 WorkBuddy 里生成一张工单草稿、一段回复话术、一份检查清单。知识不再是终点而是任务的起点。1.3 适合谁来参考这套方案如果你属于下面几类人这套组合值得花时间研究。团队里已经有腾讯乐享但感觉“存了很多没人看”的知识库运营者。正在用 WorkBuddy 或类似 Agent 工作台想给它接一个靠谱知识源的开发者。负责企业内部知识管理、想让知识库从“档案室”变成“助手”的运营同学。对 RAG、Agent、LLM Wiki 这些概念有耳闻但不知道怎么落地到具体工具上的技术爱好者。需要说明的是下面讲到的具体配置路径和参数一部分来自我自己的实操记录一部分是基于同类工具常见实践做的合理推演。不同版本的 WorkBuddy 和乐享在界面和接口上可能有差异你照着做的时候以实际版本为准。2. 整体设计思路乐享当仓库WorkBuddy 当车间2.1 为什么不让 Agent 直接读乐享有人可能会问既然乐享自己有搜索为什么不直接让 Agent 调乐享的搜索接口就完事了我一开始也是这么想的实测下来发现不行原因有三个。第一乐享的搜索是面向人的返回的是文档列表和摘要不是结构化的知识片段。Agent 拿到一堆文档标题还得自己再进去读效率很低。第二乐享的权限体系是按人和部门走的Agent 以什么身份去读、能读到哪些内容需要单独设计。第三乐享里的文档格式很杂有 Word、有 PDF、有在线文档、有表格直接丢给模型效果不稳定。所以更合理的架构是乐享作为知识源WorkBuddy 作为加工和消费端中间加一层知识处理流水线。这层流水线负责把乐享里的文档同步出来、切分、向量化、建索引然后 WorkBuddy 里的 Agent 通过检索接口去拿加工好的知识片段。2.2 三种可行的对接方式根据团队的技术能力和数据敏感度我梳理了三种对接方式你可以按需选择。对接方式实现难度数据实时性适合场景手动导出加本地索引低差需定期更新个人使用、文档量小乐享开放接口加定时同步中较好可做到小时级团队使用、文档中等乐享接口加 WorkBuddy 知识库插件中高好可做到准实时企业使用、文档量大第一种方式最土但最稳把乐享里的文档导出成 Markdown 或 PDF放到本地文件夹用 WorkBuddy 的知识库功能建索引。适合个人先跑通流程。第二种方式是用乐享的开放接口写一个定时任务把文档拉下来做增量更新。第三种是直接在 WorkBuddy 里配置知识库连接器如果版本支持的话这是最省事的。我个人的建议是先用第一种方式跑通“检索加回答”的闭环确认效果后再升级到第二种。不要一上来就追求全自动容易在权限和格式上卡住。2.3 知识处理流水线的核心环节不管用哪种对接方式中间的知识处理逻辑是相通的。我把它拆成四个环节。抽取把乐享里的文档内容拿出来保留正文、标题、层级结构去掉页眉页脚、水印、导航栏这些噪音。这一步的难点在于格式兼容Word 和 PDF 的解析质量直接决定后续效果。切分把长文档切成适合模型处理的片段。切分不是越碎越好也不是越大越好。太碎会丢失上下文太大检索精度会下降。我的经验是中文文档按 300 到 500 字一段比较合适同时保留标题作为元数据。向量化把切分后的片段转成向量存到向量数据库里。这一步决定了检索的语义匹配能力。选哪个嵌入模型要看你的文档语言和领域中文场景下建议选对中文优化过的模型。索引与检索建好向量索引后Agent 提问时先把问题向量化去索引里找最相似的片段再把片段拼成上下文交给模型生成答案。这一步可以叠加关键词检索做混合召回效果通常比纯向量检索好。3. 核心细节解析与实操要点3.1 乐享文档的抽取与清洗乐享里的文档类型主要有在线文档、上传的 Office 文件、PDF 和表格。不同格式的抽取方式不一样。在线文档一般有导出功能可以导出成 Markdown 或 Word。我建议导出 Markdown因为结构保留得最好标题层级、列表、表格都能保留下来。导出的文件按板块建文件夹文件夹名就是知识分类这个分类信息后面可以当元数据用。上传的 Office 文件如果乐享支持在线预览说明它已经做过一次解析你可以直接用预览页的文本。如果不支持就得下载原文件用工具解析。Word 用 python-docxPDF 用 pdfplumber 或 PyMuPDF表格用 openpyxl 或 pandas。这里有个坑PDF 里的表格解析经常错位如果文档里表格很多建议人工抽查几份。清洗环节要重点处理三类噪音。一是页眉页脚每页都重复出现会污染检索结果。二是目录页对检索没价值还占位置。三是图片里的文字如果没做 OCR 就是空白如果做了 OCR 可能识别错误。我的做法是抽取时就把这些标记出来切分时直接跳过。# 一个简单的 PDF 文本抽取示例 import pdfplumber def extract_pdf_text(file_path): text_blocks [] with pdfplumber.open(file_path) as pdf: for page in pdf.pages: # 跳过疑似页眉页脚的区域 content page.crop((0, 50, page.width, page.height - 50)) text content.extract_text() if text: text_blocks.append(text) return \n.join(text_blocks)注意抽取出来的文本一定要人工抽查尤其是 PDF。我遇到过一份产品手册解析出来所有数字都变成了乱码原因是字体嵌入有问题。这种问题不抽查根本发现不了。3.2 切分策略与元数据设计切分这件事很多人随便按字数切结果检索效果很差。我的做法是按语义结构切按字数兜底。具体来说先按标题层级切。一级标题下的内容如果不超过 500 字就整块保留超过就按二级标题切还没有二级标题就按段落切。段落切的时候尽量在句号、问号、分号处断开不要把一个完整句子切成两半。元数据的设计同样重要。每个片段至少要带这几个字段来源文档名、所属分类、标题路径、更新时间。标题路径就是“产品手册 部署指南 网络配置”这样的层级串检索时可以把标题路径也做匹配提升准确率。元数据字段作用示例doc_name追溯来源售后流程手册 v3category分类过滤售后服务title_path层级定位售后流程 退换货 审核标准update_time时效判断2025-11-20chunk_id唯一标识doc_012_chunk_005有了这些元数据Agent 检索时就可以做过滤比如“只在售后服务分类里找”“只要最近半年更新的文档”。这比纯语义检索精准得多。3.3 向量化与检索参数怎么定向量化模型的选择中文场景我建议优先考虑对中文语义优化过的模型。如果团队有 GPU 资源可以本地部署如果没有用云服务接口也行但要注意数据合规。检索参数里最关键的是 top_k 和相似度阈值。top_k 是每次召回多少个片段太小可能漏掉关键信息太大则上下文超长、噪音变多。我的经验值是 top_k 取 5 到 8相似度阈值设在 0.7 左右。低于阈值的片段直接丢掉宁可少给也不要给错。还有一个技巧是混合检索。纯向量检索对语义相似但用词不同的情况好但对专有名词、型号、编号这类精确匹配反而弱。所以我会同时跑一路关键词检索把两路结果合并去重后再排序。实测下来混合检索的准确率比单路高不少。3.4 WorkBuddy 里 Agent 的编排要点知识准备好了接下来是在 WorkBuddy 里编排 Agent。核心是设计好 Agent 的工作流。一个典型的问答 Agent 流程是这样的接收用户问题判断是否需要查知识库如果需要就调用检索工具拿到片段后判断是否足够回答足够就生成答案不够就换个关键词再检索一次最多重试两轮。这个“判断加重试”的逻辑很关键很多 Agent 答不好就是因为检索一次没找到就放弃了。WorkBuddy 里可以给 Agent 设定规则比如“回答必须基于检索到的内容不要自己编”“如果检索结果里没有相关信息明确告诉用户没找到”。这些规则能显著降低幻觉。提示给 Agent 定规则的时候规则要具体、可执行。比如“不要编造”这种太抽象改成“如果检索结果为空回复‘知识库中暂未找到相关内容’”就明确多了。4. 完整实操流程从乐享导出到 Agent 回答4.1 第一步在乐享里整理知识分区动手之前先做一件事把乐享里的知识结构理清楚。不要急着导出先看看哪些板块是活跃的、哪些是废弃的。我见过太多团队把三年前的过期文档也导进去结果 Agent 拿过期信息回答反而帮倒忙。具体做法是按使用频率给板块排个序优先处理高频板块。每个板块里再挑出“权威版本”同一主题有多份文档的只保留最新最全的那份。这一步花的时间会在后面省回来。整理完之后给每个板块建一个对应的本地文件夹文件夹名和板块名一致。后面导出、切分、建索引都按这个结构走。4.2 第二步批量导出与格式统一乐享支持批量导出的话最好不支持就按板块逐个导出。导出格式统一选 Markdown如果只能导出 Word就用工具转成 Markdown。转换工具我常用 pandoc命令行一条命令搞定。# 把 Word 批量转成 Markdown for f in *.docx; do pandoc $f -o ${f%.docx}.md done转换完之后要检查一遍重点看标题层级有没有乱、表格有没有散、代码块有没有丢。pandoc 转换质量整体不错但复杂表格经常出问题需要手动修。4.3 第三步切分、向量化、建索引这一步可以用脚本批量做。我写过一个简单的流水线逻辑是遍历文件夹读 Markdown按标题切分生成元数据调嵌入接口拿向量存进向量库。import os import re from langchain.text_splitter import MarkdownHeaderTextSplitter def process_markdown(file_path, category): with open(file_path, r, encodingutf-8) as f: content f.read() headers_to_split_on [ (#, h1), (##, h2), (###, h3), ] splitter MarkdownHeaderTextSplitter(headers_to_split_onheaders_to_split_on) chunks splitter.split_text(content) results [] for i, chunk in enumerate(chunks): title_path .join([v for k, v in chunk.metadata.items() if v]) results.append({ doc_name: os.path.basename(file_path), category: category, title_path: title_path, chunk_id: f{os.path.basename(file_path)}_{i}, content: chunk.page_content }) return results切分完之后把 content 送去向量化把向量和元数据一起存进向量库。向量库选型上小规模用 FAISS 就够大规模可以考虑 Milvus 或 Qdrant。4.4 第四步在 WorkBuddy 里配置检索工具向量库建好后要在 WorkBuddy 里把它暴露成一个工具让 Agent 能调用。如果 WorkBuddy 支持自定义工具就写一个检索函数输入是查询文本输出是片段列表。如果不支持自定义工具可以退而求其次把检索结果预先导出成文件让 Agent 读文件。检索函数的逻辑是接收查询向量化去向量库找 top_k按阈值过滤返回片段和元数据。这里可以加一个重排序步骤用一个小的重排模型对召回结果再排一次精度会更高。4.5 第五步设计 Agent 的提示词与规则Agent 的提示词决定了它的行为。我的提示词模板大致是这样的你是一个企业知识助手负责基于知识库内容回答用户问题。 工作流程 1. 理解用户问题的核心意图 2. 调用知识检索工具用关键词和语义两种方式检索 3. 如果检索结果相关基于结果回答并标注来源文档 4. 如果检索结果不相关或为空明确告知用户未找到不要编造 5. 如果问题涉及操作步骤按步骤列出 回答要求 - 只使用检索到的内容不要引入外部知识 - 回答要简洁直接给结论 - 涉及数字、型号、日期要准确引用这套提示词实测下来幻觉明显减少回答也更聚焦。4.6 第六步测试与调优上线前一定要做测试。我一般准备三类问题一类是知识库里明确有的看能不能准确找到一类是知识库里没有的看会不会编造一类是模糊问题看能不能理解意图。测试中发现的问题大多出在检索环节。要么是切分太碎导致上下文丢失要么是 top_k 太小导致召回不足要么是阈值太高导致过滤太狠。针对性地调这几个参数通常能解决大部分问题。5. 常见问题与排查技巧实录5.1 检索不到内容怎么办这是最常见的问题。排查顺序是这样的先确认文档确实导进来了去向量库里搜一下原始文本再确认切分没问题看看片段内容是否完整然后确认向量化没问题拿一个已知片段的内容去检索看能不能召回自己最后确认查询没问题换个说法试试。如果都正常还是检索不到大概率是相似度阈值设太高了。把阈值降到 0.5 试试如果这时候能召回但质量差说明是切分或向量化的问题。5.2 Agent 回答带幻觉怎么治幻觉的来源有三个检索结果本身不相关、提示词没约束好、模型太强自作主张。对应的解法是提高检索精度、强化提示词约束、换一个更“听话”的模型。我自己的经验是提示词里加一句“如果检索结果中没有明确答案直接说不知道”效果立竿见影。另外让 Agent 在回答里标注来源文档名也能倒逼它基于事实回答。5.3 文档更新了知识库不同步这是同步机制的问题。如果是手动导出就得建立定期更新的习惯比如每周同步一次。如果是接口同步要检查增量逻辑是否正确有没有漏掉新增和修改的文档。一个实用的技巧是给每个片段加更新时间戳检索时优先返回新片段。这样即使有旧片段残留新内容也能排前面。问题现象可能原因排查方法解决方向检索结果为空阈值过高或切分过碎降低阈值测试调阈值、改切分回答内容过时知识库未同步检查文档更新时间建同步机制回答张冠李戴召回片段不相关查看召回内容加混合检索、重排序回答太长太啰嗦提示词未约束检查提示词加简洁性要求专有名词答错向量检索弱于精确匹配测试关键词检索加关键词召回5.4 权限和数据安全怎么处理企业知识库涉及权限Agent 不能无差别读取所有内容。我的做法是在元数据里加权限标签检索时根据调用者的身份过滤。比如财务文档只对财务角色可见Agent 检索时带上角色信息向量库查询时加过滤条件。数据安全方面如果文档敏感向量化和检索都建议本地部署不要走外部接口。嵌入模型选开源的向量库选可私有化部署的整条链路都在内网完成。5.5 几个我踩过的坑第一个坑是过度依赖自动切分。有次一批文档标题层级很乱自动切分出来的片段前言不搭后语检索效果极差。后来我加了一步人工检查把明显有问题的文档单独处理。第二个坑是忽略文档时效。知识库里混着新旧两版流程Agent 有时引用旧的导致回答错误。后来我在元数据里加了版本号和生效日期检索时优先取新版。第三个坑是提示词写太复杂。一开始我把提示词写得像一篇论文结果模型反而抓不住重点。后来精简成几条核心规则效果更好。提示词不是越长越好关键是清晰。第四个坑是测试用例太少。上线前只测了十几个问题觉得没问题就推了结果真实场景里问题千奇百怪暴露了一堆边界情况。后来我建了一个测试集每次调整参数都跑一遍稳定多了。6. 进阶玩法让知识库从“能查”到“能干”6.1 从问答到任务执行基础版是问答进阶版是任务执行。比如用户说“帮我给这个客户写一封售后跟进邮件”Agent 先去知识库检索售后流程和邮件模板然后基于模板和客户信息生成邮件草稿。这就把知识库从“查询工具”变成了“生产力工具”。实现的关键是给 Agent 配多个工具检索工具、模板工具、生成工具。Agent 根据任务类型自己决定调哪个。WorkBuddy 的 Agent 编排能力在这里就体现出来了。6.2 知识库加 LLM Wiki 的思路LLM Wiki 这个概念最近挺火核心思路是让模型自己维护一个结构化的知识页面而不是每次从原始文档里检索。具体做法是Agent 读完一批文档后生成一份结构化的 Wiki 页面包含概念定义、操作步骤、常见问题。下次提问时先查 WikiWiki 里没有再回原始文档。这样做的好处是检索更快、上下文更聚焦。坏处是 Wiki 需要维护文档更新后 Wiki 也得更新。我的做法是让 Agent 定期重新生成 Wiki或者文档变更时触发更新。6.3 多知识库联合检索一个团队往往有多个知识源乐享、内部 Wiki、工单系统、聊天记录。理想状态是 Agent 能同时查多个源综合给出答案。实现上可以给每个源建一个索引检索时并行查询结果合并排序。这里要注意的是不同源的权威性不一样。产品手册比聊天记录权威正式流程比个人笔记权威。可以在元数据里加一个权威性权重排序时加权。6.4 效果评估怎么做做完一套东西怎么知道好不好我一般看三个指标召回率、准确率、用户满意度。召回率是知识库里有的内容Agent 能不能找到。准确率是找到的内容回答得对不对。用户满意度最直接让真实用户用一段时间收集反馈。评估方法上可以建一个测试集每个问题标注标准答案和来源文档定期跑一遍看指标变化。这个测试集不用很大几十个高质量问题就够。7. 一些个人体会这套组合我前前后后折腾了大概两个月从最开始的“导出文档手动喂给模型”到后来的“接口同步加 Agent 自动检索”中间踩的坑比想象中多。最大的体会是知识库的效果不取决于模型多强而取决于知识本身整理得好不好。文档结构清晰、版本统一、分类合理检索效果自然好文档乱七八糟再强的模型也救不回来。另一个体会是不要追求一步到位。先跑通最小闭环哪怕就是手动导出加简单检索只要能解决一个具体问题就有价值。然后再逐步优化切分、加混合检索、加权限、加任务执行。每加一层都要验证效果不要堆功能。最后分享一个小技巧给 Agent 加一个“引用来源”的要求让它每次回答都标注来自哪份文档。这个动作有两个好处一是用户能自己核实二是倒逼 Agent 基于事实回答。实测下来加了引用要求之后幻觉率明显下降。这套方案后续还可以往几个方向扩展。一是接入更多知识源把工单、聊天、邮件都纳进来。二是做主动推送Agent 发现用户在做某个任务时主动把相关知识推过去。三是做知识沉淀把用户和 Agent 的问答记录整理成新的知识条目反哺知识库。这些方向我还在摸索有新的进展再分享。