所有文章 标签 分类

目录

目录

把 Obsidian 交给 Agent：我的 LLM Wiki 使用体验

MartinLwx  收录于  类别 工具
     约 5039 字   预计阅读 23 分钟 

今天是 6 月 4 日，距离 Andrej Karpathy 发布 LLM Wiki 这个想法差不多过去 2 个月，我也已经深度使用了 1 个多月，写下这篇文章的目的是与大家分享我的 LLM Wiki 设置以及一个多月以来我的使用感受

在 LLM Wiki 出现之前，这几年我已经深度使用 Obsidian 做了大量的笔记，总共有 1W+（数量很多是因为我遵循了笔记应该原子化的思想，我会为每一个逻辑上比较独立的概念单独创建一个笔记）。通过这些笔记我搭建了个人知识系统，享受知识复利给我带来的好处。但维护这一套笔记系统存在不少痛点：

  • 维护来源很痛苦：我在记录笔记的时候尽量用脚注（[^] 这种风格）会引用出处，这样确保我后续检阅笔记的时候可以快速知道某些事实陈述、逻辑判断、量化数据等是怎么来的。但这个过程绝对称不上愉快。虽然 Obsidian 已经很智能了——你插入脚注之后，你可以直接在一个悬浮窗口里填写脚注内容。但整个过程还是很枯燥的
  • 维护双向链接很不方便：Obsidian 的一大特色是，你可以用 [[obsidian wikilink]] 这种风格在笔记之间创建关联。这是一个很棒的主意，但是手动维护很不方便，你新增一个页面之后需要自己找到关联的笔记加上双链，这难免有遗漏。
  • 记录笔记过程比较枯燥和无聊：记录笔记这件事情本身比较枯燥和无聊，因为你得做各种排版，打上各种标记（数学公式用 $ ... $、加粗用 ** ... **、表格需要打繁琐的 Markdown 记号等）
Tip

当然，手动记录笔记的过程其实等于再复习一次，你被迫用自己的语言对信息进行总结，从而沉淀出知识，我不否认这点 :)

因为上面这些痛点，我的笔记系统其实是有点混乱的，他们有的缺少脚注，有的缺少必要的双向链接，都不是那么完美。我采取的解决办法是：手动维护一个文件夹，确保这个文件夹里的是符合标准的。每当我访问到一个不符合标准的笔记页面的时候，我会手动修改并逐渐将笔记移动到这个文件夹内。希望有朝一日我可以将所有的笔记都修改成理想的形态。下面的图是我旧的笔记系统的“知识图谱”。你每看到的一个簇都是我在关联笔记上做的努力 :(

我们不难看出：记录笔记是一件好事，因为它可以沉淀知识并让你日后进行检索和复用，但是维护一套完美的笔记系统需要花费大量的心力。有时候，维护笔记的代价可能会超过它的收益本身。LLM Wiki 的提出在一定程度上缓解了这一点，但它也带来了新的问题，后面我会解释

Note

本章节内容取自我的 LLM Wiki，这是 DeepSeek V4 Pro 根据本文的设置 Ingest 了 Andrej Karpathy 的 gist 之后生成的，我只是将其组织成了比较适合文章阅读的格式，用于展示效果。当然，图片是我手动画的 :)

LLM Wiki 是一种使用 LLM（大语言模型）增量构建和维护持久化 Wiki 知识库的模式。其核心理念是：当用户添加新的源文档时，LLM 并非仅索引文档以备后续检索，而是主动读取、提取关键信息，并将其集成到现有 Wiki 中——更新 entity 页面、修订 topic 摘要、标记新旧数据冲突、强化或挑战现有的 synthesis。知识被编译一次后持续维护，而非在每次查询时重新推导。Wiki 是一个持久化的、可复利的 artifact：交叉引用已就位，矛盾已标记，synthesis 已反映所有已读内容。

