Agent Wiki 现状 · 杂七杂八集

2026 年 4 月，Andrej Karpathy 写了一篇 GitHub Gist，在里面介绍了一种方法，并称之为 LLM Wiki。

此后，四支团队做出了同类系统：Cognition 开发了 DeepWiki，Factory 开发了 AutoWiki，LangChain 发布了 OpenWiki，Garry Tan 发布了 GBrain。

这四套系统采用了同一种方法：LLM 只读取一次源文档，把其中的信息写进 Markdown 页面；源文档发生变化时，它会同步更新这些页面。此后，agent 读取的是这些页面，不必针对每个问题重新读取源文档。

人们把这类系统称为 agent wiki。本文会介绍它们是什么、每支团队分别做了什么、这种方法有哪些局限，以及一个经常被忽略的重要区别。

核心思路：在导入时编译，而不是在查询时编译

让模型处理大量文档，通常采用检索方法：先把文档放进数据库，再将文档切分成小块，为每个块生成 embedding。每当有人提出问题，系统就找出相关的块。

这种方法能用，但也有一个问题：系统不会保留处理结果，每次都要从原始文档块重新组织答案。第十次回答并不会比第一次更好，同样的工作成本却要支付十次。

Agent wiki 把这笔成本前移了。模型读取来源时只处理一次，把结果写入页面，而这些页面会一直保留下来。

每当有新的来源进入系统，模型会读取来源、修改相关页面、修正摘要，并标出与页面现有内容相冲突的信息。

两种方法都成立，但有两个区别：一是成本在什么时候支付，二是回答问题之后会留下什么。

每套系统都有相同的三层结构。

第一层是源文档，包括文章、论文和代码仓库。模型会读取它们，但不会修改它们。

第二层是 wiki。整个 wiki 都是由模型编写的 Markdown，其中包含摘要、各个主题的页面，以及页面之间的链接。

第三层是结构定义文件。这个文件告诉模型 wiki 应该采用什么结构，也告诉模型需要完成哪些任务。通常使用 CLAUDE.md 或 AGENTS.md。它让模型能够按照正确方式维护 wiki。

系统会执行三种操作。

导入（Ingest）：模型读取一个新来源，再把数据写入所有相关页面。

查询（Query）：你向 wiki 提问。得到一个好答案后，还可以把它作为新页面写回 wiki。

检查（Lint）：模型检查整个 wiki，找出互相冲突的信息、已经过时的信息，以及没有任何链接的页面。

为什么有效：

人工维护的 wiki 会随着时间推移变得不再准确，原因很明确：难点不在于阅读来源，也不在于提出想法，而在于持续维护。

维护工作包括修正页面之间的链接、确保摘要始终准确，以及拿每份新文档与已有页面进行比对。

这些工作永无止境，也得不到什么回报。团队一忙起来，最先停止的往往就是维护。随后 wiki 开始失准，人们也就不再使用它。

模型却可以毫无怨言地完成这些工作。它不会感到无聊，不会忘记某条链接，还能在一次操作中修改十五个文件。

这个想法并不新鲜。Vannevar Bush 在 1945 年就描述过 Memex——一个由链接相互连接的个人文档库。但 Bush 没能解决维护问题，而模型正是这个问题的答案。

这个名称从何而来

最好直接阅读 Karpathy 的 Gist，它比各种二手摘要更准确。

谈到常见方法时，他写道：“LLM 每遇到一个问题，都要从头重新发现知识，没有任何积累。”

他的方法是编译信息，而不是检索信息。这样一来，“知识只需编译一次，此后保持更新，不必在每次查询时重新推导”，最终得到的是“一份能够长期保留并不断积累价值的产物”。

你不需要亲自编写 wiki。他写道：“你永远不会（或者很少会）亲自编写 wiki，全部内容都由 LLM 编写和维护。”他把 agent 和 Obsidian 搭配使用，并写道：“Obsidian 是 IDE，LLM 是程序员，wiki 是代码库。”

这篇 Gist 还给出了规模上限，但很多摘要没有提到。对于不使用 embedding 的方法，它“在中等规模下效果出乎意料地好（约 100 个来源、数百个页面），而且不需要基于 embedding 的 RAG 基础设施”。

如果来源更多，Gist 建议加入搜索，并以 qmd 为例。它把 qmd 描述为“一款面向 Markdown 文件的本地搜索引擎，结合 BM25/向量混合搜索和 LLM 重排序”。

因此，这条规则针对的是规模，而不是要不要彻底替换检索。来源集合较小时，不要使用检索基础设施；来源集合变大后，再加入检索。

这些实验室实际做了什么

从这里开始，这套模式不再只是一个想法，而是进入工程实现阶段。不同实现之间的差异，才是真正有价值的部分。

Cognition：DeepWiki——作为公共服务的 wiki

Cognition 把这种方法用在了 GitHub 的公开仓库上。把某个公开仓库 URL 中的 github.com 替换成 deepwiki.com，就能得到该代码库对应的 wiki，其中包含架构摘要、文件索引、依赖关系图、搜索功能和指向源代码的链接（Cognition）。

目前，超过 50,000 个规模最大的公开仓库已经拥有自己的 wiki，其中包括 MCP 和 LangChain。

第二点更重要：wiki 本身并不是产品，而是 agent 使用的检索基础设施。Devin 通过 wiki 在代码库中找到相关代码。因此，DeepWiki 是 Devin 代码搜索之下那层预先编译好的基础设施（Devin Docs）。

Factory：AutoWiki——把文档当作构建产物

