2026 年 4 月，Andrej Karpathy 提出 LLM Wiki 技术构想，主张「摄入时编译」替代传统 RAG 的「查询时做功」。短短数月内，Cognition、Factory、LangChain、Garry Tan 四支团队几乎同步落地了同类产品，一条全新的技术赛道迅速成型。
Karpathy 的 Gist 发布后，四支团队几乎同时交出了工程化答案。底层架构高度一致——都遵循 Markdown + Git 存储 + 规则文件 + 摄入时编译 + 面向智能体读取，但落地方向天差地别。
面向公开 GitHub 仓库：把仓库地址中的 github.com 替换为 deepwiki.com，即可看到自动生成的项目维基，包含架构总览、文件索引、依赖图谱。Wiki 本身是 Devin 的底层检索基础设施，帮助智能体快速定位代码，无需每次从零通读整个仓库。
面向开发者 · 预编译知识层文档是代码的构建产物。Wiki 生成深度绑定 CI/CD 流程：结构扫描读取 README、依赖配置、CI 文件；语义扫描梳理接口路由、服务类、数据库结构。采用多智能体分工，每个模块由独立 Agent 负责。代码提交到主分支即 自动重新生成维基，工程机制强制保证文档与源码同步。
全自动持续更新 · CI/CD 绑定完全开源的 CLI 工具，双模式：Code Brain 为代码库生成文档；Personal Brain 是更大的突破——可接入邮箱、笔记、社交媒体、资讯订阅等多源个人数据，统一整理成本地维基。将应用场景从「代码库文档」拓展到 「个人工作全量知识沉淀」。
开源 · 个人知识维基最轻量化的方案：仅靠 Git 仓库 + Markdown 文件 + 规则文件运行，没有向量数据库，也没有复杂的后端服务。能自动生成主题间的关联图谱。最大意义在于证明了 Agent Wiki 的核心是 「LLM 自主维护结构化知识」的逻辑，而非复杂的基础设施。
极致轻量 · 最低成本跑通一个值得注意的差异：只有 Factory 依靠 CI 流水线实现全自动持续更新；其余三款都需要人工执行命令才会刷新内容。知识库的准确程度，取决于上一次手动更新的时间。
Karpathy 一针见血地指出了传统 RAG 的核心弊病：大模型每回答一个问题，都要从零开始重新梳理知识，全程没有任何积累。
文档导入时只做机械拆分+向量化，不理解内容。用户提问时，系统才检索、拼接、推理，从零开始生成答案。同一个问题问 100 次，就要重复 100 次全流程，算力和 Token 成本随提问次数线性上涨，且系统不会沉淀任何结论。
核心计算全部前置到文档导入阶段：大模型通读所有原始文档，完成语义理解、要点提炼、知识分类，输出一套结构化的 Markdown 维基页面，带摘要、分类、内链。用户提问时，只需定位到对应页面，大模型直接读取整理好的结构化内容，速度更快，成本更低。
Karpathy 用了一个经典的比喻来定义三者的角色：Obsidian 是 IDE，LLM 是程序员，维基就是代码库——整个维基全程由大模型负责「编写」和「维护」，人几乎不需要手动撰写内容，只需提供原始素材和维护规则。
Mem0 将这套系统梳理为标准的三层架构，从下到上依次为：
原始文档层：论文、代码库、规章制度等，系统只读取不修改。
维基内容层：大模型编译生成的 Markdown 页面集合，带摘要、分类、内链，是回答问题的直接依据。
规则文件层：AGENTS.md、CLAUDE.md 等「运维手册」，定义分类标准、更新规则、矛盾处理逻辑。
围绕这三层架构，有三个核心操作：
Karpathy 特别强调了一个规模边界：纯靠页面导航、不带向量检索的 Wiki 方案，只适合约 100 个信息源、几百个页面的中等规模。超过这个阈值，就需要补充 BM25 关键词检索 + 向量检索 + LLM 重排序的混合检索能力来兜底。
LLM Wiki 的思路虽然高效，但 Mem0 在分析中明确指出了四个不可回避的局限——这也是它无法完全替代传统 RAG 的核心原因。
约 100 个信息源的阈值。超过后页面关联关系指数级复杂化，增量更新与全量校验成本急剧上升，必须补充检索能力兜底。
「提前编译」必然的代价：摄入阶段的摘要、归纳过程，一定会丢失原始文档中的边缘细节，而这些被遗漏的信息，后续所有查询都无法再找回。
Wiki 内容的准确性永远等于最后一次更新的准确性。错误的 Wiki 比没有 Wiki 更危险——结构化的呈现形式会赋予内容虚假的权威性，用户更容易不加验证地采信。
提前做功不是没有成本，只是把成本从查询侧转移到摄入侧。生成全量 Wiki 页面、定期校验、维护链接都要消耗 Token。如果文档体量大但实际查询频率很低，Wiki 方案反而可能比传统 RAG 成本更高。
这是一个经典的架构权衡：用重复算力换取信息完整性（传统 RAG），还是 用少量细节损失换取效率与成本优势（LLM Wiki）。没有绝对正确的答案，只有适合场景的选型。
行业内普遍存在一个认知偏差：很多人把 Agent Wiki 称作「AI 记忆」，甚至觉得搭建了一套维基就等于给 AI 加上了记忆能力。Mem0 明确指出：这是完全错误的。
「记忆」在这里有两层完全不同的含义：
锚定文档本身，来自批量资料导入，回答的是「资料里写了什么」。对所有访问者输出一致的内容。按「主题/文档」组织知识，来自批量文档摄入。
锚定具体的用户 ID，来自真实的交互过程，记录的是用户偏好、过往决策、失败方案、临时变更的想法等。按「用户」组织数据，每个人的记忆都是独一无二的。
LLM Wiki 不是 RAG 的终结，而是 AI 知识库的进化方向。未来更主流的方式一定是混合架构：核心、高频、稳定的知识用 Wiki 做预编译提效，长尾、低频、细节性的内容用传统 RAG 兜底精度。这从来不是谁替代谁的零和博弈，而是技术演进中，把算力花在刀刃上的必然选择。