知识库搭完就完了？加上这两招，效率翻倍

备选标题①：别再用 RAG 从零搜了！3 步搭出互联知识库 + 接入 AI 助手备选标题②：99% 的人卡在"知识库能搜"就停了——你还能再做两步备选标题③：知识库入门容易精通难：两个进阶玩法效率直接翻倍

上篇我们用 MemPalace + ChromaDB + Ollama 搭好了基础知识库。安装、嵌入、搜索、定时扫描，一条龙跑通。

但说实话，能搜只是起点。

搜索是"每次从零发现"，你问一次它找一次，找不到就是找不到。知识之间的关系？没有。知识的沉淀和演化？也没有。

今天讲两个进阶玩法，直接把知识库从"能用"拉到"好用"：

第一，LLM Wiki 互联知识库。

第二，接入 AI 助手，让记忆自动流转。

一、LLM Wiki：从"搜文档"到"用知识"

传统 RAG 的致命问题

每次提问，RAG 都要重新检索、重新理解、重新组织答案。同一个知识点问了十遍，它就检索了十遍，没有任何积累。

这就像每次考试都从头翻课本，从不做笔记。

LLM Wiki 的思路不一样：一次编译知识，持续更新，互联引用。

它源自 Karpathy 的 LLM Wiki 模式，用互联的 Markdown 文件构建一个持久化的知识网络。

三层架构

LLM Wiki 的核心是三层分离：

Layer 1：raw/ —— 不可变原始资料。

放文章、论文、对话记录等原材料。

一旦放进去就不改，作为知识源头。

Layer 2：Wiki Pages —— AI 拥有的知识页面。

这是核心产出层。

包含实体页、概念页、对比页、查询页。

每个页面都是经过消化的结构化知识。

Layer 3：SCHEMA.md —— 结构规则和标签分类法。

定义整个 wiki 的域配置、标签体系、页面阈值。

是整个系统的"宪法"。

三层分离的好处：原始数据不动，知识页面持续演化，规则独立维护。

实操：5 分钟搭骨架

先创建目录结构：

1
mkdir -p ~/wiki/{raw/{articles,papers,transcripts,assets},entities,concepts,comparisons,queries}

创建 SCHEMA.md：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
# Wiki Schema

## Domain
AI Engineering & Knowledge Management

## Taxonomy Tags
- #architecture
- #embedding
- #retrieval
- #integration
- #rag
- #vector-db
- #workflow

## Page Thresholds
- entity_min_references: 2
- concept_min_sections: 3
- comparison_min_axes: 3
- query_max_age_days: 90

## Naming Convention
- lowercase-with-hyphens.md

创建 index.md（导航中心）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# Wiki Index

## Entities
<!-- entities listed here -->

## Concepts
<!-- concepts listed here -->

## Comparisons
<!-- comparisons listed here -->

## Queries
<!-- queries listed here -->

创建 log.md（操作日志）：

1
2
3
4
# Wiki Log

| Date | Action | Target | Notes |
|------|--------|--------|-------|

完成。这就是一个完整的 LLM Wiki 骨架。

三个核心操作

LLM Wiki 围绕三个操作展开：

Ingest（摄入）：把原材料变成知识。

流程是：捕获原始源 → 讨论要点 → 检查已有页面 → 创建或更新页面 → 更新导航。

不是简单存文件，而是消化、提取、关联、索引一条龙。

Query（查询）：基于已有知识回答。

关键区别：查完之后，有价值的答案会写回 wiki。知识越用越丰富。

Lint（检查）：保持知识库健康。

检测孤儿页面、断裂链接、索引完整性等六类问题。超过 100 个页面后，不跑 Lint 就是给自己埋雷。

Obsidian 兼容

LLM Wiki 原生兼容 Obsidian。[[页面名]] 的 wikilinks 语法直接可用。

Graph View 可以可视化知识网络。

把 ~/wiki 当作 Vault 打开就行，零迁移成本。

二、接入 AI 助手：让知识自动流转

知识库搭好了，但每次手动查还是很累。

更合理的做法是：把知识库变成 AI 助手的长期记忆，对话时自动存取。

方式 A：MemoryProvider 深度集成（推荐）

