Obsidian:LLM Wiki 的理想载体

从概念到落地的那个问题

上一篇《Karpathy 的 LLM Wiki:把知识组装提前到提问之前》聊过这条思路:与其在提问时现场检索拼接,不如让 Agent 提前把知识整理成互相链接的 Markdown 条目。概念很漂亮,落地时却绕不开一个非常具体的问题:这些条目放在哪?用什么软件承载?

要求其实相当苛刻:它得是人能舒适阅读、编辑的笔记软件,又得是 Agent 能直接读写的开放格式;它要有双向链接把条目织成网络,又不能把数据锁进私有数据库或云端块结构。把市面上的工具筛一遍,会发现一个老朋友恰好全部满足——Obsidian。

Obsidian 是什么

Obsidian 是一款本地优先的笔记软件,2020 年亮相,创始人是 Shida Li 与 Erica Xu 夫妇。它的第一原则一句话就能说完:你的笔记就是你磁盘上的 Markdown 文件。软件本身个人使用免费,靠官方同步、发布等增值服务维持运转。

展开一点画像:

本地优先:所有数据存在本地一个文件夹里,断网可用,就算软件哪天消失,文件还在;
纯 Markdown:每个笔记是一个 .md 文件,链接、嵌入、标注尽量都用纯文本语法表达;
双向链接:条目之间用 [[页面名]] 互链,反链面板自动聚合"谁引用了我";
插件生态:数千款社区插件,从任务管理到 AI 辅助,几乎每个需求都有人做过;
全平台:Windows、macOS、Linux、iOS、Android,配官方端到端加密同步,或者用 iCloud、Syncthing、git 自建。

核心机制:文件夹、双链与图谱

vault 就是一个普通文件夹

Obsidian 里没有"云端工作区"的概念,你打开的是一个本地文件夹,术语叫 vault(库)。每篇笔记是独立文件,图片、PDF 等附件原样存放,软件自身配置集中在 .obsidian 子文件夹。备份、迁移、批量处理、版本控制,全部可以用你已有的文件工具完成——这一点后面会反复回响,因为它正是 Agent 能无缝介入的原因。

双向链接与悬空链接

链接的写法只是一对方括号,在正文任何位置随手可打:

Transformer 的自注意力机制与 [[RAG]] 的重排阶段都依赖它。

被链接的页面会自动出现反向链接面板,列出所有引用它的条目。更关键的设定是悬空链接:链接指向一个不存在的笔记时不算错误,而是以浅色显示,点击即创建。换句话说,链接可以先于页面存在——这个机制对 LLM wiki 意义重大,下文细说。

图谱与 MOC

图谱视图把全部链接关系画成一张网络,哪些笔记是孤岛、哪些是枢纽,一眼可见。实践者常用 MOC(Map of Content,内容地图)主动组织这张网:建一类充当目录枢纽的索引页,把相关条目聚拢,而不是被动等链接自己长出来。这套方法与 wiki 的条目组织方式几乎同构。

插件生态:克制的核心,长出来的能力

核心版功能刻意保持克制,能力靠插件长出来。值得知道几类:

Dataview:把库当数据库查询,按条件自动生成索引表格;
Templater:模板引擎,批量规范条目结构;
Canvas:官方白板,自由排布笔记卡片做头脑风暴;
Bases:较新版本内置的数据库视图,给笔记加上表格化的筛选与聚合;
AI 类插件:Smart Connections、Copilot 等,后面单独展开。

数千款插件的另一面是折腾成本。我的建议是从零插件起步,遇到真实的痛再装。

为什么它恰好是 LLM wiki 的载体

回到主线。把 Karpathy 式 LLM wiki 对载体的要求逐条列出来,会发现 Obsidian 全部对得上。

文件系统就是 API

Agent 读写 Obsidian 库不需要任何专门接口——就是读写文件夹里的文本文件。任何能碰文件系统的 Agent(命令行编码助手、自动化脚本、MCP 文件服务器)天然就会操作它:没有鉴权流程、没有限流、没有导出格式,列目录、读文件、写文件就是全部 API。对比那些"必须申请 API Key 才能写入"的云端笔记,这是两种世界。

双链是人与 Agent 的共同语言

[[条目名]] 简单到 Agent 生成它零成本,而人阅读时这些链接是可点击跳转的一等公民。更妙的是悬空链接与 wiki 的生长方式天然契合:让 Agent 调研一个主题时,可以先铺一张"已写 / 待写"的链接网络——有把握的条目直接写满,没把握的留下悬空链接作为待办。知识网络的骨架先于血肉存在,这正是维基百科二十多年来的生长路径,只不过现在铺链接的可以不是人。

