Agent Wiki 现状：AI 智能体的知识编译革命

核心理念：在摄入时编译，而非查询时检索

传统上，让模型理解大量文档的方法是检索式 RAG：将文档存入数据库、分块、生成嵌入向量，每个查询都从原始片段中重新构建答案。

这种方法有效，但有一个问题：系统不会保留结果。第十次回答并不比第一次更好，而你要为同样的工作付出十次成本。

Agent Wiki 将成本前置。模型在读取源文档时一次性完成工作，将结果写入持久化的页面。

当新源文档加入时，模型执行以下步骤：读取新文档 → 更新相关的现有页面 → 修正摘要 → 标记与现有页面矛盾的信息。

两种方法都正确，但有两个关键差异：何时支付成本，以及问题之后留下了什么。

三个层次

每个 Agent Wiki 系统都包含相同的三层架构：

三个操作

• Ingest（摄入）：模型读取新源，将数据写入每个相关页面
• Query（查询）：向 Wiki 提问，也可将优质答案写回 Wiki 成为新页面
• Lint（检查）：模型审查 Wiki，发现矛盾信息、过期信息和孤立页面

为什么它能工作？

人类维护的 Wiki 会随时间变得不准确。原因很具体：难的不是阅读源材料，也不是产生想法，而是持续维护。

维护工作包括：修正页面间链接、保持摘要准确、将每个新文档与现有页面对比。这项工作永无止境，也没有回报。忙碌的团队最先放弃这项工作，然后 Wiki 变得不准确，最终被废弃。

模型做这项工作毫无问题。模型不会厌倦，不会忘记链接，可以一次性修改十五个文件。

这个想法历史悠久。1945 年 Vannevar Bush 就描述了 Memex——一个带有链接的个人文档存储系统。Bush 当时无法解决维护问题。而今天，模型就是答案。

名称由来

直接阅读 Karpathy 的 Gist 原文比任何摘要都准确。

关于传统方法，他写道："LLM 在每个问题上都在从零重新发现知识，没有积累。"

他的方法是将信息编译（compile）而非检索。于是"知识一次性编译完成并持续保持最新，而非每次查询重新推导"。结果是一个"持久的、持续积累的产物"。

你不需要自己写 Wiki。他写道："你很少（或从不）自己编写 Wiki，LLM 编写并维护所有内容。" 他将 Agent 和 Obsidian 结合使用："Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。"

Gist 还给出了规模限制——很多摘要忽略了这一点：不依赖嵌入向量的方法"在中等规模下效果出奇地好（约 100 个源，数百个页面）"。对于更大的源，Gist 建议添加搜索，以 qmd 为例——"一个基于 Markdown 文件的本地搜索引擎，混合 BM25/向量搜索和 LLM 重排序。"

所以规则是关于规模，而不是关于替代。源集小时不需要检索基础设施；源集变大时再加入检索。

各团队实际构建了什么

Cognition：DeepWiki——作为公共工具的 Wiki

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

超过 50,000 个最大的公开仓库已有 Wiki，包括 MCP 和 LangChain。

更重要的是：Wiki 本身不是产品，而是 Agent 的检索基础设施。 Devin 使用 Wiki 在代码库中查找相关代码。DeepWiki 是 Devin 代码搜索之下的编译层。

Factory：AutoWiki——文档作为构建产物

Factory 将此方法应用于持续集成。他们的理念是：文档必须是构建产物，而不是独立的项目。 文档来自源代码，拥有代码库的结构，随仓库变更而变更。

构建 Wiki 的方法有两个阶段：Pass 1（结构扫描） 读取 README、包清单、CI 配置和入口点；Pass 2（语义扫描） 读取路由、API 端点、服务类、数据库模式和功能标志。

Factory 将工作分配给多个专业 Agent，每个 Agent 负责仓库的一部分，拥有足够的上下文写出一篇好页面。这避免了单一 Agent 为大型仓库编写糟糕文档的已知问题。

Factory 用基础设施而非纪律来保持 Wiki 正确。/wiki 命令重建 Wiki，/install-wiki 命令写入 CI 工作流，每次推送到默认分支时自动重建 Wiki。

LangChain：OpenWiki——从代码到一切

LangChain 将 OpenWiki 作为开源 CLI 工具发布，用于编写和维护代码库的 Agent 文档。随后发布了 OpenWiki Brains，包含两种模式：Code Brain 用于代码仓库，Personal Brain 用于个人源文档。

Personal Brain 是关键转变。它从 Gmail、Notion、Git 仓库、X（Twitter）、Hacker News 和网页搜索 中读取数据，全部写入一个本地 Markdown Wiki。该方法从"代码仓库的文档"变成了"你工作的文档"。

