做了近两年 AI 课题，终于产出了一篇阅读量突破10万+的爆款文章。标题是《我用 WorkBuddy + Obsidian 搭建了一个会自己生长的个人知识库》。 这个数据背后折射出一个明显的用户需求：大家对于 **Agent + Obsidian + LLM wiki** 这套组合来构建个人知识库的兴趣，确实比预期要高得多。 不过，上次那篇文章只介绍了搭建的基本流程。许多朋友在实际操作时才发现，要么不知从何入手，要么搭建完成后效果远远达不到预期。 所以今天这篇，重点聚焦在“如何搭建更高效”以及“过程中容易踩哪些坑”。

在正式动手之前，有必要先厘清一个核心问题：为什么偏偏是 Agent + Obsidian + LLM wiki 这套组合？它们各自扮演什么角色？ --- ### Obsidian 的优势 先说分工。Obsidian 是本地化的笔记软件，负责文件管理；LLM wiki 是构建知识库系统的框架；Agent 则负责整理知识。

那么问题来了：为什么必须用 Obsidian？**Notion、IMA、NotebookLM** 这些工具不行吗？ Obsidian 的第一个优势，是绝对的数据主权。它所有的笔记都以 Markdown 格式保存在本地，而不是存放在厂商服务器上。这意味着你无需担心数据泄漏，也不用担心平台哪天停止服务导致迁移困难。更重要的是，所有本地 Agent 都能方便地读写这些文件。 反观 Notion、IMA、NotebookLM 这些工具，它们紧紧依赖平台。一旦需要更换平台，格式兼容问题就足以让你头疼。 第二个优势在于它的知识组织方式。Obsidian 不鼓励用文件夹分类管理笔记，而是通过双向链接关联知识——用 `[[笔记标题]]` 这样简单的语法，就能在两篇笔记之间创建链接。基于这些链接，Obsidian 会自动生成一张关系图谱，展示所有笔记与概念之间的关联。它就像一张由思想编织的网络，模拟了人脑的联想方式。 更何况，Obsidian 的插件生态非常强大，可以像搭乐高一样，为它添加看板、表格数据库、日历、思维导图等各类功能。其中最著名的如 Data view 插件，能让你像操作数据库一样查询笔记，可玩性极高。换句话说，你能把它改造成任何你想要的样子。 综合这几点，在构建个人知识库这个场景下，Obsidian 确实拥有不可替代的优势。 不过话说回来，Obsidian 在这套组合里更多承担的是文件管理与可视化的职责。知识库最终的构建质量，并不取决于 Obsidian 本身，而是取决于 Agent 的能力与知识库系统的框架设计。**所以大家千万别神化它。**

至于 Agent 工具的选择，主要看你的使用门槛，选一款自己日常用得顺手的就好。WorkBuddy、QoderWork、Codex、Claude Code 都可以。因为 Agent 的职责是根据要求读取本地笔记，然后整理文件、编译知识、长期维护这套系统。每个 Agent 都能干这些事。 **这里真正重要的其实是模型——优质模型决定了优质编译。** --- ### LLM wiki 聊完分工，再来看看整个知识库系统的灵魂所在——**LLM wiki**。 思想层面之前聊过几轮，这里不再重复。感兴趣的话可以翻翻之前两篇文章： - 《向量检索、知识图谱与 LLM Wiki》 - 《AI 知识库技术演进拆解：从 RAG 到 NotebookLM，再到 LLM Wiki》 今天我们重点看这套理念如何落地。我找到一个 GitHub 上比较火的项目——claude-obsidian，也是目前很多人都在用的。它基于 Karpathy 提出的 LLM wiki 理念，把整个流程做了 Skill 化，还做了不少优化。 不过要提醒一句：别被名字误导。这个插件不只在 Claude Code 里才能用，在 WorkBuddy、Codex、Cursor 等 Agent 中同样适用。 下面我们一步步走通整个流程。 #### 安装 Claude-Obsidian 插件 这里以 Claude-Code 为例，前提是你已经能顺利使用 Claude-Code。 打开命令行，依次执行以下命令： ``` # 第一步: 添加插件市场 claude plugin marketplace add AgriciDaniel/claude-obsidian # 第二步：安装插件 claude plugin install claude-obsidian@agricidaniel-claude-obsidian ``` #### 初始化仓库 打开 Obsidian，点击【创建】，在指定文件夹下新建一个仓库。这里命名为 llm-wiki-claude，并用 Git 做版本管理，方便后续追溯修改记录。