反链面板就是免费的反向索引

打开任何条目,引用它的全部条目自动列在侧栏。给模型喂上下文时,"当前条目 + 反链邻居"就是一段天然相关的上下文,不需要向量库参与。链接即检索,这是 LLM wiki 区别于 RAG 的核心主张,而 Obsidian 把这个主张变成了界面上的默认事实。

知识信任的落地:人可以校对

LLM wiki 最大的软肋是信任——Agent 组装的知识错了怎么办?纯文本 Markdown 给出的答案朴素有效:每条条目都是人可以打开、划线、批注、改写的普通文件。校对 Agent 的产出不需要任何专门界面,读笔记本身就是校对。阅读视图、高亮、评论类插件让这件事成为日常阅读的副产品,而不是额外的审核工单。

一文件一条目,切片问题天然缓解

之前在《深入理解 RAG:从检索准确率到持续优化》里提过,切片是检索质量的重灾区。Obsidian 的组织习惯天然鼓励"一个主题一个文件":切片边界由人在整理笔记时定义,而不是在管线里按 token 数硬切。Agent 生成条目时遵循同样粒度,后续无论走链接跳转还是走 RAG,边界都是干净的。

纯文本可 diff,演进可追溯

把库放进 git,Agent 每次写入都有提交记录:哪次改动引入了错误、什么时候删掉了什么,一目了然且可回滚。对"让 Agent 长期维护知识库"这件事,这是安全网,也是追责机制。

实操:把 Agent 接到库上

方式一:直接写文件

最简单的接入不需要任何插件。给 Agent 一份库的结构约定(可以做成一个 skill),例如:

vault/
├── 00-inbox/        # Agent 新条目先进这里,人工审阅后归档
├── 10-wiki/         # 正文条目,一个主题一个文件
│   ├── transformer.md
│   └── rag.md
├── 90-templates/    # 条目模板
└── 99-archive/      # 过时条目不删,归档

配一个条目模板:

## 一句话定义

## 正文

## 相关条目

- [[相关概念]]

## 来源

- 原始链接或文献

再约定几条纪律:新条目先进 inbox 等人审;写入前先读相邻条目,避免同一概念建出两个页面;每个新条目至少链回一个已有条目,防止孤岛。到这里,一个最小可用的"Agent 写、人审"循环就跑起来了。

方式二:MCP 服务器

社区已有多个把 Obsidian 接入 MCP 的服务器实现,装好后 Agent 获得搜索、读取、创建、移动笔记的标准工具集,部分实现还支持通过 Obsidian URI 直接拉起客户端定位到具体笔记。相比裸文件读写,MCP 方式多了现成的语义搜索工具,适合不想自己写检索逻辑的场景。

方式三:库内 AI 插件

Smart Connections:本地计算 embedding,侧栏实时显示与当前笔记最相关的条目,相当于给双链网络再补一层相似度边;
Copilot for Obsidian:把整个库当私有知识库,在库内直接对话问答,模型自选。

这三层方式各管一段:库内插件解决"人在库里提问",直接写文件与 MCP 解决"Agent 往库里沉淀知识",两件事正好互补。

和其他载体比一比

载体	Agent 可写性	人的编辑体验	双链	数据归属
Obsidian	文件系统直写	强	原生	本地纯文本
Notion	API,限流且为块结构	强	数据库关联	云端
Confluence	REST API	一般	有	云端
Logseq	文件直写,大纲格式	中	原生	本地
裸 git 仓库	最强	弱,无界面	无	本地纯文本

Notion 的问题在块结构:Agent 生成的 Markdown 还得转块,API 有限流,离线不存在;Logseq 与 Obsidian 同属本地纯文本,但大纲式的组织对长条目百科体不如标准 Markdown 顺手;裸仓库对 Agent 最友好,人读起来却痛苦。Obsidian 恰好站在中间的甜点上:对 Agent 它是文件夹,对人是软件。

上手建议

官网 obsidian.md 下载安装,建一个空 vault,先不开任何同步,用满一周再决定;
双链随手打,悬空链接别急着清空——它们就是你的待写清单;
第一个值得装的插件是 Dataview,但先让库长出内容,再谈整理;
想接 Agent,从"直接写文件 + 一个条目模板"起步,跑顺了再上 MCP;
库先进 git,再放 Agent 长期写入——trust, but verify。

结语

LLM wiki 的本质,是把知识的组装提前到提问之前;Obsidian 的本质,是一个对人和程序同样友好的文件夹。两者拼在一起,Agent 负责铺条目、织链接,人负责读、改、信,知识在人机之间用同一种纯文本语言流转。上一篇文末留下的"知识放哪"这个问题,这就是我目前最顺手的答案。