by smallnest

当 Karpathy 说"Wiki 能杀死 RAG"，整个 AI 界花了五周时间证明他可能是对的

当 Karpathy 说"Wiki 能杀死 RAG"，整个 AI 界花了五周时间证明他可能是对的

2026年4月4日，Andrej Karpathy 在 GitHub 上发布了一段不到3000字的文字。没有代码，没有论文，没有基准测试——只有一个想法。

五周之后，这段文字收获了超过5000颗 Star、5000次 Fork，以及评论区里660多条回复。十几个开源项目从中破土而出，一批创业公司以此为核心融资，YouTube 上出现了数十个深度解析视频，中文技术社区里"LLM Wiki"四个字的搜索量在一个月内翻了四十倍。

这一切发生得如此之快，以至于很多人还没来得及搞清楚一个问题：Karpathy 到底说了什么？

一个简单到令人不安的观察

Karpathy 的核心论点可以用一句话概括：RAG 是一种没有记忆的知识获取方式。

检索增强生成（Retrieval-Augmented Generation）是当前 AI 行业最主流的知识管理范式。它的原理很直接——你上传一堆文件，当你提问时，系统从文件中检索出相关片段，让大模型基于这些片段生成回答。NotebookLM、ChatGPT 文件上传、几乎所有的企业级 AI 知识库，都走这条路。

问题在于，Karpathy 说，每一次提问，模型都在从零开始重新发现知识。

如果你问了一个需要综合五篇文档的问题，RAG 会检索、拼接、生成。如果你明天再问同样的问题，它会重复整个过程。没有任何积累。没有任何记忆。跨文档的关联、矛盾、演变——这些需要时间来构建的东西，在一次次的查询中反复流失。

"大多数人放弃维护 Wiki 的原因，" Karpathy 写道，"不是因为阅读和思考太累，而是因为更新交叉引用、保持摘要时效、标注矛盾之处、维护数十个页面之间的一致性——这些案头工作太枯燥了。"

他的方案是：让 LLM 来做这些。

三层架构：比它看起来更深

Karpathy 描述的系统有三层。

原始资料层——你收集的论文、文章、播客笔记、会议纪要。不可变。LLM 只读不改。

Wiki 层——LLM 生成的 Markdown 文件目录。摘要页、实体页、概念页、比较分析、综述。LLM 拥有这一层的完整所有权。它创建页面、更新页面、维护交叉引用、标注矛盾。你阅读它；LLM 编写它。

Schema 层——一个配置文件（对 Claude Code 来说是 CLAUDE.md，对 Codex 来说是 AGENTS.md），告诉 LLM 这个 Wiki 的结构规范、命名约定、工作流程。这是让 LLM 成为"有纪律的 Wiki 维护者"而非"普通聊天机器人"的关键。你和 LLM 在使用过程中共同迭代这份文件。

三层之间的运作方式被设计为三种核心操作：

摄取（Ingest）：你往原始资料目录放入一个新文件，告诉 LLM 处理它。LLM 读完之后和你讨论关键收获，写一篇摘要页，更新索引，更新所有相关的实体和概念页面，在日志中添加一条记录。一个新文件可能触及10到15个 Wiki 页面。

查询（Query）：你向 Wiki 提问。LLM 搜索相关页面，综合答案并引用来源。关键洞察是：**好的答案应该被保存回 Wiki，成为新的页面。**你做的那次比较分析、那个跨文档的关联发现——这些不应该消失在聊天记录里。

检查（Lint）：定期让 LLM 审计整个 Wiki。查找页面间的矛盾、过时的声明、没有入链的孤立页面、被提及但尚未拥有独立页面的概念、缺失的交叉引用。让 Wiki 在增长过程中保持健康。

为什么它引起了如此强烈的共鸣

Karpathy 在 Gist 里引用了一个80年前的名字：Vannevar Bush。

1945年，Bush 在《大西洋月刊》上发表了一篇题为"As We May Think"的文章，提出了 Memex 的概念——一种个人化的、经过精心整理的知识仓库，文档之间存在联想式的关联路径。Bush 的愿景更接近 Karpathy 所描述的，而非今天 Web 的样子：私有的、主动整理的，文档之间的连接与文档本身同样有价值。

