前几天 Karpathy 发了 llm-wiki.md,我的时间线几乎被这一份 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 是基础设施——之后,上面那一层的形状几乎是自动推导出来的。它必须是:

云原生的,因为你的 Agent 不在你的笔记本上
MCP 原生的,因为 Agent 和知识对话的协议已经定下来了,就是 MCP。假装它没定下来,只是在重复一场已经结束的争论
Schema 内置的,因为采用门槛不能是"先写一份深思熟虑的 AGENTS.md"
向量原生的,因为 lint、发现、相关性推荐这些事,到了某个规模就不能只靠文本
可一键导出 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。

更新于 2026-04-23： 两周过去了，这是数据 —— qmd（Karpathy 自己给出的补丁）、rohitg00 的混合检索 v2、Graphify 的图拓扑方案，以及一份从 file-over-app 迁移出来的 benchmark 方法论。

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