原文：https://x.com/mem0ai/status/2079585032587694582本文保留原文结构、观点与全部配图，并结合各项目官方文档和代码仓库补充技术边界。原文由 Mem0 发布，其中“Wiki 不等于用户记忆”一节涉及其产品定位，相关论断按技术定义而非营销口径重新核验。

2026 年 4 月，Andrej Karpathy 在一篇 GitHub Gist 中提出了 LLM Wiki：让 LLM 先读取一批源材料，再把其中的知识整理成由模型持续维护的 Markdown Wiki。

随后，多个团队推出了相似系统：Cognition 的 DeepWiki、Factory 的 AutoWiki、LangChain 的 OpenWiki，以及 Garry Tan 发布的 GBrain。

这些产品并不完全相同，但都体现了一种共同思路：先将源材料整理成可持久化的知识页面，再让 Agent 优先读取这些页面，而不是每次遇到问题都重新消化全部原始材料。

这类系统通常被称为 Agent Wiki。本文将解释它的工作方式、不同实现、适用边界，以及一个容易被忽略的关键区别：文档集的知识层，不等于用户记忆。

核心思想：在摄取阶段编译，而不是在查询阶段重新推导

向模型提供大量文档的常见方案是 RAG：把文档分块，为片段生成 Embedding，并在每次查询时检索相关内容。

RAG 很有效，但它通常不会把每次推导形成的知识结构永久保存下来。第十次查询仍可能从原始片段重新开始，系统需要再次检索、拼接上下文和推理。

Agent Wiki 将一部分成本移到摄取或更新阶段：模型读取源材料，将信息整理为页面，后续查询复用这些页面。当新材料进入系统时，维护流程再修改相关页面、校正摘要，并标记与现有内容不一致的信息。

两种方法的差别主要体现在：

成本发生的时间不同：RAG 更多在查询时检索与组合；Wiki 更多在摄取和维护时整理。持久产物不同：RAG 的主要持久层通常是原始分块和索引；Wiki 额外保留经过综合的知识页面。

二者不是非此即彼。较实用的架构往往是：

用 Wiki 保存稳定、常用、经过综合的知识；用检索访问规模更大或更新更快的原始材料；对高风险结论回溯源文，而不是只相信摘要。

原文把 Agent Wiki 抽象为三层：

源文档层：文章、论文、代码库、邮件等原始材料，模型读取但不修改；Wiki 层：由模型维护的 Markdown 页面，包括主题摘要、页面间链接和索引；规则层：通过 CLAUDE.md、AGENTS.md、INSTRUCTIONS.md 或其他 schema 文件，约束 Wiki 的结构和维护任务。

在此基础上，系统执行三类操作：

Ingest：读取新来源，将信息写入相关页面；Query：基于 Wiki 回答问题，必要时把有价值的新结论沉淀为页面；Lint：发现矛盾、过期信息、断链和孤立页面。

这里的“编译”是一种类比，并不意味着输出具有编译器那样的确定性。LLM 生成的 Wiki 仍可能遗漏、误解或错误合并信息。

为什么这种方式可能有效

人工 Wiki 最难的环节往往不是创建，而是维护：修复页面链接、更新摘要、比较新旧材料、处理冲突，并持续清理过期内容。

这些工作重复、琐碎，且很难在繁忙团队中长期获得优先级。一旦维护停止，Wiki 逐渐失真，团队也就不再使用它。

LLM 适合承担其中一部分机械工作：批量读取文件、提出跨页修改、补充链接、识别潜在冲突。不过，原文所说“模型做维护没有成本”并不准确。自动维护仍会消耗 Token、计算资源和工程运维成本，也需要评测、审计与人工纠错。

这一思路可以追溯到 Vannevar Bush 1945 年提出的 Memex：构建一个能通过关联路径组织个人文档的知识系统。今天的模型提供了自动提炼和维护的可能性，但并没有消除准确性、来源追踪和遗忘策略等问题。

