1. 从一条工作流说起为什么我把 WorkBuddy 和腾讯乐享接在了一起第一次接触 WorkBuddy 是在一个内部工具选型的讨论上。当时团队面临的问题很具体日常沉淀在腾讯乐享里的文档、SOP、会议纪要越来越多但真正要用的时候找起来还是靠关键词硬搜搜出来的结果要么版本不对要么上下文缺失新人上手基本靠“问老人”。而 WorkBuddy 这类 Agent 工作台的出现恰好提供了一个把“静态文档”变成“可调用能力”的入口。这个组合的核心逻辑其实不复杂腾讯乐享负责“存”WorkBuddy 负责“用”。乐享本身是一个企业级知识管理与协作平台文档、Wiki、问答、直播回放都能往里放权限体系也相对完整WorkBuddy 则是一个 Agent 编排与执行的工作台可以理解为一个“能调用工具、能读知识、能按规则干活”的智能体运行环境。把两者接起来之后知识库就不再是一个只能“看”的仓库而是一个能被 Agent 主动查询、引用、组合、输出的活体资源。我之所以觉得这个方向值得写是因为它解决了一个很普遍的痛点大部分团队的知识库都死于“只进不出”。文档写完了没人看看了也找不到重点找到了也不知道怎么用。而 Agent 的介入让知识库第一次有了“被使用”的闭环——你问一个问题Agent 去乐享里检索相关文档结合上下文给出答案甚至能直接生成一份可执行的方案。这篇文章适合三类人看一是正在折腾企业知识库、想让文档真正被用起来的运营或技术同学二是对 Agent 工作流感兴趣、想找一个具体场景练手的开发者三是单纯好奇“WorkBuddy 到底能干什么”的普通用户。我会从整体设计思路、核心细节、实操过程、常见问题四个维度展开尽量把每一步的“为什么”讲清楚让你看完能直接照着搭一套。2. 整体设计思路为什么是 WorkBuddy 加腾讯乐享而不是别的组合2.1 知识库的“存”与“用”为什么要分开很多人一上来就想找一个“全能工具”既能存文档又能跑 Agent最好还自带 RAG。但实际用下来会发现存储和调用这两个环节的诉求是冲突的。存储侧要的是稳定、权限清晰、版本可追溯、多人协作方便调用侧要的是灵活、可编排、能接各种模型和工具、响应快。硬塞在一个系统里往往两头都不讨好。腾讯乐享在“存”这一侧的优势很明显它本身就是企业微信生态里的东西文档、Wiki、问答、培训材料都能统一管理权限可以细到部门、角色、单篇文档。你不需要额外搭建一套存储系统也不用担心员工不愿意用——它就在日常工作流里。而 WorkBuddy 在“用”这一侧更专注它不负责存文档而是负责定义 Agent 的行为、编排工具调用、管理上下文。两者通过 API 或连接器打通各干各擅长的事。这个思路其实和现在流行的“RAG 知识库流水线”是一个道理先把文档切块、向量化、建索引再让 LLM 去检索和生成。只不过 WorkBuddy 把这条流水线封装成了更上层的 Agent 工作流你不需要自己写检索逻辑只需要定义“什么时候去查乐享、查什么、查到之后怎么处理”。2.2 Agent 在这个组合里到底扮演什么角色Agent 不是简单的“问答机器人”。在这个场景里它至少承担四个职责意图识别判断用户的问题是需要查文档、还是需要执行操作、还是两者都要。检索编排决定去乐享的哪个知识库查、用关键词还是语义检索、要不要做多轮召回。上下文组装把检索到的文档片段、历史对话、系统提示词拼成一个完整的 prompt。结果生成与校验输出答案并在必要时标注引用来源甚至反向写入乐享作为新条目。WorkBuddy 的工作台模式让这些职责可以拆开配置。你可以给 Agent 定几条规则比如“所有涉及产品参数的问题必须先查乐享的‘产品文档’知识库”“如果检索结果置信度低于阈值直接回复‘需要人工确认’而不是瞎编”。这些规则一旦设定后续对所有任务都生效不需要每次重新交代。2.3 为什么不用纯 RAG 方案而要引入 Agent纯 RAG 方案比如 Dify 的知识库流水线、Obsidian 加插件搭建的本地知识库能解决“检索增强生成”的问题但它的交互模式是“一问一答”缺乏主动性和多步执行能力。而 Agent 可以做到先查文档发现文档里提到另一个文档再去查那个文档最后综合两份文档给出答案。这种多跳检索和工具调用的能力是纯 RAG 做不到的。另外Agent 还能处理“非问答类”任务。比如你让它“根据乐享里的会议纪要生成一份下周的工作计划”它需要先检索纪要、提取待办事项、按优先级排序、再输出结构化结果。这已经超出了 RAG 的范畴更接近一个“知识驱动的执行体”。WorkBuddy 的 skill 机制和工具编排能力正好支撑这类场景。3. 核心细节解析打通 WorkBuddy 与腾讯乐享的关键环节3.1 乐享侧的准备知识库结构比文档数量更重要在接 WorkBuddy 之前我花了两天时间重新整理乐享里的知识库结构。这一步很多人会跳过直接拿现有文档去接结果检索效果很差。原因很简单乐享的文档是按“人”的逻辑组织的而 Agent 需要的是按“问题”的逻辑组织。具体来说我做了三件事第一把知识库按主题拆分。原来是一个大库叫“公司文档”里面什么都有。我拆成了“产品文档”“技术方案”“运营 SOP”“客户案例”“会议纪要”五个子库。每个子库的文档风格和检索需求不一样拆开之后 Agent 可以按需选择查哪个库。第二给每篇文档补元数据。乐享支持给文档打标签和写摘要我要求团队在每篇文档头部加一段 100 字以内的摘要说明这篇文档解决什么问题、适合谁看、最后更新是什么时候。这段摘要会被 WorkBuddy 在检索时优先读取相当于给每篇文档做了一个“索引卡片”。第三统一术语。同一个概念在不同文档里有不同叫法比如“用户画像”有的写“客户画像”有的写“用户标签”。我在乐享里建了一个术语表文档把所有同义词映射关系列出来WorkBuddy 在检索前会先查这个术语表做查询扩展。提示乐享的权限体系要和 WorkBuddy 的服务账号对齐。如果 WorkBuddy 用的账号没有某个子库的读取权限检索会直接返回空结果而且不会报错排查起来很费时间。3.2 WorkBuddy 侧的配置Agent 规则怎么定才有效WorkBuddy 的工作台里Agent 的行为由几部分组成系统提示词、工具列表、规则集、上下文管理策略。我重点说规则集因为这是最容易踩坑的地方。规则不是越多越好。我一开始写了二十多条规则结果 Agent 经常在规则之间“打架”比如一条规则说“优先查产品文档”另一条说“涉及技术细节必须查技术方案”遇到一个既涉及产品又涉及技术的问题就卡住了。后来我精简到六条核心规则按优先级排序所有事实性回答必须基于乐享检索结果不得凭空生成。检索时先查术语表做查询扩展再查对应子库。如果检索结果少于两条降低置信度并提示用户补充信息。涉及数字、日期、版本号的内容必须原文引用并标注来源文档。如果用户问题涉及多个子库按“产品→技术→运营”的顺序依次检索。每次回答结束后询问用户是否需要将本次问答沉淀为新文档。这六条规则覆盖了大部分场景而且优先级明确Agent 不会无所适从。WorkBuddy 支持给规则设权重我把第一条的权重设得最高确保“不瞎编”这个底线不会被其他规则覆盖。3.3 检索策略关键词、语义、还是混合WorkBuddy 连接乐享后检索方式通常有三种可选关键词匹配、向量语义检索、混合检索。我实测下来混合检索在知识库场景下效果最稳。纯关键词检索的问题是“词不达意”。用户问“怎么申请报销”文档里写的是“费用核销流程”关键词匹配不上。纯语义检索的问题是“过度联想”。用户问“报销标准”语义检索可能把“差旅补贴”“招待费限额”“采购审批”全召回来噪音太大。混合检索的做法是先用关键词做粗筛再用语义做精排。WorkBuddy 的检索配置里可以设一个“召回数量”和“精排数量”我一般设召回 20 条、精排 5 条。这样既保证了召回率又控制了噪音。另外乐享的文档如果带了标签可以在检索时加权比如“产品文档”子库的权重设 1.2“会议纪要”设 0.8因为纪要的时效性强但准确性弱。3.4 上下文窗口的管理别让 Agent 被文档淹死乐享里的文档动辄几千字如果直接把整篇文档塞进上下文Agent 的注意力会被稀释回答质量反而下降。我的做法是只取文档中最相关的段落并且限制总长度。WorkBuddy 支持在检索后做“片段提取”你可以设一个最大 token 数比如 3000 token超出部分自动截断。截断策略我选的是“首尾保留、中间摘要”因为很多文档的核心结论在开头和结尾中间是论证过程。如果文档有摘要字段优先用摘要替代全文。还有一个细节多轮对话时历史上下文也要控制。我设的是只保留最近三轮对话更早的对话做摘要压缩。否则聊到第十轮的时候上下文里全是历史对话新检索到的文档反而被挤掉了。4. 实操过程从零搭建一套可用的知识库 Agent4.1 环境准备与账号打通先确认两边的账号体系。腾讯乐享这边需要一个有 API 访问权限的服务账号建议单独建一个不要用个人账号方便后续权限管理和审计。WorkBuddy 这边如果是国际版注意时区和语言设置中文文档检索时语言参数要设成 zh否则分词效果会差很多。账号打通的方式一般有两种OAuth 授权或 API Key。我选的是 API Key因为配置简单而且可以在乐享侧限制这个 Key 只能读不能写。Key 的权限范围要仔细勾选至少需要“文档读取”“知识库列表”“标签读取”这三项。如果后续要让 Agent 反向写入再加“文档创建”权限。注意API Key 不要直接写在 WorkBuddy 的配置文件里明文存储。WorkBuddy 支持环境变量引用把 Key 放在环境变量里配置文件里只写变量名。4.2 在 WorkBuddy 里创建知识库连接器WorkBuddy 的工作台里有一个“数据源”或“连接器”的入口选“腾讯乐享”之后填 API Key、选择要连接的知识库可以多选、设置同步频率。同步频率我设的是每小时一次因为乐享里的文档更新不算频繁实时同步没必要反而增加 API 调用压力。同步方式有两种全量同步和增量同步。第一次肯定是全量之后走增量。增量同步依赖乐享的文档更新时间戳WorkBuddy 会记录上次同步的时间点只拉取之后有更新的文档。这里有个坑如果文档被删除增量同步不会自动删除 WorkBuddy 侧的索引需要手动触发一次全量同步来清理。连接器建好之后WorkBuddy 会显示已同步的文档数量和索引状态。我建议先拿一个小的子库做测试确认检索结果正常之后再接大库。4.3 定义 Agent 的 skill 和工具链WorkBuddy 的 skill 机制允许你把一组操作封装成一个可复用的能力。我定义了三个核心 skillknowledge_search输入查询词返回乐享检索结果含文档标题、摘要、相关片段、来源链接。term_expand输入原始查询返回扩展后的查询词列表基于术语表。answer_with_citation输入检索结果和用户问题生成带引用的回答。这三个 skill 串起来就是一个完整的“检索-扩展-生成”流水线。WorkBuddy 支持在 skill 之间传参比如 term_expand 的输出直接作为 knowledge_search 的输入。工具链的编排可以在可视化界面里拖拽完成也可以写 YAML 配置。我两种都试过复杂逻辑还是写配置更清晰。4.4 参数计算召回数量与置信度阈值怎么定召回数量不是拍脑袋定的。我的方法是拿 20 个典型问题做测试集分别设召回 5、10、20、50 条看最终回答的准确率。实测下来召回 20 条时准确率最高再往上增加召回数量准确率反而下降因为噪音变多了。置信度阈值也是类似的方法。WorkBuddy 会给每条检索结果一个相关性分数我设的阈值是 0.65。低于这个分数的结果不进入生成环节Agent 直接回复“未找到足够相关的文档请补充信息或联系人工”。这个阈值可以根据业务容忍度调整客服场景可以设低一点0.5法务场景设高一点0.8。参数测试值最终选择选择理由召回数量5/10/20/5020准确率峰值噪音可控精排数量3/5/105兼顾覆盖率和上下文长度置信度阈值0.5/0.65/0.80.65平衡准确率和召回率上下文最大 token2000/3000/50003000避免注意力稀释历史对话轮数1/3/53保留必要上下文4.5 测试与调优用真实问题跑一轮搭好之后不要急着上线先拿真实问题跑一轮。我收集了团队里最常被问的 30 个问题比如“报销流程是什么”“产品 X 的 API 限流是多少”“上周会议定了哪几件事”逐个测试 Agent 的回答。测试时重点看三个指标回答准确率、引用完整率、拒答率。准确率靠人工判断引用完整率看 Agent 有没有标注来源文档拒答率看有多少问题因为检索不到而没回答。我第一轮测试的拒答率是 40%太高了排查发现是术语表没覆盖全很多查询词没有对应的扩展词。补了一轮术语表之后拒答率降到 15%。调优是个迭代过程不要指望一次到位。我的经验是先解决拒答率再解决准确率最后优化引用格式。拒答率高说明检索环节有问题准确率低说明生成环节有问题引用格式是锦上添花。5. 常见问题与排查技巧实录5.1 检索结果为空或明显不相关这是最常见的问题排查顺序如下先确认 WorkBuddy 的服务账号有没有对应知识库的读取权限。乐享的权限是继承的如果子库设了部门限制服务账号不在那个部门里就读不到。这个不会报错只会返回空结果。再确认文档是否已经同步到 WorkBuddy。连接器的同步日志里会显示每次同步的文档数量如果某个子库的文档数量是 0说明同步没成功。可能是 API Key 权限不够也可能是子库 ID 填错了。最后检查查询词。如果用户用的是口语化表达而文档里全是专业术语关键词匹配就会失败。这时候术语表就派上用场了。我建议术语表至少覆盖 200 个常用词并且定期更新。5.2 Agent 回答“编造”内容Agent 编造内容通常是因为检索结果置信度低但生成环节没有正确拒答。排查两个地方一是置信度阈值是不是设得太低二是系统提示词里有没有明确“不得凭空生成”的规则。我遇到过一次Agent 在检索结果只有一条且分数 0.55 的情况下仍然生成了一段看起来很合理的回答。后来发现是规则集的优先级问题有一条规则说“尽量给出回答”权重设得比“不得凭空生成”还高。把权重调过来之后问题就解决了。提示WorkBuddy 的规则权重是数值越大优先级越高默认都是 1.0。涉及安全底线的规则建议设到 2.0 以上。5.3 多轮对话后回答质量下降多轮对话时历史上下文会占用大量 token导致新检索到的文档被挤掉。解决办法是限制历史对话轮数并且对历史对话做摘要压缩。WorkBuddy 支持配置“历史压缩”策略我设的是超过三轮之后把最早的两轮对话压缩成一句话摘要。另外如果用户在对话中切换了话题最好手动重置上下文。WorkBuddy 有一个“清空上下文”的指令可以在 Agent 规则里加一条如果检测到用户问题与上一轮主题差异过大自动清空历史。5.4 同步延迟导致答案过时乐享里的文档更新后WorkBuddy 不会立即感知要等下一次同步。如果业务对时效性要求高可以把同步频率调到 15 分钟一次但要注意 API 调用配额。另一个办法是在 Agent 回答时加一句“本回答基于 X 时间点的文档版本”让用户知道时效边界。如果某篇文档特别重要且更新频繁可以在 WorkBuddy 里给它设一个“优先同步”标记连接器会单独处理这篇文档不等待全量同步周期。5.5 常见问题速查表问题现象可能原因排查动作解决方式检索结果为空权限不足/未同步/查询词不匹配检查账号权限、同步日志、术语表补权限、手动同步、扩展查询词回答编造内容置信度阈值低/规则权重错查看检索分数、规则优先级调高阈值、调整规则权重多轮后质量下降上下文超限查看 token 使用量限制历史轮数、启用压缩答案过时同步延迟检查最后同步时间提高同步频率、加时效标注引用链接失效文档被移动或删除检查乐享文档状态重新同步、更新引用映射5.6 几个我踩过的坑第一个坑是文档格式不统一。乐享里的文档有 Markdown、富文本、表格、附件WorkBuddy 在解析时对表格和附件的支持有限。我的做法是把关键表格转成 Markdown 表格附件里的内容如果重要单独摘出来写成文档。第二个坑是同义词没有覆盖。比如“登录”和“登陆”、“账号”和“账户”用户输入哪个都有可能。术语表里要把这些变体都列上否则检索会漏。第三个坑是Agent 过度引用。有一次 Agent 回答一个简单问题引用了五篇文档其中三篇完全不相关。后来我在规则里加了一条引用文档不超过三篇且必须按相关性排序。这样回答更简洁用户也更容易验证。第四个坑是忘记关掉测试环境的自动写入。测试阶段我开了 Agent 反向写入乐享的权限结果测试问题产生的问答被写进了正式知识库污染了文档。后来改成测试环境只读写入操作必须人工确认。6. 这套组合还能怎么扩展跑通基础流程之后我陆续加了一些扩展能力效果不错这里简单提几个方向。一个是多知识库联合检索。除了乐享还可以接本地的 Obsidian 库、Dify 的知识库流水线WorkBuddy 支持配置多个数据源Agent 会根据问题类型自动选择查哪个源。比如产品问题查乐享技术方案查本地库客户案例查 Dify。另一个是Agent 主动沉淀。每次问答结束后Agent 会判断这次问答是否产生了新的知识点如果是就生成一篇草稿文档推送到乐享的“待审核”目录由人工确认后正式发布。这样知识库就变成了一个“越用越丰富”的系统而不是只消耗不产出。还有一个是权限感知的检索。不同角色的用户问同一个问题Agent 返回的答案详细程度可以不一样。比如新员工问“报销流程”返回完整步骤财务问同样的问题返回的是审批要点和常见错误。这个通过在 WorkBuddy 里配置角色标签和对应的检索策略来实现。最后分享一个小技巧定期用“冷问题”测试 Agent。所谓冷问题就是那些从来没人问过、但理论上应该能回答的问题。我每个月会随机抽 10 个冷问题跑一遍看看 Agent 的表现。这比只看日常问答的准确率更能发现知识库的盲区。