Bush 没能解决的问题是：谁来做维护？

这个问题的答案，在80年后，变成了"LLM"。

但共鸣不止于此。Karpathy 描述的工作方式——一侧打开 LLM Agent，另一侧打开 Obsidian，LLM 做编辑，你实时浏览结果，跟随链接，检查图谱视图——恰好击中了当下数百万知识工作者的真实痛点：我们有太多信息，太少的连接。

"你是 IDE；LLM 是程序员；Wiki 是代码库。" Karpathy 这样形容。这个比喻之所以有力，是因为它把一个模糊的概念——"AI 辅助知识管理"——变成了一个具体的、可操作的、任何人今天就能开始的实践。

生态系统的爆发

Karpathy 的 Gist 发布后，开源社区的反应速度令人惊叹。以下是最具代表性的几个项目：

llmwiki（1000+ GitHub Stars）——由 ethanj 构建，是最早的 CLI 实现之一。支持 compile --review 模式，允许在生成的页面上线前进行审批或驳回。引入了声明级别的来源追溯（如 ^[paper.md:42-58]），支持图片、PDF、转录本的摄取，提供 BM25 重排序的分块检索，以及 llms.txt、JSON-LD、GraphML、Marp 等多种导出格式。

ΩmegaWiki（570+ Stars）——由中国开发者 skyllwt 构建，是目前唯一支持中英双语的项目。它提供了 23 个 Claude Code 技能（Skills），覆盖研究的全生命周期，定义了 9 种类型化实体和 9 种类型化边，支持知识图谱的构建与查询。

SwarmVault（90+ 发布版本）——从 Karpathy 的 Gist 出发，已发展为一个完整的知识基础设施工具。支持视频摄取、图谱合并、SQL 解析、GitHub 仓库作为来源，以及 Neo4j 导出。最新的 swarmvault chat 功能支持在编译后的 Wiki 上进行持久化多轮对话。

NEXUS——一个多 Agent 记忆系统，在 VPS 上运行 6 个 AI Agent，使用 Weaviate 向量数据库 + Ollama 本地 LLM + Wiki.js。它在 Karpathy 发布 Gist 后的四天内就投入了生产环境。

Eshel——由 alirezabbasi 构建的项目，将 LLM Wiki 概念从被动的知识积累扩展为"持久的工程智能层"。它跟踪架构决策、编码标准、实现细节、工作流程、技术债务——让知识在软件工程的生命周期中复合增长，而非衰减。

Synthadoc v0.2.0——一个生产就绪的实现，支持六种 LLM 提供商的热切换，不同 Agent（摄取、查询、检查、技能）可以同时运行在不同模型上。内置审计追踪，记录每一次摄取、查询、矛盾和自动解决，附带 token 计数和成本核算。

Link v1.1.0——本地优先的 Markdown Wiki + MCP 服务器。支持 SQLite FTS 支持的搜索、图谱可视化，以及记忆生命周期管理（remember、recall、brief、profile、audit、review、archive、restore、forget）。

Keel——一个 Mac 应用，知识以本地磁盘上的纯 Markdown 形式存储，模型可替换。偏向本地优先和数据自主。

PulseOS Lite——面向企业级场景，将 LLM Wiki 扩展为"公司记忆 + 本体 + 证据 + 运行时"，试图让整个公司变得"机器可读"。

Sigma Guard——解决了一个被大多数项目忽略的问题：结构一致性检查。它使用层上同调（sheaf cohomology）进行确定性的矛盾检测，不依赖 LLM 判断，返回精确的冲突位置。

karpathy-llm-wiki——由 Astro-Han 构建，是目前唯一遵循 Agent Skills 开放标准（agentskills.io）的实现。一条命令 npx add-skill Astro-Han/karpathy-llm-wiki 即可在 Claude Code、Cursor、Codex CLI、OpenCode 等工具中安装使用。它遵循 Karpathy 原始的 raw/ → wiki/ 目录结构，维护全局索引（index.md）和追加式操作日志（log.md），提供摄取、查询、检查三个操作。项目附带真实生产数据：94 篇 Wiki 文章、99 份原始资料、7 天内 87 条操作记录——是目前少数公开展示长期运行数据的项目之一。

