用 WorkBuddy / Codex + Obsidian 搭建自生长的个人知识库实战

这是苍何的第 576 篇原创！

大家好，我是苍何。

和朋友半开玩笑的说，如果没有 AI，我最想做的是知识管理博主。

但老实说，卢曼卡片盒、PARA 分类法、双链笔记，这些方法论，分享起来也没那么有意思。

而且，最痛苦的你会发现，一套操作下来：知识整理比学习还累。

于是，很长一段时间，我都在研究如何用 AI 更好的做知识管理。

最近，基于 Karpathy 公开的 LLM wiki 知识库构建方法和架构，我做了一些实践。

用 WorkBuddy / Codex + LLM wiki + Obsidian 构建了一套能够自生长的个人知识库。

它能够将剪藏的文章、AI 对话、随手记的灵感，通过 WorkBuddy / Codex 把知识持续沉淀成可进化的知识大脑。

这篇文章主要分以下几大部分，为大家拆解这套系统的核心搭建思路，以及实操步骤。

内容会有些长，可以点赞收藏后丢给你的 Agent 放进你自己的个人知识库系统。

要理解 LLM wiki，得先搞清楚它到底要解决什么问题。

现在主流的玩法，不管是 RAG 系统，还是 NotebookLM、GPT 的文件上传，本质都是同一套流程：你先上传资料，提问时模型召回相关知识片段，再临时综合出一个答案。

听着挺智能，但问题很明显。

每次提问，模型都在从碎片里重新拼答案，答完就散。同样的问题问一百遍，它就重新拼一百遍，知识本身没有任何积累。

Karpathy 提出的 LLM wiki，可以理解成给 AI 安排了一份长期工作：持续维护知识库。

每加入一份资料，Agent 都会先查看现有页面。已有内容会被补充，新概念会单独建页；遇到不同观点，则把来源、时间和适用范围一起留下。知识的分歧因此有迹可循，也不会被一段看似完整的总结悄悄抹掉。

我觉得，“自生长”的关键就在这里：AI 处理完资料后，知识库必须留下变化。它可能新增一个概念、补上一条关联，也可能暴露一个暂时没有答案的问题。一次次变化累积起来，才会形成真正属于自己的知识体系。

为了让这个过程可控，整套系统分成三层：Raw 层保存文章、论文、聊天记录等原始资料；Wiki 层沉淀 AI 整理出的概念、实体和主题；Schema 层规定 AI 如何归档、更新、引用，以及怎么处理冲突。

简单说，Raw 保存证据，Wiki 记录理解，Schema 负责定规则。后面的实战，就是让这三层真正运转起来。

为什么是 Obsidian？

这套系统用到了 Obsidian，那为什么不直接用 Notion、Ima、NotebookLM 呢？

首先 Obsidian 是完全本地化和数据自主的。一个 Vault 就是电脑上的普通文件夹，笔记以 Markdown 纯文本保存，不依赖某个平台的页面数据库。

聊天记录、会议纪要等私人资料可以留在自己的设备上，是否同步、同步到哪里，都由自己决定。说得直白一点，工具可以换，知识不用跟着搬家。

这种文件形态也很适合 Agent 工作。WorkBuddy / Codex 可以直接读取目录、创建页面、修改链接和维护索引，每次变化都能定位到具体文件，还可以通过 Git 留下记录。

Obsidian 的双链、反向链接和知识图谱，则把概念、人物、工具和主题连接起来，帮助我发现核心节点、孤立页面和新的关联。

而且 Obsidian 的插件生态进一步提供了扩展空间，从模板、查询、版本管理到发布和可视化，都可以按需添加。

在整套系统中，Obsidian 同时承担存储底座、人机操作界面和知识观察窗口三种角色；

WorkBuddy / Codex 负责执行，Obsidian 负责保存、连接和呈现结果。对于一套需要长期使用的个人知识库，本地自主、结构开放、变更可追踪和能力可扩展，已经足够构成选择它的理由。

WorkBuddy / Codex 能做什么？

在这套系统里，WorkBuddy / Codex 承担的是 Agent 执行层。它们可以直接读取 Obsidian Vault 里的目录和 Markdown 文件，调用搜索、脚本和命令完成批量处理，并按照AGENTS.md中约定的规则工作。

简单说，Obsidian 提供工作空间，LLM Wiki 提供知识结构，WorkBuddy / Codex 负责让这套结构真正运转起来。

当新资料进入 Raw 层后，Agent 会先理解内容，识别其中的概念、实体和主题，再与现有 Wiki 进行对照。已有知识会被补充，新内容会创建页面，相关知识会建立链接；遇到不同说法时，它还要保留来源、时间和适用范围，并同步更新索引与变更记录。整个过程都属于增量维护，不需要反复重建整套知识库。

