2026 年 4 月，Andrej Karpathy 写了一篇 GitHub Gist。他在里面描述了一种方法，称之为LLM Wiki。
随后，四个团队在短时间内各自构建了相同的概念：
Cognition构建了 DeepWiki
Factory构建了 AutoWiki
LangChain发布了 OpenWiki
Garry Tan发布了 GBrain
这四个系统的核心方法完全一致：LLM 一次性读取你的源文档，将信息写入 Markdown 页面，并在源文档变更时保持页面更新。智能体直接读取这些页面，而无需为每个问题重新读取原始文档。
人们将这些系统称为Agent Wiki（智能体维基）。本文将告诉你它们是什么、每个团队构建了什么、这种方法的局限性，以及一个被许多人忽略的关键区别。
* *
核心理念：在摄入时编译，而非查询时检索
传统上，让模型理解大量文档的方法是检索式 RAG：将文档存入数据库、分块、生成嵌入向量，每个查询都从原始片段中重新构建答案。
这种方法有效，但有一个问题：系统不会保留结果。第十次回答并不比第一次更好，而你要为同样的工作付出十次成本。
Agent Wiki 将成本前置。模型在读取源文档时一次性完成工作，将结果写入持久化的页面。
当新源文档加入时，模型执行以下步骤：读取新文档 → 更新相关的现有页面 → 修正摘要 → 标记与现有页面矛盾的信息。
两种方法都正确，但有两个关键差异：何时支付成本，以及问题之后留下了什么。
三个层次
每个 Agent Wiki 系统都包含相同的三层架构：
| 层级 | 内容 | 说明 |
| — | — | — |
| Layer 1 | 源文档 | 文章、论文、代码仓库，模型只读不修改 |
| Layer 2 | Wiki 维基 | Markdown 格式，模型编写全部内容，包含摘要、主题页面和页面间链接 |
| Layer 3 | Schema 文件 | 告诉模型 Wiki 的结构和要执行的任务（通常是 CLAUDE.md 或 AGENTS.md） |
三个操作
Ingest（摄入）：模型读取新源，将数据写入每个相关页面
Query（查询）：向 Wiki 提问，也可将优质答案写回 Wiki 成为新页面
Lint（检查）：模型审查 Wiki，发现矛盾信息、过期信息和孤立页面
* *
为什么它能工作？
人类维护的 Wiki 会随时间变得不准确。原因很具体：难的不是阅读源材料，也不是产生想法，而是持续维护。
维护工作包括：修正页面间链接、保持摘要准确、将每个新文档与现有页面对比。这项工作永无止境，也没有回报。忙碌的团队最先放弃这项工作，然后 Wiki 变得不准确，最终被废弃。
模型做这项工作毫无问题。模型不会厌倦，不会忘记链接，可以一次性修改十五个文件。
这个想法历史悠久。1945 年 Vannevar Bush 就描述了Memex——一个带有链接的个人文档存储系统。Bush 当时无法解决维护问题。而今天，模型就是答案。
* *
名称由来
直接阅读 Karpathy 的 Gist 原文比任何摘要都准确。
关于传统方法，他写道："LLM 在每个问题上都在从零重新发现知识，没有积累。"
他的方法是将信息编译（compile）而非检索。于是 "知识一次性编译完成并持续保持最新，而非每次查询重新推导"。结果是一个 "持久的、持续积累的产物"。
你不需要自己写 Wiki。他写道："你很少（或从不）自己编写 Wiki，LLM 编写并维护所有内容。" 他将 Agent 和 Obsidian 结合使用："Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。"
Gist 还给出了规模限制——很多摘要忽略了这一点：不依赖嵌入向量的方法 "在中等规模下效果出奇地好（约 100 个源，数百个页面）"。对于更大的源，Gist 建议添加搜索，以qmd为例——"一个基于 Markdown 文件的本地搜索引擎，混合 BM25/向量搜索和 LLM 重排序。"
所以规则是关于规模，而不是关于替代。源集小时不需要检索基础设施；源集变大时再加入检索。
* *
各团队实际构建了什么
Cognition：DeepWiki——作为公共工具的 Wiki
Cognition 将此方法应用于 GitHub 上的公开仓库。将 URL 中的github.com替换为deepwiki.com，即可获得该代码库的 Wiki。包含架构摘要、文件索引、依赖关系图和搜索功能，且 Wiki 包含指向源代码的链接。
超过 50,000 个最大的公开仓库已有 Wiki，包括 MCP 和 LangChain。
更重要的是：Wiki 本身不是产品，而是 Agent 的检索基础设施。Devin 使用 Wiki 在代码库中查找相关代码。DeepWiki 是 Devin 代码搜索之下的编译层。
Factory：AutoWiki——文档作为构建产物
Factory 将此方法应用于持续集成。他们的理念是：文档必须是构建产物，而不是独立的项目。文档来自源代码，拥有代码库的结构，随仓库变更而变更。
构建 Wiki 的方法有两个阶段：Pass 1（结构扫描）读取 README、包清单、CI 配置和入口点；Pass 2（语义扫描）读取路由、API 端点、服务类、数据库模式和功能标志。
Factory 将工作分配给多个专业 Agent，每个 Agent 负责仓库的一部分，拥有足够的上下文写出一篇好页面。这避免了单一 Agent 为大型仓库编写糟糕文档的已知问题。
Factory 用基础设施而非纪律来保持 Wiki 正确。/wiki命令重建 Wiki，/install-wiki命令写入 CI 工作流，每次推送到默认分支时自动重建 Wiki。
LangChain：OpenWiki——从代码到一切
LangChain 将 OpenWiki 作为开源 CLI 工具发布，用于编写和维护代码库的 Agent 文档。随后发布了OpenWiki Brains，包含两种模式：Code Brain用于代码仓库，Personal Brain用于个人源文档。
Personal Brain 是关键转变。它从Gmail、Notion、Git 仓库、X（Twitter）、Hacker News 和网页搜索中读取数据，全部写入一个本地 Markdown Wiki。该方法从"代码仓库的文档"变成了"你工作的文档"。
每个团队做出了相同的决策：输出不是给人阅读的文本，而是供 LLM 使用的结构化 Markdown。包含标题、页面间链接和摘要。Wiki 的读者是模型。
GBrain——个人规模的开源版本
GBrain 将方法应用于个人知识库而非代码库。使用 Git 仓库中的 Markdown，拥有 Schema 文件，自动生成主题间的链接图。
GBrain 展示了这种方法几乎不需要基础设施：没有向量数据库，没有服务，只有文件。模型维护文件，人也可以阅读文件。
* *
技术矩阵对比
| 特性 | DeepWiki | AutoWiki | OpenWiki | GBrain |
| — | — | — | — | — |
| Markdown in Git | ✓ | ✓ | ✓ | ✓ |
| Schema 文件 | ✓ | ✓ | ✓ | ✓ |
| 摄入时编译 | ✓ | ✓ | ✓ | ✓ |
| 源变更时更新 | ✓ | ✓（CI） | ✓（手动） | ✓（手动） |
| 为 Agent 编写 | ✓ | ✓ | ✓ | ✓ |
四个团队用四种不同的应用场景解决了四个不同的问题，却得出了相同的架构。这种一致性是架构正确性的有力证据。
唯一的差异在于维护方式：Factory 通过 CI 自动维护；其他三个系统需要手动运行命令。因此，后者的 Wiki 只在上次命令运行时才是正确的。
* *
局限性
限制 1：规模
Karpathy 给出了这个限制。不依赖嵌入向量的方法适用于约 100 个源。更多页面时，必须添加搜索引擎（BM25 + 向量搜索）。
限制 2：准确性
模型在摄入时编译信息。早期的摘要可能遗漏源文档中的细节，后续每个答案都会继承这个错误。RAG 不会出现这个问题——你是在用重复工作的成本交换数据丢失的风险。
限制 3：过时信息
页面的正确性取决于最后一次更新。这是 Factory 的 CI 方法如此重要的原因。错误的 Wiki 比没有 Wiki 更糟糕，因为错误信息具有正确信息的格式。
限制 4：成本
你支付 Token 来创建页面，其中一些页面可能无人阅读。你还要支付 Token 来检查没有变化的页面。
* *
Wiki ≠ 记忆
有一个关键区别你必须知道。这个领域中的术语还不够精确。
很多人将这些系统称为记忆（Memory）。LangChain 称 OpenWiki 为 AI Agent 的 Wiki 记忆层。但"记忆"在这里有两个不同的含义：
含义一：文档集的知识。Wiki 能做到这一点。它编译文档、仓库或 Gmail 中的数据，告诉你文档中有什么。
含义二：用户的记忆。这是不同的数据。包括：个人的偏好、个人做出的决策、团队曾拒绝的方法、Agent 在不同应用中尝试某种方法的结果。
用户的记忆具有不同的结构——它与个人相关而非文档集，来自交互而非摄入。它还必须在每个用户维度上做到：修正矛盾信息、删除过期信息、保留每条信息的来源、按请求删除数据。
Wiki 能做好第一件事，但做不了第二件事。你的 Gmail Wiki 能告诉 Agent 你的 Gmail 中有什么，但无法告诉 Agent 你在星期二的对话中改变了一个决定。
记忆层做第二件事。Mem0 就是一个例子。它用user_id保存每条记忆，记忆随用户在会话、应用和 Agent 之间移动。当事实变化时更新已有记录，而不是每次都新增一条。
这两个系统不是替代关系——两个都用。错误不是使用 Wiki，而是认为 Wiki 能给你用户的记忆。
* *
总结
Agent Wiki 的理念是正确的：一次编译知识，持续保持正确，不要为每个问题重新构建。维护拖垮了人类 Wiki，而模型可以零成本地完成维护工作。四个月之内四个团队构建了相同的架构——这是强有力的证据。
做这三件事：
当文档集稳定且你频繁阅读时，将文档编译成页面
当文档集变大时加入检索，如 Karpathy 的 Gist 所述
区分文档集的知识和用户的记忆——Wiki 给你前者，不给你后者
* *
本文是 In Context#17，属于@mem0ai 的博客系列，涵盖 AI Agent 记忆与上下文工程。
Mem0 是一个智能的开源记忆层，为 LLM 和 AI Agent 提供跨会话的长期、个性化、上下文感知交互。
🔗 获取免费 API Key：app.mem0.ai
🔗 自托管 Mem0：GitHub -mem0ai/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
#AgentWiki#LLMWiki#AI#Mem0#DeepWiki#AutoWiki#OpenWiki#GBrain#Karpathy#RAG#AI记忆#AI知识管理
