Karpathy 的 LLM Wiki 模式：让 AI 自动维护你的知识库
Andrej Karpathy 在离开 OpenAI 后，一直在探索一个问题：如何让 AI 不只是回答问题，而是主动构建和维护知识？
他提出的 "LLM Wiki" 模式最近被人集成到了 Obsidian 的 Agent 工作流中（vault-operator，28分 HN），让这个概念从理论走向了实践。
什么是 LLM Wiki 模式
传统 Wiki 是人类手动维护的知识库——你写词条、加链接、更新内容。问题是：没人真的会持续维护它。
Karpathy 的核心想法：让 LLM 承担 Wiki 维护者的角色。
核心属性
| 特性 | 说明 |
|---|---|
| 追加式摄入 | 原始材料（论文、推文、代码、对话）持续流入 |
| 综合式输出 | LLM 将原始信息蒸馏为结构化摘要 |
| 自动关联 | Agent 检测概念间的关系，自动创建超链接/反向链接 |
| 新鲜度优先 | 词条有"最后验证"时间戳，过期条目被标记重新调研 |
| 多分辨率 | 同一主题有一行摘要、一段概述、深入长文三个层次，由Agent保持一致 |
| 查询即接口 | 你不浏览Wiki，而是问问题，Agent从已维护的知识中综合答案 |
与传统方案的区别
传统 Wiki：人写 → 人读 → 人更新（99% 会过时）
RAG：人写 → 向量化 → 检索（只是搜索，不综合）
LLM Wiki：信息流入 → Agent 综合 → Agent 更新 → 你查询
关键差异：LLM Wiki 中，Agent 是主动维护者，不是被动检索器。
vault-operator：Obsidian 中的实现
vault-operator（github.com/pssah4/vault-operator）将这个模式落地到了 Obsidian。
设计灵感：Kubernetes Operator 模式
- Vault = Obsidian Vault（一个 Markdown 文件文件夹）
- Operator = 控制循环：监视期望状态 vs 实际状态，自动调和
它做什么
- 监视变更：新笔记、修改的笔记、收件箱里的新材料
- 调和：运行 LLM 驱动的维护 pass
- 自动摘要：长笔记生成3行概述
- 自动标签：根据内容推断分类
- 自动链接：发现相似概念，插入
[[反向链接]] - 去重检测：内容相似的笔记合并建议
- 输出：自动维护的 MOC（Map of Content）页面
为什么用 Obsidian
- 本地优先：纯 Markdown 文件，你完全拥有数据
- Git 友好：可以 diff、版本控制
- 生态丰富：已有社区插件可以辅助
- 开放格式：不锁定在任何平台
与 Karpathy 的 autoresearch 的关系
Karpathy 还在做一个叫 autoresearch 的项目：让 LLM Agent 自主进行研究。
两者的关系是一个完整循环：
autoresearch（生成）→ 产出原始发现
↓
LLM Wiki（综合）→ 蒸馏为结构化知识
↓
未来研究查询 ← 从Wiki中获取上下文，避免重复工作
简单说：autoresearch 是 "输入端"（产生新知识），LLM Wiki 是 "存储端"（组织和维护知识）。
现有替代方案对比
| 工具 | 方式 | 与 LLM Wiki 的差异 |
|---|---|---|
| Mem.ai | AI 原生笔记，自动组织 | 云端、闭源、消费级 |
| Khoj | 自托管 AI 助手 | 被动问答，不主动维护 |
| Obsidian Smart Connections | LLM 插件 | 响应式（回答问题），非主动式 |
| Quivr | RAG 知识库 | 只检索，不综合 |
| Notion AI | Notion 内置 AI | 云端锁定，不做自主维护 |
| Fabric (Daniel Miessler) | AI 增强模式库 | 模式库，不是持久Agent |
vault-operator 的独特之处：
- 本地优先 + Agent 主动维护 + 图结构维护 + 可组合（可叠加多个调和器）
如何开始构建自己的 LLM Wiki
方案一：直接用 vault-operator
git clone https://github.com/pssah4/vault-operator
cd vault-operator
# 配置你的 Obsidian Vault 路径和 LLM API Key
cp .env.example .env
# 编辑 .env 填入路径和 API key
npm install && npm start
方案二：最小可行版（Claude Code + cron）
如果你不想用现成工具，可以自己搭：
- Obsidian Vault 作为知识基底
- 每日 cron job 运行 Claude 处理
inbox/文件夹 - Claude 的指令：摘要、打标签、找关联、更新 MOC
- 输出写回 Vault 的对应位置
核心提示词大概长这样：
你是一个知识库维护Agent。
任务：处理 inbox/ 中的新笔记。
对每个笔记：
1. 生成3行摘要放在 frontmatter
2. 推断标签（最多5个）
3. 找到 vault 中相关的已有笔记，插入 [[反向链接]]
4. 如果与已有笔记高度重复，建议合并
5. 处理完后移到对应分类文件夹
6. 更新 MOC.md 的索引
方案三：进阶——多Agent架构
摄入 Agent → 从 RSS/Twitter/论文 抓取新信息
分析 Agent → 判断相关性、提取关键观点
综合 Agent → 更新现有词条、创建新词条
质检 Agent → 检查链接有效性、标记过期内容
这种模式适合谁
- 研究者：每天读大量论文，需要系统性积累
- 技术负责人：跟踪多个领域的技术动态
- 内容创作者：需要从积累中提炼选题
- 终身学习者：想让知识像复利一样增长
当前局限
- 成本：每次 "调和" 都消耗 API 调用（可以用 DeepSeek V3 降本）
- 幻觉风险：Agent 可能创建不准确的关联
- 规模上限：Vault 超过几千篇后，全量扫描变慢
- 隐私：如果用云端 API，你的笔记会被发送到外部
未来展望
结合 Claude Code 的 Memory 系统和 Skills，我们可能很快会看到：
- 编程知识库自动从 commit history 中学习
- 团队知识自动从 Slack/会议记录中沉淀
- 个人 Wiki 与编码 Agent 无缝对接
Karpathy 画的饼可能比我们想象的更快变为现实。
想记录和管理你学到的技术知识？不妨从 Markdown 编辑器 开始，所见即所得地编写你的第一篇知识笔记。