到了查询和日常维护阶段，Agent 还会负责检索相关页面、整理答案、追溯来源，并批量检查失效链接、缺失字段和长期没有更新的内容。

它在系统中承担执行与编排，人负责设定规则、检查结果和处理关键判断。这样一来，知识管理从大量手工整理，逐渐变成一套人机协作的持续维护流程。

实战

接下来，进入实战环节，这里的 Agent 选择你可以用 Codex、Claude Code，也可以用 WorkBuddy，模型的话建议选择上下文长一些的模型。

在模型这里，如果追求极致的性价比，目前来说 DeepSeek V4 Flash 是个不错的选择，但可惜的是不支持多模态。

我非常不建议你用 Codex 里的 GPT 5.6 Sol，因为用量真的太猛了。

当然，如果使用国内模型，也可以选择 Kimi K3 这类原生多模态模型，或 Doubao-Seed-Evolving 这类面向 Agent 与长程任务优化而且是动态永续进化的模型。

到了长链路、多轮任务里，模型需要持续读取文档和图片、调用工具、维护上下文，并根据中间结果不断调整后续动作，因此上下文容量、工具调用稳定性、指令遵循和结构化输出能力，都会直接影响整套流程能否稳定运行。

实际选型时，建议用自己的真实资料跑一遍完整任务，重点观察上下文是否丢失、工具调用是否稳定、输出格式是否漂移，以及单次任务的时间和成本。

准备工作

要搭建这样一套知识系统，需要提前准备一下工具及环境。

首先是 Obsidian，在 obsidian. md 免费下载后，新建一个 Vault（仓库）：

全程记得开代理，特别是访问插件市场的时候。

这里先抛一个彩蛋，下载完 Obsidian 后，你到插件市场再下载一下 WeSight 插件，也可以更丝滑的搭建这套知识大脑。

如果你感兴趣，可以在文章后面看更为简单和丝滑的搭建方法。

有了 Obsidian 后，你还需要准备 WorkBuddy 或者 Codex。这里就不细讲如何下载和使用了，也可以直接去我们开源的蓝皮书上看教程。

WorkBuddy：workbuddy.homes Codex：codexguide.ai

当然了，当前文章也会同时同步到蓝皮书上。

LLM Wiki 三层架构

LLM wiki 理论整体的三层架构，你可以按照自身需求再自定义，也可以复用我的这个模板：

●●●
 my-wiki/├── AGENTS. md          ← Schema 规范层：给 AI 的工作说明书（核心）├── index. md           ← 全局索引/站点地图（AI 定位知识的入口，导航目录）├── log. md             ← 变更日志（只追加，谁改了什么一目了然）│├── raw/                   ← 原始资料层（只读，AI 不许改）│   ├── articles/          ← 剪藏的文章、网页│   ├── papers/            ← 论文、报告│   ├── books/             ← 书籍、划线、笔记│   ├── chats/             ← 有价值的 AI 对话记录（File Back 回填的）│   └── notes/             ← 自己随手记的灵感碎片│   └── meetings/          ← 会议纪要转写│└── wiki/                  ← Wiki 层（AI 全权维护）    ├── sources/           ← 来源摘要页：一份 raw 资料对应一页    ├── concepts/          ← 概念页：解释方法论、理论、模式    ├── entities/          ← 实体页：人物、公司、产品、工具    └── topics/            ← 主题综述页：某个领域的综合对比分析

如何搭建

搭建这套系统，我亲身实践下来一共有三种方法，我认为是比较友好的，对大多数人来说也相对简单。

下面就以上手难易程度分别介绍，最简单的方式我放到最后一个方法中做说明。

方法一：直接搭建法

第一种是根据三层架构模板，直接让 WorkBuddy 或 Codex 来搭建。

可以在 WorkBuddy 中打开刚刚新建的 Obsidian Vault，进入这个目录：

选择「日常办公」，然后输入以下提示词：