然后，在对应路径下用 Claude-Code 打开，输入 `/claude-obsidian:wiki` 指令初始化项目。 这一步它会询问你创建知识库的主要用途是什么，并给出了六种模式供选择。**每一种模式对应的目录结构设计都完全不同。**

我们选择“项目研究”，最终生成的项目结构如下：

如果选其他模式，wiki 这一层的目录结构会有差异。因为它是由标准基础结构加上模式特有层组合而成的。下面是标准的基础结构：

从这个步骤能看出一个问题：我们以前搭建知识库时，一开始就没想清楚目的是什么，直接套了一套 Karpathy 提出的标准化结构。结果就是并不一定匹配具体场景。 **目录结构的设计本质上是对知识抽取模型的设计。不同场景的知识库结构，差别确实很大。** Claude Obsidian 这个项目内置了六种场景，每种模式具体的目录结构可以去看项目源码中 wiki 这个 Skill 下的 modes 文件，这里不展开。 --- ### 模版完善 仓库初始化完成之后，按理说可以直接进行知识摄入了。但别急，先看看生成的框架是否真的能用。

原始知识从 raw 文件中被 Agent 抽到 wiki 里，结构元素必须被约束，不能让 AI 随意发挥。`_templates` 文件夹中的模版文件就非常重要，它约定了写入 wiki 的知识结构长什么样，以及每个页面需要包含哪些元信息。 如果这个环节没有约束，大模型在编译知识时会自由发挥，出来的东西可能乱七八糟。

从上面文件结构可以看出，模版文件和 wiki 下的目录并不是一一对应的。gaps、meta、domains、thesis、comparison 这些就没有模版文件。最好的做法是补齐这些未定义的页面类型模版。 下面来看一个模版文件的基本构成，以 Question 为例： ``` --- type: question status: answered question: "" sources_consulted: [] confidence: medium tags: [question] created: {{date}} updated: {{date}} --- # Q: {{title}} ## Question *The original question as asked.* ## Answer *Synthesized answer based on wiki context.* ## Sources *Which wiki pages were consulted.* ## Confidence *How confident we are in this answer and why.* ## Follow-ups *Open threads from this question.* ``` 开头部分是页面的元信息。这套元信息的设计基于都伯林核心元数据标准（图书情报学的国际标准）做了扩展，主要用途是结构化描述页面基本信息，方便后续做查询过滤、知识状态标记、图谱构建等。 而正文部分是每个知识单元的关键构成。以 Question 模版为例，它包含用户问的原始问题、基于 wiki 生成的答案、生成答案时参考了哪些 wiki 页面、这个答案的置信度与理由、以及衍生问题。 把高质量的回答写回 wiki 时，就需要遵循这套模版要求。确保答案一定是基于 wiki 页面生成的，而不是靠大模型的预训练知识随口瞎编，还要做知识溯源和置信度评分。 **这里的关键是：每个类型的知识生成，必须有框架来约束，绝不能放任模型自由发挥。** --- ### 知识摄入 我们找一篇之前写过的公众号文章《向量检索、知识图谱与 LLM Wiki：RAG 被嘲笑了三年，但企业还是离不开它》作为知识源，放入 `.raw` 文件夹，然后进行知识编译。

知识摄入操作使用以下命令： > /claude-obsidian:wiki-ingest

基于单篇文章，最终新建了 16 个页面，抽离出 6 个核心概念、5 个实体对象，以及文章中的重要观点和下一步知识补足建议。

结合原文内容和编译结果来看，整体质量相当不错，实体、概念与观点都能一一对应。

但多次操作之后，会遇到一个实际问题：**如果重复执行摄入指令，如何避免知识源文件被重复编译生成？** 举个例子，第一次执行指令时我没指定文件路径，那下一次加入新的知识文件后，是不是必须指定新加文件的路径？ 不需要，直接输入前面的摄入指令就行。 **因为每次摄入时系统都会为文件生成内容 hash 值**，然后在 `.raw/.manifest.json` 文件中检查是否有相同的 hash。如果命中则跳过编译，未命中则正常处理。编译完成后，会把本次摄入的源文件 hash 值记录到 `.manifest.json` 中，下次再 ingest 时直接跳过。

