如果你所在团队最近正认真做知识库应该能明显感觉到AI知识库的竞争点已经从能检索变成能记忆、能动手、能沉淀技能了。我们内部把一套知识库工程定名为 WeKnora v0.8.0主要落地在微信/企业微信办公场景目标是让业务同事直接在聊天窗口里问问题、办事情而不是打开一个冷冰冰的问答页面。跑了两周多整体效果超出预期但也踩了不少配置、记忆、工具调用和文档解析的坑。这篇手记不吹不黑把我认为最关键的技术决策和实操细节都写出来。1. 为什么把微信办公场景里的知识库押注在 WeKnora v0.8.01.1 当时摆在我们面前的三条路线一开始我们根本没打算从一堆方案里做复杂选型因为需求很明确数据不能出内网、用户主要在企业微信里提问、知识库要能和内部系统联动。当时实际考虑过三条路线。第一条是直接用 Dify、RAGFlow、AnythingLLM 这类成熟的 RAG 平台。它们的优势是界面友好、部署文档全Dify 的工作流编排、RAGFlow 的文档解析都做得不错。但我们试下来有个共同的问题重。为了一个知识库要拉起一堆服务东西虽全真正用得上的却不到一半尤其记忆和技能这两块多数平台要么刚起步要么得靠外部插件硬凑。第二条是基于 LangChain 或 LlamaIndex 自研。这条路灵活度最高但团队只有两个人既要管文档解析、向量检索又要自己做对话记忆和工具调用估计两三个月都上不了线。自研的边际成本太高更像长期主义的选择不适合当下的业务节奏。第三条就是我们最终选定的 WeKnora v0.8.0。它吸引我们的点很直接开源、可私有化部署、轻量而且 v0.8.0 这个版本的发布说明里明确提到了三个能力——记忆、工具调用和技能树。这三个词正好对应我们困扰很久的痛点知识库总是答完就忘、只能输出文字不能办事、高频业务流程没有沉淀机制。我是这么理解这三条路线的差异的现成平台是住酒店拎包入住但房间是别人的自研是自己盖房子时间成本极高WeKnora 属于买精装房再局部改造基础功能齐全留了足够的接口让我们接入企业微信和企业内部系统。1.2 v0.8.0 带来的关键变量记忆、手脚、技能如果你只看 v0.8.0 的版本号可能觉得这只是一次常规迭代。但对我们来说它补上了 AI 知识库最缺的三层能力。记忆指的是知识库不再是一问一答的无状态接口。用户在聊天里提到过的背景信息、历史对话结论、项目偏好会被结构化地存下来下次再聊的时候自动带上。热词里有个workbuddy 历史对话记录、本地记忆迁移我们实际关注的就是这个从旧版本升级之后历史会话记录如何平滑迁移到新的记忆系统而不是升级即失忆。手脚对应的是工具调用。知识库不能只会返回一段建议还要能查工单状态、读库存、调内部 API把你说该怎么办变成我直接帮你办好。技能则是对高频操作的沉淀。它比普通 Prompt 更结构化比工作流更灵活更像一套技能树——不同场景、不同意图触发不同的技能组合每个技能可以绑定特定的工具、记忆策略和输出模板。这三者组合起来知识库才从检索工具变成了数字员工。这也是我把这篇落地手记的标题定为长出了记忆、手脚和技能的原因。1.3 私有化部署与企业微信环境的约束清单在真正开始部署之前我们先列了一份硬性约束清单后面几乎所有坑都跟这份清单有关数据不出内网所有模型调用、向量存储、文档解析必须在本机或内网完成不能依赖公网 API。统一身份认证用户从企业微信里发起对话系统要知道提问的人是谁才能读写对应的长期记忆。消息通道要稳定企业微信机器人负责转发消息知识库的响应时间必须控制在 5 秒以内不然同事会以为服务挂了。权限隔离不同部门的知识库内容要隔离工具调用也要区分只读和写操作。可观测每一次问答、每一次工具调用都要有日志方便复盘和调优。WeKnora v0.8.0 的外部接口还算完整我们把消息接收、用户身份解析、问答请求转发这些逻辑都封装成了一个中间服务架构大致是企业微信机器人 - 中间服务 - WeKnora API - 向量库/工具服务。这样即使后面把 WeKnora 换掉中间服务也不用动。2. 记忆让知识库记得住上次聊到哪、默认偏好是什么2.1 v0.8.0 的记忆到底加了什么我们在选型时最关心的就是记忆机制但很多人对记忆的理解停留在把聊天记录存下来再塞进上下文。真正落地时会发现无脑存对话会导致两个问题token 消耗爆炸以及记忆互相冲突。WeKnora v0.8.0 把记忆分成了几个层次会话记忆短期记忆当前会话内最近 N 轮对话加上滚动摘要。N 由 token 预算控制超过预算就把更早的对话压缩成摘要。长期事实记忆从历史对话中抽取出来的用户偏好、身份信息、项目背景存成结构化的记忆条目。本地记忆迁移升级到 v0.8.0 后旧版本的历史对话记录可以一次性导入新的记忆库不会因为版本升级丢掉用户之前交代过的背景。记忆的存储方式不是一个简单的 key-value而是记忆向量库 记忆摘要库的组合。向量库负责语义召回摘要库负责在对话开始时快速加载用户的核心画像。两者结合才能既快又准。我们按热词里双网络记忆模型的思路做了简化理解一类是语义记忆网络负责存事实是什么比如用户是销售部、负责华北区另一类是情景记忆网络负责存上次经历了什么比如用户上次问过理赔流程并留下了结论。回答问题时两路记忆并行召回再合并给大模型效果比单路好很多。2.2 短期记忆和长期记忆的分工机制分工的逻辑其实和人的记忆很像短期记忆图快长期记忆图稳。短期记忆负责当前任务上下文。比如用户连续问了三个问题我们公司的年假规则是什么入职满一年能休几天那我要提前几天申请如果没有短期记忆第三个问题里的那和我毫无指向知识库没法把你关联到第一个问题的入职满一年场景。短期记忆就是把这三轮对话作为一个整体交给大模型让它自然理解指代关系。长期记忆负责跨会话的连续性。举个例子一个销售同事第一周问过华为项目的合同模板在哪知识库在他的长期记忆里写入了用户关注华为项目合同模板。第二周他直接问那个模板更新了吗系统不需要他重新解释那个是什么直接通过长期记忆召回就能定位。我们在配置里给两类记忆设置了不同的召回策略记忆类型存储方式召回时机生命周期短期记忆会话上下文窗口 滚动摘要每次对话会话结束或过期清除长期事实记忆结构化记忆向量库新会话开始时主动召回可长期保留支持人工删除2.3 不是每句话都值得记记忆回写的触发条件这是我们在实际使用中踩过的一个概念坑一开始我以为记忆当然是记得越多越好结果跑了两天就发现长期记忆库里塞满了用户说今天天气不错这种毫无价值的话真正需要的信息反而被噪声淹没。后来我们参考了 LangMem、MemGPT 这类项目里常见的做法给记忆回写加了一道评估器。只有满足以下条件之一对话内容才会被写入长期记忆用户明确表达了偏好或否定比如以后别给我推技术文档我看不懂用户交代了持久的身份或业务背景比如我是华东区的销售负责人对话产生了可复用的结论或参数比如会议时间定在周三下午三点用户主动要求记住比如这个模板我常用记一下。低置信度的记忆会先进入候选区如果后续对话再次出现相同模式才正式写入。这个机制帮我们把记忆库的噪声压低了百分之六七十召回准确率也明显提高。本地记忆迁移这块我们升级的时候用了一个简单的脚本把旧版本的 session 表按用户分组导出逐条调用 v0.8.0 的记忆写入接口。实测两百多个用户的会话记录迁移过去后用户再提问时基本能做到无缝衔接不需要重新交代背景。2.4 记忆召回的实测效果记忆系统上线之后我们拿真实业务场景压了压。第一个案例是理赔流程。用户第一次问我们保险理赔的完整流程是什么知识库回答完之后在记忆里记了一条用户关注理赔流程。隔了一周用户直接发一句理赔要准备哪些材料系统通过长期记忆定位到理赔这个主题配合知识库检索给出了材料清单整个回答没有让用户重复任何背景。这在旧版知识库里是不可能做到的旧版遇到这种省略式提问基本就答非所问了。第二个案例是跨部门信息校验。一位项目经理论过企业微信问上次和研发对齐的排期结论是什么由于他的历史会话摘要里有这次对齐的结论系统不仅从会话记忆里找回了排期结论还主动从知识库检索了最新的开发进度两者对比后提醒了一句当前排期比原结论延后两天。这种主动结合记忆与实时检索的能力用户反馈非常正向。当然也有翻车的时候。有个用户提到上回我们聊的那个方案但上回其实是三个月前超出系统默认的长期记忆召回范围结果没召回成功。后来我们把长期记忆的召回时间窗从默认 30 天调到了 90 天这类问题就大幅减少了。3. 手脚从只会答到能办事的工具调用链路3.1 工具注册与权限设计知识库有了记忆之后用户会觉得它懂我但真正让它产生价值的是能办事。WeKnora v0.8.0 提供了一个工具调用框架模型可以根据用户意图选择调用注册好的工具再把工具返回结果整合成自然语言回答。我们在配置里把工具分成三类查讯类只能读取数据比如查工单状态、查库存、查合同模板版本。这类工具权限最低AI 可自由调用。执行类会产生写操作比如创建会议纪要、发起审批、发送通知。这类工具必须有明确的参数校验并且调用前会让用户确认。敏感类涉及财务、人事数据修改AI 不能直接调用只能生成待人工执行的操作描述由管理员在后台确认后执行。工具注册的配置大致如下简化的 YAML 片段tools: - name: query_workorder_status type: readonly api: http://internal-svc/workorder/status params: - workorder_id description: 根据工单号查询IT工单当前处理状态 - name: create_meeting_minutes type: write api: http://internal-svc/minutes/create params: - title - attendees - decisions description: 创建会议纪要并自动发送给参会人这里的核心不是工具本身而是description 的写法。模型要靠 description 判断什么时候该调用哪个工具如果描述含糊它就会在错误的场景触发调用。比如 create_meeting_minutes 如果不写清楚只能在用户明确要求记录会议结论时调用模型很可能在用户随口提了一句上次开会说的那个事时就误触发创建操作。3.2 让知识库去执行真实操作从查询到写操作工具调用的价值在我们接入企业微信后体现得非常直接。最常用的场景是 IT 工单查询。同事们习惯在企业微信里问我的工单 BUG-1024 到哪一步了以前需要打开工单系统自己查现在知识库识别出工单号直接调工单 API返回当前状态已分配给运维组预计今天下午完成还会顺便把工单处理人的联系方式附上。因为知识库接入了长期记忆用户第二次报工单时甚至不用完整输入工单号说刚刚那个工单就能定位。另一个让我印象深刻的场景是一线销售的周报生成。销售在企微里说把本周客户沟通情况汇总一下知识库从文档知识库中召回该销售本周的拜访记录以文档形式存在从工具服务中同步 CRM 里的客户阶段信息再用固定模板生成周报草稿回传给用户确认。确认后它执行 create_meeting_minutes 类的写操作把周报同步到指定文档空间。整个过程用户只说了两句话。这个链路能跑通的核心在于模型不仅要学会调用工具还要学会从历史上下文里提取工具所需参数。比如刚刚那个工单这句话里没有任何工单号是长期记忆和工作会话记忆共同提供了工单号这个参数。如果记忆系统没做好工具调用就会频繁卡在参数缺失这一步。3.3 工具调用失败时的降级策略工具调用最理想的情况是一次就成功但现实是工具也会超时、参数也会抽错、接口也会临时变更。我们在日志里统计过上线第一周工具调用失败率大概在 15% 左右后来恢复了 10%因为排查了很多参数抽取的边界问题。我们最终落地的降级策略是参数缺失时主动反问。模型检测到工具必填参数缺失时不允许瞎填必须反问用户补齐。比如查工单没给工单号就回复请提供工单号或告诉我大概提交时间我来帮你定位。工具超时重试一次。内部系统偶尔会有 1-2 秒的抖动重试一次能救回不少请求。如果重试仍然失败就明确告诉用户当前系统繁忙请稍后再试不要硬编一个错误答案。写操作失败转人工。比如创建会议纪要失败时知识库会把用户的需求整理成一段文字生成一条人工待办消息发给管理员由管理员线下处理。这是保险杠避免 AI 把简单问题越搞越复杂。回放失败日志优化参数抽取。所有失败的工具调用请求体都会记录在日志里每周回放一次看是模型选错工具、抽错参数还是接口本身的问题。这个失败转人工的设计在业务上特别重要。知识库是用来提效的不是用来背锅的。如果 AI 把用户的一个操作请求吞掉然后给个模糊答案还不如直接转给真人处理。4. 技能把高频操作沉淀成可复用的技能树4.1 技能、工作流、Prompt 到底差在哪很多人的第一反应是技能不就是更长的 Prompt 吗或者不就是工作流吗我们在落地过程中花了不少时间理清这三者的边界。Prompt 是单次指令比如请总结这段文档。它没有条件判断没有工具依赖输进去就出来用完即弃。工作流是预设步骤比如 Dify 里的文档解析 - 关键信息抽取 - 生成摘要 - 发送通知。它适合步骤固定、变化不大的流程缺点是灵活性差流程里任何一步想动态调整都很麻烦。技能是一套带触发条件的能力组合它包含触发意图判断什么情况下该使用这个技能依赖的记忆是否需要读取用户的长期记忆或会话记忆可调用的工具技能运行时可以调用哪些工具输出模板回答用什么结构组织校验规则输出前要做哪些检查。如果类比一下Prompt 像一条菜谱工作流像标准化中央厨房的一条产线技能则像一个厨师掌握的整套做菜功夫——他会根据客人今天想吃什么、冰箱里有什么菜灵活决定怎么搭配。这也是热词里技能树给我的启发技能不是一个个孤立的壳子而是按领域、按场景分层组织的体系。4.2 技能定义文件与加载机制在 WeKnora v0.8.0 里一个技能对应一个定义文件通常用 YAML 表示加载时自动注册进技能列表。我们的一个技能定义大概长这样name: claim_progress_check description: 用户咨询理赔进度、理赔材料、赔款到账时间时使用 trigger: intent_tags: - claim - 理赔 - 赔付 - 材料 require_memory: true tools: - claim_api - doc_retriever memory: long_term: true short_term: true steps: - step: extract_order_id tool: claim_api desc: 从用户记忆或当前会话中提取理赔单号 - step: retrieve_claim_docs tool: doc_retriever desc: 检索理赔流程文档作为参考 output_template: | 理赔进度{status} 当前节点{current_step} 如需准备材料{material_list}这套机制的好处是把知识的调用方式和知识内容解耦了。知识库里的文档负责提供事实技能负责定义怎么用这些事实办事。同事问理赔到哪一步了模型会触发 claim_progress_check 技能读取记忆里的理赔单号调理赔 API 拿状态再去文档库检索材料清单最后按模板输出。加载机制方面v0.8.0 会在启动时扫指定目录下的所有技能定义文件解析后注册。我们调整技能内容时不需要重启整个服务只要调用热加载接口重新读取单个技能文件即可。这个能力在调试阶段非常省时间不然每改一次 description 就要重启一次容器心态很容易崩。4.3 让模型自主选择技能准确率从 72% 到 91%技能定义得再好如果模型不知道该触发哪个技能一切都是空谈。我们在 v0.8.0 的技能路由上专门做了一轮评测。评测方式是准备 50 条真实业务 query人工标注每个 query 应该命中哪个技能然后统计模型选择的准确率。第一版跑下来只有 72%问题集中在两个地方description 写得太简短模型把理赔进度和理赔材料清单两个技能混为一谈技能边界重叠同一个 query 触发了两个相似技能输出内容互相矛盾。针对这两个问题我们做了两件事第一给每个技能丰富描述加入触发和禁止场景。比如 claim_progress_check 里注明仅当用户咨询理赔进度或材料时使用如果用户要修改理赔信息请转人工处理。加了负面样例之后误触率下降非常明显。第二对技能做了去重叠处理。原先理赔材料单独是一个技能后来合并进了 claim_progress_check由同一个技能在内部通过工具调用来区分查进度和查材料。减少技能数量反而提升了路由准确率。优化后的准确率到了 91%。剩下 9% 主要是用户口语过于省略系统难以判断意图。我们对这类 query 的策略是多技能答案融合——让模型同时参考两个最相似技能的输出借助记忆里的上下文修正而不是非要选一个。5. 落地过程中的几个深坑与最终效果5.1 Docker 部署与文档解析的真实问题部署层面WeKnora v0.8.0 提供了 Docker 镜像我们采用的是 docker compose 方式把服务、PostgreSQL、向量数据库、对象存储一起编排起来。整体上不算复杂但有三个坑值得单独说。第一个坑是向量化模型首次加载的问题。默认的 embedding 模型需要在服务启动时从模型仓库拉取内网环境直接拉不动。我们的解决方案是在一台有外网的机器上先把模型文件拉下来做成本地镜像或挂载目录再复制到内网服务器。我们在 compose 文件里通过MODEL_CACHE_DIR指定本地模型路径启动速度从失败的几分钟变成稳定的十几秒。第二个坑是文档解析质量。业务方上线的第一批文档里有一堆 Word 格式的合同模板和 PDF 版本的制度文件。默认解析器对 PDF 里带表格的内容处理得很粗糙表格行列经常错乱导致召回时出现张冠李戴。我们启用了表格识别增强把表格内容按行转成 key-value 文本例如合同期限: 2024-01-01 至 2025-01-01而不是保留原来的多列排版。转换之后合同条款的召回准确率高了不少。第三个坑是扫描版 PDF。有几个制度文件是扫描件默认解析器提取出来全是乱码。我们给 WeKnora 挂了 OCR 组件在配置文件里把扫描版 PDF 的解析策略设为先 OCR 再切分。OCR 会增加约一倍的处理时间但面对不可检索的 PDF 这是唯一可行的方案。5.2 召回质量调优chunk、embedding、rerank知识库产品的口碑好坏往往不取决于模型多聪明而取决于召回准不准。我们在调优上花的时间最多最终确定了一组适合我们业务文档的参数。chunk_size 从默认的 500 调到了 350。我们测试发现公司内部文档经常一个段落塞进几十个字的关键信息如果 chunk 太大embedding 会被无关内容稀释召回排名反而靠后。chunk 改小之后配合 50 的 overlap既能保证上下文连贯又能提高命中率。embedding 模型换成了中文效果更好的 bge-large-zh。官方默认的嵌入模型在中文场景下表现一般尤其面对专有名词多、句式复杂的内部文档时相关度排错的情况不少。切换模型之后Top 5 召回命中率大约提升了 8 个百分点。换个模型听起来简单实际上要重新对全量文档做 embedding我们写了个批量脚本在夜间完成两小时搞定。rerank 阈值设在了 0.3。低于这个阈值时知识库不会强行组织答案而是直接回复没有在现有文档中找到相关信息建议联系知识库管理员。很多团队不敢做拒答怕体验差实际上适度拒答反而能建立信任。调完这三项之后我们做了一次回归测试用 100 条业务问题挨个验证相关文档召回率从 76% 提升到了 89%。这个数字不一定能推广到别的知识库因为文档类型和问题类型差异极大但调优方法论是通用的先切分、再向量、再重排每个环节单独验证不要一上来就换大模型。5.3 上线后的使用数据与个人体会上线两周我们统计了几个核心指标日均问答量 800 多条其中约 25% 的对话触发了工具调用30% 的对话会命中长期记忆。知识库主动拒答的情况占 8% 左右没有造成明显投诉反而管理员收到不少知识库说没有帮我补充一下的反馈形成了知识迭代的正循环。我印象最深的一个细节是有个同事在企微里问我的报销到哪一步了金额是三千多那个系统通过他的企业微信身份定位到长期记忆里的报销记录结合工具调用返回了报销单状态。他说了一句这机器人终于像自己人了。这句话让我意识到知识库要融入真实工作场景身份识别 记忆 动作缺一不可。从 v0.8.0 的落地过程来看我个人的核心体会是不要把记忆、手脚、技能当成分散的功能点它们其实是一条完整链路的三个阶段。记忆让系统理解上下文手脚让系统能改变现实技能让高频能力沉淀复用。缺了记忆工具调用参数抽不准缺了技能每次对话都从零开始缺了动作知识库始终只是个高级搜索引擎。如果你也准备在类似场景落地一个能记住、能干活的知识库我的建议是先从记忆回写规则和工具权限设计入手这两个点最影响上线初期的体验。技能树可以等业务跑顺了再逐步沉淀不必一开始就追求大而全。
AI知识库落地企业微信：记忆、工具调用与技能树实践
如果你所在团队最近正认真做知识库应该能明显感觉到AI知识库的竞争点已经从能检索变成能记忆、能动手、能沉淀技能了。我们内部把一套知识库工程定名为 WeKnora v0.8.0主要落地在微信/企业微信办公场景目标是让业务同事直接在聊天窗口里问问题、办事情而不是打开一个冷冰冰的问答页面。跑了两周多整体效果超出预期但也踩了不少配置、记忆、工具调用和文档解析的坑。这篇手记不吹不黑把我认为最关键的技术决策和实操细节都写出来。1. 为什么把微信办公场景里的知识库押注在 WeKnora v0.8.01.1 当时摆在我们面前的三条路线一开始我们根本没打算从一堆方案里做复杂选型因为需求很明确数据不能出内网、用户主要在企业微信里提问、知识库要能和内部系统联动。当时实际考虑过三条路线。第一条是直接用 Dify、RAGFlow、AnythingLLM 这类成熟的 RAG 平台。它们的优势是界面友好、部署文档全Dify 的工作流编排、RAGFlow 的文档解析都做得不错。但我们试下来有个共同的问题重。为了一个知识库要拉起一堆服务东西虽全真正用得上的却不到一半尤其记忆和技能这两块多数平台要么刚起步要么得靠外部插件硬凑。第二条是基于 LangChain 或 LlamaIndex 自研。这条路灵活度最高但团队只有两个人既要管文档解析、向量检索又要自己做对话记忆和工具调用估计两三个月都上不了线。自研的边际成本太高更像长期主义的选择不适合当下的业务节奏。第三条就是我们最终选定的 WeKnora v0.8.0。它吸引我们的点很直接开源、可私有化部署、轻量而且 v0.8.0 这个版本的发布说明里明确提到了三个能力——记忆、工具调用和技能树。这三个词正好对应我们困扰很久的痛点知识库总是答完就忘、只能输出文字不能办事、高频业务流程没有沉淀机制。我是这么理解这三条路线的差异的现成平台是住酒店拎包入住但房间是别人的自研是自己盖房子时间成本极高WeKnora 属于买精装房再局部改造基础功能齐全留了足够的接口让我们接入企业微信和企业内部系统。1.2 v0.8.0 带来的关键变量记忆、手脚、技能如果你只看 v0.8.0 的版本号可能觉得这只是一次常规迭代。但对我们来说它补上了 AI 知识库最缺的三层能力。记忆指的是知识库不再是一问一答的无状态接口。用户在聊天里提到过的背景信息、历史对话结论、项目偏好会被结构化地存下来下次再聊的时候自动带上。热词里有个workbuddy 历史对话记录、本地记忆迁移我们实际关注的就是这个从旧版本升级之后历史会话记录如何平滑迁移到新的记忆系统而不是升级即失忆。手脚对应的是工具调用。知识库不能只会返回一段建议还要能查工单状态、读库存、调内部 API把你说该怎么办变成我直接帮你办好。技能则是对高频操作的沉淀。它比普通 Prompt 更结构化比工作流更灵活更像一套技能树——不同场景、不同意图触发不同的技能组合每个技能可以绑定特定的工具、记忆策略和输出模板。这三者组合起来知识库才从检索工具变成了数字员工。这也是我把这篇落地手记的标题定为长出了记忆、手脚和技能的原因。1.3 私有化部署与企业微信环境的约束清单在真正开始部署之前我们先列了一份硬性约束清单后面几乎所有坑都跟这份清单有关数据不出内网所有模型调用、向量存储、文档解析必须在本机或内网完成不能依赖公网 API。统一身份认证用户从企业微信里发起对话系统要知道提问的人是谁才能读写对应的长期记忆。消息通道要稳定企业微信机器人负责转发消息知识库的响应时间必须控制在 5 秒以内不然同事会以为服务挂了。权限隔离不同部门的知识库内容要隔离工具调用也要区分只读和写操作。可观测每一次问答、每一次工具调用都要有日志方便复盘和调优。WeKnora v0.8.0 的外部接口还算完整我们把消息接收、用户身份解析、问答请求转发这些逻辑都封装成了一个中间服务架构大致是企业微信机器人 - 中间服务 - WeKnora API - 向量库/工具服务。这样即使后面把 WeKnora 换掉中间服务也不用动。2. 记忆让知识库记得住上次聊到哪、默认偏好是什么2.1 v0.8.0 的记忆到底加了什么我们在选型时最关心的就是记忆机制但很多人对记忆的理解停留在把聊天记录存下来再塞进上下文。真正落地时会发现无脑存对话会导致两个问题token 消耗爆炸以及记忆互相冲突。WeKnora v0.8.0 把记忆分成了几个层次会话记忆短期记忆当前会话内最近 N 轮对话加上滚动摘要。N 由 token 预算控制超过预算就把更早的对话压缩成摘要。长期事实记忆从历史对话中抽取出来的用户偏好、身份信息、项目背景存成结构化的记忆条目。本地记忆迁移升级到 v0.8.0 后旧版本的历史对话记录可以一次性导入新的记忆库不会因为版本升级丢掉用户之前交代过的背景。记忆的存储方式不是一个简单的 key-value而是记忆向量库 记忆摘要库的组合。向量库负责语义召回摘要库负责在对话开始时快速加载用户的核心画像。两者结合才能既快又准。我们按热词里双网络记忆模型的思路做了简化理解一类是语义记忆网络负责存事实是什么比如用户是销售部、负责华北区另一类是情景记忆网络负责存上次经历了什么比如用户上次问过理赔流程并留下了结论。回答问题时两路记忆并行召回再合并给大模型效果比单路好很多。2.2 短期记忆和长期记忆的分工机制分工的逻辑其实和人的记忆很像短期记忆图快长期记忆图稳。短期记忆负责当前任务上下文。比如用户连续问了三个问题我们公司的年假规则是什么入职满一年能休几天那我要提前几天申请如果没有短期记忆第三个问题里的那和我毫无指向知识库没法把你关联到第一个问题的入职满一年场景。短期记忆就是把这三轮对话作为一个整体交给大模型让它自然理解指代关系。长期记忆负责跨会话的连续性。举个例子一个销售同事第一周问过华为项目的合同模板在哪知识库在他的长期记忆里写入了用户关注华为项目合同模板。第二周他直接问那个模板更新了吗系统不需要他重新解释那个是什么直接通过长期记忆召回就能定位。我们在配置里给两类记忆设置了不同的召回策略记忆类型存储方式召回时机生命周期短期记忆会话上下文窗口 滚动摘要每次对话会话结束或过期清除长期事实记忆结构化记忆向量库新会话开始时主动召回可长期保留支持人工删除2.3 不是每句话都值得记记忆回写的触发条件这是我们在实际使用中踩过的一个概念坑一开始我以为记忆当然是记得越多越好结果跑了两天就发现长期记忆库里塞满了用户说今天天气不错这种毫无价值的话真正需要的信息反而被噪声淹没。后来我们参考了 LangMem、MemGPT 这类项目里常见的做法给记忆回写加了一道评估器。只有满足以下条件之一对话内容才会被写入长期记忆用户明确表达了偏好或否定比如以后别给我推技术文档我看不懂用户交代了持久的身份或业务背景比如我是华东区的销售负责人对话产生了可复用的结论或参数比如会议时间定在周三下午三点用户主动要求记住比如这个模板我常用记一下。低置信度的记忆会先进入候选区如果后续对话再次出现相同模式才正式写入。这个机制帮我们把记忆库的噪声压低了百分之六七十召回准确率也明显提高。本地记忆迁移这块我们升级的时候用了一个简单的脚本把旧版本的 session 表按用户分组导出逐条调用 v0.8.0 的记忆写入接口。实测两百多个用户的会话记录迁移过去后用户再提问时基本能做到无缝衔接不需要重新交代背景。2.4 记忆召回的实测效果记忆系统上线之后我们拿真实业务场景压了压。第一个案例是理赔流程。用户第一次问我们保险理赔的完整流程是什么知识库回答完之后在记忆里记了一条用户关注理赔流程。隔了一周用户直接发一句理赔要准备哪些材料系统通过长期记忆定位到理赔这个主题配合知识库检索给出了材料清单整个回答没有让用户重复任何背景。这在旧版知识库里是不可能做到的旧版遇到这种省略式提问基本就答非所问了。第二个案例是跨部门信息校验。一位项目经理论过企业微信问上次和研发对齐的排期结论是什么由于他的历史会话摘要里有这次对齐的结论系统不仅从会话记忆里找回了排期结论还主动从知识库检索了最新的开发进度两者对比后提醒了一句当前排期比原结论延后两天。这种主动结合记忆与实时检索的能力用户反馈非常正向。当然也有翻车的时候。有个用户提到上回我们聊的那个方案但上回其实是三个月前超出系统默认的长期记忆召回范围结果没召回成功。后来我们把长期记忆的召回时间窗从默认 30 天调到了 90 天这类问题就大幅减少了。3. 手脚从只会答到能办事的工具调用链路3.1 工具注册与权限设计知识库有了记忆之后用户会觉得它懂我但真正让它产生价值的是能办事。WeKnora v0.8.0 提供了一个工具调用框架模型可以根据用户意图选择调用注册好的工具再把工具返回结果整合成自然语言回答。我们在配置里把工具分成三类查讯类只能读取数据比如查工单状态、查库存、查合同模板版本。这类工具权限最低AI 可自由调用。执行类会产生写操作比如创建会议纪要、发起审批、发送通知。这类工具必须有明确的参数校验并且调用前会让用户确认。敏感类涉及财务、人事数据修改AI 不能直接调用只能生成待人工执行的操作描述由管理员在后台确认后执行。工具注册的配置大致如下简化的 YAML 片段tools: - name: query_workorder_status type: readonly api: http://internal-svc/workorder/status params: - workorder_id description: 根据工单号查询IT工单当前处理状态 - name: create_meeting_minutes type: write api: http://internal-svc/minutes/create params: - title - attendees - decisions description: 创建会议纪要并自动发送给参会人这里的核心不是工具本身而是description 的写法。模型要靠 description 判断什么时候该调用哪个工具如果描述含糊它就会在错误的场景触发调用。比如 create_meeting_minutes 如果不写清楚只能在用户明确要求记录会议结论时调用模型很可能在用户随口提了一句上次开会说的那个事时就误触发创建操作。3.2 让知识库去执行真实操作从查询到写操作工具调用的价值在我们接入企业微信后体现得非常直接。最常用的场景是 IT 工单查询。同事们习惯在企业微信里问我的工单 BUG-1024 到哪一步了以前需要打开工单系统自己查现在知识库识别出工单号直接调工单 API返回当前状态已分配给运维组预计今天下午完成还会顺便把工单处理人的联系方式附上。因为知识库接入了长期记忆用户第二次报工单时甚至不用完整输入工单号说刚刚那个工单就能定位。另一个让我印象深刻的场景是一线销售的周报生成。销售在企微里说把本周客户沟通情况汇总一下知识库从文档知识库中召回该销售本周的拜访记录以文档形式存在从工具服务中同步 CRM 里的客户阶段信息再用固定模板生成周报草稿回传给用户确认。确认后它执行 create_meeting_minutes 类的写操作把周报同步到指定文档空间。整个过程用户只说了两句话。这个链路能跑通的核心在于模型不仅要学会调用工具还要学会从历史上下文里提取工具所需参数。比如刚刚那个工单这句话里没有任何工单号是长期记忆和工作会话记忆共同提供了工单号这个参数。如果记忆系统没做好工具调用就会频繁卡在参数缺失这一步。3.3 工具调用失败时的降级策略工具调用最理想的情况是一次就成功但现实是工具也会超时、参数也会抽错、接口也会临时变更。我们在日志里统计过上线第一周工具调用失败率大概在 15% 左右后来恢复了 10%因为排查了很多参数抽取的边界问题。我们最终落地的降级策略是参数缺失时主动反问。模型检测到工具必填参数缺失时不允许瞎填必须反问用户补齐。比如查工单没给工单号就回复请提供工单号或告诉我大概提交时间我来帮你定位。工具超时重试一次。内部系统偶尔会有 1-2 秒的抖动重试一次能救回不少请求。如果重试仍然失败就明确告诉用户当前系统繁忙请稍后再试不要硬编一个错误答案。写操作失败转人工。比如创建会议纪要失败时知识库会把用户的需求整理成一段文字生成一条人工待办消息发给管理员由管理员线下处理。这是保险杠避免 AI 把简单问题越搞越复杂。回放失败日志优化参数抽取。所有失败的工具调用请求体都会记录在日志里每周回放一次看是模型选错工具、抽错参数还是接口本身的问题。这个失败转人工的设计在业务上特别重要。知识库是用来提效的不是用来背锅的。如果 AI 把用户的一个操作请求吞掉然后给个模糊答案还不如直接转给真人处理。4. 技能把高频操作沉淀成可复用的技能树4.1 技能、工作流、Prompt 到底差在哪很多人的第一反应是技能不就是更长的 Prompt 吗或者不就是工作流吗我们在落地过程中花了不少时间理清这三者的边界。Prompt 是单次指令比如请总结这段文档。它没有条件判断没有工具依赖输进去就出来用完即弃。工作流是预设步骤比如 Dify 里的文档解析 - 关键信息抽取 - 生成摘要 - 发送通知。它适合步骤固定、变化不大的流程缺点是灵活性差流程里任何一步想动态调整都很麻烦。技能是一套带触发条件的能力组合它包含触发意图判断什么情况下该使用这个技能依赖的记忆是否需要读取用户的长期记忆或会话记忆可调用的工具技能运行时可以调用哪些工具输出模板回答用什么结构组织校验规则输出前要做哪些检查。如果类比一下Prompt 像一条菜谱工作流像标准化中央厨房的一条产线技能则像一个厨师掌握的整套做菜功夫——他会根据客人今天想吃什么、冰箱里有什么菜灵活决定怎么搭配。这也是热词里技能树给我的启发技能不是一个个孤立的壳子而是按领域、按场景分层组织的体系。4.2 技能定义文件与加载机制在 WeKnora v0.8.0 里一个技能对应一个定义文件通常用 YAML 表示加载时自动注册进技能列表。我们的一个技能定义大概长这样name: claim_progress_check description: 用户咨询理赔进度、理赔材料、赔款到账时间时使用 trigger: intent_tags: - claim - 理赔 - 赔付 - 材料 require_memory: true tools: - claim_api - doc_retriever memory: long_term: true short_term: true steps: - step: extract_order_id tool: claim_api desc: 从用户记忆或当前会话中提取理赔单号 - step: retrieve_claim_docs tool: doc_retriever desc: 检索理赔流程文档作为参考 output_template: | 理赔进度{status} 当前节点{current_step} 如需准备材料{material_list}这套机制的好处是把知识的调用方式和知识内容解耦了。知识库里的文档负责提供事实技能负责定义怎么用这些事实办事。同事问理赔到哪一步了模型会触发 claim_progress_check 技能读取记忆里的理赔单号调理赔 API 拿状态再去文档库检索材料清单最后按模板输出。加载机制方面v0.8.0 会在启动时扫指定目录下的所有技能定义文件解析后注册。我们调整技能内容时不需要重启整个服务只要调用热加载接口重新读取单个技能文件即可。这个能力在调试阶段非常省时间不然每改一次 description 就要重启一次容器心态很容易崩。4.3 让模型自主选择技能准确率从 72% 到 91%技能定义得再好如果模型不知道该触发哪个技能一切都是空谈。我们在 v0.8.0 的技能路由上专门做了一轮评测。评测方式是准备 50 条真实业务 query人工标注每个 query 应该命中哪个技能然后统计模型选择的准确率。第一版跑下来只有 72%问题集中在两个地方description 写得太简短模型把理赔进度和理赔材料清单两个技能混为一谈技能边界重叠同一个 query 触发了两个相似技能输出内容互相矛盾。针对这两个问题我们做了两件事第一给每个技能丰富描述加入触发和禁止场景。比如 claim_progress_check 里注明仅当用户咨询理赔进度或材料时使用如果用户要修改理赔信息请转人工处理。加了负面样例之后误触率下降非常明显。第二对技能做了去重叠处理。原先理赔材料单独是一个技能后来合并进了 claim_progress_check由同一个技能在内部通过工具调用来区分查进度和查材料。减少技能数量反而提升了路由准确率。优化后的准确率到了 91%。剩下 9% 主要是用户口语过于省略系统难以判断意图。我们对这类 query 的策略是多技能答案融合——让模型同时参考两个最相似技能的输出借助记忆里的上下文修正而不是非要选一个。5. 落地过程中的几个深坑与最终效果5.1 Docker 部署与文档解析的真实问题部署层面WeKnora v0.8.0 提供了 Docker 镜像我们采用的是 docker compose 方式把服务、PostgreSQL、向量数据库、对象存储一起编排起来。整体上不算复杂但有三个坑值得单独说。第一个坑是向量化模型首次加载的问题。默认的 embedding 模型需要在服务启动时从模型仓库拉取内网环境直接拉不动。我们的解决方案是在一台有外网的机器上先把模型文件拉下来做成本地镜像或挂载目录再复制到内网服务器。我们在 compose 文件里通过MODEL_CACHE_DIR指定本地模型路径启动速度从失败的几分钟变成稳定的十几秒。第二个坑是文档解析质量。业务方上线的第一批文档里有一堆 Word 格式的合同模板和 PDF 版本的制度文件。默认解析器对 PDF 里带表格的内容处理得很粗糙表格行列经常错乱导致召回时出现张冠李戴。我们启用了表格识别增强把表格内容按行转成 key-value 文本例如合同期限: 2024-01-01 至 2025-01-01而不是保留原来的多列排版。转换之后合同条款的召回准确率高了不少。第三个坑是扫描版 PDF。有几个制度文件是扫描件默认解析器提取出来全是乱码。我们给 WeKnora 挂了 OCR 组件在配置文件里把扫描版 PDF 的解析策略设为先 OCR 再切分。OCR 会增加约一倍的处理时间但面对不可检索的 PDF 这是唯一可行的方案。5.2 召回质量调优chunk、embedding、rerank知识库产品的口碑好坏往往不取决于模型多聪明而取决于召回准不准。我们在调优上花的时间最多最终确定了一组适合我们业务文档的参数。chunk_size 从默认的 500 调到了 350。我们测试发现公司内部文档经常一个段落塞进几十个字的关键信息如果 chunk 太大embedding 会被无关内容稀释召回排名反而靠后。chunk 改小之后配合 50 的 overlap既能保证上下文连贯又能提高命中率。embedding 模型换成了中文效果更好的 bge-large-zh。官方默认的嵌入模型在中文场景下表现一般尤其面对专有名词多、句式复杂的内部文档时相关度排错的情况不少。切换模型之后Top 5 召回命中率大约提升了 8 个百分点。换个模型听起来简单实际上要重新对全量文档做 embedding我们写了个批量脚本在夜间完成两小时搞定。rerank 阈值设在了 0.3。低于这个阈值时知识库不会强行组织答案而是直接回复没有在现有文档中找到相关信息建议联系知识库管理员。很多团队不敢做拒答怕体验差实际上适度拒答反而能建立信任。调完这三项之后我们做了一次回归测试用 100 条业务问题挨个验证相关文档召回率从 76% 提升到了 89%。这个数字不一定能推广到别的知识库因为文档类型和问题类型差异极大但调优方法论是通用的先切分、再向量、再重排每个环节单独验证不要一上来就换大模型。5.3 上线后的使用数据与个人体会上线两周我们统计了几个核心指标日均问答量 800 多条其中约 25% 的对话触发了工具调用30% 的对话会命中长期记忆。知识库主动拒答的情况占 8% 左右没有造成明显投诉反而管理员收到不少知识库说没有帮我补充一下的反馈形成了知识迭代的正循环。我印象最深的一个细节是有个同事在企微里问我的报销到哪一步了金额是三千多那个系统通过他的企业微信身份定位到长期记忆里的报销记录结合工具调用返回了报销单状态。他说了一句这机器人终于像自己人了。这句话让我意识到知识库要融入真实工作场景身份识别 记忆 动作缺一不可。从 v0.8.0 的落地过程来看我个人的核心体会是不要把记忆、手脚、技能当成分散的功能点它们其实是一条完整链路的三个阶段。记忆让系统理解上下文手脚让系统能改变现实技能让高频能力沉淀复用。缺了记忆工具调用参数抽不准缺了技能每次对话都从零开始缺了动作知识库始终只是个高级搜索引擎。如果你也准备在类似场景落地一个能记住、能干活的知识库我的建议是先从记忆回写规则和工具权限设计入手这两个点最影响上线初期的体验。技能树可以等业务跑顺了再逐步沉淀不必一开始就追求大而全。