它的几个核心思想是

  • 持久化编译：知识被编译为结构化的 markdown 页面后持续维护，而非每次查询从原始文档重新检索推导。Wiki 是不断丰富、复利增长的 artifact。
  • 增量集成：每添加一个新的源文档，LLM 不仅创建其摘要，还更新所有相关 entity 和 concept 页面、修订交叉引用。单个源文档可能触及 10-15 个 Wiki 页面。
  • 交叉引用与一致性：Wiki 中的交叉引用由 LLM 自动维护。当新数据与旧结论矛盾时，LLM 会标记矛盾并更新 synthesis。人类无需手动维护一致性。
  • 人机分工：人类负责策展源文档、指导分析方向、提出好问题；LLM 负责所有"体力劳动"——摘要、交叉引用、归档、一致性维护。Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。

LLM Wiki 的架构由三个层次组成：

  • Raw Sources（原始源文件）：人类策展的源文档集合——文章、论文、图片、数据文件。LLM 从中读取但绝不允许修改，这是知识的不可变源。
  • Wiki（Wiki 目录）：LLM 生成的 markdown 文件集合——摘要页、entity 页、concept 页、对比页、概览页、synthesis 页。LLM 完全拥有这层：创建页面、在新源文档到达时更新页面、维护交叉引用、保持全站一致性。
  • Schema（模式约定）：一份文档（如 CLAUDE.md 或 AGENTS.md），定义 Wiki 的结构、命名规范和工作流。这是关键的配置文档——使 LLM 成为有纪律的 Wiki 维护者。

两个特殊文件帮助 LLM（和人类）随着 Wiki 增长进行导航：

  • INDEX.md：面向内容。Wiki 中所有页面的目录——每个页面包含链接、一行摘要、可选元数据（日期、源文档数）。按类别组织（entities、concepts、sources 等）。LLM 在每次 Ingest 后更新它。查询时 LLM 先读取 INDEX 找到相关页面再深入阅读。在中等规模下这种导航方式出奇有效。
  • LOG.md：面向时间。仅追加的操作记录——Ingest、Query、Lint 的日期和描述。如果每条记录以一致的前缀开头（如 ## [2026-04-02] ingest | Article Title），日志可被简单 unix 工具解析。日志提供 Wiki 演进的时间线和 LLM 了解近期操作的上下文。
Note

本章节内容同样取自我的 LLM Wiki，这是 DeepSeek V4 Pro 根据本文的设置 Ingest 了 Andrej Karpathy 的 gist 之后生成的，我只是将其组织成了比较适合文章阅读的格式，用于展示效果

LLM Wiki 里有 3 个重要的操作

Ingest（摄取）是将新源文档集成到 Wiki 的核心操作流程。典型流程是

  • 🧑‍💻/👩‍💻 - 用户将新源文档放入 Raw Sources 集合，通知 LLM 处理
  • 🤖 - LLM 读取源文档，与用户讨论关键要点，在 Wiki 中撰写摘要页面，更新 INDEX.md，更新所有相关的 entity 和 concept 页面，最后在 LOG.md 追加一条操作记录

一个源文档可能触及 10-15 个 Wiki 页面。用户可以逐个摄取（单次、高参与度），也可以批量摄取（多次、低监督），取决于个人工作流偏好。

Query（查询）是用户通过 Wiki 进行提问并获取答案的流程。典型流程是

  • 🧑‍💻/👩‍💻 - 用户针对 Wiki 进行提问
  • 🤖 LLM 首先搜索相关页面、读取内容、综合答案并附上引用。答案可以采取多种形式——markdown 页面、对比表、幻灯片（Marp）、图表（matplotlib）、canvas 等

关键洞察是：好的答案可以被回存为新的 Wiki 页面。用户提出的对比、分析、发现的连接——这些都是有价值的知识，不应消失在聊天历史中。这使得探索过程像源文档一样在知识库中复利积累。

Lint（检查）是定期对 Wiki 进行健康检查的操作。典型流程是

  • 🧑‍💻/👩‍💻 - 用户要求 LLM 检查问题项，比如页面间的矛盾、已被较新源文档取代的过时声明、没有入链的孤立页面、被提及但缺少独立页面的重要概念、缺失的交叉引用、可通过网络搜索填补的数据空白
  • 🤖 - 根据用户设定的规则对已有的页面进行检查，并提出修改建议和操作修改