●●●你现在是这套个人知识库的搭建与维护 Agent。请在当前 Obsidian Vault 根目录中，搭建一套可长期增量维护的 LLM Wiki。
## 目标
建立 Raw、Wiki、Schema 三层结构：
- Raw 层保存原始资料，只允许读取，不修改原文。- Wiki 层保存 AI 整理后的结构化知识，由 Agent 增量维护。- Schema 层通过根目录下的 `AGENTS.md` 定义归档、更新、引用和冲突处理规则。
## 需要创建的结构
- `AGENTS.md`：Agent 的长期工作规范- `index.md`：全局索引和知识导航入口- `log.md`：变更日志，只追加新记录- `raw/articles/`：文章和网页剪藏- `raw/papers/`：论文和报告- `raw/books/`：书籍、划线和读书笔记- `raw/chats/`：有价值的 AI 对话- `raw/notes/`：灵感与随手记录- `raw/meetings/`：会议纪要与转写- `wiki/sources/`：原始资料对应的来源摘要页- `wiki/concepts/`：概念、理论和方法页- `wiki/entities/`：人物、公司、产品和工具页- `wiki/topics/`：跨来源的主题综述页
## AGENTS.md 必须包含的规则
1. 处理新资料前，先搜索 `wiki/` 中已有的相关页面，判断需要补充旧页面还是创建新页面。2. `raw/` 是事实来源，禁止改写、删除或移动其中的文件。3. 每份 Raw 资料在 `wiki/sources/` 中建立对应的来源摘要页，并保留原始文件链接。4. 概念、实体和主题使用独立页面，通过 Obsidian 双链建立关系，避免把所有信息堆在一篇笔记中。5. 所有事实性内容都要标注来源；无法确认的内容明确写为“待核实”。6. 新旧资料出现分歧时，同时保留不同说法及其来源、时间和适用范围，不直接覆盖旧结论。7. 每次只更新受影响的页面，并同步维护相关双链、`index.md` 和 `log.md`。8. `log.md` 采用只追加方式，记录日期、资料来源、新建页面、更新页面和待人工确认事项。9. 不擅自删除现有文件；同名文件已经存在时，先读取并合并必要规则，保留原内容。10. 信息不足或判断可能影响整体结构时，暂停执行并向我提问。
## 页面模板
请分别在 `wiki/sources/`、`wiki/concepts/`、`wiki/entities/` 和 `wiki/topics/` 中创建 `_template.md`。模板使用 Obsidian 兼容的 YAML 属性，至少包含：`title`、`type`、`aliases`、`tags`、`sources`、`created`、`updated`。正文预留摘要、核心内容、相关页面、来源与待核实问题等区域。
## 执行与验收
执行前先检查当前目录，确认这里是 Obsidian Vault；如果无法确认，请先询问我。随后创建缺失的目录和文件，不覆盖已有内容。
完成后请进行一次自检，并向我汇报：
- 新建了哪些目录和文件- 哪些文件因已存在而被保留或合并- `AGENTS.md` 中最重要的维护规则- 当前结构是否通过检查- 下一步应该把第一份测试资料放到哪个目录

可以看到 Agent 就会按照规则创建目标文件和目录，以及定义 AGENT. md

Agent 会自动按照要求建好相关结构。

这个时候，你打开 Obsidian 就能看到对应的结构已经建好了：

然后收藏一篇文章来做下验证，这里就借助一个叫 Obsidian Web Clipper 的浏览器插件，可以把网页文章一键剪藏到 Obsidian 中。

这里在实际目录选择的时候选择我们刚建好的 raw/articles目录

然后你就能看到在 Obsidian 中对应目录下已经把这个文章同步过来了，非常的方便：

然后接着在 WorkBuddy 或 Codex 中建 wiki，可以参考以下提示词：

●●●请读取 `raw/articles/` 中新增的文章，并严格按照 `AGENTS.md` 的规则增量维护 Wiki。
处理前先检索现有页面：为文章创建来源摘要，提取其中的概念、实体和主题；已有内容补充到原页面，新内容创建页面，不同观点保留来源、时间和适用范围。随后建立相关双链，并更新 `index.md` 与 `log.md`。
不要修改 `raw/` 中的原始文件。完成后告诉我新建、更新了哪些页面，以及有哪些内容需要人工确认。

agent 会按照在 AGENTS. md 来建实体、概念、来源摘要、主题等 wiki。这里可以看到 WorkBuddy 已经帮我们新建了 9 个页面。

去 Obsidian 中也能看到新建的 wiki 页面信息：

这些 Wiki 页面当然可以直接阅读，但它更重要的价值，是成为 Agent 的长期检索层和推理底座。经过结构化整理后，原本分散在文章里的概念、实体、主题和来源关系，都变成了可以直接定位、交叉引用和持续更新的知识节点。

当我们再次提问时，Agent 可以优先检索已经沉淀的 Wiki 页面，再沿着双链回到相关资料，快速组织出有依据、可追溯的回答。随着处理的资料越来越多，这层可复用的中间知识会持续积累，后续查询和维护也会越来越高效。

比如我在 WorkBuddy 中提问：

请基于刚刚入库的文章和现有 Wiki，回答三个问题：文章提出了哪些核心观点？涉及的概念、实体和主题之间有什么关系？哪些结论可以转化为可执行的行动建议？ 回答时请标注引用的 Wiki 页面和 Raw 原文路径；如果资料中存在不同观点、信息缺口或待核实内容，也请单独列出。

可以看到，Agent 会先从 Wiki 中定位相关知识节点，再沿着页面之间的双链关系完成交叉检索与综合，并将关键结论追溯到对应的 Raw 原文；整个回答过程因此具备更高的检索效率、上下文一致性和事实可核验性。