LLM Wiki 这个名称从何而来

Karpathy 在原始 Gist 中指出，常见系统会让 LLM 在每个问题上“从头重新发现知识”，缺少积累。他提出的替代方案是：

知识只编译一次，之后持续维护，而不是在每次查询时重新推导。

这样形成的是一个能够不断累积的持久产物。Wiki 主要由 LLM 编写和维护，人只在少数情况下直接修改。Karpathy 将这种关系概括为：

Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。

原始方案同时明确了规模边界：不使用 Embedding 的方式，在约 100 个来源、数百个页面的中等规模下可能足够有效；规模继续扩大后，应加入搜索。Karpathy 举出的例子是 qmd。

qmd 并非只有简单的文件搜索。其官方 README 描述了三层检索：

search：基于 SQLite FTS5 和 BM25 的关键词搜索；vsearch：基于 Embedding 的语义检索；query：融合词法与向量结果，并使用 query expansion、RRF 和本地 cross-encoder reranker。

因此，真正的判断规则不是“Wiki 替代 RAG”，而是：小规模知识层可以先依赖结构、链接和全文搜索；规模扩大后，再把 Wiki 与混合检索结合。

各团队分别实现了什么

相同的设计原则进入真实产品后，具体实现差异比共同口号更有价值。

Cognition：把 DeepWiki 做成公共代码知识层

Cognition 将这一方法应用于 GitHub 公共仓库。把公开仓库 URL 中的 github.com 改成 deepwiki.com，即可进入该代码库的 DeepWiki。

官方资料确认，DeepWiki 会为代码库生成架构图、说明文档、源代码链接和摘要。连接仓库时，Devin 会自动建立 Wiki；Ask Devin 则将 DeepWiki 上下文与代码搜索结合，用于生成基于代码的回答。

Cognition 在 2025 年发布时称已索引超过 50,000 个公共仓库。这是厂商在特定时间点披露的数量，不应理解为当前覆盖规模或独立验证的质量指标。

需要注意的是，公开 DeepWiki 与完整 Devin 产品并不相同。官方文档说明，高级代码搜索、规划和创建 Devin session 等能力属于 Devin 应用；公开 DeepWiki 主要提供生成文档和基础问答。

此外，DeepWiki 官方文档没有公开其底层模型、索引算法、更新频率和删除语义。将其断言为 Devin 内部某一种确定的“编译式检索基础设施”，超出了公开资料能够证明的范围。

Factory：让 AutoWiki 成为构建产物

Factory 的核心主张是：文档应当像构建产物一样由代码生成，而不是独立维护的项目。

其官方资料描述了多阶段、多 Agent 的流程。初始 survey 包含两轮扫描：

结构扫描：读取 README、依赖和 package metadata、CI 配置、入口点等；语义扫描：分析 route、API endpoint、service、schema 和 feature flag 等。

随后，系统进行规划、页面生成、视觉素材捕获、视频渲染和上传。不同 Agent 分别处理仓库中的特定关注点，避免把整个大型代码库一次性交给单个 Agent。

维护方面：

/wiki 根据当前仓库状态手动重新生成；/install-wiki 安装 GitHub Actions 或 GitLab CI，在默认分支收到 push 后更新；初次运行分析整个仓库；后续根据前一版本元数据中的 commit 标识定位变化，重建受影响页面并保留未变化页面。

生成结果可以进入 Factory Web viewer、GitHub Wiki、Droid session，以及随代码提交的 droid-wiki/ 目录。

不过，官方资料没有承诺每条 Wiki 结论都带行级引用，也没有给出完整性或准确性保证。自动更新解决的是“触发维护”问题，并不自动解决“维护结果是否正确”。

LangChain：OpenWiki 从代码扩展到个人资料

OpenWiki 是一个开源 CLI，用于生成和刷新面向 Agent 的代码库或个人知识文档。

