一、知识管理的痛：存了就等于记住了？
你电脑里的文档，是不是越存越多，但真要用的时候就死活找不到？
几十个G的技术方案、项目笔记、行业报告——明明就在硬盘里，搜"血糖仪"找不到"健康监测系统"，搜"项目方案"匹配不到"立项报告"。关键词搜索的逻辑，和你脑子的想法，永远对不上。
这中间横着一个问题：语义鸿沟。
我们团队从2026年4月开始，围绕这个核心问题，用一套"本地+远程"双引擎方案，把知识管理从"搜不到"进化到了"用得出"。
二、第一步：先把全县城翻一遍
第一版方案很直接——把OpenClaw工作区所有的文档做向量化索引。
我们选了 sqlite-vec 做本地向量引擎，配套 BAAI/bge-small-zh-v1.5 中文嵌入模型。选sqlite-vec的理由很简单：零依赖、不开新服务、数据全在一个文件里，备份就是拷走。
迁移脚本跑通后，全量索引的结果：
- 1,737 篇文档
- 11,812 个文本块
- 向量库体积：38.9 MB
- 成功率：98%
接着部署了看门狗脚本，每小时自动增量索引，凌晨2点做一次全量重建。搜索体验从"关键词匹配"变成了"语义找答案"。"记不住"变成了"搜得到"。
三、第二步：发现问题，升级方案
本地方案跑顺了，但新问题跟着来了。
第一个问题：知识来源割裂。 工作区有项目文档，Obsidian有个人笔记，后面还有Coze、Dify等平台的内容。把所有来源塞进一个sqlite-vec库，技术上能跑，但管理成本高——每个来源的扫描、分块、嵌入流程都不同，全挤在一个库里，出问题根本查不清。
第二个问题：扩展性瓶颈。 后面要开放给其他AI平台用，需要标准化的REST API接口，而不是直接操作SQLite文件。
于是我们做了升级：从"单一向量库"升级为"双引擎架构"。
- Local引擎（沿用原方案）：sqlite-vec + BGE模型，512维，日常主力搜索
- ChromaDB引擎（新部署）：384维，all-MiniLM-L6-v2模型，面向多平台扩展
两个引擎独立计算嵌入、独立存储，通过统一的网关对外服务。
四、双引擎怎么协同
架构上，云主机和家庭服务器通过ZeroTier组成了虚拟局域网。
云主机（192.168.195.213）跑Local引擎和网关服务；家庭服务器（192.168.195.113）跑Docker里的ChromaDB。两台机器点对点直连（P2P），延迟低、稳定性好。
ChromaDB 里建了两个集合：
- obsidian_kb：个人笔记，144篇文档
- openclaw_kb：工作区文档，4,799篇文档
两个集合用同一嵌入模型，但存放不同来源。搜索时网关自动跨两个集合查询、合并结果，用户无感知。
knowledge_gateway.py 是统一的搜索入口，支持三种策略：
- local：只查本地库（1,737文档）
- chroma：跨两个ChromaDB集合合并搜索（4,943条）
- dual：两个引擎同时查，结果合并去重排序
以"AI工程合伙人方法论"为例，local策略能搜到工作区相关文档，chroma策略能搜到Obsidian里的《AI工程合伙人合作介绍书》《企业AI工程可行性自查表》——这些是个人笔记，本地库里没有。dual策略取两者之长，结果更全面。
五、这样设计解决了什么
双引擎方案最大的价值，不是技术指标上的提升，而是解决了三个实际问题：
1. 知识来源独立管理：工作区文档、个人笔记、平台文档各有各的索引，不混在一起
2. 统一API对外服务：不管背后几个引擎，用户只调一个接口
3. 渐进式演进路径：先跑通本地库，再扩展远程引擎，每一步都有备份
六、下一步
短期把更多来源（Coze、Dify等平台文档）纳入ChromaDB索引；中期评估ChromaDB能否升级为主力引擎，把本地引擎降为备份角色；长期把ChromaDB打造成统一的知识中心，为所有AI平台提供标准化的知识检索服务。
知识管理这件事，做一遍不难，难的是做得通、用得顺、可持续。这套双引擎方案，我们还在这条路上继续走。
IT老傅 | 坐标北京 | 近30年软件行业老兵 | 17年创业经历
核心业务：
1. AI培训与咨询 —— 帮个人和企业用好AI（让天下没有难用的AI）
2. 软件定制开发 —— 从AI应用到企业系统（AI重造业务）
正在做的事：
· 运营「AI应用模式探索」知识星球，每天分享能落地的AI玩法
· 打造AI工作流系统，让个人和中小企业也能用上AI
想了解更多AI应用模式和实操落地方法？
欢迎加入我的知识星球「AI应用模式探索」
知识星球链接：https://wx.zsxq.com/group/88511145421842
关注我，一起用AI提升效率、创造价值！
微信公众号：神州共赢 | IT老傅聊AI
抖音|快手|视频号|小红书：IT老傅聊AI |
