从 RAG 到可持续演化的知识库：llm-wiki 介绍

如果把今天大多数 LLM 文档问答系统抽象一下，本质上还是一种"查询时检索"。你把一批文档交给系统，等提问时再去切片、召回、拼接、生成答案。这种方式当然有用，但它有一个明显问题：知识不会沉淀。每次提问，模型都像第一次接触这些材料一样重新搜索、重新理解、重新综合。

llm-wiki 试图解决的，正是这个问题。

它不是让大模型每次都回到原始资料里"现查现答"，而是让大模型持续维护一套持久化的 wiki。新的文章、论文、笔记被加入后，LLM 会把信息吸收进 wiki：创建页面、更新摘要、补充概念、维护交叉链接、标记冲突、修正旧结论。这样，知识不再停留在一次次临时回答中，而是变成一个不断累积、不断演化的中间层。

从这个角度看，llm-wiki 更像"知识编译"，而不是"知识检索"。

项目地址：

llm-wiki-agent: github.com/regexp-lin/...

一、什么是 llm-wiki

llm-wiki 的核心思想可以概括为三层结构：

原始资料层 raw/
由 LLM 维护的 wiki 层 wiki/
约束 LLM 行为的 schema / agent instruction 层

其中：

raw/ 是原始输入，通常是文章、论文、会议记录、调研笔记等，不应该被 agent 修改。
wiki/ 是知识沉淀层，由 LLM 负责创建和维护，里面是结构化的 Markdown 页面。
schema 或 agent 指令文件用于告诉模型：目录怎么组织、页面怎么命名、frontmatter 用什么格式、什么时候更新索引、什么时候追加日志。

这套模式和传统 RAG 最大的区别，不在于"是否用了向量检索"，而在于是否有一个持续存在、可被反复增量维护的知识中间产物。

也就是说，llm-wiki 的重点不是"让模型更会搜"，而是"让模型替你长期整理知识"。

二、为什么这种模式有意义

llm-wiki.md 中强调的一个判断很关键：很多知识工作真正麻烦的，并不是阅读本身，而是后续维护。

比如你读了几十篇论文、几十篇行业分析、几个月会议记录后，最痛苦的事情通常是：

某个概念之前在哪篇文章里出现过？
新文档是不是推翻了旧结论？
这个人物、公司、项目值得不值得单独建页？
哪些页面已经成为孤岛，没有被任何地方引用？
某次对话里提炼出的结论，是否应该沉淀为长期资产，而不是留在聊天记录里？

这些工作非常适合交给 LLM。因为它们需要跨文档阅读、跨页面改写、批量更新、重复执行，而且很琐碎。对人来说维护成本高，对模型来说却是天然强项。

因此，llm-wiki 的价值不只是"能回答问题"，而是：

让知识随着资料增加而复利增长
让答案可以回写成页面，而不是消失在上下文窗口里
让 wiki 逐渐形成稳定结构，而不是一堆散乱笔记
让 LLM 成为知识库维护者，而不仅仅是问答助手

三、适合哪些使用场景

这个模式非常适合"持续积累知识"的任务，而不只是一次性问答。

典型场景包括：

个人知识管理：把日记、文章摘录、课程笔记、播客记录整理成一个长期演化的个人 wiki。
研究型学习：围绕某个主题持续读论文、报告、博客，逐步形成概念页、人物页、争议点和总体综述。
读书伴随系统：边读书边让 agent 维护角色、主题、事件线和概念之间的关系。
团队内部知识库：把会议纪要、项目文档、Slack 讨论、客户访谈逐步沉淀成内部 wiki。
行业研究和竞品分析：随着新资料进入，不断修正观点，而不是每次从零开始重做分析。
课程学习和专题训练：把阶段性问题、对比分析、总结稿保存成 synthesis 页面，作为后续学习的基础。

如果你的工作特点是"持续读、持续想、持续更新判断"，那么 llm-wiki 会比一次性 RAG 更有吸引力。

四、llm-wiki-agent 在做什么

llm-wiki 是理念，llm-wiki-agent 则是把这套理念落地为可操作 workflow 的智能体方案。

当前这个仓库里的 llm-wiki-agent-nodejs，是它的 Node.js / TypeScript 实现。它把 agent 的工作明确拆成四个核心流程：

ingest：摄入新资料
query：基于现有 wiki 回答问题
lint：检查 wiki 健康状况
graph：构建知识图谱