Code mode 将当前项目写入 openwiki/；Personal mode 则把本地 Git、Notion、Gmail、X、Hacker News 和 Web Search 等来源整理到本地 Wiki。连接器先保存源数据与 manifest，再由面向不同来源的 Agent 生成 Wiki。

输出采用 Markdown，并包含 YAML metadata、索引、日志、页面链接和可选 Mermaid 图。系统能够自动维护根目录中由 OpenWiki 管理的 AGENTS.md 与 CLAUDE.md 区域，同时保留用户原有内容。

更新通过 --update 执行，也可接入 GitHub Actions、GitLab CI 或 Bitbucket Pipelines。

OpenWiki 展示了一个重要变化：Agent Wiki 不再局限于代码文档，而是开始成为个人工作资料的统一整理层。但其 README 并未公开一套具体的查询排序或 Embedding 架构，因此不能仅凭“Wiki for agents”推断其运行时检索方式。

官方仓库还显示，连接器会先把原始 JSON 和 manifest 写入本地 ~/.openwiki/connectors/，再由来源专属 Agent 综合进个人 Wiki。需要特别注意：Wiki 保存在本地，不代表推理完全在本地完成；源数据仍可能进入所选云模型的上下文。此外，公开文档没有承诺远端来源删除后，派生页面一定会同步清除。

GBrain：个人规模的可编程知识系统

GBrain 也以 Git 中的 Markdown 文件作为系统记录，但它并非原文所描述的“只有文件、没有数据库”。官方 README 显示，它会把内容索引到 Postgres：个人部署默认使用本地 PGLite，较大规模或多机共享则使用 Postgres 与 pgvector。

GBrain 支持 schema pack、类型化链接、backlink 和图遍历。页面写入时会抽取实体引用并生成 graph edge；查询则组合向量搜索、BM25、RRF、来源分层信号、reranking 和图关系加权。

它还提供同步、去重、引用修复、显著性评分和矛盾检查等维护任务。PGLite 被定位为大约 50,000 页面以内的个人部署，并且是 single-writer；大型同步时需要避免与正在运行的 MCP server 发生写竞争。

因此，GBrain 更准确的描述是：以 Markdown 和 Git 为可检查的知识源，以数据库、混合检索和图结构作为运行时索引。

技术对照

这些系统都重视持久页面、结构化说明和面向 Agent 的上下文，但不能简单归纳为“四个系统完全采用同一架构”：

DeepWiki 的内部索引与刷新机制并未完全公开；Factory 把 CI 和增量重建作为核心；OpenWiki 同时覆盖代码与多种个人数据源；GBrain 明确使用数据库、混合检索和知识图索引。

它们真正共享的是更高层的设计方向：将可复用的领域知识提前整理成持久、可检查、可更新的上下文层。

Agent Wiki 的适用边界限制一：规模

Karpathy 给出的无 Embedding 方案主要面向约 100 个来源、数百个页面的中等规模。页面继续增加后，需要全文、向量或混合检索，不能假设模型仅靠目录和链接就能稳定找到所需内容。

限制二：摘要损失与错误传播

Wiki 在摄取阶段压缩信息。早期摘要如果遗漏细节或形成错误结论，后续回答可能重复使用这一错误。RAG 从原始片段检索，并不意味着它没有召回和上下文拼接问题；但它至少保留了直接回到原文的路径。

更稳妥的设计是保留 provenance：页面中的关键主张应链接到源文件、commit、段落或消息，并允许 Agent 在高风险场景回查原文。

限制三：陈旧信息

页面只与最近一次成功更新一样可靠。触发器失败、权限变化、部分数据源断开或增量判断出错，都会让 Wiki 落后于真实来源。

因此需要记录：

来源版本和最后更新时间；最近一次更新是否成功；页面由哪些源材料生成；哪些内容存在冲突或置信度不足；删除、撤回和访问权限变化如何传播。限制四：成本

