「写在前面」如果你做过 RAG，大概率遇到过这样一个问题：同一批文档，系统回答第 10 个问题时，并不比回答第 1 个问题时更聪明。每次查询都从原始分块重新推导一遍，前 9 次积累的理解，没有沉淀下来。
近一年中，几个团队从不同方向给出了相似的答案——不要在查询时重新推导，而要在资料导入时完成编译。这套模式被称为 Agent Wiki。Mem0 技术博客《The State of Agent Wikis》里，梳理了 Agent Wiki 的架构与运作方式、四个代表性系统的工程实现，以及它的适用边界。接下来我们就一起来看看：
2026 年 4 月 4 日，Andrej Karpathy 发布的 Gist llm-wiki（gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#file-llm-wiki-md）把它讲得最清楚，也让它真正传播开来。不过 Cognition 的 DeepWiki 在 2025 年 5 月就已公开，比 Gist 早约 11 个月；而 GBrain 也与 Gist 基本同期出现；AutoWiki 和 OpenWiki 则分别发布于 2026 年 6 月和 7 月。
多个团队从不同场景出发，先后收敛到了相似的结构。这种跨场景的一致性就是一个值得注意的工程信号。
给模型接入大量文档，常规检索做法是
文档入库 → 切分成块 → 生成 Embedding → 写入向量索引
每次提问时，系统再召回相关分块，交给模型生成答案。
这个方案能用，但有一个结构性问题：它不保留结果。每个答案都是从原始分块现场重建的，第 10 个答案不会比第 1 个更好，同样的理解工作要重复支付 10 次成本。
Agent Wiki 把这笔成本挪到了前面。模型在读取源文档时把工作做完一次，把结果写成页面，页面持久保留。新的源文档进入系统时，模型执行的是一套增量操作：读取新资料、更新相关页面、修正受影响的摘要，并标记与既有页面相互矛盾的信息。
两种方案都成立，差别在两点：成本发生在什么时候，以及一次查询结束后留下了什么。
四个系统的架构可以抽象成同一个三层模型：
第一层是源文档——文章、论文、代码仓库。模型只读，不修改。
第二层是 Wiki，内容采用 Markdown 格式，全部由模型写入，包含摘要、按主题组织的页面，以及页面之间的链接。
第三层是维护指令或配置，用于告诉模型 Wiki 如何组织、生成和更新。具体载体因项目而异，可能是 CLAUDE.md、AGENTS.md，也可能是项目专用配置文件或工作流。
Ingest：模型读取新的源文档，把信息分发到所有相关页面。
Query：向 Wiki 提问。一个好的回答可以作为新页面反写回 Wiki。
Lint：模型检查整个 Wiki，找出互相矛盾的信息、已经过时的内容，以及没有任何链接指向的孤立页面。Lint 这一步容易被忽略，但它恰恰是这套方案能长期成立的关键——原因见下一节。
人类维护的 Wiki 会随时间腐化，原因很具体：难的从来不是读文献，也不是产生洞见，而是维护。
维护意味着这些持续性的工作：修正页面之间的链接、让摘要与最新事实保持一致、把每一份新文档与已有页面逐一比对。这类工作没有尽头，也不产生任何即时回报。团队一忙，最先被放弃的就是它。接着 Wiki 开始失准，然后没人再用它。
模型做这件事没有同样的障碍：它不会厌倦，不会因为琐碎而跳过某条交叉引用，也可以在一次操作里改动 15 个文件。
这个思路本身并不新鲜。早在 1945 年，Vannevar Bush 就曾描述过 Memex——一个带有关联链接的个人文档库。Bush 当年没能解决的正是维护问题，而模型补上了这一环。
其实， Karpathy 的 Gist 原文值得一读，它比大多数转述总结都准确。
Karpathy 对常规做法的判断是：模型在每个问题上都在从零重新发现知识，没有任何积累。他给出的替代方案是编译而非检索——知识编译一次，此后持续保持更新，而不是每次查询时重新推导，最终得到一个持久的、能不断累积的产物。
他也明确了人的位置：你几乎从不亲手写这个 Wiki，模型写它，也维护它。他给出的那个类比很精准：Obsidian 是 IDE，模型是程序员，Wiki 是代码库。
这里有一个被大量转述总结漏掉的关键限制：规模。 Gist 明确写了，靠索引文件 index.md 定位页面的做法在中等规模下效果不错——约 100 份源文档、数百个页面——并且能省掉一整套基于 Embedding 的 RAG 基础设施。超出这个量级，Gist 建议加上搜索，并给出了 QMD 作为示例。QMD 是一个面向 Markdown 的本地搜索引擎，采用 BM25 与向量混合检索，再加上模型重排序。
所以这条规则是关于规模的，不是关于替代的。需要注意的是，触及天花板的是「用一个扁平索引定位页面」这套导航方式，而不是「编译成 Wiki」这个模式本身——源文档集较小时，不必上检索基础设施；变大之后，在 Wiki 之上补一层搜索即可。
模式讲完了，现在来看看有意思的地方——各家在工程上的取舍差异。
DeepWiki：把 Wiki 做成公共设施
Cognition 把这套方法应用到了 GitHub 上的公开仓库：把 URL 里的 github.com 换成 deepwiki.com，就能得到这个代码库的 Wiki，包含架构摘要、文件索引、依赖图和搜索，并且链接回源码。上线时已覆盖 5 万多个主流公开仓库，其中包括 MCP 和 LangChain。
但更值得注意的是第二点：Wiki 本身不是产品，它是给 Agent 使用的检索基础设施。 Devin 依靠它在代码库中定位相关代码。也就是说，DeepWiki 是 Devin 代码搜索能力底下那层被预先编译好的结构。
Factory 的切入点是持续集成。他们的主张很明确：文档应该是一个构建产物，而不是一个独立项目——文档从源码生成，结构与代码库对齐，代码库变了，它就跟着变。
生成过程分两遍。第一遍是结构扫描，读取 README、包清单、CI 配置和入口文件；第二遍是语义扫描，读取路由、API 端点、服务类、数据库 Schema 和特性开关。
工作被拆给多个专职 Agent，每个 Agent 负责代码库的一部分，并拿到足以写好这一部分页面的上下文。这个设计是为了规避这个问题：单个 Agent 面对大型代码库时，写出来的文档质量会明显下降。
保持更新依靠的是基础设施，而不是自觉。/wiki 命令重新生成 Wiki，/install-wiki 命令写入一个 CI 工作流，让每次推送到默认分支时自动重建。对 GitHub 仓库，产物直接进入仓库的 Wiki 标签页。
LangChain 开源了 OpenWiki，一个为代码库生成和维护 Agent 文档的 CLI 工具。随后推出的 OpenWiki Brains 提供两种模式：Code Brain 面向代码仓库，Personal Brain 面向个人的各类信息源。
Personal Brain 是真正的变化所在。 它从 Gmail、Notion、Git 仓库、X、Hacker News 和网页搜索拉取数据，全部写进一个本地 Markdown Wiki，供 Agent 读取。至此，这套方法从「为代码库写文档」扩展成了「为你的工作写文档」。
这里还有一个四家共同的设计决策值得单独点出：输出首先按照模型的读取需求组织，同时保持对人可读。 这些结构化 Markdown 页面带有层级标题、页面间链接和摘要，目的是让 Agent 快速定位相关信息。模型是 Wiki 的主要读者之一，但不是唯一读者。
GBrain 面向的是个人知识库，而不是代码库。它以 Markdown 为主要载体，包含 Schema 文件，也会构建主题之间的链接图谱。
GBrain 默认采用嵌入式 PGLite，无需单独部署数据库服务或 Docker；它支持全文检索、向量检索和知识图谱，Embedding 默认启用，也可在初始化时关闭。其轻量化体现在无需额外部署基础设施，而不是完全不使用数据库或检索系统。文件仍然可以由人直接阅读。
四个系统的结构高度一致：以 Markdown 作为知识载体，包含 Schema 文件，在资料导入阶段编译知识，在源文档发生变化时重新生成，并按照 Agent 的读取需求组织页面。四个团队面对不同的问题，最后采用了相似的结构。这种跨场景的一致性是一项值得关注的工程信号，但还不能单独证明它们完全独立地得出了同一结论。
它们真正的分歧在维护方式：它们真正的分歧在维护方式。Factory 将更新直接接入 CI；OpenWiki 也支持 GitHub Action 和本地定时任务；GBrain 提供定时同步机制。不同系统的差异，主要在于更新如何被触发，以及是否与源资料变化可靠绑定。这意味着后者的 Wiki 只能保持到「上一次命令执行时」的状态。
规模。 Karpathy 给出的经验值是约 100 份源文档。再多就需要引入搜索，并且建议将 BM25 与向量检索结合使用。
精度。 信息是在资料导入阶段被压缩的，早期摘要一旦丢掉某个细节，之后所有基于它的回答都可能延续这个错误。直接检索原始分块不会以同样的方式固化摘要错误，但仍可能出现漏检、误召回或跨文档关系缺失。这里真正的交换，是用更低的重复推导成本，换取信息在编译过程中丢失或失真的风险。
时效。 页面的准确度只到上次更新为止。这也是 Factory 那套做法的价值所在：一个失准的 Wiki 比没有 Wiki 更糟，因为错误的信息穿着正确信息的外衣。
成本。 生成页面需要消耗 Token，你可能生成了一批从未被读取的页面；Lint 没有发生变化的页面，同样需要消耗 Token。
最后是术语上的区分。这个领域的术语还没有精确下来，「记忆」正在被用于表达两种不同含义。
第一种含义是对某个文档集的知识。 Wiki 做的是这件事：它把文档、代码库或邮箱里的内容编译成结构化知识，告诉你这些文档里有什么。
第二种含义是关于某个用户的记忆。 这是完全不同的一类数据：一个人的偏好、他做过的决策、团队否决过的方案，以及 Agent 在其他场景里尝试某种方法之后得到的结果。
这类数据的结构也不同——它绑定的是人，而不是文档集；它来自持续交互，而不是资料导入。系统还必须为每个用户修正相互矛盾的信息、淘汰过期内容、保留每条信息的来源，并在用户要求时删除数据。
Wiki 能出色地完成第一件事，但完成不了第二件。你的邮箱 Wiki 能告诉 Agent 邮箱里有什么，但它不会知道你周二在一次对话里改了主意，也不会知道某个方案在你的场景中已经失败过。
这正是记忆层要解决的问题，Mem0 是其中一个方案：每条记忆绑定 user_id，因而能跟随用户跨越不同会话、应用和 Agent；事实变化时更新原有记录，而不是不断追加新记录。
需要强调的是，两者不是二选一的关系，而应该同时使用。真正的误区是以为有了 Wiki 就等于有了用户记忆。
Agent Wiki 的核心判断是成立的：知识编译一次，然后持续更新，不要为每个问题重新构建一遍。压垮人类 Wiki 的是维护成本，而模型更适合承担这类持续、重复的工作，并能显著降低人工维护成本。
落到实践上有三条：
当文档集相对稳定，而且会被反复查询时，把文档编译成页面；
当文档集变大时，按照 Gist 的建议把检索加回来；
始终区分「对文档集的知识」和「对用户的记忆」——Wiki 提供前者，不提供后者。
关于本文： 本文编译、译校自 Mem0 技术博客《The State of Agent Wikis》，核心框架与技术梳理均来自原文。
核查与修正： 其一，原文称四个项目均在 Karpathy 的 Gist 之后出现。经核查，DeepWiki 至少在 2025 年 5 月已经公开发布，比 Gist 早约 11 个月；GBrain 与 Gist 基本同期。我们据此重写了时间线，并调整为「多个团队在不同时间、从不同场景出发，最终收敛到相似结构」的表述。
其二，原文称 GBrain「没有向量数据库、没有服务」。实际上，GBrain 默认采用嵌入式 PGLite，支持全文检索、向量检索和知识图谱，且默认启用 Embedding。我们将其修正为「无需单独部署数据库服务或 Docker」，以保留原文关于轻量化的判断。
其三，原文将 Gist 中「约 100 份源文档」的规模上限归于整套方案，经比对 Gist 原文，该上限针对的是以 index.md 定位页面的导航方式，我们据此还原。此外，我们对原文中若干过于绝对的表述做了精确化处理——例如「Wiki 的读者是模型」「直接检索原始分块没有这个问题」——以避免与文中其他论述相互冲突。
粤ICP备14082021号
免费POC，
零成本试错