这四个流程，基本就对应了一个知识库从"吸收信息"到"产出答案"再到"自我维护"的完整闭环。

1. ingest：把原始资料编译进 wiki

在 src/workflows/ingest.ts 里，摄入流程不是简单做摘要，而是明确执行以下动作：

读取源文件内容并计算 SHA256 摘要
读取现有 wiki/index.md、wiki/overview.md
额外读取最近 5 个 source pages，形成当前 wiki 上下文
读取 WIKI_SCHEMA.md，把结构规范一并送给模型
调用 Claude Sonnet 返回结构化 JSON
将 JSON 写入多个目标文件

生成结果不是单文件，而是一组更新：

wiki/sources/<slug>.md
若干 wiki/entities/<Name>.md
若干 wiki/concepts/<Name>.md
可选更新 wiki/overview.md
更新 wiki/index.md
追加 wiki/log.md

这正是 llm-wiki 和普通摘要工具的差别所在：输入一份资料，输出的是一组知识库变更，而不是一段一次性的总结。

2. query：不是查 raw，而是查 wiki

src/workflows/query.ts 展示了一个很有代表性的设计：查询优先面向 wiki 页面，而不是原始资料。

它的流程是：

先读取 wiki/index.md
用标题关键词做第一轮匹配
如果匹配不足，再用 Claude Haiku 从索引里选择相关页面
读取命中的 wiki 页面内容
用 Claude Sonnet 基于这些页面进行综合回答

这里有两个很重要的信号：

它依赖 index.md 作为内容入口，而不是默认做向量数据库检索
它要求回答中使用 [[WikiLink]] 形式引用来源页面

这说明该实现的基本假设是：当 wiki 规模还在中等范围内时，维护良好的索引和页面结构，本身就足以支撑高质量问答。

而且，查询结果还可以通过 --save 存入 wiki/syntheses/。也就是说，问答本身也可以变成知识资产。

3. lint：把 wiki 当代码库一样维护

src/workflows/lint.ts 是整个设计里很有意思的一部分，因为它把知识库维护显式工程化了。

它会做两类检查：

结构性检查：孤立页面、断链、被多次引用但没有独立页面的实体
语义检查：矛盾、过时内容、数据缺口、深度不足的概念

其中结构检查完全基于本地规则完成，比如：

解析 [[wikilinks]]
统计入链数量找 orphan pages
判断链接目标是否存在
统计被提及次数达到阈值但未建页的实体

而语义检查则交给模型完成。

这背后的思路很值得借鉴：知识库不是"生成完就结束"，而是应该被持续巡检。lint 在这里扮演的角色，很像软件工程里的静态检查和健康诊断。

4. graph：把页面关系可视化

src/workflows/graph.ts 则把 wiki 页面之间的关系构造成图。

它分两步：

Pass 1：从显式的 [[wikilinks]] 中提取确定性边
Pass 2：对变更页面做语义推断，补充隐含关系边

这个流程还有几个实现上的亮点：

使用 SHA256 缓存，只对内容变更页面做推断
区分 EXTRACTED、INFERRED、AMBIGUOUS 三类边
用 Louvain 社区检测给节点分组
输出 graph/graph.json 和可直接打开的 graph/graph.html

所以它并不是只做一个"好看图谱"，而是在为知识结构提供额外的浏览与诊断视角。

五、这个 Node.js 实现为什么值得注意

从源码看，llm-wiki-agent-nodejs 不是随意拼出来的 demo，而是有比较清晰的工程化分层。

目录结构大致是：

text 复制代码

src/
├── shared/
├── workflows/
└── cli/

其中：

shared/ 放通用能力，比如路径常量、文件读写、wiki 链接处理、LLM 响应解析
workflows/ 放真正的业务流程
cli/ 只做命令行参数解析和入口转发

这种拆分有几个好处：

workflow 可以同时被 CLI 和 agent 指令复用
schema 被单独抽到 WIKI_SCHEMA.md，避免 IDE 专属说明污染 prompt
类型定义集中在 src/shared/types.ts，减少 LLM 返回 JSON 时的处理混乱
后续更换模型、改目录、扩充 workflow 都有清晰落点

特别值得一提的是 WIKI_SCHEMA.md。它在这个项目里不是配角，而是单一事实来源：

IDE agent 会读它
CLI prompt 会嵌入它
页面命名和 frontmatter 规范由它统一定义

这意味着，这个项目真正可迁移、可扩展的部分，不只是 TypeScript 代码，更是"把知识库规则显式写成 schema"这件事。

