Agent Wiki：把语料知识编译成可维护上下文

推荐这篇文章，Mem0 团队对 Agent Wiki 这个新兴品类做了一次全景综述。今年 4 月 Karpathy 在一个 Gist 里提出 LLM Wiki 模式之后，Cognition、Factory、LangChain、Garry Tan 四家各自独立实现了同一套架构。文章最值得读的是最后一部分——把 Wiki（语料知识）和 Memory（用户记忆）做了一次清晰切割：wiki 告诉你语料里有什么，memory 告诉你这个人是谁、做过什么决定。 !Article cover https://t.co/i1JubsHz6N 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，查询时取出相关 chunk 然后回答。这能用，但有一个结构性的缺陷：什么都不会积累。每个问题都从原始 chunk 开始，模型一遍又一遍地重新推导出同样的理解，关于一个代码库的第十个问题并不比第一个更便宜或者更深入。 LLM Wiki 颠倒了"合成"发生的时刻。不是在查询时从原始碎片拼出知识，而是由一个 LLM 在写入时一次性把知识组装成持久的页面，然后维护它们。当有新源材料到达，模型读取它，更新受影响的实体页面，修订摘要，把与已有内容的矛盾标出来。 RAG 在每次提问时重新推导知识。Wiki 推导一次然后保持最新。两者都是合理的做法；区别在于你在什么时候支付合成成本，以及结果是否存活下来。 架构：始终是三层 原始来源是不可变的：文章、论文、仓库、数据。模型读取它们，永远不编辑它们。 Wiki 是 LLM 生成的 markdown，模型完全拥有：摘要、实体页面、概念页面、交叉引用。 Schema 是一个配置文件（CLAUDE.md、AGENTS.md 或类似的东西），告诉模型 wiki 怎么组织、跑什么工作流。这才是让它成为一个有纪律的维护者、而不是一个带文件访问权限的聊天机器人的东西。 三条操作运行在上面：写入一个来源，把它归档到它影响的所有页面；查询 wiki（以及可选地把好的回答归档成新页面，这样探索也会积累）；扫描，一次周期性遍历，寻找矛盾、过时的声明和孤儿页面。 它为什么管用：瓶颈从来不是写作 人类 wiki 会腐烂，原因很具体。最难的部分从来不是读源材料或拥有洞察。最难的是记录管理：更新交叉引用、保持摘要最新、把一份新文档和四十个已有页面对齐。这项工作是无限的、不体面的，也是繁忙团队最先放掉的事。于是 wiki 衰减，人们不再信任它，它就死了。 这恰恰是语言模型不介意的工作。它不会无聊、不会忘记更新一条交叉引用、可以一次触及十五个文件。LLM Wiki 之所以能运转，是因为它消除了维护成本——就是这项成本杀死了之前所有的 wiki。 这个想法比工具古老得多。Vannevar Bush 在 1945 年描述了 Memex：一个经过筛选的个人文档存储，文档之间有联想路径。Bush 没有解决的问题是：谁来维护这些路径。八十年后的答案是：模型。 这个名字从哪里来 Karpathy 的 Gist 值得直接读一下，因为它比大多数摘要更精确。他对于普通文档工作流的抱怨是："LLM 在每个问题上都从零开始重新发现知识。没有积累。"他的替代方案是编译而不是检索，这样"知识被编译一次然后保持当前，而不是在每次查询时重新推导"，产出的东西他称之为"一个持久的、会积累的造物"。 关键的是，你不需要写它。"你永远不（或很少）自己写 wiki，LLM 编写和维护它全部。"他自己的设置是一边是 agent，另一边是 Obsidian，看着页面实时更新："Obsidian 是 IDE；LLM 是程序员；wiki 是代码库。" 这个 Gist 在规模问题上也很具体，这是最值得传承的细节。不使用 embedding 的、以索引为先的方法"在中等规模下效果出奇地好（约 100 份源材料，约几百个页面），避免了基于 embedding 的 RAG 基础设施的需要。"超过这个规模，他建议添加搜索，特别是 qmd，描述为"一个针对 markdown 文件的本地搜索引擎，带有混合 BM25/向量搜索和 LLM 重排序。" 这读起来更像一个范围规则，而不是对检索的替代。在语料很小的时候跳过检索基础设施，等它变大再加回来。编译时合成和查询时合成坐落在一条光谱上，你最终落在哪里主要取决于你有多少材料。 工程问题是：这个模式在超越个人规模之后长什么样——过去几个月回答的就是这个问题。 实验室们真正构建了什么 这里开始，模式不再是一个想法，而是工程。各实现之间的差异才是最有用的部分。 Cognition：DeepWiki，作为公共基础设施的 wiki Cognition 把这个模式指向了 GitHub 上的每一个公开仓库。在任何公开仓库的 URL 里把 https://t.co/3xHlU1nQfD 换成 https://t.co/4TUmh9gCPF，你就得到了一个生成的、可导航的代码库 wiki：架构概览、文件索引、依赖图和搜索，带回到源代码的链接。 两件事值得注意。规模是真实的：超过 5 万个顶级公开仓库已经被索引了，从 MCP 到 LangChain。而且 wiki 不是产品的终点——它是 agent 的检索基础设施。Devin 用 wiki 来在代码库中定位相关上下文，所以 DeepWiki 是让 Devin 的代码搜索更扎实的编译层。 Factory：AutoWiki，作为构建产物的文档 Factory 用 CI 的语言来框定同一个模式，他们的框定是这个品类里最锋利的一句话：文档应该是一个构建产物，而不是一个副项目。它从源代码构建，围绕代码库实际工作方式组织，在仓库变化时刷新。 生成方法是四家里工程化程度最明确的。AutoWiki 运行两轮分析：一轮对 README、包清单、CI 配置和入口点做结构性扫描，然后一轮对路由、API 端点、服务类、数据库 schema 和 feature flag 做更深的语义扫描。工作被拆分到专门的 agent 上，每个 agent 只负责仓库的一个方面，刚好有足够的上下文产出一页好的内容。这是对上下文问题的直接解决——单 agent 做文档生成在规模上平庸的原因就在这里。 时效性被当成基础设施而不是纪律来处理：/wiki 按需重新生成，/install-wiki 写一条 CI 工作流，在每次推送到默认分支时刷新 wiki。对 GitHub 仓库来说，它同步到仓库自己的 wiki tab 里。 LangChain：OpenWiki——从代码跃向一切 LangChain 开源了 OpenWiki，一个为代码库编写和维护 agent 文档的 CLI 工具，然后把它扩展为 OpenWiki Brains，有两种模式：Code Brain，原始的仓库用例；以及 Personal Brain，从你自己连接的数据源构建 wiki。 第二种模式是那个重要的跃迁。Personal Brain 从 Gmail、Notion、Git 仓库、X、Hacker News 和网页搜索读取数据，把它们合成为一个本地 markdown wiki，agent 去查询它。品类从"给我的仓库写文档"跳到了"编译我的整个工作生活"。 有一个设计细节值得注意，因为每个团队都汇聚到了这一点：输出不是面向人类的散文。它是面向 LLM 上下文优化的结构化 markdown，有标题、交叉引用和摘要，设计目标是让 agent 能快速找到相关上下文。wiki 是为真正会读它的那个读者写的，那个读者是一个模型。 GBrain：个人规模的、开源版本 Garry Tan 的 GBrain 把同样的形态应用到了个人知识库而不是代码库：Git 仓库里的 markdown、一个 schema 文件、一个自动维护的实体交叉链接图。它是模式"底层非常简单"的最清晰证明。不需要向量数据库、不需要服务，只是一个模型维护、人类能读的文件集合。 技术矩阵 按列往下读，收敛本身就是信号。四个团队、四种语料、一种架构：Git 里的 markdown、一个模型遵守的 schema 文件、在写入时合成、在变化时刷新、面向 agent 阅读而写的页面。当解决不同问题的独立团队落在同一个形态上时，这个形态通常是正确的。 差异在于时效性，这是成熟度的信号。Factory 把过时当成构建问题，在 CI 里解决。其他所有家都是按需刷新，这意味着它们的 wiki 的当前程度等于上一次有人记得运行命令的时间。 它的边界 这个模式确实好，所以需要诚实地说明它的局限。 规模。Karpathy 自己就说了：不用 embedding 的、以索引为先的方法是中等规模的技术，大约一百份源材料。超过几百页之后，你就回到了搜索引擎，这也是他自己的 Gist 推荐混合 BM25 和向量搜索的原因。 保真度。在写入时编译意味着，一个早期摘要可能悄悄丢失源材料中的某个细节，而后面的每一次回答都会继承这个丢失。针对原始 chunk 的检索没有这个失败模式。你是在用重新推导的成本换取压缩风险。 过期。一页编译过的内容只在最后一次刷新前是真的。这就是为什么 Factory 的 CI 框架比它最初看起来更重要：一个过时的 wiki 比没有 wiki 更糟，因为它用一种看起来权威的格式自信地犯错。 编译成本。你需要真金白银地付 token 来构建你可能永远不会查询的页面，并重新扫描那些什么也没变的页面。 Wiki 不是 Memory 有一点需要仔细画出来，因为这个领域的词汇表目前还很松散。 这些系统越来越被描述为 memory。LangChain 把 OpenWiki 称为 AI agent 的 wiki memory 层，围绕这个模式的普遍说法是"这就是你怎么给 agent memory"。这个词承载了太多分量，它盖住了两件相当不同的事。 一根术语下面有两条轴。 语料知识是 wiki 做的事：编译一组文档、或一个仓库、或你的 Gmail 归档说了什么。它回答的是"这份材料里包含什么"。 用户和体验记忆是另一条轴：一个具体的人偏好什么、他们上周做了什么决定、他们团队已经拒绝过哪种方案、一个 agent 昨天在另一个 app 里尝试了什么、结果如何。它按身份划定范围，不是按语料。它从交互中积累，不是从写入中积累。它需要处理矛盾、过期、来源追溯和按用户的删除。 wiki 在第一件事上极其出色，并且不试图做第二件事。把你的 Gmail 编译成页面，告诉 agent 你的 Gmail 里有什么。它不会告诉 agent 你在上周二的一次谈话里改了主意、关于那个供应商的决定，或者某种建议方案已经失败过一次了。 第二条轴是像 Mem0 这样的专用 memory 层要做的事：memory 标记到 user_id，跨会话、跨 app、跨 agent 跟随一个人，当事实变化时原地更新，而不是永远追加。这两者是互补的。错误不在于选择了 wiki。错误在于认为因为你编译了一份语料，你就解决了 memory 问题。 收获 LLM Wiki 是一个真实的模式，背后有一个真实的洞见：知识应该被编译一次然后维护，而不是在每次提问时重新推导。而杀死人类 wiki 的维护工作，恰恰是模型免费完成的劳动。四个团队在几个月里交付了同一套架构，这是它正确的最强证据。 从这里带走三件事。当语料稳定且被反复阅读时，把你的文档编译成维护中的页面。当它超越个人规模时，添加真正的检索——原始提案也这样建议。以及，保持"编译语料"和"记住用户"的区别，因为 wiki 给你第一件，给不了第二件。那已经很值了，但那不是同一件事。 https://t.co/iZatEoDhq7 #AgentWiki #上下文工程 #AgentMemory

https://t.co/cBO8YIxQLh