文章总结： 本文解析智能体Wiki的编译式架构及四家团队的实现。该方法在摄取时一次性编译知识以避免RAG重复检索，但存在百个来源的规模瓶颈与准确性风险。核心要点是须区分文档知识与用户记忆，Wiki无法记录用户偏好。建议小文档集用Wiki，规模扩大后加检索，并用专门记忆层处理个性化数据。 综合评分： 80 文章分类： 软文广告,产品介绍

来自 mem0 的深度研究： Agent Wiki 的现状

mem0 mem0

ThinkInAI社区

2026年7月23日 12:14 北京

在小说阅读器读本章

去阅读

原文：https://x.com/mem0ai/status/2079585032587694582

2026 年 4 月，Andrej Karpathy 写了一篇 GitHub Gist。他在里面描述了一种方法。他把这种方法称为 LLM Wiki。

之后有四个团队做出了同样的东西。Cognition 做了 DeepWiki。Factory 做了 AutoWiki。LangChain 发布了 OpenWiki。Garry Tan 发布了 GBrain。

这四个系统采用的方法是一样的。一个大语言模型一次性读取你的源文档。它把信息写入 Markdown 页面。当源文档发生变化时，它会让这些页面保持正确。智能体读取这些页面。智能体不会为了每个问题再次读取源文档。

人们把这些系统称为智能体 Wiki。本文会介绍它们是什么。会介绍每个团队做了什么。会介绍这种方法的局限。还会介绍一个很多人忽略的重要区别。

⬆️关注 ThinkInAI 星科社区，最及时最干货的AI内容分享

核心想法：在摄取时编译，而不是在查询时编译

让模型处理大量文档的常见方法是检索。你把文档放进数据库。你把文档分成多个片段。你为这些片段生成嵌入。对于每个问题，系统会找到相关片段。

这种方法可行。但它也有一个问题：系统不会保留结果。它每次都从原始部分重新构建答案。第十次回答并不会比第一次回答更好。你相当于把同样的工作成本支付了十次。

智能体 wiki 转移了这种成本。模型在读取来源时只做一次工作。它把结果写入页面。页面会保留下来。

当有新的来源进入时，模型会执行这些步骤。它读取来源。它修改相关页面。它修正摘要。它标记出与页面内容不一致的信息。

两种方法都是正确的。它们在两个方面不同。第一个差异是你在什么时候支付成本。第二个差异是提问之后会留下什么。

每个系统都有相同的三层。

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

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

第三层是模式文件。这个文件告诉模型 wiki 的结构。它还告诉模型要执行哪些任务。常见的文件是 CLAUDE.md 或 AGENTS.md。这个文件让模型成为 wiki 的合格维护者。

系统会执行三种操作。

摄取：模型读取一个新的来源。然后模型把数据写入每个相关页面。

查询：你向 wiki 提问。你可以把一个好的答案作为新页面写回 wiki。

检查：模型检查 wiki。它会找出相互矛盾的信息。它会找出过时的信息。它会找出没有链接的页面。

它为什么有效：

人类维护的 wiki 会随着时间变得不准确。原因很具体。难点不在于阅读来源。难点也不在于产生想法。难点在于维护。

维护包含这些任务。你必须修正页面之间的链接。你必须保持摘要准确。你必须把每份新文档与已有页面进行比较。

这项工作不会停止。这项工作没有回报。忙碌的团队最先停止的就是这项工作。然后 wiki 就会变得不准确。然后人们就不再使用它。

模型做这项工作没有问题。模型不会感到无聊。模型不会忘记一个链接。模型可以在一次操作中修改十五个文件。

这个想法很早就有了。Vannevar Bush 在 1945 年描述过 Memex。Memex 是一个带有文档间链接的个人文档存储系统。Bush 没有给出维护问题的答案。模型就是答案。

这个名字从何而来

直接阅读 Karpathy 的 gist。它比那些摘要更准确。

他这样描述通常的方法：“大语言模型在每个问题上都从零开始重新发现知识。没有积累。”

他的方法是编译信息，而不是检索信息。然后“知识被编译一次，并保持更新，而不是在每次查询时重新推导。”结果是“一个持久的、可复利增长的产物。”

不是你来写 wiki。他写道：“你从不（或很少）亲自写 wiki，wiki 全部由大语言模型编写和维护。”他把智能体和 Obsidian 结合使用。他写道：“Obsidian 是 IDE；大语言模型是程序员；wiki 是代码库。”

