Karpathy 的 LLM Wiki 很美。但它有一个不太被讨论的天花板。

前几天 Karpathy 发了 llm-wiki.md，我的 timeline 几乎被这一份 gist 刷屏。不到 48 小时，GitHub 上已经有人写出了 Go 写的二进制工具、CLI 编译器、Obsidian vault 生成器，中文圈的解读文章也在路上。

这种场面只在他真讲对一件事的时候才会出现。

而这次他确实讲对了。我想把这一点说在前面，因为接下来我打算反对他的一部分结论 —— 不是反对那个核心洞察，而是反对他那个洞察自然推导出的实现方式。

Karpathy 命名了一件事：在原始资料和 LLM 的最终答复之间，应该存在一层会被持续维护、持续演化、持续被 Agent 消费的中间层。这一层不该是聊天记录里的临时产物，也不该是每次查询都从零开始的 RAG 检索。它应该作为一个独立的对象存在，有结构、有索引、有时间维度，会随着你和 Agent 的每一次互动慢慢长大。

这个洞察是对的。它可能是 2026 年关于个人知识管理最重要的一句话。

但他给出的实现方式 —— 本地 Markdown + Obsidian + Claude Code + 一份手写的 AGENTS.md —— 有一个不太被讨论的天花板。这个天花板的位置，恰好就是这套东西从「开发者的个人玩具」开始想成为「基础设施」的那一刻。

先快速地从头说一下他做了什么

为了让没读过原文的读者也能跟上，我用最短的话总结一遍。

Karpathy 的方案有三层：

• raw/ —— 原始资料，只读。文章、论文、代码、截图，丢进去不动。
• wiki —— LLM 维护的 Markdown 知识层。摘要页、概念页、对比页、综合页，还有两个特殊文件：index.md 是空间地图，log.md 是时间流水。
• schema —— 一份 CLAUDE.md 或 AGENTS.md，告诉 LLM 怎么组织、怎么 ingest、怎么 query、怎么 lint。

整套东西的核心动作叫 file-back —— 写回。当一次 query 产出了有价值的东西，就把它写回 wiki 成为新页面。问答从消耗上下文，变成生产上下文。

如果你过去两年用 RAG 一直觉得哪里不对劲，知识总是在蒸发，那么读到「file-back」那一刻，大概会和我一样有种「啊，原来缺的是这个」的感觉。

所以问题来了：既然这件事这么对，我反对什么？

天花板一：schema 是一项被伪装成"配置文件"的编程任务

Karpathy 给的 schema 例子很干净。问题是，它们都是 Karpathy 写的。

这两天我读了至少六七份社区实现，每一份的 AGENTS.md 都长得不一样。有人按文档类型分类，有人按主题分类，有人按时间分类。有人给 index 设了 token 预算，有人没设。有人规定每次任务必须产出"回答 + 写回"两份东西，有人忘了加这条所以 LLM 干脆就忘了写回。

gist 评论区里那些被点赞最多的留言，内容都是"我踩过这个坑，你最好这样写 schema"。

这说明什么？说明 schema 这一层根本不是配置文件，它是软件。只不过你是在用 Markdown 项目符号写而已。

对喜欢这种事的开发者来说，它没问题，甚至挺好玩。但如果你再退一步问："在所有可能从'持续维护的知识中间层'里受益的人当中，有多少比例的人愿意从一份空白的 AGENTS.md 开始写自己的 schema？"

答案是：很小一部分。

schema 是 Karpathy 方案的天花板，因为它是这个方案里最不可规模化的部分。每个人都要从零开始重新发明轮子，而每个人发明的轮子都不一样。

这里有一个真正有意思的产品问题：当 schema 层作为产品出厂、但仍然可以被特化的时候，它应该长什么样？

这不是 Markdown 能回答的问题。这是产品设计要回答的问题。

天花板二：你的 Agent 早就不在你的笔记本上了

这是 Farzapedia 那个例子最重要的遗漏，虽然 Farza 自己可能没意识到。

Farza 拿了大约 2500 条个人材料（日记、Apple Notes、iMessage），让 LLM 编译成 400 篇互相链接的个人百科。然后他说了那句被 Karpathy 反复引用的话：

"这个 wiki 不是为我建的，是为我的 Agent 建的。"

这句话定调极其精准。它一刀切开了"个人笔记应用"和"Agent 知识基础设施"两个市场，而且站在了后者那一边。

但是 —— 这句话也同时摧毁了 file-over-app 架构本身，只要你认真对待它。

因为如果 wiki 是为 Agent 建的，而你的 Agent 是本地跑的 Claude Code —— 那好，文件没问题。但你的 Agent 越来越不是那种东西了。它可能是：

• 部署在 VPS 上的 Claude Code，定时自动跑定时任务
• 你手机上的 ChatGPT，通过 MCP 接入
• Slack 里给团队答疑的 bot
• 某个外贸场景里的 Agent，要在客户邮件来的瞬间查你的产品知识库
• 另一个 Agent 派生出来的子 Agent

这些东西没有一个能 cd ~/wiki && grep。

它们需要的是一个 URL，而不是一条文件路径。一个网络协议，而不是一个目录。一台远程可达的服务器，而不是你早上锁了屏的那台 Mac。

Karpathy 的方案默认了一个非常具体的部署假设：一个人 + 一台笔记本 + 一个有文件系统访问权限的 Agent 进程。只要你违反这三个假设里的任意一个 —— 而 2026 年所有有意思的 Agent 用例几乎都同时违反这三个 —— 这套东西就开始漏水。