六、llm-wiki-agent 的使用方式

llm-wiki-agent 有两种主要用法：agent 模式和 CLI 模式。

1. Agent 模式

这是仓库最推荐的使用方式。

直接在支持的 coding agent IDE 中打开项目，例如：

Claude Code
Cursor
Codex
OpenCode
Gemini CLI / Antigravity

这些 IDE 会读取仓库里的 AGENTS.md、CLAUDE.md 或 GEMINI.md，从而知道如何执行 wiki workflow。

然后你可以直接对 agent 说：

text 复制代码

ingest raw/papers/my-paper.md
query: what are the main themes?
lint
build graph

在这种模式下，agent 直接利用本地读写能力维护 wiki，不需要你自己额外拼 prompt。

2. CLI 模式

如果你希望用命令行明确调用 workflow，这个项目也提供了 CLI。

前提是：

Node.js >= 22.16.0
已安装 pnpm
CLI 模式下需要设置 ANTHROPIC_API_KEY

安装：

bash 复制代码

cd llm-wiki-agent-nodejs
pnpm install

常见命令如下：

bash 复制代码

pnpm dev:ingest raw/papers/my-paper.md
pnpm dev:query "what are the main themes?"
pnpm dev:lint
pnpm dev:graph --open

如果需要编译后运行：

bash 复制代码

pnpm build
node dist/cli/ingest.js raw/papers/my-paper.md

或者使用 package.json 中声明的二进制入口：

wiki-ingest
wiki-query
wiki-lint
wiki-graph

3. 一个典型使用流程

如果从零开始搭一个知识库，比较自然的节奏通常是：

把原始资料放进 raw/
逐篇执行 ingest
用 query 从 wiki 中提取阶段性认识
把重要回答保存进 wiki/syntheses/
定期执行 lint
通过 graph 查看结构、社区和孤立节点

这样，原始文档会逐步转化为：

source pages
entity pages
concept pages
synthesis pages
overview
index 与 log

最后得到的不是"一个问答接口"，而是一套不断增长的 Markdown 知识库。

七、它和传统 RAG 的关系

严格说，llm-wiki 不是反对 RAG，而是把 RAG 放到了更靠后的位置。

在这个模式里，优先级通常是：

先维护好结构化 wiki
在中小规模下，依靠 index.md 和页面间链接完成检索
wiki 变大后，再考虑引入搜索引擎或混合检索

原始理念文档里也提到，等规模继续增长，可以接入类似 qmd 这样的本地搜索工具。但那属于增强项，不是这个模式成立的前提。

换句话说，llm-wiki 的关键创新点不是"用了什么检索引擎"，而是"把知识维护过程本身交给了 LLM"。

八、这个方案的边界与前提

当然，这种模式也不是没有前提。

要让它工作得好，至少需要满足几件事：

原始资料最好是相对干净、可读的 Markdown 或文本
你愿意把知识沉淀为文件，而不是完全停留在聊天窗口
schema 需要持续调优，而不是一次写完永远不变
人仍然要承担资料筛选、问题定义和关键结论把关

另外，当前这个 Node.js 实现本质上仍然依赖大模型的输出稳定性。例如：

ingest 的质量高度取决于 prompt 和模型理解
query 的页面选择策略目前仍偏轻量
lint 的语义检查是抽样式的，不是全量形式化验证
graph 的隐式关系推断也会受到模型判断波动影响

但这些问题并不会否定它的价值。相反，它们说明：llm-wiki-agent 的真正意义，不是把知识管理自动化到完全不需要人，而是显著降低"维护一套高质量 wiki"所需的人力成本。

九、总结

如果只把 LLM 当成一个随问随答的聊天工具，那么知识往往会停留在一次次临时上下文里，难以沉淀、难以复用、难以演化。

llm-wiki 提供的是另一种思路：让 LLM 维护一个持久存在的知识中间层。新资料进入后，知识被编译进 wiki；新问题出现后，答案可以继续回写；随着时间推移，整个知识库会越来越完整、越来越结构化。

而 llm-wiki-agent，尤其是这里的 llm-wiki-agent-nodejs，则把这种思路落成了一套可执行的工程实现：有 schema，有 workflow，有日志，有索引，有健康检查，也有图谱视图。

对于那些真正需要长期积累认知的人来说，这比"再做一个 RAG 问答壳"更有想象力。

项目地址：

llm-wiki-agent: github.com/regexp-lin/...