这个 gist 给出了规模限制。许多摘要没有包含这个限制。没有 embeddings 的方法“在中等规模（约 100 个来源、数百个页面）下效果出奇地好，并且避免了对基于 embedding 的 RAG 基础设施的需求。”

对于更多来源，gist 告诉你加入搜索。它给出的例子是 qmd。gist 将 qmd 描述为“一个面向 markdown 文件的本地搜索引擎，使用混合 BM25/向量搜索和大语言模型重排序。”

因此，规则关乎规模。规则不是关于替代。当来源集合较小时，不要使用检索基础设施。当来源集合变大时，再加入检索。

这些实验室实际构建了什么

在这里，这个模式不再只是一个想法，而变成了工程实践；不同实现之间的差异才是有用之处。

Cognition：DeepWiki，把 wiki 作为公共工具

Cognition 将这种方法应用到了 GitHub 上的公开仓库。把公开仓库 URL 中的 github.com 替换为 deepwiki.com。然后你就会得到该代码库的 wiki。这个 wiki 有架构摘要、文件索引、依赖图和搜索。wiki 中有指向源代码的链接（Cognition）。

超过 50,000 个最大的公开仓库已经有了 wiki。名单中包括 MCP 和 LangChain。

第二点更重要。wiki 不是产品。wiki 是智能体的检索基础设施。Devin 使用 wiki 来在代码库中找到相关代码。因此，DeepWiki 是 Devin 中代码搜索之下的编译层（Devin Docs）。

Factory：AutoWiki，把文档作为构建产物

Factory 将这种方法应用到了持续集成中。Factory 写道，文档必须是构建产物，而不是一个单独的项目。文档来自源代码。它具有代码库的结构。它会在仓库变化时发生变化（Factory）。

制作 wiki 的方法分为两轮。第一轮是结构扫描。它会读取 README 文件、包清单、CI 配置和入口点。第二轮是语义扫描。它会读取路由、API 端点、服务类、数据库 schema 和功能开关。

Factory 将工作分配给专门的智能体。每个智能体负责仓库的一部分。每个智能体都会获得足够的上下文，以写出一页高质量内容。这种方法避免了一个已知问题：让单个智能体独自为大型仓库编写文档，效果很差。

Factory 不是靠纪律，而是靠基础设施来保持 wiki 的正确性。/wiki 命令会重新生成 wiki。/install-wiki 命令会写入一个 CI 工作流。这个工作流会在每次推送到默认分支时重新生成 wiki。对于 GitHub，wiki 会进入仓库的 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 wiki。智能体会读取这个 wiki。方法已经从记录一个仓库，转变为记录你的工作。

每个团队都对输出做出了相同决定。输出不是给人阅读的文本。输出是用于大语言模型上下文的结构化 markdown。它有标题、页面之间的链接和摘要。这种结构让智能体能够快速找到相关信息。wiki 的读者是模型。

GBrain：个人规模的开源版本

GBrain 将这种方法应用于个人知识库，而不是代码库。GBrain 使用 git 仓库中的 markdown。它有一个 schema 文件。它会自动生成主题之间的链接图谱。

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

技术矩阵

这四个系统有相同的结构。它们在 git 中使用 markdown。它们使用一个 schema 文件。它们在摄取时编译。它们在源内容变化时重新生成 wiki。它们把页面写成供智能体阅读的形式。四个团队解决了四个不同的问题，却做出了相同的结构。这种一致性有力地说明，这个结构是正确的。

这些系统在维护方式上有所不同。Factory 在 CI 中进行维护。其他三个系统则是在有人运行命令时进行维护。因此，它们的 wiki 是否正确，只取决于上一次命令运行时的状态。

它在哪里停止

限制 1 是规模。Karpathy 提出了这个限制。不使用嵌入的方法，在大约 100 个源以内是正确的。页面更多时，就必须加入搜索引擎。那篇 gist 建议你同时使用 BM25 搜索和向量搜索。

限制 2 是准确性。模型在摄取时编译信息。早期的摘要可能会从源内容中删掉某个细节。之后的每一次回答都会带着这个错误。从原始片段中检索则没有这个问题。你用重复工作的成本，换取了数据丢失的风险。

限制 3 是旧信息。一个页面是否正确，只取决于上一次更新。这就是 Factory 方法重要的原因。错误的 wiki 比没有 wiki 更糟。错误信息拥有正确信息的格式。