每个团队做出了相同的决策：输出不是给人阅读的文本，而是供 LLM 使用的结构化 Markdown。 包含标题、页面间链接和摘要。Wiki 的读者是模型。

GBrain——个人规模的开源版本

GBrain 将方法应用于个人知识库而非代码库。使用 Git 仓库中的 Markdown，拥有 Schema 文件，自动生成主题间的链接图。

GBrain 展示了这种方法几乎不需要基础设施：没有向量数据库，没有服务，只有文件。模型维护文件，人也可以阅读文件。

技术矩阵对比

四个团队用四种不同的应用场景解决了四个不同的问题，却得出了相同的架构。这种一致性是架构正确性的有力证据。

唯一的差异在于维护方式：Factory 通过 CI 自动维护；其他三个系统需要手动运行命令。因此，后者的 Wiki 只在上次命令运行时才是正确的。

局限性

限制 1：规模

Karpathy 给出了这个限制。不依赖嵌入向量的方法适用于约 100 个源。更多页面时，必须添加搜索引擎（BM25 + 向量搜索）。

限制 2：准确性

模型在摄入时编译信息。早期的摘要可能遗漏源文档中的细节，后续每个答案都会继承这个错误。RAG 不会出现这个问题——你是在用重复工作的成本交换数据丢失的风险。

限制 3：过时信息

页面的正确性取决于最后一次更新。这是 Factory 的 CI 方法如此重要的原因。错误的 Wiki 比没有 Wiki 更糟糕，因为错误信息具有正确信息的格式。

限制 4：成本

你支付 Token 来创建页面，其中一些页面可能无人阅读。你还要支付 Token 来检查没有变化的页面。

Wiki ≠ 记忆

有一个关键区别你必须知道。这个领域中的术语还不够精确。

很多人将这些系统称为记忆（Memory）。LangChain 称 OpenWiki 为 AI Agent 的 Wiki 记忆层。但"记忆"在这里有两个不同的含义：

含义一：文档集的知识。 Wiki 能做到这一点。它编译文档、仓库或 Gmail 中的数据，告诉你文档中有什么。

含义二：用户的记忆。 这是不同的数据。包括：个人的偏好、个人做出的决策、团队曾拒绝的方法、Agent 在不同应用中尝试某种方法的结果。

用户的记忆具有不同的结构——它与个人相关而非文档集，来自交互而非摄入。它还必须在每个用户维度上做到：修正矛盾信息、删除过期信息、保留每条信息的来源、按请求删除数据。

Wiki 能做好第一件事，但做不了第二件事。 你的 Gmail Wiki 能告诉 Agent 你的 Gmail 中有什么，但无法告诉 Agent 你在星期二的对话中改变了一个决定。

记忆层做第二件事。 Mem0 就是一个例子。它用 user_id 保存每条记忆，记忆随用户在会话、应用和 Agent 之间移动。当事实变化时更新已有记录，而不是每次都新增一条。

这两个系统不是替代关系——两个都用。 错误不是使用 Wiki，而是认为 Wiki 能给你用户的记忆。

总结

Agent Wiki 的理念是正确的：一次编译知识，持续保持正确，不要为每个问题重新构建。 维护拖垮了人类 Wiki，而模型可以零成本地完成维护工作。四个月之内四个团队构建了相同的架构——这是强有力的证据。

做这三件事：

1. 当文档集稳定且你频繁阅读时，将文档编译成页面
2. 当文档集变大时加入检索，如 Karpathy 的 Gist 所述
3. 区分文档集的知识和用户的记忆——Wiki 给你前者，不给你后者

JOTO 企业落地观察

• 企业部署此类系统时，需明确区分「知识编译」与「交互记忆」两类基础设施，避免用 Wiki 替代用户级记忆层，否则将导致决策上下文缺失。
• 智能体工程中，采用「摄入即编译」范式意味着将文档维护责任从人工流程转为自动化流水线，这对 CI/CD 工程能力提出更高要求，尤其在多 Agent 协同场景下需定义清晰的 Schema 边界。
• RAG 知识工程正从「查询时拼凑」转向「摄入时沉淀」，但该路径对源文档稳定性敏感——若源频繁变更且无 CI 触发机制，Wiki 将快速过时，此时需评估是否引入轻量级向量检索兜底。
• AI 安全治理需覆盖 Wiki 的生命周期审计：因页面由模型自动生成，企业须建立 Schema 版本控制、页面变更日志与冲突标记机制，确保知识演进过程可追溯、可回滚。