Lint 保持 Wiki 系统的健康演化。

LLM Wiki 的技术方案在我看来很有吸引力，因为它完美解决了我手动维护 Wiki 系统的痛点，它让 Wiki 系统的维护变得简单了。从维护工作中解放出来的人类可以从事更多的脑力劳动

但我很快意识到这一套方案的一些问题

第一，LLM Wiki 可能无法很好 Scale？在原始的 gist 里，Andre Karpathy 提到几百个 Wiki 页面是没有问题的。那如果是几千个、几万个页面呢？在未来的某一天，你搭建的 LLM Wiki 的 INDEX.md 可能就无法完整放入到 Agent 的上下文窗口里面，此时 Agent 如何快速找到要找的 Wiki 页面，如何确定 Wiki 页面之间的关联？

第二，如何避免整个过程中的“幻觉传播”问题？Ingest 的过程是 LLM 帮你阅读源文档并生成笔记，但是 LLM 很可能会因为幻觉问题自己发挥创作。那么在后面 Query 的时候检索到的信息也可能是“幻觉”产生的，那么答案就不靠谱。这样搭建的 LLM Wiki 系统显然也站不住脚

我在互联网上发现也有人有这样的担忧。经过一番调研，我找到了一个比较有意思的工作——LLM Wiki Compiler。它提出了 Coverage Indicator 这个概念。简单来说，你的 Wiki 页面的每一个章节都会有一个 [coverage: {level} -- {N} sources] 标记，这个标记表示这个章节的可信程度，其中 level 分为 high/medium/low 3 个等级，不同的等级对应了不同的 N 的范围。N 的含义是这个章节引用的源文档的数量，所以 LLM Wiki Compiler 的 Wiki 页面看起来应该像这样1

## Summary [coverage: high -- 15 sources]
...trust this, it's well-sourced...

## Experiments & Results [coverage: medium -- 3 sources]
...decent overview, check raw files for details...

## Gotchas [coverage: low -- 1 source]
...read the raw gotchas.md directly...

显然，如果某一个章节有很多可以参考的源文档，那么这个章节大概率是比较可信的，那么就会被分类为 medium 设置是 high。当我们让 LLM 根据我们的 Wiki 系统回答问题的时候，它也发挥了作用。在提示词里面，我们会让 LLM 这么用 Coverage Indicator1

  • [coverage: high] – 这个章节的内容可以直接信任，不需要阅读源文档
  • [coverage: medium] – 这个章节的内容总结得不错，如果想了解细节问题可以参考源文档
  • [coverage: low] – 阅读这个章节引用的源文档

这个设计还是很巧妙的，它在可信的源文档和 Wiki 页面之间建立了追溯关系。不管是我们还是 LLM，根据这个标记都可以初步判断一个章节的内容是否靠谱。我也是看到这个工作之后才开始使用 LLM Wiki

Tip

一开始我用的是 OpenCode，还给 LLM Wiki 写了 3 个命令，并且后面针对 ingest、query、lint 都做了改进。但我最后还是决定用 Hermers 并把这 3 个命令变成了一个 SKILL，主要考虑的是

  • Hermers Agent 可以根据和用户聊天的情况对 SKILL 进行改进，自进化实在太有吸引力
  • Hermers Gateway 设置好之后，我甚至可以在手机上就让它帮我写 Wiki 页面
  • Hermers Agent 自带了 Obsidian 的使用方法的 SKILL，它知道如何写 Obsidian 的 markdown 文件