**另外，实践一段时间后发现，少量知识摄入的质量普遍很高，这可能跟短上下文和内容足够聚焦有关。** **但单次摄入太多、或主题太分散时，抽离质量会出现明显下降，对应的概念、实体、结论会漏掉。** 知识源本身的质量同样关键。如果你把所有看到的文章都一股脑塞进去，模型基于错误的知识进行加工，生成的知识也必然是错误的——典型的 **垃圾进垃圾出**。 **所以，想保证知识库质量，除了控制单次摄入量，还得从源头把关，慎重选择知识源文件。** --- ### 知识查询

知识查询操作使用以下命令： > /claude-obsidian:wiki-quey rag 有哪些检索技术？ 检索结果如下：

红框里的核心判断，高度符合原文表达。 上一篇文章里我们提过，它的检索思路是先查 `wiki/index.md` 索引文件，再按需查找相关页面，类似于 Skill 的渐进式披露机制。这么设计的好处是提升检索效率，同时减少 Token 消耗。 Claude Obsidian 还做了一个优化：每次操作后，无论写入还是查询，都会把本次关键上下文写入 `hot.md` 文件，大约 500 词。注意，这里是直接覆盖。 **后续会话中，无论是新开会话还是跨项目使用，都会优先读取 hot.md 的缓存内容。相比直接读 index 加上 N 个页面，单次 query 能省下 70% 以上的 token。** 简单说，它通过本地文件把会话关键信息持久化保存，确保上下文在不同会话中能够衔接，无需重复解释。下一次 query 不必从零开始，大大节省了 Token 消耗。 --- ### 回答保存 如果某个回答质量很高，可以把对话内容归档到 wiki 中，使用以下命令： > /claude-obsidian:sa ve 结果如下：

这里就会用到前面的 Question 模版文件，把刚才对话的问题、答案和参考的 wiki 页面一起写入 `wiki/questions` 中。 看下面这个截图，我打开一个新的会话询问相同的问题：

从结果来看，当我再次问同样问题时，系统没有重新去 wiki 里找相关页面再组织答案，而是直接基于已有答案进行回答，内容与之前完全一致。 不过有个问题需要注意：**答案被沉淀到 wiki 后，如果对应的知识页面更新了，但当前答案可能仍然没有更新，下次检索时拿到的答案就是过时的。** 这里提供两种处理办法： 一是，在检索流程中增加交叉验证。不仅从 `wiki/questions` 查找，拿到结果后还要从相关的概念、实体等页面中验证答案是否正确。 二是从源头解决。在知识摄入时，如果已有 wiki 页面发生更新，同步更新引用该 wiki 页面的 question 页面的元信息，把 `stale` 字段设为 true。后续统一扫描过期的答案，集中治理。 --- ### 自动研究 前面说的知识摄入，处理流程是我们提供资料，Agent 帮我们整理。但实际情况是，我们提供的资料难免有缺口，导致知识缺口长期存在。 比如刚才只加入了一篇文章，关于 RAG 的知识体系还差很多内容。我想补充 Agentic RAG 这部分知识，但手里又没有高质量的知识源——这时候可以用 autoresearch 的能力自动补足缺口知识。 使用方式如下：

