最近大火的 AI Wiki 到底是什么？和 RAG、记忆到底有什么关系

先说结论

这段时间 AI 圈里反复出现的 wiki，大概率不是在说传统意义上的 Wikipedia，也不是在说公司里那种普通文档站。

它更像一种新的知识组织方式：

• 原始资料继续保留
• LLM 不再每次临时现查现拼
• 而是把读过的东西持续整理成一个可更新、可链接、可复用的 wiki 层

所以这波 wiki 火起来，本质上不是“大家突然又爱上百科了”，而是大家慢慢发现，纯 prompt 不够，纯 RAG 也不够，Agent 需要一个能持续积累知识的中间层。

一句话概括：

• RAG 更像“临时翻资料”
• memory 更像“记住偏好、状态和过程”
• wiki 更像“把知识整理成一套长期可维护的外部脑子”

最近这波 AI Wiki，火的到底是什么

如果你最近刷 X、GitHub 或 Agent 圈博客，看到大家在聊 wiki，大多绕不开两条线。

第一条线是 DeepWiki。

DeepWiki 是 Cognition 推出来的 repo wiki 方案。Cognition 在 2025 年 5 月 5 日 发布了公开版 DeepWiki，主打“给任何公开仓库自动生成 wiki 式文档”；到了 2026 年，官方文档里已经把它描述成会自动索引仓库、生成架构图、源码链接和代码总结，还能通过 MCP 直接读 wiki 结构和内容。

第二条线是 Karpathy 的 LLM Wiki。

Andrej Karpathy 在 2026 年 4 月 4 日 发了一个 LLM Wiki gist，这个东西不是产品，而是一份“思路文件”。它最打动人的地方在于，它不是让 LLM 每次都去原始文档里重新捞片段，而是让 LLM 持续维护一套 markdown wiki，把知识一点点编译出来。

这两条线看起来不一样，一个偏代码仓库，一个偏个人或团队知识库，但底层想法其实很像：

不要每次都从原材料重新理解一遍，而是把理解过的东西沉淀下来。

AI 圈里的 Wiki，到底不是啥

先排除几个容易混淆的东西。

它不是普通文档目录。

普通文档库的问题是，文档往往越堆越多，但结构不一定越来越清楚。很多团队最后不是没资料，而是资料太散，没人愿意维护。

它也不是单纯的向量库。

向量库擅长“召回相似内容”，但它不负责把知识组织成一个稳定结构。你今天问一次，明天再问一次，模型可能还是得重新拼。

它更不是“把所有文件丢给 ChatGPT”。

那种做法常常只能解决一次性问题。问浅一点的问题还行，问深一点、跨文档、跨时间的问题，模型就容易重复劳动，甚至前后不一致。

所以 AI 圈里说的 Wiki，重点不在“文件存哪”，而在：

• 知识有没有被整理
• 页面之间有没有关系
• 新资料来了以后，旧知识会不会更新
• 同一个结论下次还能不能复用

它为什么最近又突然火了

因为很多人都踩到了同一个坑：纯 RAG 在简单问答上够用，但在长期任务和复杂 Agent 场景里，很容易不够用。

RAG 的优点很明显：

• 上手快
• 对原始资料侵入小
• 查资料型问题很好用

但它也有一个天然限制：它默认每次查询都像一次“临时开卷考试”。

也就是说：

• 资料是原始的
• 召回是临时的
• 综合结论也是临时拼的

如果问题很复杂，比如要横跨十几篇文档、好几轮任务、多个矛盾来源，模型每次都重新检索和重组，成本就高，稳定性也一般。

这时候大家就会很自然地往前走一步：

能不能不要每次都重新读？
能不能把已经读明白的东西保存下来？
能不能把事实、实体、结论、冲突、时间线都慢慢整理成一套外部知识层？

这就是 Wiki 重新火起来的原因。

说白了，RAG 更像临时搜索，Wiki 更像持续编书。

AI Wiki 的核心思路到底是什么

Karpathy 那份 LLM Wiki 其实把这个思路说得很清楚了。它大概分三层：

1. 原始资料层
   文章、论文、会议记录、Slack 对话、仓库代码、日志，这些都保留原样，不随便改。

2. Wiki 层
   由 LLM 维护的一组 markdown 页面，负责摘要、实体页、主题页、关联页、比较页和综合结论。

3. Schema 层
   告诉 LLM 应该怎么维护这套 wiki，比如页面怎么命名、什么时候更新、怎么处理冲突、怎么引用来源。

真正关键的，不是“生成一篇总结”，而是 持续维护。

新资料来了以后，它不是简单丢进索引里等以后查，而是会触发这些动作：

• 更新相关页面
• 补充新事实
• 修正旧结论
• 标记冲突信息
• 建立交叉链接

这时候知识就不是散落的片段，而是越来越像一个可以长期工作的系统。

它和 RAG、记忆、向量库到底怎么区分