限制 4 是成本。你需要花费 token 来生成页面。你可能会生成没人阅读的页面。你也需要花费 token 去检查那些没有变化的页面。

wiki 不是记忆

有一个区别你必须知道。这个领域中的用词还不够精确。

很多人把这些系统称为记忆。LangChain 把 OpenWiki 称为 AI 智能体的 wiki 记忆层。其他人则说 wiki 赋予了智能体记忆。这里的「记忆」一词有两种不同含义。

第一种含义是对一组文档的了解。Wiki 做的就是这件事。它汇编你的文档、代码仓库或 Gmail 中的数据。它告诉你这些文档包含什么内容。

第二种含义是对用户的记忆。这是不同的数据。它包括一个人的偏好。它包括一个人的决策。它包括团队否决过的方法。它还包括当某个智能体在另一个应用中尝试某种方法时得到的结果。

对用户的记忆有不同的结构。它与人相关，而不是与一组文档相关。它来自交互，而不是来自摄取。它还必须为每个用户完成这些任务：纠正相互矛盾的信息，移除过时的信息，保留每条信息的来源，并在收到请求时删除数据。

Wiki 能正确完成第一项任务。Wiki 不能完成第二项任务。你的 Gmail wiki 会告诉智能体你的 Gmail 里有什么。它不会告诉智能体，你在周二的一次对话中改变了某个决定。它也不会告诉智能体，某种方法已经在你这里失败过。

记忆层完成第二项任务。Mem0 就是一个例子。它用 user_id 保存每条记忆。因此，记忆会随着人在不同会话、应用和智能体之间流转。当事实发生变化时，它会在原位置修改该事实。它不会每次都新增一条记录。

这两个系统并不是替代关系。两者都要用。错误不在于使用 wiki。错误在于以为 wiki 能给你用户记忆。

总结

智能体 wiki 的想法是正确的。把知识编译一次。然后让它保持正确。不要为每个问题重新构建。维护曾经让人类维护的 wiki 难以为继，而模型可以零成本完成维护。四个团队在几个月内构建了相同的结构。这是强有力的证据。

做这三件事。当文档集稳定且你会频繁阅读时，把文档编译成页面。当文档集变大时，像 gist 所说的那样加入检索。区分一组文档的知识和用户记忆。Wiki 给你前者。Wiki 不会给你后者。

In Context #17

这篇博客属于 In Context，这是一个由*@mem0ai*（https://x.com/@mem0ai）推出的博客系列，内容涵盖 AI 智能体记忆和上下文工程。

Mem0 是一个智能的开源记忆层，专为大语言模型和 AI 智能体设计，用于在不同会话之间提供长期、个性化且具备上下文感知的交互。

• 在这里获取你的免费 API Key：app.mem0.ai（https://app.mem0.ai/?utm_source=x_article_mem0&utm_medium=x_article&utm_campaign=agent_wiki&utm_content=agent_wiki）
• 或者从我们的开源 GitHub 仓库（https://github.com/mem0ai/mem0）自行托管 mem0

参考资料

• Andrej Karpathy，LLM Wiki（GitHub Gist，2026 年 4 月）（https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f）
• qmd：用于 markdown 的本地混合 BM25/向量搜索（https://github.com/tobi/qmd）
• Cognition，DeepWiki：适用于任何代码仓库的 AI 文档（https://cognition.com/blog/deepwiki）
• Devin Docs，DeepWiki（https://docs.devin.ai/work-with-devin/deepwiki）
• Factory，推出 AutoWiki（https://factory.ai/news/wiki）
• Factory Documentation，AutoWiki 概览（https://docs.factory.ai/cli/features/wiki/overview）
• langchain-ai/openwiki（GitHub）（https://github.com/langchain-ai/openwiki）
• LangChain，Wiki Memory（https://www.langchain.com/blog/wiki-memory）
• garrytan/gbrain（GitHub）（https://github.com/garrytan/gbrain）
• Vannevar Bush，《诚如所思》（The Atlantic，1945）（https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/）
• Mem0（https://mem0.ai/）

加入ThinkInAI社区

#

如果你也对AI充满兴趣，欢迎加入我们的ThinkInAI社区，在这里，你可以：

• 获取最新AI工具资讯
• 参与实战经验分享
• 结识志同道合的伙伴
• 共同探讨AI应用方向

扫描文末二维码，加入ThinkInAI社区，一起拥抱AI新时代！

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：ThinkInAI社区 mem0 mem0《来自 mem0 的深度研究： Agent Wiki 的现状》