mem0(@mem0ai)

https://t.co/cBO8YIxQLh

8.5内容质量
https://t.co/cBO8YIxQLh

TL;DR · AI 摘要

Agent Wikis通过预处理生成知识库降低查询成本，四家团队实现相同架构但各有差异，系统分三层结构并包含摄入/查询/检查三类操作。

核心要点

  • Agent Wikis将文档处理成本从查询时转移到摄入时，减少重复计算
  • 系统分三层：源文档-维基-模式文件，模式文件定义知识库结构
  • 四家团队实现相同核心机制但各有差异化功能（DeepWiki/AutoWiki/OpenWiki/GBrain）

结构提纲

按章节快速跳转。

  1. §引言

    Andrej Karpathy的LLM Wiki概念引发四家团队实现相同架构。

  2. ·核心机制

    系统通过预处理生成维基页面，查询时直接使用预处理结果。

  3. ›系统架构

    三层结构包含源文档、维基页面和定义知识库结构的模式文件。

  4. ·操作流程

    系统包含摄入、查询和检查三种核心操作类型。

  5. ›实现差异

    四家团队在相同架构基础上开发了不同功能的实现方案。

  6. ·方法对比

    与传统检索方法相比，Agent Wikis减少重复计算成本。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • Agent Wikis架构
    • 核心机制
      • 摄入时处理文档
    • 系统架构
      • 源文档层
      • 维基层（markdown）
      • 模式文件层
    • 操作类型
      • 摄入
      • 查询
      • 检查

金句 / Highlights

值得收藏与分享的关键句。

#LLM#Agent Wikis#知识库系统#信息检索
打开原文

mem0 on X: "https://t.co/cBO8YIxQLh" / X