这是最容易讲乱的地方。

最简单的理解方式是看它们分别在解决什么问题。

RAG 在解决什么

RAG 解决的是：现在这个问题，应该去哪里找资料。

它擅长的是召回。

比如：

• 查某个 API 文档
• 找某个报错的相关片段
• 从知识库里找最相关的几段内容

它的重点是“找”。

memory 在解决什么

memory 解决的是：这个系统应该记住什么，才能下次继续干活。

它更偏运行态。

比如：

• 用户偏好
• 当前任务状态
• 已做过哪些步骤
• 哪些工具调用失败过

它的重点是“记住过程和状态”。

wiki 在解决什么

wiki 解决的是：已经理解过的知识，怎么沉淀成长期可复用的结构化内容。

比如：

• 某个项目里有哪些核心模块
• 某个客户有哪些关键历史事实
• 某个研究主题有哪些结论、争议和证据链

它的重点是“整理成知识”。

向量库在解决什么

向量库解决的是：如何高效做相似检索。

它是能力组件，不是最终知识形态。

所以一个更接近真实工程的关系通常是：

• 向量库给 RAG 提供召回能力
• memory 保存任务状态和用户上下文
• wiki 沉淀长期知识结构
• Agent 再把它们组合起来用

为什么很多人会觉得 Wiki 比纯 RAG 更“像人”

因为人类处理复杂知识，本来就不是每次都从原始材料重新开始。

一个做研究的人，不会每次回答问题都把几十篇论文从头读一遍。他会有：

• 笔记
• 主题归纳
• 实体关系
• 关键结论
• 冲突观点

本质上，这就是个人 wiki。

所以 LLM Wiki 让人有感觉，不是因为这个词新，而是因为它更接近人类长期学习的方式：

先读原始资料，再整理成自己的知识结构，之后主要基于这个结构继续思考。

这也是为什么很多人会把它看成 Agent memory 的一个更靠谱方向。因为比起只存聊天记录，wiki 更强调：

• 事实沉淀
• 结构清晰
• 可持续修改
• 可跨任务复用

用一个 Agent 场景看懂它的价值

假设你在做一个“自动修 bug 的 Agent”。

如果你只有 prompt 和 RAG，系统可能每次都这样：

• 搜测试日志
• 搜相关代码
• 搜历史提交
• 临时拼一个解释
• 改完代码后下一轮又重新搜

这当然能工作，但很容易重复劳动。

如果你加上一层 Wiki，事情会变成这样：

• 第一次分析后，把“模块边界”“常见故障点”“历史坑位”“测试依赖关系”写进 wiki
• 第二次再遇到类似问题时，先读 wiki，再去补充新日志和新 diff
• 发现某个模块最近又改过，就更新对应页面
• 最后把这次修复的新结论继续沉淀回 wiki

这样跑几轮之后，这个 Agent 手里就不只是“历史聊天记录”，而是一套越来越像经验库的东西。

这就是为什么很多人会说，Wiki 比单纯记忆更适合复杂任务。

什么情况下你做的是知识库，什么情况下你做的是 Wiki

这个判断其实很实用。

如果你的系统只是：

• 存了一堆文档
• 做了切片
• 建了索引
• 查的时候召回几段

那你大概率做的是知识库，或者更具体一点，做的是 RAG 底座。

如果你的系统已经开始做这些事：

• 自动生成主题页和实体页
• 新资料来了会更新旧页面
• 页面之间有明确链接关系
• 有统一结构和维护规则
• 同一个结论会不断被修订，而不是每次重新现编

那你就开始接近 Wiki 了。

所以 Wiki 最重要的区别，不是页面长什么样，而是它是不是一个 持续演化的知识产物。

这波热度里，最值得关注的其实不是产品，而是思路

我觉得这点特别重要。

DeepWiki 让很多人第一次直观看到，“原来代码仓库也可以被自动整理成 wiki”；Karpathy 的 LLM Wiki 又把这个思路往前推了一步，变成“任何长期知识工作，都可以让 LLM 去维护一套外部知识层”。

所以这波真正值得记住的，不是某个产品名，而是一个越来越清晰的趋势：

Agent 不只是要会搜，还要会整理；不只是会回答，还要会积累。

这也是为什么我觉得 wiki 这个词会继续火下去。因为它刚好补上了 prompt、RAG 和短期 memory 之间一直缺的那块东西。

结尾

最近 AI 圈里的 wiki 之所以火，不是因为大家又想回到传统文档时代，而是因为大家终于越来越清楚：

如果你想让 Agent 真正长期工作，它不能每次都只靠临时检索和临时生成，它需要一个能不断沉淀、修订和复用知识的外部脑。

RAG 负责找，memory 负责记，wiki 负责把“已经理解过的东西”变成长期资产。

当你这样看它时，你就会明白，这波 AI Wiki 的热度，其实不是噱头，而是在补 Agent 工程里一块很现实的短板。