这不是在批评 Karpathy 的设计。这是在描述他的设计优化的是哪个场景。他优化的是「开发者 + Obsidian + Claude Code」那个场景。这是一个真实的、有价值的场景。但它不是这个领域正在去的地方。

天花板三：lint 这个词背后藏着一座小山

Karpathy 的工作流是 ingest → query → file-back → lint。前三步都很激动人心。第四步，是我见过的所有长期运行的个人知识系统最终死掉的地方。

在这个语境下，lint 意味着：发现矛盾、找出过期的论断、修复断链、识别陈旧的页面、合并语义重复的条目。

Karpathy 自己说了一句很谨慎的话：human owns verification —— 人负责校验。这句话是对的。但是验证需要分诊，而上规模的分诊靠 grep 和人工注意力是干不到的。

我说一件没有人愿意大声说出口的事：

当你的 wiki 超过几百页之后，你就没办法只用文本工具来 lint 了。

你需要语义相似度，才能找出"用不同的词写的同一件事"。你需要访问日志，才能找出"Agent 从来没读过的页面"。你需要向量邻域，才能找出孤立条目。你需要的是一组Markdown 目录天然不具备的能力。

Karpathy 这套模式在未来几个月会催生一大批漂亮的 80 页小 wiki。它们都会很好看。然后到 800 页的时候，它们会安静地腐烂。

不是因为这套模式不对，而是因为维护层需要的能力，恰好是 file-over-app 故意排除掉的能力。

那么上面那一层该是什么样

如果你接受这三个天花板 —— schema 是产品、Agent 在远端、lint 是基础设施 —— 那么上面那一层的形状几乎是自动推导出来的。它必须是：

1. 云原生的，因为你的 Agent 不在你的笔记本上
2. MCP 原生的，因为 Agent 和知识对话的协议已经定下来了，就是 MCP，再装它没定下来只是在重复一个已经结束的争论
3. Schema 内置的，因为采用门槛不能是"先写一份深思熟虑的 AGENTS.md"
4. 向量原生的，因为 lint、发现、相关性推荐这些事在某个规模就不能只靠文本
5. 可一键导出 Markdown 的，因为"我要我的数据"这件事的正确答案是一键导出，不是拒绝使用数据库

这不是凭空想出来的需求列表。这是 Karpathy 的叙事和 2026 年 Agent 真实部署形态之间那条裂缝里，自然长出来的东西。

给"file over app"派的话

我想认真地为坚持 file-over-app 的人说几句话，因为他们捕捉到的东西是真实的。

他们捕捉到的是：锁定是坏的，格式会死，公司会关闭，你的知识应该比托管它的服务活得更久。这些都对。我都同意。

他们搞错的地方是：他们把存储格式和部署形态混为一谈了。

你完全可以 —— 你的数据是 Markdown 文件，同时它可以被远程 Agent 通过协议访问。这是两个独立的决策。"文件比应用好"这个论点的真正含义是"开放格式比封闭格式好"，而这个论点的胜利方式是导出 Markdown，不是拒绝运行服务器。

最干净的答案是：Markdown 作为正式表示，向量嵌入作为索引，MCP 作为访问协议，内置 schema 作为上手体验。用户对着输入框敲字，Agent 看到的是结构化的知识图，底下的真相依然是一组你可以 git clone 走的文件。

这是我正在做的东西。它叫 KnowMine。11 个 MCP 工具，pgvector 向量层，有一个叫 SOUL 的个性化层，接入了 Claude / OpenClaw / MCP 生态。你现在把它接到 Claude Code 上，你的 Agent 立刻就有了 file-back 闭环和 get_related_knowledge 的语义关联发现，不需要写一行 AGENTS.md。

但说实话，你用不用 KnowMine，不是这篇文章的重点。

这篇文章的重点

重点是：Karpathy 命名了一件重要的事，但从他的 gist 最自然的读法是"去 Obsidian 里搭一套"，而这个读法会让半个月后的很多人卡在 schema 和 lint 的天花板上。

LLM Wiki 这套模式真正的教训，比 Karpathy 展示的那个实现要大。它是这样一句话：

原始资料和 Agent 回答之间的中间层，应该作为一个一等公民的产品存在。它由 Agent 维护，跨会话持久，可以从 Agent 运行的任何地方访问到，被当作基础设施而不是某个文件夹里的文件。

如果你认真对待这句话，你不会落到 Obsidian。你会落到一个"知识协议层"。那是一种不一样的东西。

边界，以及一些诚实的话

我想用 Karpathy 自己做得很好的一件事来收尾：清楚地说明你的工具不为谁服务。

云端知识协议层这条路 —— KnowMine 也好，任何类似的产品也好 —— 不适合你，如果：

• 你是开发者，文档少于 500 篇，你享受自己写工具
• 你有硬性的离线 / 物理隔离需求
• 你对任何云服务原则上就过敏，"一键导出"也打动不了你

这些情况下，Karpathy 的方案就是正确答案。去用，玩得开心。那份 gist 写得非常好。

但如果你正在尝试的事是：给你的 Agent —— 跨设备、跨会话、跨你一周里用的四五个不同的 AI 工具 —— 提供一个会复利而不是会蒸发的知识层，那么你已经走出了 file-over-app 的边界。你大概半个月前就需要一层协议层了。

好消息是，它现在存在了。它在 knowmine.ai。免费额度，MCP 端点，11 个工具，不需要写 AGENTS.md。