OpenClaw知识库机制配置

未来的哇咔咔••3 分钟阅读

三项基础能力

这三项能力要同时存在，Agent 才能真正表现出“有记忆、会查知识”的效果。

文档库管理能力

  1. 虽然原理一致，但最好把“记忆”和“知识库”分开管理，否则后续检索会混杂。
  2. workspace*/memory：动态内容，偏会话记录，信息密度低，使用方法是显式搜索。
  3. workspace*/knowledge：相对稳定的知识文档，信息密度高，使用方法是自动的语义查询和上下文注入。
  4. 管理重点：命名清晰、结构清晰、持续清理过时文档。

文档向量化能力

  1. 文档不能直接用于语义检索，需要先经过 embedding 转成向量，再写入向量库。
  2. 流程：读取文档并切块；用 embedding 模型生成向量；写入本地或远程向量库。
  3. 常见向量库存储方式：SQLite vec0（内置机制），ChromaDB（自己安装）。

语义查询触发能力

  1. 即使完成向量化，如果没有查询触发机制，知识也不会自动进入对话上下文。
  2. 被动触发：用户命令查询。
  3. 主动触发：插件在会话中自动召回并注入上下文。

OpenClaw的memory机制

  1. 自带memory目录：OpenClaw 默认提供 memory 目录机制，不需要额外接入就能使用。你可以把它理解为“默认记忆通道”。

  2. 自动更新向量数据库：在监听开启时，memory 文档变化会自动触发增量索引。模型可用 Gemini 等 embedding 方案，系统持续维护向量库新鲜度。

  3. 被动查询：用户按需查询，而不是每轮对话都强制检索。建议把 memory 当作“随时可检索的工作记忆层”，而不是一次性上下文堆叠层。

OpenClaw的knowledge机制

内嵌QMD后端提供基础能力

  1. 内置了QMD/检索后端负责整条链路：读取文档；按规则切块；调用 embedding 生成向量；写入向量库；检索命中后回填对话上下文。
  2. 需要本地或远程接入知识库：直接提供路径即可，建议在本地创建。

自行使用本地或者远程模型

  1. 本地模型：成本低延迟低速度快（某些条件下），但受限于硬件，性能一般，需要好好衡量任务的复杂度。
  2. 远程模型：有一点成本，但上限更高，可以做复杂的重新排序等计算，能利用现成的qmd机制方案也比较简洁。
  3. 如何抉择：先用本地方案跑通并验证稳定性，如果出现“召回不稳、排序不准、跨表达失配”，再评估远程。

注意配置问题

  1. 索引阶段和查询阶段必须遵守同一向量空间约定，否则召回会不稳定。
  2. 维度：embedding 模型一致（或严格兼容）；向量维度一致；相似度与归一化策略一致；切块与 metadata 约定一致（如 doc_id、section_path）等。

我当前的方案

我的需求特点

  1. 每个知识库文档量控制在100篇以内。
  2. 每篇 Markdown 尽量不超过3000字。
  3. 文档结构清晰，不追求重排等高质量查询能力。

方案落地配置

  1. 在每个 workspace 下维护独立 knowledge 目录，做到数据隔离。
  2. 使用 bge-small-zh-v1.5 生成中文向量（8GB的intel芯片硬件）。
  3. 使用“心跳机制 + 哈希检查”做自动化增量更新。
  4. 使用 chromadb-memory 插件自动完成检索与上下文注入。
  5. 保留后续切换远程方案的接口，不在当前阶段过度扩展。