在 Andrej Karpathy 发布的 gist 下方，你可以看到无数人分享自己的 LLM Wiki 实现。在我看来，LLM Wiki 的核心还是挺简单的，专门搞一个独立的软件感觉没有必要。考虑到我已经在 Obsidian 里有大量的笔记了，并且日常使用 Hermes Agent 和 LLM 进行交互，Obsidian + Hermes 已经可以完成这一套 LLM Wiki 系统。下面是具体的实现方案

  1. (可选) Obsidian Web Clipper：将自动变成 Markdown 并存储到 Obsidian Vault 里。这里设置为可选是因为，你可以直接给 Hermes 丢链接，它可以很好处理
  2. (可选) Obsidian CLI：Obsidian 官方维护了一个 CLI 工具，可以和 Obsidian Vault 进行各种交互，在很多时候，它都比你直接用 Bash 命令更高效
  3. LLM Wiki SKILL：一份内容丰富的 SKILL，用于告诉 LLM 什么是 LLM Wiki，Ingest、Query、Lint 的时候都有哪些标准流程等
  4. SCHEMA.md：一份描述了你的 Wiki 系统如何组织（目录结构、文件命名惯例等），每个 Wiki 页面要遵循的结构等信息

可以看到，最核心的实现是 LLM Wiki SKILL。而这个最难写的文件其实已经包含在 Hermes Agent 自带的 SKILL 里面了，你可以在这里看到它是如何实现的。我建议你直接基于这个文件进行改造即可，毕竟默认的可能不是最适合你的。我基于官方的 LLM Wiki 进行了改造，主要改造内容是 Wiki 系统的组织方式（有什么文件夹，每个文件夹的含义是什么）、Coverage Indicator 的相关信息（定义以及如何使用）。你可以在这里看到我是如何编写这个文件的

另外一个要编写的文件是 SCHEMA.md，这里我不打算展开这个文件要如何编写，因为每个人对 Wiki 系统的理解都不大一样，对每个页面要求的也不大一样

这里我想提一下使用 Hermes Agent 好处：它的 SKILL 会随着你的使用越来越好用，它的记忆系统会让它记住你的偏好。简而言之，你感觉它能理解你。就在前两天，我跟 Hermes Agent 抱怨它的 Coverage Indicator 经常没写对——high/medium/low 和 N 的关系对不上。Hermes 意识到了这个错误模式，并改进了我自己写的 SKILL。修改内容是每次修改 Wiki Page 之后都要做硬性的检查，确保没有问题。并且它在自己的记忆系统里面加上了这么一段（我手动换成了多行）

Health check is now Step 5 of the my-llm-wiki Ingest workflow (references/audit.py).
Run BEFORE updating INDEX/LOG. Recurring mistakes: (1) coverage N counts footnote
references instead of unique source docs → [^1],[^2],[^3] all pointing to
same doc = N=1; (2) footnote-free sections wrongly tagged N>0; 
(3) source_cnt ≠ actual unique sources. 
Also: wikilink inline at point of mention, not just footer.

经过一个月的深度使用之后，我的笔记系统工作流已经发生了很大的变化

  • 以前：我一边看文章一边记录要点，呈现 看文章 -> 记笔记 -> 看文章 -> ... 这样的交互循环。有时候我在手机上看文章，但手机的输入效率实在太低，我只能先收藏一下文档等回家用电脑再看。
  • 现在：不管我在使用什么设备，我都可以专注于理解文章本身。通常在我看完文章之后，我会让 Hermes 帮我把它加入到我的 LLM Wiki 里。我会检查它输出的内容是否在格式上符合要求，在内容上是否提到了我想要记录的点。如果不满足我会让它进行修改

Coverage Indicator 的设计在一定程度上缓解了 LLM 的幻觉问题，但如何 Scale 的问题仍然没有解决。当 Wiki 页面达到一定数量级之后：Agent 就很难检索到相关的页面；Wiki 的维护成本也会越来越大；不同页面的知识的一致性不好保证。虽然存在种种可能的问题，但就目前我个人使用上而言，我认为 LLM Wiki 还是带来了一些正向的变化，并且我相信社区会给这些问题提出优秀的解决方案，不管是从算法上还是从工程上，又或者是 LLM 已经进化到 Next Level 了😈️

  1. Coverage Indicator - LLM Wiki Compiler ↩︎ ↩︎

更新于 2026-06-03
 知识工程
 | 主页