MemPalace 直接作为 AI 助手框架的 memory provider，对话时自动同步记忆。

在框架配置文件中设置：

1
2
3
4
5
6
7
8
memory:
  memory_enabled: true
  user_profile_enabled: true
  memory_char_limit: 2200
  user_char_limit: 1375
  provider: mempalace
  nudge_interval: 10
  flush_min_turns: 6

再创建 mempalace.json 配置自动提取：

1
2
3
4
{
  "auto_extract": true,
  "extract_model": "glm-4-flash"
}

这里 extract_model 用轻量模型做记忆提取，成本极低。

配置完成后，框架自动注册 6 个工具：

mempalace_recall（语义搜索）、mempalace_store（精准存储）、mempalace_knowledge（查询知识图谱）。

mempalace_kg_add（添加三元组）。

mempalace_kg_invalidate（标记过期）、mempalace_status（记忆总览）。

三个自动钩子

集成后，三个钩子自动工作：

sync_turn() —— 每轮对话结束，自动把消息持久化到 MemPalace。你不用手动存。

on_memory_write() —— 框架内置记忆写入时，自动镜像到 MemPalace。双写，不丢。

on_session_end() —— 对话结束时，自动提取三类记忆：Persona、Episodic、Instruction。提取完直接存入，下次对话自动加载。

去重机制：新记忆与已有记忆做 cosine similarity，超过 0.92 视为重复，跳过存储。防止记忆膨胀。

方式 B：MCP Server（备选）

如果框架不支持 MemoryProvider，可以用 MCP 协议接入：

1
2
3
4
mcp_servers:
  mempalace:
    command: python
    args: ["-m", "mempalace.mcp_server"]

功能一样，但没有自动钩子方便，适合过渡。

三、多实例隔离：别让并发写炸了你的数据库

同时跑多个 Agent（主助手 + OpenClaw 定时挖掘 + 其他实验），它们都写同一个 ChromaDB，迟早出问题。

ChromaDB 不是为高并发写入设计的。多进程同时写，数据损坏只是时间问题。

解决方案：每个 Agent 用独立的 MemPalace 实例。

实例	路径	使用者
主实例	`~/.mempalace/palace/`	AI 助手主程序
第二实例	`~/.mempalace/palace-openclaw/`	OpenClaw 定时挖掘
第三实例	`~/.mempalace/palace-yuan/`	其他 Agent

路径不同，ChromaDB 实例不同，互不干扰。

OpenClaw 定时挖掘脚本示例：

1
2
3
4
5
6
#!/bin/bash

PALACE_DB="/root/.mempalace/palace-openclaw"
PALACE_PATH="/root/.openclaw/workspace-main"

mempalace --palace "$PALACE_DB" mine "$PALACE_PATH" --limit 500

然后配置定时执行。用 OpenClaw 自己的 cron，不要用系统 crontab。

踩坑清单

1. ChromaDB 并发写必挂。 多 Agent 共享一个实例是"能跑"但"迟早崩"。老老实实隔离。

2. 记忆提取模型别用大模型。 extract_model 用轻量模型就够了。用大模型做提取，成本是收益的十倍。

3. LLM Wiki 的 Lint 别偷懒。 知识库超过 100 个页面后，孤儿页面和矛盾内容会越来越多。

4. wiki 路径别用中文。 文件名和目录名都用英文加连字符。中文路径在 wikilinks 中会出奇怪问题。

5. MemPalace 去重阈值 0.92 不要调低。 调到 0.85 以下，相似但不同的记忆会被误判为重复丢弃。宁可多存，不可误删。

6. flush_min_turns 别设太大。 设成 20 的话，对话在第 15 轮断了，那 15 轮的记忆都没存。建议 6-8 轮。

总结

上篇解决了"知识库能存能搜"。

这篇解决了两个更关键的问题：

第一，知识库能互联、能演化。LLM Wiki 的三层架构让知识从"孤立文档"变成"互联网络"，越用越丰富。

第二，知识库能和 AI 助手自动协同。MemPalace 作为 MemoryProvider，对话即存储，查询即回忆，全程自动化。

加上多实例隔离，多 Agent 并行也不会打架。

三步走：基础搭建 → 互联知识库 → AI 助手集成。到这步，你的知识库系统才算真正完成。