在前面：如果你做过 RAG，大概率遇到过这样一个问题：同一批文档，系统回答第 10 个问题时，并不比回答第 1 个问题时更聪明。每次查询都从原始分块重新推导一遍，前 9 次积累的理解，没有沉淀下来。

近一年中，几个团队从不同方向给出了相似的答案——**不要在查询时重新推导，而要在资料导入时完成编译**。这套模式被称为 Agent Wiki。Mem0 技术博客《The State of Agent Wikis》里，梳理了 Agent Wiki 的架构与运作方式、四个代表性系统的工程实现，以及它的适用边界。接下来我们就一起来看看：

## 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 月。

多个团队从不同场景出发，先后收敛到了相似的结构。这种跨场景的一致性就是一个值得注意的工程信号。

## 核心思路：把成本从查询阶段挪到资料导入阶段

![](https://developer.qcloudimg.com/http-save/yehe-12464096/ce1d1220716fa957525450d88ca5065d.png)

给模型接入大量文档，常规检索做法是

```Python
文档入库 → 切分成块 → 生成 Embedding → 写入向量索引
```

每次提问时，系统再召回相关分块，交给模型生成答案。

这个方案能用，但有一个结构性问题：**它不保留结果**。每个答案都是从原始分块现场重建的，第 10 个答案不会比第 1 个更好，同样的理解工作要重复支付 10 次成本。

Agent Wiki 把这笔成本挪到了前面。模型在读取源文档时把工作做完一次，把结果写成页面，页面持久保留。新的源文档进入系统时，模型执行的是一套增量操作：读取新资料、更新相关页面、修正受影响的摘要，并标记与既有页面相互矛盾的信息。

两种方案都成立，差别在两点：**成本发生在什么时候，以及一次查询结束后留下了什么。**

### 三层结构

![](https://developer.qcloudimg.com/http-save/yehe-12464096/0988173495e540dfc20685c88cf9ef16.png)

四个系统的架构可以抽象成同一个三层模型：

**第一层是源文档**——文章、论文、代码仓库。模型只读，不修改。

**第二层是** **Wiki**，内容采用 Markdown 格式，全部由模型写入，包含摘要、按主题组织的页面，以及页面之间的链接。

**第三层是维护****指令****或配置，**用于告诉模型 Wiki 如何组织、生成和更新。具体载体因项目而异，可能是 `CLAUDE.md`、`AGENTS.md`，也可能是项目专用配置文件或工作流。

### 三个操作

**Ingest**：模型读取新的源文档，把信息分发到所有相关页面。

**Query**：向 Wiki 提问。一个好的回答可以作为新页面反写回 Wiki。

**Lint**：模型检查整个 Wiki，找出互相矛盾的信息、已经过时的内容，以及没有任何链接指向的孤立页面。Lint 这一步容易被忽略，但它恰恰是这套方案能长期成立的关键——原因见下一节。

## 为什么它能成立：瓶颈在于维护

人类维护的 Wiki 会随时间腐化，原因很具体：难的从来不是读文献，也不是产生洞见，而是**维护**。

维护意味着这些持续性的工作：修正页面之间的链接、让摘要与最新事实保持一致、把每一份新文档与已有页面逐一比对。这类工作没有尽头，也不产生任何即时回报。团队一忙，最先被放弃的就是它。接着 Wiki 开始失准，然后没人再用它。

模型做这件事没有同样的障碍：它不会厌倦，不会因为琐碎而跳过某条交叉引用，也可以在一次操作里改动 15 个文件。

这个思路本身并不新鲜。早在 1945 年，Vannevar Bush 就曾描述过 Memex——一个带有关联链接的个人文档库。Bush 当年没能解决的正是维护问题，而模型补上了这一环。

## 回到 Karpathy 的原始表述

其实， Karpathy 的 Gist 原文值得一读，它比大多数转述总结都准确。

Karpathy 对常规做法的判断是：模型在每个问题上都在从零重新发现知识，没有任何积累。他给出的替代方案是编译而非检索——知识编译一次，此后持续保持更新，而不是每次查询时重新推导，最终得到一个持久的、能不断累积的产物。

他也明确了人的位置：你几乎从不亲手写这个 Wiki，模型写它，也维护它。他给出的那个类比很精准：**Obsidian 是** **IDE****，模型是程序员，Wiki 是代码库。**

**这里有一个被****大量转述总****结漏掉的关键限制：规模。** Gist 明确写了，靠索引文件 `index.md` 定位页面的做法在中等规模下效果不错——约 100 份源文档、数百个页面——并且**能省掉一整套基于 Embedding 的 RAG 基础设施**。超出这个量级，Gist 建议加上搜索，并给出了 QMD 作为示例。QMD是一个面向 Markdown 的本地搜索引擎，采用 BM25 与向量混合检索，再加上模型重排序。

所以这条规则是关于**规模**的，不是关于**替代**的。需要注意的是，触及天花板的是「用一个扁平索引定位页面」这套导航方式，而不是「编译成 Wiki」这个模式本身——源文档集较小时，不必上检索基础设施；变大之后，在 Wiki 之上补一层搜索即可。

## 四个团队的工程实现

模式讲完了，现在来看看有意思的地方——各家在工程上的取舍差异。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/25599f8691b7896c17c219de4adbaeee.png)

### DeepWiki：把 Wiki 做成公共设施

Cognition 把这套方法应用到了 GitHub 上的公开仓库：把 URL 里的 `github.com` 换成 `deepwiki.com`，就能得到这个代码库的 Wiki，包含架构摘要、文件索引、依赖图和搜索，并且链接回源码。上线时已覆盖 5 万多个主流公开仓库，其中包括 MCP 和 LangChain。

但更值得注意的是第二点：**Wiki** **本身不是产品，它是给 Agent 使用的检索基础设施。** Devin 依靠它在代码库中定位相关代码。也就是说，DeepWiki 是 Devin 代码搜索能力底下那层被预先编译好的结构。

### AutoWiki：把文档变成构建产物

Factory 的切入点是持续集成。他们的主张很明确：文档应该是一个构建产物，而不是一个独立项目——文档从源码生成，结构与代码库对齐，代码库变了，它就跟着变。

生成过程分两遍。**第一遍是结构扫描**，读取 README、包清单、CI 配置和入口文件；**第二遍是语义扫描**，读取路由、API 端点、服务类、数据库 Schema 和特性开关。

工作被拆给多个专职 Agent，每个 Agent 负责代码库的一部分，并拿到足以写好这一部分页面的上下文。这个设计是为了规避这个问题：单个 Agent 面对大型代码库时，写出来的文档质量会明显下降。

保持更新依靠的是基础设施，而不是自觉。`/wiki` 命令重新生成 Wiki，`/install-wiki` 命令写入一个 CI 工作流，让每次推送到默认分支时自动重建。对 GitHub 仓库，产物直接进入仓库的 Wiki 标签页。

### OpenWiki：从代码库扩展到全部工作

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：个人规模的开源实现

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 不等于记忆

![](https://developer.qcloudimg.com/http-save/yehe-12464096/69c8bc435ebff1c159b4126b289d60d8.png)

最后是术语上的区分。这个领域的术语还没有精确下来，「记忆」正在被用于表达两种不同含义。

**第一种含义是对某个文档集的知识。** 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 的读者是模型」「直接检索原始分块没有这个问题」——以避免与文中其他论述相互冲突。

在前面：如果你做过 RAG，大概率遇到过这样一个问题：同一批文档，系统回答第 10 个问题时，并不比回答第 1 个问题时更聪明。每次查询都从原始分块重新推导一遍，前 9 次积累的理解，没有沉淀下来。

从 DeepWiki 到 OpenWiki：Agent Wiki 到底有什么用？

Agent Wiki 是一种新型知识管理范式：将RAG中“查询时实时检索”改为“导入时预编译”，用模型自动生成并持续维护结构化Markdown Wiki。它解决传统RAG重复推导、无法积累的问题，适用于稳定文档集，但需区分“文档知识”与“用户记忆”。

人工智能

后端

开发工具

AgentWiki通过将知识编译工作前置到资料导入阶段，显著提升AI系统效率。多个团队独立开发出相似的三层架构：源文档层、模型生成的Markdown Wiki层和维护指令层。这种方案解决了传统RAG重复计算的问题，使系统能持续积累知识。文章对比了DeepWiki、AutoWiki等四个实现方案，并指出Wiki适用于文档知识管理，但无法替代用户记忆功能。

2026上云采购 | AI焕新·智启新局

tencentdb-catalog

coding

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AgentWiki通过将知识编译工作前置到资料导入阶段，显著提升AI系统效率。多个团队独立开发出相似的三层架构：源文档层、模型生成的Markdown Wiki层和维护指令层。这种方案解决了传统RAG重复计算的问题，使系统能持续积累知识。文章对比了DeepWiki、AutoWiki等四个实现方案，并指出Wiki适用于文档...

从 DeepWiki 到 OpenWiki：Agent Wiki 到底有什么用？-腾讯云开发者社区-腾讯云

从 DeepWiki 到 OpenWiki：Agent Wiki 到底有什么用？

从 DeepWiki 到 OpenWiki：Agent Wiki 到底有什么用？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