[](https://x.com/)

*

Image 3: Article cover image
Image 3: Article cover image

代理维基的现状

2026年4月，Andrej Karpathy发布了一个GitHub Gist。他在其中描述了一种方法，称之为LLM维基。

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

这四个系统的实现方式相同。LLM会一次性读取源文档，将信息写入Markdown页面。当源文档变更时，系统会保持页面内容的准确性。代理会读取这些页面，而不会为每个问题重新读取源文档。

人们将这些系统称为代理维基。本文将解释它们的原理，说明各团队的实现方案，分析方法的局限性，并指出一个常被忽视的重要差异。

**核心思想：在数据摄入时编译，而非查询时处理**

通常向模型提供大量文档的方法是检索。将文档存入数据库，拆分文档内容，为各部分内容生成嵌入向量。每次提问时，系统会查找相关部分并生成答案。

这种方法虽然有效，但存在缺陷。系统不会保存处理结果，每次回答都需要重新处理原始数据。回答第十次时，效果与第一次并无提升，相当于重复支付了十次处理成本。

代理维基将这种成本转移了。模型在首次读取源文档时完成处理，将结果写入页面。这些页面会持续保留。

当新源文档到来时，模型会执行以下操作：读取源文档，更新相关页面，修正摘要，标记与现有页面冲突的信息。

两种方法都正确，但存在两个关键差异。第一个差异在于成本支付时机，第二个差异在于问题解决后保留的内容。

每个系统都包含相同的三层结构。

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

第二层是维基，采用Markdown格式。模型会生成所有维基内容，包括摘要、主题页面和页面间的链接。

第三层是模式文件。该文件定义维基的结构，告诉模型需要执行的任务。常规文件格式为CLAUDE.md或AGENTS.md。这个文件使模型能够正确维护维基内容。

系统执行三种操作：

数据摄入：模型读取新源文档，然后将数据写入相关页面。

查询：你向维基提问，可以将优质答案作为新页面写入维基。

校验：模型检查维基内容，发现冲突信息、过时信息以及无链接的页面。

维护工作包含以下任务。你必须修正页面之间的链接。必须确保摘要内容准确。必须将每个新文档与现有页面进行比对。

这项工作不会停止。这项工作不会带来回报。忙碌的团队会优先停止这项工作。随后维基内容变得不准确。最终人们不再使用它。

模型可以无差错地完成这项工作。模型不会感到厌倦。模型不会遗漏任何链接。模型可以在一次操作中修改十五个文件。

这个想法并不新。1945年，范内瓦·布什（Vannevar Bush）曾描述过Memex系统。Memex是一个带有文档链接的个人文档存储系统。布什没有提出维护方案。模型就是答案。

名称的由来

直接阅读Karpathy的gist内容。它比任何摘要都更准确。

他这样描述常规方法："LLM在每次提问时都从零开始重新发现知识。没有知识积累。"

他的方法是编译信息而非检索信息。这样"知识只需编译一次并保持更新，而不是每次查询都重新推导"。结果是"一个持久且复合的产物"。

你不会编写维基。他写道："你几乎从不（或很少）自己编写维基，LLM会编写并维护所有内容。"他将代理与Obsidian结合使用。他写道："Obsidian是IDE；LLM是程序员；维基是代码库。"

gist中给出了规模限制。许多摘要没有包含这个限制。无嵌入的方法"在中等规模（约100个来源，数百页）上出人意料地有效，并避免了基于嵌入的RAG基础设施需求。"

对于更多来源，gist建议添加搜索。它以qmd作为示例。gist将qmd描述为"一个支持混合BM25/向量搜索和LLM重排序的本地Markdown文件搜索引擎。"

因此规则与规模有关。规则不是关于替代。当数据源集较小时，不要使用检索基础设施。当数据源集变大时，添加检索。

**实验室实际构建的内容**

这是模式从理念转变为工程实践的起点，而不同实现之间的差异才是有价值的部分。

认知：DeepWiki，作为公共基础设施的维基

认知将该方法应用于GitHub上的公共仓库。将公共仓库URL中的github.com替换为deepwiki.com，即可获得该代码库的维基。维基包含架构摘要、文件索引、依赖关系图和搜索功能。维基包含指向源代码的链接（认知）。

超过50,000个最大的公共仓库都拥有维基。列表包含MCP和LangChain。

第二点更为重要。维基不是产品。维基是代理的检索基础设施。Devin使用维基来查找代码库中的相关代码。因此DeepWiki是Devin（Devin Docs）中代码搜索下方的编译层。

工厂：AutoWiki，文档作为构建产物

工厂将该方法应用于持续集成。工厂指出文档必须是构建产物，而不是独立项目。文档来自源代码。它具有代码库的结构。当仓库变更时，文档也会变更（工厂）。

构建维基的方法分为两个阶段。第一阶段是结构扫描，它会读取README文件、包清单、CI配置和入口点。第二阶段是语义扫描，它会读取路由、API端点、服务类、数据库模式和功能标志。

Factory将工作分配给专业代理。每个代理负责仓库的一部分，每个代理都能获得足够的上下文来编写一篇优质页面。这种方法解决了已知的问题：单个代理为大型仓库编写文档时效果较差。

Factory通过基础设施而非纪律来保持维基的正确性。/wiki命令会重新生成维基。/install-wiki命令会编写CI工作流。该工作流会在每次推送到默认分支时重新生成维基。对于GitHub，维基会显示在仓库的Wiki标签页中（Factory Docs）。

LangChain：OpenWiki，以及从代码到一切的飞跃

LangChain将OpenWiki作为开源软件发布。OpenWiki是一个CLI工具，用于编写和维护代码库的代理文档。随后，LangChain发布了OpenWiki Brains，该工具包含两种模式。Code Brain是第一种模式，用于仓库；Personal Brain是第二种模式，用于您自己的资料（LangChain）。

Personal Brain是重要的变革。它从Gmail、Notion、git仓库、X、Hacker News和网络搜索中读取数据，并将所有数据写入本地的Markdown维基。代理会读取这个维基。方法从仓库文档转变为工作文档。

每个团队都对输出做出了相同的决定。输出不是给人阅读的文本，而是用于LLM上下文的结构化Markdown。它包含标题、页面间的链接和摘要。这种结构使代理能够快速找到相关信息。维基的读者是模型。

GBrain：个人规模的开源版本

GBrain将该方法应用于个人知识库，而非代码库。GBrain在git仓库中使用Markdown，它包含一个模式文件，可以自动创建主题间的链接图谱。

GBrain表明该方法只需要极少的基础设施。它没有向量数据库，没有服务，只有文件。模型维护这些文件，人可以阅读这些文件。

**技术矩阵**

这四个系统具有相同的结构。它们都在git中使用Markdown，使用模式文件，在摄入时进行编译，当源内容变化时重新生成维基，为代理编写可读页面。四个团队解决了四个不同的问题，却采用了相同的结构。这种共识是结构正确的有力证据。

这些系统在维护方式上存在差异。Factory在CI中进行维护，其他三个系统在用户运行命令时进行维护。因此，它们的维基正确性仅取决于最后一次命令的执行结果。

**局限性**

限制1是规模。Karpathy设定了这个限制。没有嵌入的方法适用于大约100个来源。对于更多页面，必须添加搜索引擎。要点提示你应结合BM25搜索和向量搜索。

限制2是准确性。模型在摄入时编译信息。早期摘要可能从源中删除细节。每个后续回答都会出现这个错误。从原始部分检索不会出现这个问题。你用重复工作的成本换取数据丢失的风险。

限制3是过时的信息。页面的准确性取决于最后一次更新。这就是为什么工厂方法如此重要的原因。一个错误的维基百科比没有维基百科更糟糕。错误信息的格式与正确信息相同。

限制4是成本问题。创建页面需要消耗令牌。你可以创建无人阅读的页面。你还需要为未更改的页面的语法检查支付令牌费用。

**维基百科不是记忆**

你必须了解一个关键区别。这个领域的术语尚未精确。

许多人将这些系统称为“记忆”。LangChain 将 OpenWiki 称为 AI 代理的“维基记忆层”。其他人则认为维基百科为代理提供了记忆。这里的“记忆”一词有两种不同的含义。

第一种含义是对文档集合的知识。维基百科确实能实现这一点。它会整理你文档、仓库或 Gmail 中的数据，并告诉你文档包含哪些内容。

第二种含义是用户的记忆。这是完全不同的数据。它包括个人的偏好、个人的决策、团队拒绝的方法，以及代理在不同应用中尝试方法时的结果。

用户记忆具有不同的结构。它与个人相关，而非文档集合。它来源于交互，而非数据摄入。它还必须为每个用户执行以下任务：修正矛盾信息、删除过时信息、保留每项数据的来源，并根据请求删除数据。

维基百科能正确完成第一项任务，但无法完成第二项任务。你的 Gmail 维基百科会告诉代理你的 Gmail 中有什么内容，但它不会告诉代理你在周二的对话中改变了某个决定，也不会告诉代理某种方法对你来说已经失败过。

记忆层能完成第二项任务。Mem0 就是这样一个例子。它为每个用户记忆分配一个 user_id。因此，记忆会随着用户在会话、应用和代理之间移动。当事实发生变化时，记忆层会更新事实的位置，而不是每次添加新记录。

这两个系统并非替代关系。应该同时使用两者。错误不在于使用维基百科，而在于认为维基百科能提供用户记忆。

**总结**

代理维基百科的理念是正确的。一次性整理知识，然后保持其准确性。不要为每个问题重新构建。人工维基百科的维护工作已经停止，而模型可以零成本完成维护。四支团队在几个月内构建了相同的结构，这是强有力的证据。

请做到以下三点：当文档集合稳定且你频繁查阅时，将文档编译成页面；当文档集合变得庞大时，按照摘要提示添加检索功能；区分文档集合的知识与用户记忆。维基百科能提供前者，但无法提供后者。

上下文 #17

_本文是 In Context 系列博客的一部分，由__@mem0ai__撰写，涵盖 AI 代理记忆与上下文工程。_

_Mem0 是专为 LLM 和 AI 代理设计的智能开源记忆层，旨在提供跨会话的长期、个性化和上下文感知的交互。_

**参考文献**

下午3:11 · 2026年7月21日239.2K 次浏览

20

113

973

2.3K

阅读更多17条回复