Factory 把这种方法接入了持续集成。Factory 认为，文档应该是构建产物，而不该是一个独立项目。文档从源代码中生成，结构与代码库保持一致，并在代码仓库变化时同步更新（Factory）。

生成 wiki 分为两遍。第一遍是结构扫描，读取 README、包清单、CI 配置和入口点；第二遍是语义扫描，读取路由、API 端点、服务类、数据库 schema 和功能开关。

Factory 把工作分给多个专门的 agent。每个 agent 负责代码仓库的一部分，并获得足够的上下文来写好一个页面。这样可以避免一个已知问题：只让单个 agent 处理大型代码仓库，写出来的文档往往很差。

Factory 依靠基础设施而不是人的自觉来保持 wiki 准确。/wiki 命令会重新生成 wiki；/install-wiki 命令会写入一套 CI workflow，在每次向默认分支 push 时重新生成 wiki。在 GitHub 上，生成结果会进入代码仓库的 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 阅读。这套方法由“记录代码仓库”扩展成了“记录你的工作”。

各支团队对输出形式都做出了同样的选择：输出不是写给人看的普通文本，而是供 LLM 用作上下文的结构化 Markdown，其中包含标题、页面之间的链接和摘要。这种结构让 agent 能快速找到相关信息。wiki 真正的读者是模型。

GBrain：面向个人场景的开源版本

GBrain 把这套方法用于个人知识库，而不是代码库。它把 Markdown 存在 Git 仓库中，配有结构定义文件，还会自动生成主题之间的链接图。

GBrain 证明，这套方法几乎不需要什么基础设施：没有向量数据库，也没有服务，只有文件。模型负责维护文件，人也可以直接阅读。

技术矩阵

四套系统拥有相同的结构：都在 Git 中使用 Markdown，都有结构定义文件，都在导入时编译，在来源变化时重新生成 wiki，并把页面写给 agent 阅读。四支团队解决了四个不同的问题，却得出了同一种结构。这种一致性有力地说明了这套结构是合理的。

这些系统在维护方式上有所不同。Factory 在 CI 中自动维护，另外三套系统则要由人运行命令才能维护。因此，它们的 wiki 是否准确，取决于上一次运行命令是什么时候。

这套方法的边界

第一项限制是规模。Karpathy 给出了这条界限：不使用 embedding 时，这套方法适用于约 100 个来源；页面更多后，就必须加入搜索引擎。Gist 建议同时使用 BM25 搜索和向量搜索。

第二项限制是准确性。模型在导入时编译信息，早期摘要可能会遗漏来源中的某个细节，之后的每个回答都会继承这个错误。直接从原始文档块中检索不会遇到这个问题。你省下了重复计算的成本，却承担了数据丢失的风险。

第三项限制是信息过时。页面是否准确，取决于上一次更新是什么时候。这正是 Factory 方法的重要之处。错误的 wiki 比没有 wiki 更糟，因为其中的错误信息看起来与正确信息一样可靠。

第四项限制是成本。生成页面需要消耗 token，其中可能有些页面永远没人读取；检查没有变化的页面同样需要消耗 token。

Wiki 不等于记忆

这里有一个必须弄清楚的区别。目前，这个领域使用的词还不够精确。

很多人把这些系统称为记忆系统。LangChain 把 OpenWiki 称为 AI agent 的 wiki 记忆层，也有人说 wiki 能为 agent 提供记忆。但这里的“记忆”实际有两种不同含义。

第一种含义是对一组文档的了解，wiki 可以做到这一点。它会编译文档、代码仓库或 Gmail 中的数据，告诉你这些资料包含什么。

第二种含义是对用户的记忆，所涉及的数据完全不同，包括一个人的偏好和决定、团队否决过的方法，以及 agent 在另一个应用中尝试某种方法后的结果。

用户记忆采用不同的结构。它围绕某个人组织，而不是围绕一组文档组织；它来自交互，而不是导入。系统还必须针对每位用户完成这些任务：修正互相冲突的信息、删除过时信息、保留每条内容的来源，并按要求删除数据。

Wiki 能提供第一种记忆，却提供不了第二种。你的 Gmail wiki 会告诉 agent 邮箱里有什么，但不会告诉它你在周二的一次对话中改变了决定，也不会告诉它某种方法此前已经在你这里失败过。

记忆层负责的是第二种记忆，Mem0 就是一个例子。它通过 user_id 保存每条记忆，因此记忆可以跟随同一个人在不同会话、应用和 agent 之间流转。事实发生变化时，它会原地更新，而不是每次都新增一条记录。

这两类系统并不是二选一，而是应该同时使用。不使用 wiki 是错的；以为 wiki 能提供用户记忆，同样是错的。

总结

Agent wiki 的核心思路是对的：把知识编译一次，此后持续更新，不要每遇到一个问题就重新构建。持续维护拖垮了人工 wiki，而模型可以不费人力地承担维护。短短几个月内，四支团队做出了相同的结构，这是很有力的证据。

实践时要做好三件事：当文档集合比较稳定、而且你需要频繁读取时，把文档编译成页面；文档集合变大后，按照 Gist 的建议加入检索；始终分清“对一组文档的了解”和“对用户的记忆”。Wiki 能提供前者，不能提供后者。

In Context #17

本文属于 In Context——由 @mem0ai 推出的博客系列，内容涵盖 AI agent 记忆和上下文工程。

Mem0 是一个面向 LLM 和 AI agent 的智能开源记忆层，用于跨会话提供长期、个性化且能感知上下文的交互。

在这里获取免费 API 密钥：app.mem0.ai
或从我们的开源 GitHub 仓库自行部署 mem0