它的工作流程是：根据输入的主题，分解成 3-5 个搜索角度，跑 3 轮，大约 45 次 webSearch。 第一轮，围绕主题从不同角度分别找资料；第二轮，基于第一轮发现的空白和矛盾，做针对性搜索；第三轮，如果仍然存在关键缺口，就继续补充，否则进入整理阶段。 最后把结果沉淀到 wiki 中。 听起来不错，但实践下来你会发现效果并不稳定。我的经验是： **autoresearch 仅适合补足空白知识，而且主题范围越小，结果越好。因为它是联网搜索去抓取内容，主题定得太宽，可能抓回来一堆分散的资料。这里还要注意限定信息源，优先抓官方文档，尽量避开营销软文。** 在编写提示词的时候，必须花些功夫把研究主题聚焦、研究范围写明确、约束条件写清楚，就像上面示例那样。 --- ### 健康检查 整个知识摄入过程完全依赖大模型处理。刚开始笔记少的时候，靠人工二次确认问题不大，但随着知识库页面数量增长，问题会逐渐暴露出来：孤立页面、死链接、过期结论、缺失页面、交叉引用缺失、元信息缺失、索引漂移…… 这时候就需要定期执行： > /claude-obsidian:wiki-lint 这个 Skill 会帮你完成上述检查，并在 `wiki/meta` 下生成一份检测报告，告诉你当前知识库哪里有问题、哪些可以自动修复、哪些需要人工判断。 这一步非常重要，建议每摄入 15 次左右就做一次健康检查，让知识库 wiki 保持健康状态。 但问题来了：怎么让 wiki 记住摄入次数，并在到达对应次数时主动提醒你？否则很容易忘记。 处理办法是，在摄入工作流末尾加上一条规则：摄入完成后，读取 `log.md`——计算距离上次 lint 操作以来的 ingest 次数。如果大于等于 15 次，主动告知用户“建议进行健康检查”并等待确认；如果不到 15 次，则不提示。 LLM wiki 不是一次性工程，而是一个会长期生长的系统。只要持续摄入，就需要持续治理。 --- ### 本地检索 前面讲的查询流程，默认是先查 hot.md，再查 index.md，然后查相关页面。这种方式对于小型知识库来说很好用，但当 wiki 持续变大后，检索效率会明显下降，Token 消耗也会变得很大。 要解决这个性能瓶颈，Claude-Obsidian 集成了本地检索方案——`wiki-retrieve`。它的核心流程是： 1. 先把 wiki 页面拆分为小的 chunk； 2. 给每个 chunk 生成上下文前缀，确保脱离原文也能被理解； 3. 基于这些 chunk 构建 BM25 关键词索引； 4. 查询时先用 BM25 召回候选片段，**再用向量相似度做语义重排**； 5. Agent 读取命中的原始页面，然后生成最终答案。 注意，这里用的是 BM25 关键词检索，而非纯向量检索。向量只用于语义重排。之所以这样做，是因为本地知识库内容经常变化，纯向量构建成本太高。 这套检索方案是可选的，需要单独初始化才能使用，默认还是前面介绍的检索流程。当你的个人知识库出现性能瓶颈时，才建议激活使用。 --- ### 总结 以上就是用 Claude-Obsidian 搭建个人知识库的完整实践。整体流程其实很清晰，使用成本也不高。关键是一些细节需要注意，希望这篇能帮你更顺利地搭建属于自己的知识库系统。 最后再说一个大家问得比较多的问题：这套东西能不能用到企业场景？

LLM Wiki 这套架构的**核心优势**是自动知识提炼与结构化。从文章、笔记等原始资料中，Agent 能自动生成概念页、实体页、论点页，把隐性知识网络显性化、结构化。**这比人力一条条整理快多了。** 然而，成也萧何败也萧何。既然 LLM Wiki 吃了大模型整理文档的红利，就自然要承担它的缺陷。 第一，**知识质量高度依赖模型和源材料。** 源文件质量差或者模型能力不行，抽出来的信息就很容易出问题。虽然现在的模型多数时候稳定性不错，但也有降智的情况——**一颗耗子屎打烂一锅饭**的风险是真实存在的。 所以，想要质量高，就一定会有**管理成本**。就算用了 LLM Wiki，也别想着做甩手掌柜。检查死链接、孤立页面、缺失元数据……这些都是日常功课。 第二，**多人实时协作与权限控制能力薄弱。** 这套方案基于本地文件加 Git 的工作流，没有类似钉钉文档、飞书文档那样的实时共同编辑、细粒度页面级权限。如果团队使用，得依赖 Git 分支和拉取请求来协作，对非技术背景的成员门槛较高。 另外，数据量大了之后的情况我还没测试过，但直觉上单机文件系统可能也不太扛得住。 所以结论是： **LLM Wiki 更适合个人使用。** 企业要落地，难度不小。要考虑成本和效率，单单是 **Token 消耗、查询频次、文档后置的维护成本**就不太过得去。 如果你的目标是做一个对外的、多用户的、成本敏感的企业知识库，LLM Wiki 这条纯 Agent 驱动的技术路径需要大量工程改造，比如增加问答缓存、分层检索等。而改造之后的系统，可能已经偏离了 **LLM Wiki** 强调的零摩擦、自生长的初衷了。