以上方法一，比较粗暴，对提示词及工程化理解要很到位，而且 AGENTS. md 要不断调整以适应自身知识库搭建需求。

方式二：claude-obsidian 插件

下面介绍下方法二，有大佬已经基于 LLM wiki 这套理论实践出了工程化落地较好的开源项目，叫 claude-obsidian。

它把常用的方法封装成了插件及 Agent Skill，比如可以初始化知识库，将笔记保存到 wiki，自动索引和链接等。

你不需要再通过提示词及自定义指令来实现 LLM wiki 的能力，你只需要借助该项目，就能搭建一套属于你的个人自生长知识库。

这种方式相对上一种更为简单，你只需要在 WorkBuddy / Codex 中安装该项目：

当前 Vault 就会自动创建好结构，只需要简单：ngest 一下，就能把新素材同步 wiki：

用 retrieve 来从知识库中快速查询结果：

你甚至不用显式指定 retrieve，Agent 会命中知识库中的 wiki 来快速检索：

方式二比方式一更进一步：项目将初始化、入库、索引和检索封装成可复用的 Agent Skill，省去了反复编写提示词和维护复杂规则的工作。

不过，主要操作仍然发生在 WorkBuddy / Codex 中，用户需要理解并调用ingest、retrieve等指令；Obsidian 更多承担文件存储和结果浏览，任务状态、执行过程与知识变化缺少直观的可视化反馈。对第一次接触这套架构的用户来说，使用门槛依然存在。

要让这套知识库真正融入 Obsidian，操作入口也需要进入 Vault。于是就有了第三种方式：

方式三：WeSight 知识大脑

WeSight 插件把知识库初始化、资料入库、Wiki 更新和智能检索整合到 Obsidian 内部，让用户在熟悉的笔记界面中完成整个流程，同时由后台 Agent 负责结构维护与持续更新。

这样一来，人看到的是清晰可视的操作和结果，Agent 处理的是复杂的知识编排，两者最终形成一套完整的人机协作闭环。

你现在仅需要开启「知识大脑」能力，WeSight 会自动为你当前 Vault 配置好环境及结构。

可以一键将当前笔记加入到知识大脑对应的 wiki：

Chat 时选择「基于知识库」模式，WeSight 会优先检索 Vault 中已经沉淀的 Wiki 页面，并沿着双链定位相关概念、实体和原始来源，再基于这些上下文组织回答。整个检索、引用与上下文装配过程都会自动完成，无需手动指定目录或调用命令。

而且还可以将与 Claude Code、Codex 的聊天记录一键保存到知识大脑，方便后续检索、关联和复用，让有价值的对话继续沉淀为长期知识资产。

不过当前 WeSight 知识大脑功能仅对会员少量开放内测，欢迎大家体验。

这套组合的“自生长”，来自知识结构的持续增量更新。每当新资料进入 Raw 层，Agent 都会按照 Schema 检索现有 Wiki，补充已有页面、创建新节点、建立双链，并记录来源与观点冲突。每次处理都会留下可复用的结构化结果，知识库也会随着输入不断演化。

Obsidian 提供稳定的本地载体和可视化界面，WorkBuddy / Codex 提供理解、判断与编排能力，WeSight 则把入库、更新和查询进一步整合进日常笔记流程。人负责输入高价值资料和完成关键判断，Agent 承担重复维护，数据、规则与执行由此形成闭环。

对于资料的搜集，如果是手机上可以配合 ima 或者其他剪藏工具来进行搜集，甚至直接可以借助 WorkBuddy 小程序快速搜集文章及灵感：

对于电脑文章搜集可直接使用 Obsidian Web Clipper 的浏览器插件一键剪藏。

其他散落在各处的比如飞书文档啊，也可以借助 Agent 快速的收藏近知识库中来。

回过头看，这套系统带来的最大变化，是让知识管理从一次性的手工整理，变成一套可以持续运行的维护机制。文章、笔记、对话和灵感进入 Raw 后，Agent 按照规则完成归档、关联和更新，Obsidian 负责长期保存与呈现，零散资料也就逐步长成了属于自己的知识网络。

当然，自生长并不意味着完全自动化。哪些资料值得保留、规则如何设定、关键结论能否成立，仍然需要人的判断；AI 更适合承担重复、耗时且结构化的维护工作。人和 Agent 各自处理擅长的部分，知识管理才有机会长期坚持下去。

如果你也想试试，不需要一开始就搭出一套完美系统。先建好三层目录，放入一篇真实资料，让 Agent 完成第一次增量更新，再根据实际使用不断调整 Schema。只要每次输入都能留下可复用的结果，你的知识库就已经开始生长了。