当智能体开始内置 Wiki

如果说开源项目的爆发是社区层面的响应，那么主流 AI 智能体平台对 LLM Wiki 的接纳，则标志着这一模式正在成为基础设施的一部分。

Hermes Agent——由 NousResearch 构建的开源智能体——在 v2.1.0 版本中将 LLM Wiki 作为一个内置捆绑技能（Bundled Skill）集成到了核心功能中。这不是一个社区贡献的第三方插件，而是项目维护者主动选择将其作为官方能力的一部分。

在 Hermes 的实现中，LLM Wiki 拥有完整的技能文档（SKILL.md），定义了标准化的目录结构、Schema 模板、标签分类体系和页面阈值。三个核心操作——摄取（Ingest）、查询（Query）、检查（Lint）——被封装为可复用的命令。每次摄取会生成摘要页并更新所有相关实体页面，页面间通过 YAML frontmatter 维护元数据一致性。社区中有人这样概括两者的互补关系："Hermes 记住你做了什么，LLM Wiki 记住你读了什么。"

Web 端实现则更进一步，采用三个专用 Go Agent（Ingest Agent、Summarize Agent、Link Agent）协作运行，底层使用 SQLite 作为任务队列，Git 作为存储后端。这种架构意味着 Wiki 的每一次变更都有版本记录，可以回溯、对比和回滚。同时支持 Obsidian 集成，包括服务器场景下的无头模式。

OpenClaw——在五个月内积累了超过 355,000 GitHub Stars 的 AI 智能体平台——则通过另一种路径拥抱了 LLM Wiki。它的 memory-wiki 伴随插件提供了一种将 LLM Wiki 的知识管理模式嵌入到智能体工作流中的方式。

OpenClaw 的"Dreaming"系统（v2026.4.7）尤其值得关注。它支持将清理后的会话转录导入 Wiki，每天自动生成"会话语料笔记"——本质上是用 LLM 把对话中的知识提取、压缩、存档，让零散的聊天记录变成可检索、可引用的知识单元。这与 Karpathy 描述的"好的答案应该被保存回 Wiki"的理念完全一致。

围绕 OpenClaw 的生态也迅速发展出了多种 Wiki 相关技能：openclaw-wiki 提供核心 Wiki 功能，openclaw-wiki-lancedb 使用 LanceDB 加 BGE 向量嵌入实现混合搜索，llm-wiki-skill 则为 OpenClaw 和 Codex 提供了跨平台兼容方案。官方技能注册表中已有超过 5,400 个技能，其中 Wiki 相关的技能数量持续增长。

这两个平台的路径不同——Hermes 走的是"深度集成"，OpenClaw 走的是"生态扩展"——但都指向同一个方向：LLM Wiki 正在从一种个人工作流，演变为智能体平台的标准能力。

争议：这真的能替代 RAG 吗？

并非所有人都买账。

在 Karpathy Gist 的评论区，一条被广泛引用的批评来自用户 @a-a-k：

"这是一个不错的个人工作流，但炒作远远走在了证据前面。没有基准测试，没有任务定义，没有扩展曲线，没有与严肃基线的对比。我们不知道这是否比混合 RAG、BM25 + 重排序、向量搜索、GraphRAG、层次摘要、长上下文提示、NotebookLM、Perplexity Spaces 或 ChatGPT Projects 更好。在没有这些证据的情况下将其称为新架构，为时尚早。"

这条评论指出了几个核心问题：

信息损失。LLM Wiki 本质上是一种有损压缩——你把原始文档改写成派生的 Wiki 页面，可能丢失注意事项、日期、少数派观点、精确措辞、边缘案例和源文档上下文。一旦人们开始查询 Wiki 而非原始材料，摘要错误就成为了知识库的一部分。

更新问题。添加一个新来源可能影响许多实体页面、概念页面、时间线、摘要和索引。在规模扩大时，这变成了图谱维护：检测变更、解决冲突、避免重复、保留来源追溯、防止过时声明、不静默破坏旧页面。"让 LLM 来维护它"不是一个工程解决方案，除非有验证器、源文件哈希、段落级引用、回归测试和人工审查。

