把本地知识库折腾到“能干活”，而不是只能做一个高级搜索引擎，这件事我前前后后花了快一个月。手里资料从 PDF、Word 到 Markdown 都有，还有一堆散落在聊天记录、收藏夹里的碎片信息，之前用普通 RAG 方案做出来的东西，问答倒是能答，但一问三不知、答非所问的情况也不少。直到把 WeKnora v0.8.0 完整落地下来，我才真正觉得这个知识库“活了”它有记忆、有手脚、有技能，而且能直接接到微信上随时问。
先说清楚这玩意儿是干嘛的。WeKnora 是一个开源知识库项目，定位是 RAG（检索增强生成）引擎外加 Agent 运行时。和市面上一堆只做“上传文档、提问、给答案”的知识库不一样，v0.8.0 这版把知识库从被动问答升级成了能主动干活的实体。所谓“记忆”，指的是对话上下文、用户偏好和长期知识沉淀；“手脚”指的是外部工具调用能力，比如查数据库、请求 API、执行代码；“技能”则是一套可编排的动作流程，告诉模型“遇到什么情况，按什么顺序调用什么工具”。这三样凑齐，知识库就不再是书架，而是一个有经验的助手了。
这篇手记适合两类人看：一是用 Dify、FastGPT、AnythingLLM 之类工具搭过知识库，但觉得检索不准、流程死板、扩展受限的人；二是想把个人或团队知识库接入聊天工具（尤其是微信），实现“问点什么、让它自己查、自己算、自己整理”的人。我会把 v0.8.0 的部署、记忆配置、工具接入、技能编排和踩坑实录都过一遍，拿到的配置和 YAML 可以直接抄。
1. 为什么选 WeKnora：先搞清楚它和 Dify 这类平台的差别
在动手部署之前，我花了不少时间对比现有方案。Dify 和 FastGPT 我也都用过一阵子，它们当然能做 RAG，也支持工作流编排，但有几个点让我一直不太舒服。
一是文档解析质量。Dify 对 PDF、Word 的处理基本是“能读出来就行”，排版复杂一点的表格、双栏文章、扫描件，切出来的 chunk 经常前言不搭后语。WeKnora 在 v0.8.0 里对文档解析做了专门优化，支持版面分析、表格识别、公式抽取，切分时会根据标题层级、段落结构、表格边界做语义化拆分，而不是简单按固定字符数硬切。这个差距在实际问答里非常明显。
二是检索策略。Dify 默认是向量检索加一个相似度阈值，向量模型选不好或者文档主题很杂时，召回结果经常跑偏。WeKnora 默认走“稠密向量 + 稀疏检索（BM25）+ 重排序”的混合检索管线，这个组合我在后面会展开讲。简单说，向量负责理解语义，BM25 负责抓关键词，rerank 再把可能相关的结果精排一遍，三层过滤之后，答案质量确实不一样。
三是扩展性。Dify 的工作流本质上是在一个图形界面上连线，做复杂逻辑时节点一多就乱，而且每个节点能干什么受平台限制。WeKnora v0.8.0 则把“技能”做成了配置文件加代码模板，一个技能就是一个可版本管理的文件夹，里面定义了触发条件、执行步骤、工具调用方式和输出模板。这种设计更适合我这种喜欢把逻辑写进 Git 里的人。
四是最关键的微信接入。我知道有人用公众号后台或者个人号机器人套壳对接 LLM，但要让一个 RAG 系统能处理“用户发一段语音转成的文字、带着上下文追问、再触发一次数据查询”这种完整链路，大部分知识库工具根本不提供标准接口。WeKnora 自带消息渠道抽象层，v0.8.0 对微信适配做了补齐，我后面会详细说怎么配。
我这么说不是劝所有人都换过来。如果只是做内部知识问答、不需要复杂工具编排，Dify 上手确实更快。但如果你和我一样，想让知识库真正参与工作流自动产出，WeKnora 值得认真试试。
2. 本地部署的完整过程与初始配置
2.1 用 Docker Compose 拉起整套服务
WeKnora 提供了官方 Docker 镜像，也支持从源码编译，但说实话，本地体验最稳的还是 Docker Compose 方式。整套服务包含三块：核心 API 服务（weknora-core）、检索服务（内置了向量库和 BM25 索引）、前端管理面板（weknora-ui）。如果还要接本地大模型，可以再挂一个 Ollama 或 vLLM 容器，不挂也没关系，直接调用云端模型 API 也行。
我本机的环境是 Ubuntu 22.04，32GB 内存，无独显。Compose 文件大致长这样：
version: "3.8" services: weknora-core: image: weknora/weknora-core:v0.8.0 container_name: weknora-core restart: unless-stopped ports: - "8080:8080" volumes: - ./data:/app/data - ./skills:/app/skills - ./config:/app/config environment: - WEKNORA_LOG_LEVEL=INFO - WEKNORA_DEFAULT_LLM_PROVIDER=openai_compatible - WEKNORA_LLM_BASE_URL=http://host.docker.internal:11434/v1 - WEKNORA_LLM_API_KEY=ollama - WEKNORA_LLM_MODEL=qwen2.5:14b - WEKNORA_EMBEDDING_PROVIDER=ollama - WEKNORA_EMBEDDING_MODEL=bge-m3 - WEKNORA_VECTOR_DB_PATH=/app/data/vector_db extra_hosts: - "host.docker.internal:host-gateway" weknora-ui: image: weknora/weknora-ui:v0.8.0 container_name: weknora-ui restart: unless-stopped ports: - "8081:80" depends_on: - weknora-core这里有几个关键点。WEKNORA_LLM_BASE_URL指向本机的 Ollama，因为核心服务跑在容器里，访问宿主机要用host.docker.internal，Linux 下必须显式声明extra_hosts，否则容器里解析不到宿主机地址，我头一次部署就栽在这上面，日志里全是连接拒绝。Embedding 模型我选的是bge-m3，它支持中英文和 8192 长度的输入，对混合语言的知识库很友好，后面也会说为什么 embedding 模型别乱换。
2.2 模型选择与全局参数调优
WeKnora 本身不强绑定某个模型，它通过一个抽象层对接各类 LLM。我在 v0.8.0 里测了三种组合，这里直接给结论。
| 场景 | LLM 推荐 | Embedding 推荐 | 说明 |
|---|---|---|---|
| 纯本地隐私优先 | qwen2.5:14b 或 32b | bge-m3 | 14b 回答质量尚可，32b 明显更稳，但吃内存 |
| 预算有限、追求中文效果 | deepseek-chat（云端 API） | bge-m3 | 中文理解强，API 便宜，适合个人 |
| 英文技术文档为主 | gpt-4o-mini | text-embedding-3-large | 英文语义理解最好，但接口费用高 |
需要注意，LLM 的温度参数和 top_p 不是越高越好。知识库问答场景下，我习惯把 temperature 设在 0.2 到 0.4，太高了模型会自由发挥，回答里掺进知识库没有的内容，看似流畅实际上不可信。v0.8.0 支持在每个知识库里单独设置生成参数，我建议“团队制度类”知识库用 0.2，“创意构思类”知识库用 0.7，别全局一把梭。
Embedding 的相似度阈值也值得调。系统默认是 0.5，意思是检索结果和问题的向量余弦相似度低于 0.5 的一律丢弃。但 bge-m3 这种模型的分数分布和别的向量模型不一样，直接套默认阈值可能把所有结果都过滤光。我后来改成 0.35，召回率才正常。这个教训后面还会出现在排查表里。
2.3 导入第一批知识库文档
知识库支持的上传格式很全，docx、pdf、md、html、txt 都可以。我实际测试中，PDF 解析最考验功底。v0.8.0 内置的解析器对文本型 PDF 很准，但对于扫描版 PDF，如果服务器装了 OCR 组件，也能自动走 OCR 流程。我导入了一份公司盖章制度的扫描件，识别准确率大概在 95% 左右，表格线条复杂的地方会丢字，但整体可用。
还有一个体验很好的改进：你可以在上传时给文档打标签，并指定“切分策略”。比如制度类文档用“章节切分”，代码类文档用“代码块切分”，表格多的用“表格感知切分”。我一开始没注意这个选项，所有文档都用默认的“自动切分”，结果一份 80 页的运维手册被切得七零八落，问到某个命令参数时，检索出来的片段经常是从半句开始的。后来我把运维手册改成“标题层级切分”，问题立刻解决。
3. 让知识库长出记忆：会话记忆与用户画像
3.1 短期记忆：会话内的上下文管理
“记忆”这个词在知识库里其实分好几层。最基础的是短期记忆，也就是多轮对话里模型记得你刚才问过什么。WeKnora 默认会对每个会话维护一个上下文窗口，把最近几轮问答压缩后重新塞给模型。
但这里有个容易忽略的点：上下文窗口不是越大越好。你把最近 20 轮全塞进去，token 消耗大不说，模型还容易被前面的问题带偏，答着答着忘了当前问的是什么。v0.8.0 的多轮记忆做了“滑动窗口 + 摘要压缩”的混合策略。具体来说，它保留最近 4 轮完整对话，如果超过 4 轮，更早的内容会被 LLM 自动压缩成一段摘要。这个设计很实用，既保留了关键历史信息，又不会撑爆上下文。
我在实际使用中验证了一个场景：用户先问“上周生产环境的 CPU 告警怎么处理的”，过了十几轮又突然问“那个告警后来还有没有再出现”。如果只保留最近 4 轮，模型早就忘了前面的告警；但有了摘要压缩，它能把“CPU 告警”这个关键实体沉淀到摘要里，后续提问还能衔接上。这一点确实比很多知识库做的“一问一答、毫无记忆”强太多。
3.2 长期记忆：把对话中产生的信息沉淀下来
短期记忆只是记忆的第一步，真正让我觉得 WeKnora 有“脑子”的，是它的长期记忆机制。v0.8.0 里有一个叫“记忆写入”的开关，默认关闭。打开之后，系统会在每轮对话结束时，让 LLM 判断这轮对话里有没有“值得记下来的事实”。
举个例子。我在知识库里和它说：“以后写周报时，项目 A 的开发阶段已经结束了，下阶段重点是测试。”如果没有长期记忆，这句话只是当轮对话的一部分，下次开新会话它就忘了。开启记忆写入后，系统会提取出“项目 A 处于测试阶段”这个事实，写入专门的记忆向量库和结构化记忆表。下次新会话里再问“项目 A 现在什么进度”，它能从长期记忆里捞出来，甚至结合知识库里的项目文档给出完整回答。
这个机制我理解下来，本质是把“对话产生的知识”回流到“知识库”本身。它解决的痛点是：静态文档更新不及时，但对话里有很多动态信息值得沉淀。我建议把长期记忆开关常开，但每周末定期去记忆库里做一次清理，删掉过时或明显错误的条目，否则记忆库会膨胀，检索噪音也随之增加。
3.3 用户画像：针对不同人记住不同偏好
除了通用长期记忆，v0.8.0 还引入了用户画像记忆模块。这个在团队场景里特别有用。当接入微信之后，系统会给每个微信用户建立一个画像档案，记录他的常用语言风格、关注的业务领域、历史提问偏好等。
我实测下来，这个功能在一个场景里效果惊人：同一个知识库，产品经理问“新版功能什么时候上”，回答会偏项目排期和上线时间；研发主管问同样的问题，回答会自动带上技术方案细节和风险点。原因是用户画像里记录了两类人历史关注的侧重点不同，检索结果出来后，重排序环节会给和用户画像匹配度高的文档片段加权。
不过要注意，用户画像的建立需要时间，新用户在头几次对话里不会有明显差别。如果接入的频道是匿名的或者一个群多人共用，画像可能会串味。我的做法是在微信里给每个成员做个简单备注映射，让系统知道这个微信号对应的是谁。
4. 让知识库长出手脚：工具调用与外部系统对接
4.1 内置工具与 Function Calling 机制
知识库光会“记”还不够，要真正干活，得有“手脚”。v0.8.0 的工具系统走的是 Function Calling 路线，模型在回答之前，会先判断“当前问题需不需要调用工具”，如果需要，就生成一个结构化的工具调用指令，系统执行后把结果返回给模型，模型再基于结果组织回答。
默认内置的工具包括：
- 知识库检索：RAG 主检索能力
- 网页请求：输入 URL 抓取网页内容
- 数据库查询：支持 MySQL、PostgreSQL，通过配置连接串访问
- API 调用：按 OpenAPI 规范注册外部接口
- 代码执行：在沙箱环境跑 Python/JS 代码
- 内容转换：把 Markdown 转成 HTML、PDF 等
这一层逻辑上不复杂，真正考验人的是工具权限管理。如果你把数据库查询工具放开，模型只要拿到提示词里的连接串，理论上就能执行任意 SQL。我在配置时给每个工具都加了“作用域”限制，比如数据库工具只读SELECT，API 工具只允许白名单里的域名，代码执行沙箱禁用网络访问。这些限制一定要在最开始就设好，别像我一开始那样图省事全放开，结果模型在测试时给我执行了一条DROP TABLE，虽然库是测试库，也把我吓出一身冷汗。
4.2 自定义 OpenAPI 工具：对接公司内部系统
内置工具只能覆盖通用场景，真正让知识库“长出手脚”的是自定义工具。WeKnora 支持 OpenAPI 规范导入，也就是说，只要你的内部系统暴露了一个符合 OpenAPI 的 HTTP API，就能直接在管理后台注册成工具，模型会自动学会怎么调用。
我之前对接了一个内部的项目管理系统，它有查询任务列表、获取任务详情、更新任务状态几个接口。注册方式很简单，把 OpenAPI 的 json 文件传上去，系统会自动解析出每个接口的参数和格式。注册完成后，我在知识库里问“帮我查一下张工这周的任务完成情况”，模型会自动选择“查询任务列表”工具，填入assignee=张工、time_range=本周参数，然后把接口返回的 JSON 加工成自然语言回答。
这里要特别提醒参数描述的重要性。OpenAPI 文件里如果参数描述写得含糊，模型就不知道该传什么值。比如user_id这个参数，如果你只写“用户 ID”，模型看到“张工”这种中文名字时根本不会联想到它，它需要的是“用户姓名，例如：张工”这种描述。我踩过一次坑，后来把所有关键参数描述都改成了带中文示例的写法，工具调用的成功率从 40% 飙升到 85%。
4.3 工具调用失败时的兜底策略
工具调用不可能每次都成功，外部接口超时、参数填错、返回数据格式不对，这些都是家常便饭。v0.8.0 的处理逻辑是：工具调用失败后，不会直接告诉用户“出错”，而是尝试换一种方式再调，或者把错误信息反馈给模型，让模型基于已有知识回答。
我实际碰到最多的问题是数据库查询工具偶发超时。后来发现是查询语句涉及的表太大，索引没建好，接口响应超过系统默认的 10 秒超时。解决方法是先在数据库层优化查询性能，同时把工具调用的超时时间调到 30 秒。另一个问题是模型有时候会把参数类型填错，比如接口要 integer，它填了字符串。我在 OpenAPI 配置里把类型约束写得特别死，并且加了一个“参数类型校验”的前置步骤，不匹配就直接让模型重试，而不是真把错误请求发出去。
这些兜底策略配置好之后，知识库的工具调用稳定性才算真正可用。否则你兴致勃勃地问它“帮我把这周的销售数据汇总一下”，它回一句“调用失败，请稍后再试”，那体验比纯问答还差。
5. 让知识库长出技能：技能编排与实战配置
5.1 技能和插件的区别：一个是动作库，一个是剧本
微信群里经常有人问“agent 中插件和技能有什么区别”，我在 WeKnora 里实践后的理解是这样的：插件是动作库，提供“能做什么”；技能是剧本，定义“遇到什么情况、按什么顺序做”。插件可以单独被调用，比如“查天气”“发邮件”，技能则是一整套流程，可能包含多个插件调用、多次知识检索、多轮信息汇总。
比如我写了一个“周报自动生成”技能。它的流程是：
- 从知识库检索本周项目文档、会议纪要、任务记录
- 调用项目管理 API 拉取本周已完成和进行中的任务
- 用代码工具把上面两部分数据合并，按模板格式组织段落
- 调用 LLM 总结出本周亮点和风险
- 输出一篇完整周报
你看，这个技能里用到了知识检索、API 调用、代码执行和 LLM 生成四类能力，但它们不是分散的，而是被组织成一个有先后顺序的剧本。这就是技能和插件的本质区别。
5.2 一个技能配置文件的逐行解读
WeKnora v0.8.0 的技能定义在 YAML 文件里，存放在我在 Compose 里挂载的./skills目录下。技能的热加载让它改完就能生效，不用重启服务，这对频繁调参数的人来说太重要了。
下面是我写的“周报生成”技能的核心配置，注释已经写在文件里：
name: weekly_report description: 根据项目文档和任务系统数据生成周报 version: 1.0.0 trigger: type: intent patterns: - "生成周报" - "帮我写周报" - "本周总结" memory: required: true use_profile: true steps: - id: retrieve_docs type: knowledge_search params: query: "本周项目进展 会议纪要 任务记录" top_k: 10 rerank: true - id: fetch_tasks type: tool_call params: tool: project_task_api action: list_tasks args: time_range: "this_week" - id: merge_data type: code_execution params: language: python code: | import json docs = load_docs("retrieve_docs") tasks = load_tool_result("fetch_tasks") combined = docs + "\n" + json.dumps(tasks, ensure_ascii=False) save_intermediate("combined_data", combined) - id: generate_report type: llm_generate params: prompt: | 你是项目助理，请根据以下材料生成周报。 要求： 1. 分“项目进展”“本周任务”“风险与问题”三个板块 2. 语言简洁，用数据说话 3. 风险点单独列出 材料如下： {combined_data} temperature: 0.3 output: type: text format: markdown这段配置里最关键的是trigger和steps。trigger用意图匹配来判断用户是不是想触发这个技能，我写的几个中文模式覆盖了大多数说法。steps是执行流程，每一步都指定了类型，系统按顺序执行，上一步的输出会作为下一步的输入。
这里有个设计上的注意点：不要把太多逻辑塞进 YAML。我一开始想把数据清洗也在 YAML 里写，结果配置越来越长，改起来很痛苦。后来我调整了策略，YAML 只定义流程骨架，复杂的计算逻辑都抽到code_execution步骤里用 Python 写，相当于把脏活累活从配置里剥出去，整个技能文件才变得清爽。
5.3 技能与记忆、工具的联动效果
技能之所以比其他知识库的“工作流”高一个段位，是因为它能把记忆和工具串联起来。还是拿周报技能举例，技能执行到generate_report这一步时，模型会读取当前用户的画像记忆。如果画像记录了这个用户平时写周报喜欢“先讲风险再讲进展”，生成出来的文字就会按这个顺序，而不是机械地按配置里的固定模板。
技能还能触发其他技能。我写了一个“日报提交”技能，每天早上自动检索昨天的任务数据、生成日报，然后把日报结果作为触发条件，调用“周报生成”技能时，能把日报里的内容一并汇总进去。这种“技能套技能”的组合方式，让我可以把一个大任务拆成多个小技能，每个技能只负责一件事，调试和管理都方便得多。
这种组合能力在单个知识库工具里很少见，大多数竞品要么只能做问答，要么工作流编排得极其繁琐。WeKnora 把技能做成了像代码一样的可复用模块，我觉得这是它最有价值的地方。
6. 接入微信：让知识库走进聊天窗口
6.1 微信渠道的接入配置
现在回到标题里最显眼的“微信”两个字。WeKnora v0.8.0 支持把微信对话接入知识库，让它变成一个微信里的机器人助理。这样你在通勤路上随手发条消息，就能查文档、生成周报、调数据，非常符合“知识库长出手脚”的想象。
微信接入的底层渠道有两种：一种是接入企业微信自建应用，适合团队用；另一种是接入个人微信，适合自用和小范围测试。企业微信的接入比较标准，在管理后台创建自建应用，拿到 CorpID、AgentId、Secret 三个凭证，填入 WeKnora 的渠道配置里就行。个人微信的接入要复杂一些，v0.8.0 是通过一个消息转发中间件来实现的，中间件负责监听微信消息，转成 WeKnora 的标准消息格式发给核心服务，再把回复发回微信。
我建议有条件优先走企业微信渠道，稳定性和合规性都更好。个人微信方案虽然也能跑通，但存在账号风控风险，这一点我要旗帜鲜明地提醒大家。
6.2 让微信场景下的问答更自然
接入微信后，第一个要解决的问题是消息格式。用户在微信里发的消息可能是语音转文字、带表情符号、一句话没头没尾，这和网页端输入的规范问句完全不一样。v0.8.0 在渠道层做了消息预处理，包括：识别并剥离表情符号、把口语化的表述重写为书面语、识别消息里的 @ 提及和群聊标题。
我在一个测试群里做了个实验，用户直接发语音“那个，上次说的那个啥，到底什么时候上线啊”，系统能正确解析出“那个啥”指代的是之前聊天记录里提到的“新版门户上线时间”，然后从知识库检索排期文档，给出准确日期。这背后起作用的，就是前面说的会话记忆加用户画像加检索的完整链路。如果只是简单的“专人问答”，根本做不到这种程度。
群聊场景还有个特殊点：机器人不能所有消息都回复，否则群就炸了。v0.8.0 支持按“提及触发”“关键词触发”“私聊自动应答”三种模式配置。我配置的是：群里只有被 @ 时才回复，私聊则全部自动应答。这样既不会打扰群聊，私聊体验又很完整。
6.3 微信状态下技能调用的入口
技能在微信里怎么触发？除了对话意图触发，我配置了一个更实用的方式，在消息里带上技能前缀来精准触发。比如我发“周报：生成上周总结”，系统会跳过意图匹配，直接执行名为 weekly_report 的技能。这种“命令式入口”在真实使用里特别高效，因为意图匹配偶尔会翻车，而显式指令永远不会猜错。
技能执行时间通常比普通问答长，几秒到十几秒不等。微信对消息响应有超时限制，如果超过时间没有回复，用户端会提示“服务不可用”。我的解决办法是：把耗时超过 10 秒的技能全部改成异步模式。系统先回复用户一句“正在处理，请稍等”，技能跑完后主动推送给用户结果。这个体验上的细节很关键，一开始我没做异步，好几个同事跑来跟我说“机器人不回消息”。
7. 常见问题与排查技巧实录
7.1 检索质量差：答案牛头不对马嘴
这是知识库类应用被吐槽最多的问题，我在 WeKnora 上也碰到过。排查顺序和建议按下面这张表来：
| 现象 | 可能原因 | 排查与解决 |
|---|---|---|
| 检索结果完全不相关 | Embedding 模型选错或语言不匹配 | 换用 bge-m3 这类中英双语模型 |
| 明明有相关内容却召回不出来 | 相似度阈值过高 | 把阈值从 0.5 降到 0.3 到 0.4 逐个测试 |
| 召回的片段语义对但缺关键信息 | 文档切分不合理 | 改为“标题层级切分”，避免把段落切碎 |
| 多个相似文档互相干扰 | 缺少重排序 | 打开 rerank，并在重排序模型上加领域数据微调 |
| 问题涉及多个实体关系 | 单轮检索不够 | 打开“多跳检索”，让系统拆解原问题分多次检索 |
遇到检索问题时，可以先在管理后台上跑一次“检索调试”，输入一条问题，系统会把命中的文档片段、相似度分数、重排序分数全部展示出来。我靠这个功能定位了至少 80% 的检索问题，效率比拍脑袋改参数高多了。
7.2 多轮对话丢失上下文
如果你发现用户问到第五轮时，模型开始忘记前面的内容，重点检查两处：一是记忆写入开关是否打开，二是上下文摘要压缩是否生效。我见过最典型的情况是用户在一个会话里切换了话题，系统还把旧话题的完整记录塞在上下文里，导致模型分不清当前在问什么。v0.8.0 的会话管理支持“话题切换检测”，检测到明显跳变时会自动重置短期记忆，我打开后效果立竿见影。
7.3 文档解析乱码或丢内容
中文 PDF 乱码是最常见的解析问题，根源通常是 PDF 里使用了自定义字体或者字符编码不标准。WeKnora 的应对策略是先走原生解析器，如果检测到异常再自动切换 OCR 流程，但 OCR 对表格和代码段落的识别效果有限。我的建议是：对于重要 PDF，尽量用 WPS 或 Office 先转成 Word 再上传，解析准确率能提升一个档次。
7.4 工具调用失败与超时调优
工具调用失败排在前面的是参数填错、接口超时、鉴权失败三类。参数填错的问题我在第 4 节提过，关键是优化 OpenAPI 描述。接口超时的话，先检查目标服务的响应效率，然后再调高 WeKnora 工具调用的超时配置。鉴权失败要重点检查 token 是否过期，WeKnora 支持为每个工具配置独立的鉴权刷新策略，比如 OAuth2 的 refresh_token 自动续期。
7.5 Docker 容器内存不足
WeKnora 带上模型后还是比较吃内存的。我用 qwen2.5:14b 加 bge-m3，32GB 内存跑得还算流畅，但如果同时开多个会话，核心服务偶尔会被 OOM。解决办法是在 Compose 里给服务加上内存限制，同时调低模型的并发数。还有一个细节，知识库里图片和音频多了之后，/app/data目录会膨胀很快，建议定期清理历史聊天记录里的多媒体缓存，并设置数据目录自动备份。
7.6 微信消息长时间收不到回复
如果微信里发了消息但机器人一直不回复，先看消息中间件的日志，确认消息是否转发到了 WeKnora 核心服务。常见原因包括：微信凭证过期、中间件进程挂掉、核心服务的渠道 webhook 没配对。我的排查口诀是“先看转发、再看处理、最后看回复”，从日志里逐段确认链路，基本十分钟内能定位问题。
8. 我的一些体会：什么场景下值得折腾这套东西
折腾完 WeKnora v0.8.0，我对“知识库”这个概念的理解已经变了。以前我把知识库当成一个“文件柜”，资料存进去，要找的时候翻出来。现在它更像一个“读过所有资料、会查外部系统、能按流程办事的员工”。这个转变不是靠一个功能点完成的，而是记忆、工具、技能三个能力叠加后的整体涌现。
如果你问我，到底什么人适合搭这套东西？我的建议很直接：如果你手里有大量文档，而且这些文档需要经常被“用”而不是只被“查”——比如自动生成报告、定时汇总数据、按部门分发信息——那么 WeKnora 这套“记忆 + 手脚 + 技能”的架构值得投入时间去研究。如果只是偶尔搜一下公司制度、查个过往方案，那用现成的在线知识库工具就足够了，没必要折腾本地部署。
整个部署和配置过程花了大概一周，但真正回本是在接上微信和技能之后。现在每天早上，群里会自动推送前一天的运营数据摘要，每周五下午，系统会自动把项目周报整理好发到管理群。这些东西以前全靠人工整理，现在知识库自己就把活干了。
最后说一个实操里的小建议：无论你选择哪个知识库工具，部署前先想清楚“它要帮你解决哪些具体动作”，而不是先搭完再想能干什么。我是先列了五个必须自动化的工作流，再回头找合适的工具，这样落地起来目标明确得多，也不会陷入功能把玩的泥潭里。这个思路，比任何版本号的新特性都管用。
