2026 年 4 月，Andrej Karpathy 写了一个 GitHub Gist。他在其中描述了一种方法。他称这种方法为 LLM Wiki。
之后，四个团队构建了同样的东西。Cognition 构建了 DeepWiki。Factory 构建了 AutoWiki。LangChain 发布了 OpenWiki。Garry Tan 发布了 GBrain。
这四个系统的方法相同。一个 LLM 一次性读取你的源文档。它将信息写入 Markdown 页面。当源文档发生变化时，它保持页面正确。Agent 读取这些页面。Agent 不会为每个问题重新读取源文档。
人们称这些系统为 Agent Wiki。本文告诉你它们是什么。它告诉你每个团队构建了什么。它告诉你这种方法的局限性。它还告诉你一个很多人忽略的重要区别。
核心思想：在摄入时编译，而非在查询时编译
给模型提供大量文档的常规方法是检索。你将文档放入数据库。你将文档分割成片段。你为这些片段生成嵌入。对于每个问题，系统找到相关片段。
这个方法有效。但它也有一个问题。系统不会保留结果。它每次都从原始片段重新构建答案。第十个答案并不比第一个答案更好。你为这份工作付出了十次的成本。
Agent Wiki 转移了这种成本。模型在读取源文档时一次性完成工作，并将结果写入页面。页面得以保留。
当新源文档进入时，模型执行以下步骤：它读取源文档，修改相关页面，纠正摘要，标记与页面相矛盾的信息。
两种方法都是正确的。它们在两个方面不同。第一个区别是你何时支付成本。第二个区别是问题之后保留了什么。
每个系统都有相同的三个层次。
第一层是源文档。这些是你的文章、论文和仓库。模型读取它们。模型不会修改它们。
第二层是 Wiki。Wiki 是 Markdown 格式。模型编写所有 Wiki 内容。Wiki 包含摘要、每个主题的页面以及页面之间的链接。
第三层是模式文件。这个文件告诉模型 Wiki 的结构。它还告诉模型要执行哪些任务。通常的文件是 CLAUDE.md 或 AGENTS.md。这个文件让模型成为 Wiki 的正确维护者。
系统执行三种操作。
摄入：模型读取一个新源文档。然后模型将数据写入每个相关页面。
查询：你向 Wiki 提问。你可以将好的答案写回 Wiki 作为新页面。
检查：模型检查 Wiki。它发现矛盾的信息，发现过时的信息，发现没有链接的页面。
为什么有效：
人类维护的 Wiki 会随时间变得不准确。原因是特定的。困难的部分不在于阅读源文档，也不在于产生想法。困难的部分在于维护。
维护包括这些任务：你必须纠正页面之间的链接，保持摘要正确，将每个新文档与现有页面进行比较。
这项工作不会停止。这项工作没有回报。忙碌的团队会首先停止这项工作。然后 Wiki 变得不准确，人们就不再使用它。
模型可以毫无问题地完成这项工作。模型不会感到厌倦。模型不会忘记链接。模型可以在一次操作中修改十五个文件。
这个想法并不新鲜。Vannevar Bush 在 1945 年描述了 Memex。Memex 是一个个人文档存储库，文档之间带有链接。Bush 没有解决维护问题。模型就是答案。
名称的由来
直接阅读 Karpathy 的 Gist。它比任何摘要都更准确。
他关于常规方法写道："LLM 在每次提问时都从头开始重新发现知识。没有积累。"
他的方法是编译信息，而不是检索信息。然后"知识被编译一次并保持最新，而不是在每个查询中重新推导。"结果是"一个持久的、不断积累的产物。"
你不需要自己编写 Wiki。他写道："你从不（或很少）自己编写 Wiki，LLM 编写并维护所有内容。"他将 Agent 和 Obsidian 结合使用。他写道："Obsidian 是 IDE；LLM 是程序员；Wiki 是代码库。"
该 Gist 给出了一个规模限制。许多摘要没有包含这个限制。没有嵌入的方法"在适度规模（约 100 个源文档，约数百个页面）下效果出奇地好，并避免了对基于嵌入的 RAG 基础设施的需求。"
对于更多的源文档，Gist 建议添加搜索。它给出了 qmd 作为例子。Gist 将 qmd 描述为"一个用于 Markdown 文件的本地搜索引擎，具有混合 BM25/向量搜索和 LLM 重排序。"
因此，规则是关于规模的。规则不是关于替代。当源文档集较小时，不要使用检索基础设施。当源文档集变大时，再添加检索。
各实验室实际构建了什么
这就是模式从想法变为工程的地方，实现之间的差异才是最有用的部分。
Cognition: DeepWiki，作为公共服务的 Wiki
Cognition 将这种方法应用于 GitHub 上的公共仓库。在公共仓库的 URL 中，用 deepwiki.com 替换 github.com。然后你会得到该代码库的 Wiki。该 Wiki 包含架构摘要、文件索引、依赖关系图和搜索。Wiki 包含指向源文档的链接（Cognition）。
超过 50,000 个最大的公共仓库都拥有 Wiki。列表包括 MCP 和 LangChain。
第二点更重要。Wiki 不是产品。Wiki 是 Agent 的检索基础设施。Devin 使用 Wiki 来查找代码库中的相关代码。因此，DeepWiki 是 Devin 中代码搜索之下的编译层（Devin Docs）。
Factory: AutoWiki，文档作为构建产物
Factory 将这种方法应用于持续集成。Factory 写道，文档必须是一个构建产物，而不是一个独立的项目。文档来自源文档，具有代码库的结构，并在仓库变化时随之变化（Factory）。
构建 Wiki 的方法有两遍。第一遍是结构扫描。它读取 README 文件、包清单、CI 配置和入口点。第二遍是语义扫描。它读取路由、API 端点、服务类、数据库模式和功能标志。
Factory 将工作分配给专门的 Agent。每个 Agent 负责仓库的一部分。每个 Agent 获得足够的上下文来编写一个良好的页面。这种方法防止了一个已知问题：单个 Agent 为大型仓库编写糟糕的文档。
Factory 通过基础设施而不是纪律来保持 Wiki 的正确性。/wiki 命令重新生成 Wiki。/install-wiki 命令编写一个 CI 工作流。该工作流在每次推送到默认分支时重新生成 Wiki。对于 GitHub，Wiki 会进入仓库的 Wiki 标签页（Factory Docs）。
LangChain: OpenWiki，从代码到一切的飞跃
LangChain 将 OpenWiki 发布为开源软件。OpenWiki 是一个 CLI 工具。它为代码库编写和维护 Agent 文档。然后 LangChain 发布了 OpenWiki Brains，它有两种模式。Code Brain 是第一种模式，用于仓库。Personal Brain 是第二种模式，用于你自己的源文档（LangChain）。
Personal Brain 是重要的变化。它从 Gmail、Notion、Git 仓库、X、Hacker News 和网络搜索中读取数据。它将所有这些数据写入一个本地 Markdown Wiki。Agent 读取这个 Wiki。这种方法从仓库的文档转变为你的工作文档。
每个团队都做出了相同的输出决定。输出不是供人阅读的文本。输出是供 LLM 上下文使用的结构化 Markdown。它包含标题、页面之间的链接和摘要。这种结构让 Agent 能够快速找到相关信息。Wiki 的读者是一个模型。
GBrain: 个人规模的开源版本
GBrain 将这种方法应用于个人知识存储库，而不是代码库。GBrain 使用 Git 仓库中的 Markdown。它有一个模式文件。它自动生成主题之间的链接图。
GBrain 表明这种方法需要很少的基础设施。它没有向量数据库。它没有服务。它只有文件。一个模型维护这些文件。一个人可以阅读这些文件。
技术矩阵
这四个系统具有相同的结构。它们使用 Git 中的 Markdown。它们使用一个模式文件。它们在摄入时编译。当源文档变化时，它们重新生成 Wiki。它们编写供 Agent 读取的页面。四个团队解决了四个不同的难题，却构建了相同的结构。这种一致性是结构正确的有力证据。
这些系统在维护方式上有所不同。Factory 在 CI 中进行维护。其他三个系统在有人运行命令时进行维护。因此，它们的 Wiki 只与最后一次命令一样正确。
局限性
限制 1：规模。Karpathy 给出了这个限制。没有嵌入的方法对于大约 100 个源文档是正确的。对于更多的页面，你必须添加一个搜索引擎。Gist 建议同时使用 BM25 搜索和向量搜索。
限制 2：准确性。模型在摄入时编译信息。早期的摘要可能会从源文档中删除一个细节。后面的每个答案都会包含这个错误。从原始片段进行检索则没有这个问题。你是在用重复工作的成本交换数据丢失的风险。
限制 3：过时信息。一个页面只与最后一次更新一样正确。这就是 Factory 方法重要的原因。一个不正确的 Wiki 比没有 Wiki 更糟糕。不正确的信息具有正确信息的格式。
限制 4：成本。你支付 Token 来创建页面。你可能会创建没有人阅读的页面。你还要支付 Token 来检查没有变化的页面。
Wiki 不是记忆
有一个区别你必须知道。这个领域中的词语还不够精确。
许多人称这些系统为记忆。LangChain 称 OpenWiki 为 AI Agent 的 Wiki 记忆层。其他人说 Wiki 给了 Agent 记忆。这里的"记忆"一词有两个不同的含义。
第一个含义是文档集的知识。Wiki 做到了这一点。它编译了你的文档、仓库或 Gmail 中的数据。它告诉你文档中包含了什么。
第二个含义是用户的记忆。这是不同的数据。它包括一个人的偏好，包括一个人的决策，包括一个团队拒绝过的方法，包括 Agent 在不同应用程序中尝试某种方法的结果。
用户的记忆具有不同的结构。它与一个人相关，而不是与文档集相关。它来自交互，而不是来自摄入。它还必须为每个用户执行以下任务：纠正矛盾的信息，删除过时的信息，保留每个条目的来源，并根据请求删除数据。
Wiki 正确地完成了第一个任务。Wiki 没有完成第二个任务。你的 Gmail Wiki 告诉 Agent 你的 Gmail 里有什么。它不会告诉 Agent 你在周二的一次对话中改变了一个决定。它不会告诉 Agent 某个方法对你来说已经失败了。
记忆层完成了第二个任务。Mem0 就是一个例子。它用 user_id 保存每条记忆。因此，记忆会随着人在会话、应用程序和 Agent 之间移动。当某个事实发生变化时，它会更新该事实的位置，而不是每次都添加一条新记录。
这两个系统不是替代关系。同时使用两者。错误在于不使用 Wiki。错误在于认为 Wiki 能给你提供用户的记忆。
总结
Agent Wiki 的理念是正确的。一次性编译知识。然后保持正确。不要为每个问题重新构建。维护工作曾经阻碍了人类 Wiki，而模型可以零成本地完成维护。四个团队在几个月内构建了相同的结构。这是强有力的证据。
做这三件事：当文档集稳定且你经常阅读时，将你的文档编译成页面。当文档集变大时，添加检索，正如 Gist 告诉你的那样。区分文档集的知识和用户的记忆。Wiki 给你前者。Wiki 不给你后者。
In Context #17
这篇博客是 In Context 系列的一部分，该系列是 @mem0ai 的博客系列，涵盖 AI Agent 记忆和上下文工程。
Mem0 是一个智能的、开源记忆层，专为 LLM 和 AI Agent 设计，提供跨会话的长期、个性化、上下文感知的交互。
- 在此获取免费 API 密钥： app.mem0.ai
- 或从我们的 开源 GitHub 仓库 自托管 Mem0
参考文献
- Andrej Karpathy, LLM Wiki (GitHub Gist, April 2026)
- qmd: local hybrid BM25/vector search for markdown
- Cognition, DeepWiki: AI docs for any repo
- Devin Docs, DeepWiki
- Factory, Introducing AutoWiki
- Factory Documentation, AutoWiki overview
- langchain-ai/openwiki (GitHub)
- LangChain, Wiki Memory
- garrytan/gbrain (GitHub)
- Vannevar Bush, As We May Think (The Atlantic, 1945)
- Mem0