提前编译知识并不是免费操作。系统可能生成从未被读取的页面，也可能反复 lint 没有实质变化的内容。总成本取决于来源变化频率、页面粒度、模型选择、增量检测质量和查询复用率。

只有当一批资料相对稳定、会被频繁查询，而且重复理解成本明显高于维护成本时，Agent Wiki 才更容易体现价值。

限制五：安全与隐私

个人 Wiki 可能同时连接 Gmail、Notion、代码库和聊天记录。系统在综合内容时，可能把原本隔离的数据写入同一页面，从而扩大可见范围。

生产设计至少需要：

来源级与页面级访问控制；多租户隔离；secret 与凭据过滤；数据保留和按请求删除机制；更新与查询审计日志；防止不可信文档中的 Prompt Injection 影响维护 Agent；删除源数据后同步删除派生摘要和索引。

以 OpenWiki 为例，官方文档说明密钥与 OAuth token 默认放在 ~/.openwiki/.env，目录和文件权限分别建议设为 0700 与 0600；代码文档 Agent 也被限制在指定文档目录内写入。其匿名 telemetry 默认开启但可以关闭。上述措施只覆盖 OpenWiki 自身，不能替代对 LLM provider、Tavily、Notion、Slack、Google、X 或 tracing 服务的数据政策审查。

Wiki 不等于用户记忆

这个领域中的“memory”至少包含两种不同含义。

第一种是文档集知识。Wiki 擅长这一类：它整理代码库、邮件、论文或笔记中已经存在的信息，回答“这些资料包含什么”。

第二种是用户或交互记忆，包括：

某个人的偏好；用户或团队已经做出的决定；被否决的方法及原因；Agent 在特定任务中的尝试和结果；随时间变化、需要替换或遗忘的个人事实。

这类记忆来自持续交互，而不只是批量摄取文档。它通常需要绑定用户身份、保存来源和时间、解决新旧事实冲突、支持撤回与删除，并在不同 session、应用或 Agent 之间按权限复用。

Mem0 将自身定位为第二类能力：记忆与 user_id 关联，并在事实变化时更新已有记忆，而不是无限追加记录。这是产品的设计主张，实际效果仍取决于抽取准确率、冲突策略、数据治理和应用集成。

原文认为 Wiki 只能解决第一类问题，这个说法作为概念区分有价值，但边界并非绝对。GBrain、OpenWiki Personal mode 等系统已经同时包含摄取、交互、检索和维护能力。判断一个系统是不是“记忆层”，不应只看它是否使用 Markdown，而应看它是否具备身份绑定、时间语义、冲突消解、来源追踪、删除传播和跨会话调用等机制。

Wiki 与用户记忆也不是替代关系：可以用 Wiki 保存稳定的领域知识，用 memory layer 保存与用户和交互历史相关的动态事实，再由 Agent 按任务组合两者。

总结

Agent Wiki 的核心思想是：把会被反复使用的知识提前整理成持久上下文，并在来源变化时维护它，而不是每次查询都从零开始推导。

实践中可以遵循三个原则：

对相对稳定、频繁访问的资料，在摄取阶段生成结构化页面；当来源和页面规模扩大后，加入 BM25、向量检索、reranking 或图检索；区分文档集知识与用户记忆，并为两者分别设计更新、权限、来源和删除机制。

但 Agent Wiki 不是 RAG 的简单替代品，也不是天然准确的“长期记忆”。它更像 RAG 与 Agent 之间的一层预计算知识表示：以额外的摄取和维护成本，换取更稳定的结构、更低的重复理解成本，以及可供人和 Agent 检查的持久产物。

真正决定系统质量的，不是 Markdown 文件是否存在，而是这条链路是否可靠：

原始来源 → 增量检测 → 综合与冲突处理 → 可追溯页面 → 检索与回源 → 持续评测和删除传播