用Agent构建LLM Wiki：让AI自动管理知识库

从简易本地知识库说起

构建本地知识库的原理其实非常简单：新建一个文件夹，往里面放入若干 Markdown（.md）文档，这就构成了最基础的本地知识库。之后你就可以在各类 Agent 中直接提问，例如"根据知识库的内容告诉我如何征询别人"。

由于文档位于指定文件夹之中，Agent 便可以搜索该目录下的所有文件、阅读其中的文本，然后进行总结、归纳并输出给你。整个过程一目了然：先定位相关文件，再打开阅读，最后归纳输出。你甚至不必手动整理，直接把原文转成 Markdown 丢进去就能用。

这种方式最大的优点就是门槛极低——只要把需要的知识让 AI 帮你整理下来即可。但它的弊端也同样明显，这正是本文要解决的核心问题。

简易方案的瓶颈在哪里

当文档数量很少时（比如只有两三个），Agent 的搜索几乎是瞬时完成的。但设想一下，当你的知识库膨胀到 200 个甚至 2000 个文档时，情况就大不相同了。

AI 在盲目搜索这些文档时会消耗大量时间，而且不一定能找对。如果有四五个文档描述的是相关内容，AI 很可能看错文档；整个搜索与判断的过程不仅拖慢响应速度，还会消耗大量 Token。

这里有必要说明 Token 消耗问题的深层原因。大语言模型存在一个根本性约束——上下文窗口（Context Window）。主流模型如 GPT-4o 的上下文窗口约为 128K Token，Claude 3.5 系列可达 200K Token，但即便如此，当知识库包含数百个文档时，将所有内容塞入单次请求仍是不可能的。更重要的是，Token 数量直接对应 API 调用成本和响应延迟：每处理 1M Token，主流商业模型的费用约在 1–15 美元之间，响应时间也随 Token 量线性增长。因此，"盲目全文扫描"在工程上是极其昂贵的做法。

换句话说，随着知识规模增长，简易方案的检索效率和准确率会急剧下降。这时候，我们就需要一套更结构化的知识管理方法——这正是 Andrej Karpathy 提出的 LLM Wiki 理念的价值所在。

LLM Wiki 的核心理念

Andrej Karpathy 是 AI 领域极具影响力的研究者，曾任特斯拉 AI 总监及 OpenAI 研究科学家，以深度学习课程《Neural Networks: Zero to Hero》广为人知。他提出 LLM Wiki 理念的出发点，是观察到现有笔记系统（如 Notion、Roam Research）在知识量级扩大后维护成本急剧上升的现象。其核心洞察是：大型语言模型天然擅长处理结构化文本和建立语义关联，完全可以承担传统上需要人工完成的"知识整理员"角色。这一理念与知识管理领域的**卡片盒笔记法（Zettelkasten）**有异曲同工之妙——后者同样强调每条知识的原子化与显式链接，区别在于 LLM Wiki 将维护者从人类替换为 AI。

传统知识库为什么难以坚持？核心原因在于——人类太讨厌打标记和建索引了。每新增或修改一条知识，你都需要手动为它与其他知识建立链接。知识量少时尚可应付，但当知识网络变得庞大，一条新知识可能需要与几十上百条已有知识建立关联，纯靠人工维护几乎不可能。

LLM Wiki 的精髓在于：把这些繁琐的打标记、建索引工作交给 AI 去做。AI 可以自动分析新知识与已有知识的重合点，自动建立双向链接，从而维护起一个庞大而有序的知识网络。

值得一提的是，LLM Wiki 所解决的检索效率问题，本质上是 RAG（检索增强生成，Retrieval-Augmented Generation） 领域的核心挑战。RAG 是一种将外部知识库与大语言模型结合的架构，允许模型在生成回答时动态调取相关文档。传统 RAG 方案通常依赖向量数据库（如 Pinecone、Chroma），将文本切片后转化为高维向量并存储，检索时通过余弦相似度匹配最相关片段。然而向量检索存在"语义漂移"问题——相似的向量不一定代表逻辑上相关的知识。LLM Wiki 选择了另一条路：用结构化索引和显式双向链接替代隐式的向量相似度，使检索路径对人和 AI 都透明可解释。

引入 Obsidian 作为可视化工具

在实践 LLM Wiki 之前，推荐先安装 Obsidian（官网 obsidianmd）。它本质上是一个 Markdown 编辑器，但额外提供了几个关键能力：

• 双向链接（反向链接）：在文档中输入 [[文档名]] 即可建立跳转链接；
• 知识图谱：将知识之间的链接可视化成网络图；
• 白板功能：可以自由拼组笔记，构建知识画布。

Obsidian 采用的双向链接（Bidirectional Links）机制源自超文本理论的早期构想。与万维网单向链接不同，双向链接在 A 文档指向 B 的同时，B 文档的"反向链接"面板中也会自动显示来自 A 的引用。在技术实现上，Obsidian 通过解析 Markdown 文件中的 [[文档名]] 语法，在内存中构建一张有向图（Directed Graph），其知识图谱视图便是这张图的可视化渲染。对于 LLM Wiki 而言，这套机制的价值在于：AI 每次为新知识建立链接时，都在这张图中新增"边（Edge）"，随着知识累积，图的密度不断增加，AI 检索时可以沿图的边进行"语义游走"，从一个概念快速跳转到关联概念，而无需重新扫描全量文档。

