LLM Wiki on Kalend's Blog

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

Fri, 29 May 2026 10:00:00 +0800

备选标题①：别再用 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 助手集成。到这步，你的知识库系统才算真正完成。

我给AI建了个全自动知识库：每周自动从对话中提炼知识点

Tue, 26 May 2026 23:00:00 +0800

和AI聊了几百轮，发现最有价值的知识全散落在聊天记录里。下次遇到类似问题，还得重新问一遍。

这不是工具推荐，是我自己搭的一套系统。用了一年，从零长到23个知识页面，全是AI自己从对话里提炼出来的。

先说结论：把AI当知识管理员，比当聊天机器人有用得多。

一、为什么要自动化知识库

我每天和AI助手聊天，聊技术、聊工具、聊踩坑经验。

这些对话里藏着大量可复用的知识点：某个工具的配置方法、某个问题的解决方案、某个概念的清晰解释。

但问题是——它们全在聊天记录里。

想找的时候翻不到，找到了也不确定是最新的。

更关键的是，下次遇到类似问题，我又得重新描述一遍背景，重新问一遍。

所以我想要一个系统：自动扫描对话，自动提炼知识点，自动写入知识库。

不是什么Notion模板，不是Obsidian手动整理。

是真正的全自动——我正常聊天，知识库自动生长。

二、方案：LLM Wiki 规范 + 定时扫描

我的方案基于Karpathy提出的LLM Wiki规范。

核心思路：用Markdown文件存知识，用双向链接把知识点串成图谱，用AI定时扫描对话来增量更新。

整个知识库就是一个文件夹，长这样：

1
2
3
4
5
6
7
8
9


wiki/
 entities/ # 实体页（工具、人物、项目）
 concepts/ # 概念页（方法论、架构、工作流）
 comparisons/ # 对比页（方案选型）
 queries/ # 查询页（常见问题）
 raw/ # 原始素材（对话摘要）
 SCHEMA.md # 规范定义
 index.md # 全局索引
 log.md # 操作日志

每个页面都有统一的frontmatter格式：

1
2
3
4
5
6
7
8
9


---
title: 页面标题
created: 2026-05-14
updated: 2026-05-25
type: entity | concept | comparison | query
tags: [ai, tools, open-source]
sources: [raw/articles/xxx.md]
confidence: high | medium | low
---

用[[wikilinks]]语法在页面间建立双向链接。

比如opencode页面引用了understand-anything，后者又引用了hermes-agent。

这些链接自动形成知识图谱，不用手动维护。

三、扫描脚本：从对话中挖知识点

核心是一个Python脚本，每周自动扫描最近7天的AI对话记录。

它的逻辑很简单：

第一步：扫描会话数据库，找到最近有实质内容的对话。

筛选标准：消息数≥5条，标题非空，时间在7天内。

第二步：用关键词匹配分类。我定义了8个类别：

1
2


AI/模型 | 工具/Agent | 数据库 | OSINT
DevOps | 编程 | 写作 | 记忆/知识库

每条匹配规则是多个关键词用管道符连接。

比如"ai|llm|模型|训练|推理"都归到AI类。

第三步：过滤掉已有页面覆盖的内容，输出候选清单。

第四步：LLM Agent拿到候选清单，判断是否值得入库。

不是什么都记。有两个硬性门槛：

同一个知识点出现2次以上，或者来自1个高质量核心来源。

这样避免了把闲聊当知识的问题。

四、自动化流程：定时任务配置

我把扫描脚本配成了定时任务，每周日上午11点自动运行。

流程是四步：

扫描脚本输出候选 → LLM判断是否值得入库 → 创建或更新wiki页面 → 追加操作日志

目前已经跑了5轮自动入库，产生了这些内容：

实体页13个：hermes-agent、mempalace、opencode、obsidian、karpathy等。

概念页5个：双向链接、知识库工作流、五层记忆架构、MySQL大表DDL方案、被动验证方法论。

最有价值的是交叉引用。

opencode → understand-anything → hermes-agent → openclaw

这条引用链，把四个工具的定位和关系串了起来。

下次我需要对比它们，直接看知识库就行。

五、设计思考：为什么不用Notion

很多人会问：为什么不直接用Notion？或者Obsidian的插件？

三个原因：

第一，数据主权。我的知识库是本地Markdown文件，git管理。

不依赖任何云服务，不会因为某天服务下线就丢数据。

第二，增量构建。不是一次性搭好架子然后手动填充。

是每周自动从对话中生长，越用越丰富。

我正常使用AI，知识库自动变厚。

第三，AI做苦力。扫描、分类、提取、格式化，全部自动化。

我只做最终决策——这个东西值不值得记。

当然也有代价：没有Notion那么漂亮的界面，没有协作功能。

但知识库的本质是"能找到"，不是"好看"。

六、一个真实页面长什么样

拿hermes-agent这个实体页举例：

开头是frontmatter，包含标题、日期、类型、标签、来源、置信度。

然后是正文：概述、核心架构（配置层级表格）、Profile隔离系统、Skill系统、五层记忆架构、多平台网关。

最后是相关页面链接：nous-research、llm-wiki、obsidian、mempalace。

每个链接都能跳转，形成知识网络。

整个页面从创建到现在更新了3次，每次都是自动扫描触发的。

不是手动维护的"死"文档，而是跟着我的使用持续进化的"活"知识。

回看log.md的操作记录，5次自动入库覆盖了完全不同的领域：

从MySQL大表DDL方案到OSINT被动验证方法论。

这正是自动化的价值——它不会只记你"觉得重要"的东西。

而是记录你"实际在用"的东西。

如果你也在大量使用AI工具，强烈建议搭一个自己的知识库。

不需要复杂，一个文件夹 + 一个扫描脚本就够了。

关键不是工具选型，而是让知识自动沉淀。

手动整理的知识库，最后都会变成没人维护的死文档。

只有自动化的，才能活下来。

关注 varkm，一起学习，一起成长

下一篇讲怎么给这个知识库加上语义搜索，让它从"能找到"变成"能联想"