检索并未消失。当 Wiki 增长到一定规模后，你仍然需要搜索、排名、索引、重排序、分块和访问控制。此时 Markdown Wiki 只是另一个被索引的语料库，而非 RAG 的替代品。

生产级问题被忽略。权限、多用户编辑、审计日志、回滚、删除、敏感数据、源文件版本控制、并发、合规、成本、延迟、更新频率——这些不是小细节，而是知识库系统真正失败的地方。

对此，Yarmoluk 团队提供了实际基准数据。他们在 GitHub 上公开了比较实验（BERT F1、token 经济学、跨 RAG 对比），论文地址为 github.com/Yarmoluk/ckg-benchmark/blob/main/paper/main.pdf。这是目前少数提供了量化对比的实现之一。

另一场争论围绕"Wiki"这个名称本身展开。用户 @gnusupport 认为，Karpathy 所描述的系统本质上是"带有超链接的文件系统"，而非 Ward Cunningham 意义上的 Wiki——后者要求多人实时协作编辑、争议解决机制和社区治理。将 AI 生成的静态 Markdown 笔记称为"Wiki"，在他看来是一种语言学上的误导。

这场争论没有赢家。但它揭示了一个重要事实：LLM Wiki 的真正价值不在于它叫什么名字，而在于它暴露了 RAG 范式的一个根本性缺陷——知识的临时性。

2025-2026：从 RAG 到"上下文工程"

LLM Wiki 的出现并非孤立事件。它是一个更大趋势的缩影。

2025年，RAG 技术本身经历了深刻反思和实质性演进。根据 InfoQ 的年终总结，RAG 正在从"简单的外挂知识库"演变为更成熟的"上下文工程"（Context Engineering）。Agentic RAG——Agent 驱动的主动检索与多步推理——成为年度热词。知乎上的系列文章系统梳理了 RAG 从开放域问答原型到多领域大规模应用的演化脉络。

BetterYeah 的企业级指南指出，2025年 RAG 技术的重点已从 Prompt Engineering 转向更深层的系统架构：数据治理、索引优化、部署流水线。长上下文窗口的普及并未淘汰 RAG，两者在精度、成本和可追溯性上形成了互补。

中文技术社区对 LLM Wiki 的解读则更加激进。腾讯云开发者社区的深度文章将 Karpathy 的方案称为"知识编译"——用三层架构加 Schema 契约设计，预先将文档编译为结构化知识图谱，而非在查询时临时拼接。YouTube 上的中文解析视频标题直接写道："从 RAG、GraphRAG 到大模型知识运行时"。

2026年初的展望中，RAG 被认为将与 Agent、强化学习验证奖励（RLVR）、GRPO 等技术深度融合。LLM Wiki，无论它最终是否被证明优于 RAG，已经成功地将整个行业的注意力从"如何更好地检索"转向了"如何让知识累积"。

一个诚实的评估

在写这篇文章的过程中，我反复回看 Karpathy 的原文。有一段话值得特别引用：

"这个文档是有意保持抽象的。它描述的是一个想法，不是一个具体实现。确切的目录结构、Schema 约定、页面格式、工具链——所有这些都将取决于你的领域、你的偏好、你选择的 LLM。上面提到的每一样东西都是可选的、模块化的——选你需要的，忽略你不需要的。"

这段话既是 LLM Wiki 的魅力所在，也是它的局限所在。

它是一个模式（Pattern），不是一个产品。它是一套原则，不是一个框架。这意味着每个人都需要从零开始搭建自己的系统，调试自己的 Schema，发展自己的工作流。社区已经证明了这在个人和小团队层面是可行的。但企业级、大规模、多用户、高合规要求的场景，目前仍然缺乏成熟的解决方案。

Karpathy 自己也承认了这一点。他说，LLM Wiki 最适合的场景是：中小规模、变化较慢、人工参与整理的知识收集。对于大规模、快速变化、高风险、多用户的知识库，目前的证据还远远不够。

但这不影响一个事实：2026年4月4日，一个曾经领导过 Tesla AI 和共同创办过 OpenAI 的人，用一个周末下午写下的文字，在五周内催生了一个完整的技术生态系统。这件事本身，就值得我们认真对待。

附录：关键资源