LLM Wiki：Karpathy 提出的 Agent 知识库方案为什么火了

几周前 Karpathy 在 X 上发了一个想法：为什么不让 AI Agent 维护自己的 wiki？

不是向量数据库那种花哨的方案，就是最朴素的 Markdown 文件 + Git 版本控制。Agent 在工作过程中把学到的东西写进 wiki，下次需要的时候去查。和人类程序员维护内部文档的方式一模一样。

这个想法发出来之后一个月内，GitHub 上冒出来十几个实现。其中叫 WUPHF 的那个拿了 HN 260 分，现在已经是一个完整的多 Agent 协作框架了。

为什么一个这么「低技术含量」的想法能引起这么大反响？

现有方案的问题

目前 Agent 获取长期知识有两条路：

路线一：全塞进上下文。 把所有相关信息拼成一个超长 prompt 喂给模型。好处是简单直接，坏处是上下文窗口有限（就算是 200K 的窗口也不够放一个项目的所有文档），而且越长越贵、越慢、越容易丢失关键信息。

路线二：RAG（检索增强生成）。 把文档切块、做 embedding、存进向量数据库，用的时候检索最相关的片段注入上下文。好处是能处理海量文档，坏处是检索质量不稳定（经常检索到相关但没用的片段），而且向量数据库本身是一个需要维护的基础设施。

两条路都有一个共同的问题：知识是被动的。系统从一堆现有文档里找东西给 Agent，但 Agent 自己没有办法主动组织、整理、更新这些知识。

Karpathy 的想法换了一个角度：让 Agent 成为知识的生产者而不只是消费者。

具体来说：

不需要向量数据库，不需要 embedding，不需要任何额外基础设施。一个文件夹、几个 .md 文件、一个 git 仓库，够了。

WUPHF（名字来自《The Office》里 Ryan Howard 的创业项目）是目前最完整的 LLM Wiki 实现。它不只是一个 wiki 工具，而是一整套多 Agent 协作框架。

它的记忆系统分两层：

Notebook（个人笔记本）：每个 Agent 有自己的私有笔记本。工作过程中的原始想法、观察、临时结论都写在这里。只有这个 Agent 自己能看到。

Wiki（共享知识库）：团队共享的知识库。当 Notebook 里的某条信息被验证为可靠且有长期价值时，Agent 把它「晋升」到 Wiki。所有其他 Agent 都能查到。

晋升不是自动的。Agent 自己判断什么值得共享、什么只是临时性的工作记录。这避免了 wiki 被大量低质量信息淹没。

Wiki 的底层不只是一个 Markdown 文件夹。它有类型化的实体、三元组关系图、LLM 综合生成的摘要（以 archivist 身份提交）、还有一个 lint 工具检测矛盾、孤立条目、过时信息。

但对外暴露的接口非常简单：cat、grep、git log、git clone 全能用。不需要学任何新的 API。

有人会问：这不就是回到了最原始的方案吗？向量数据库不是比 grep 更智能吗？

对于 Agent 来说，不一定。

Agent 搜索知识的方式和人不一样。人类在搜索时经常用模糊的、不精确的查询（「那个关于认证的东西」）。这种场景下语义搜索确实比关键词搜索好用。

但 Agent 通常知道自己在找什么。它不会搜「那个什么东西」，它会搜「OAuth2 token refresh endpoint」。这种精确查询，grep 够了，而且 grep 不会返回「语义相关但实际没用」的噪音。

另外 Git 提供了两个向量数据库给不了的东西：

时间线。 git log 可以看到知识是什么时候写的、什么时候被修改过。如果一条信息是 6 个月前写的，Agent 可以判断它可能过时了。向量数据库里的 chunk 没有这个时间维度。

可回滚。 如果 Agent 写了一条错误的信息，git revert 一下就好了。版本控制天然支持纠错。向量数据库里的 embedding 一旦更新就很难精确回滚。

当然不是所有人都买账。Medium 上有一篇文章标题就是「Karpathy's LLM Wiki Is a Bad Idea」。

主要批评点：

不能扩展。 当 wiki 文件变成几千个的时候，grep 的效率会下降。你需要某种索引。

Agent 写的东西质量不保证。 如果 Agent 把错误的信息写进 wiki，其他 Agent 会基于错误信息工作，形成错误传播。

没有权限控制。 所有 Agent 都能读写 wiki，没有审核机制。

这些批评都有道理。但它们更适用于大型、长期运行的 Agent 集群。对于个人使用场景（一个人 + 几个 Agent 处理日常工作），Markdown + Git 的简单性远比这些边界场景的缺陷重要。

如果你在用 Claude Code，你可能已经在不知不觉中使用了类似的方案。Claude Code 的 CLAUDE.md 文件、memory 系统、project instructions，本质上就是一个简化版的 LLM Wiki。

区别是 Claude Code 的记忆更多是人工维护的（你告诉它记什么），而 Karpathy 的设想是让 Agent 自主维护。方向一样，自动化程度不同。

Karpathy 有一个一贯的特点：他提出的方案总是异常简单。autoresearch 就是三个文件。LLM Wiki 就是 Markdown + Git。没有花哨的架构，没有新发明的协议。

但简单不等于容易想到。在所有人都在卷向量数据库、知识图谱、RAG pipeline 的时候，退一步想「也许一个文件夹就够了」需要一种反直觉的判断力。

很多时候最好的工程方案不是最复杂的，而是能让你今天下午就开始用、出了问题能一眼看明白哪里错了的那个。

这是 AI Agent 系列的第十篇。前几篇：