打开 Obsidian 时选择"打开本地仓库"，把知识库文件夹作为仓库即可。带点的隐藏目录（如 .obsidian、.workbuddy）会被自动忽略，这些通常是软件配置文件，无需操心。

这里有一点值得特别强调：这些 Wiki 结构并不是给人看的，而是给 AI 看的。所以哪怕图谱里的英文概念你一时看不懂，也不必焦虑——AI 在回答问题时会依赖这些索引进行精准检索。

实操：用 Agent 初始化 LLM Wiki

实践 LLM Wiki 的方式非常简单。在 Skill 集市搜索 "Wiki"，找到卡帕西设计的 LLM Wiki Skill，点击安装并把说明复制到你正在使用的 Agent（如 WorkBuddy）中，Agent 就会自动从网站下载并安装该 Skill。

安装完成后，新建一个文件夹（比如命名为 MyWiki），绑定为工作空间，然后对 Agent 说"用 LLM Wiki 初始化这个仓库"，Agent 便会根据 Skill 规则对文件夹进行初始化，生成一套标准的目录结构。

三层知识库结构解析

初始化后，知识库呈现出清晰的三层结构：

第一层：原始文档层（Raw） 这是数据源，存放你的文章、论文、笔记、数据乃至图片音视频等资源。核心原则是——原文件原样保留，AI 不能修改。它是所有知识的最终来源。

第二层：知识库层（Wiki） 这一层完全由大模型维护，包含几个关键组成部分：

• source：每个来源的简短摘要、基本信息与核心知识点；
• entity：实体，把具体的技术、产品、人物等按维度抽象出来；
• concept：概念，将知识中的每个概念单独提炼；
• index：内容索引，记录每条知识存放的位置；
• overview：综合预览，介绍整个知识库收录了什么、核心主线是什么。

其中 entity 层和 concept 层，对应**知识图谱（Knowledge Graph）**领域的经典范式。知识图谱以"实体–关系–实体"三元组（Triplet）为基本单位组织知识，谷歌知识图谱、Wikidata 等产品均采用此结构。传统知识图谱的构建需要大量人工标注或专门的 NLP 管道（命名实体识别、关系抽取等）。LLM 的出现使这一过程大幅简化：大模型具备开箱即用的实体识别和关系推理能力，可以直接从非结构化文本中提炼出结构化的三元组。微软在其 GraphRAG 项目中采用了类似思路，通过 LLM 自动构建文档的局部知识图，再做社区检测和摘要，显著提升了跨文档推理的准确率——这与 LLM Wiki 的设计哲学高度一致，都是以图结构替代扁平化的向量检索。

第三层：配置层（wiki.md） 这是控制 Wiki 运作的核心文件，告诉 AI 当前知识库的结构如何、新知识进来后该如何编译和维护、双向链接怎么建、旧知识打什么标记，甚至还包含定期检查知识质量、处理矛盾知识的"健康检查"步骤。

知识入库的完整流程

以 Python 讲义为例：把原文档下载到本地，让 AI 读取路径，然后说"把这里面的内容入库"。所谓入库，就是让 AI 按照 LLM Wiki 的规则读取所有文档，进行编译，转存到知识库中。

入库完成后，Raw 目录保留完整的原始 Markdown，而 Wiki 目录下则生成了摘要、概念卡片、实体索引等结构化内容。当 AI 后续回答问题时，它会先查 index 索引和 overview 概览——比如你问与 Excel 处理相关的问题，它能直接定位到对应文章，而无需在几百个文档中盲目搜索。若索引信息仍不足，它再回到 Raw 数据源查阅原文。

这套检索策略在工程上是典型的**懒加载（Lazy Loading）**思想：先用轻量的 index 和 overview（通常仅数千 Token）定位目标，仅在必要时才召回原始文档。这与移动端图片按需加载、数据库查询先走索引再取全表的思路如出一辙——用少量的结构化元数据，大幅降低每次检索的资源消耗。

这样一来，检索既精准又快速。当然，这套方案也有代价：每条新知识入库时，都需要与已有的卡片、实体、概念建立链接，建链接的过程相对繁琐——但这恰恰是 AI 大显身手的地方。

总结与落地建议

LLM Wiki 的本质，是用结构化索引替代盲目全文检索，用 AI 自动维护替代人工打标记。它针对性地解决了简易知识库在规模膨胀后检索慢、易出错、耗 Token 的痛点。从更宏观的视角看，它代表了个人知识管理从"文件夹堆砌"向"语义图谱"演进的一个可落地路径，融合了 RAG、知识图谱、卡片盒笔记法等多个领域的精华，并以 AI 作为全自动的维护引擎。

对使用者而言，理解三层结构（Raw 数据源 / Wiki 知识层 / 配置层）非常重要——这样当 AI 输出时你心里有底，清楚它是如何入库、如何查询、如何做健康检查的。

建议动手实践一次：如果暂时没有合适的素材，直接用课程讲义入库即可。真正落地时，则应结合自己的业务场景构建专属知识库。记住一个核心认知——Wiki 不是给人看的，而是给 AI 看的，人只需在图谱和白板里浏览成果即可。

核心要点