最近大火的 AI Wiki 到底是什么和 RAG、记忆到底有什么关系文章目录最近大火的 AI Wiki 到底是什么和 RAG、记忆到底有什么关系先说结论最近这波 AI Wiki火的到底是什么AI 圈里的 Wiki到底不是啥它为什么最近又突然火了AI Wiki 的核心思路到底是什么它和 RAG、记忆、向量库到底怎么区分RAG 在解决什么memory 在解决什么wiki 在解决什么向量库在解决什么为什么很多人会觉得 Wiki 比纯 RAG 更“像人”用一个 Agent 场景看懂它的价值什么情况下你做的是知识库什么情况下你做的是 Wiki这波热度里最值得关注的其实不是产品而是思路结尾先说结论这段时间 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 Wikigist这个东西不是产品而是一份“思路文件”。它最打动人的地方在于它不是让 LLM 每次都去原始文档里重新捞片段而是让 LLM持续维护一套 markdown wiki把知识一点点编译出来。这两条线看起来不一样一个偏代码仓库一个偏个人或团队知识库但底层想法其实很像不要每次都从原材料重新理解一遍而是把理解过的东西沉淀下来。AI 圈里的 Wiki到底不是啥先排除几个容易混淆的东西。它不是普通文档目录。普通文档库的问题是文档往往越堆越多但结构不一定越来越清楚。很多团队最后不是没资料而是资料太散没人愿意维护。它也不是单纯的向量库。向量库擅长“召回相似内容”但它不负责把知识组织成一个稳定结构。你今天问一次明天再问一次模型可能还是得重新拼。它更不是“把所有文件丢给 ChatGPT”。那种做法常常只能解决一次性问题。问浅一点的问题还行问深一点、跨文档、跨时间的问题模型就容易重复劳动甚至前后不一致。所以 AI 圈里说的 Wiki重点不在“文件存哪”而在知识有没有被整理页面之间有没有关系新资料来了以后旧知识会不会更新同一个结论下次还能不能复用它为什么最近又突然火了因为很多人都踩到了同一个坑纯 RAG 在简单问答上够用但在长期任务和复杂 Agent 场景里很容易不够用。RAG 的优点很明显上手快对原始资料侵入小查资料型问题很好用但它也有一个天然限制它默认每次查询都像一次“临时开卷考试”。也就是说资料是原始的召回是临时的综合结论也是临时拼的如果问题很复杂比如要横跨十几篇文档、好几轮任务、多个矛盾来源模型每次都重新检索和重组成本就高稳定性也一般。这时候大家就会很自然地往前走一步能不能不要每次都重新读能不能把已经读明白的东西保存下来能不能把事实、实体、结论、冲突、时间线都慢慢整理成一套外部知识层这就是 Wiki 重新火起来的原因。说白了RAG 更像临时搜索Wiki 更像持续编书。AI Wiki 的核心思路到底是什么Karpathy 那份LLM Wiki其实把这个思路说得很清楚了。它大概分三层原始资料层文章、论文、会议记录、Slack 对话、仓库代码、日志这些都保留原样不随便改。Wiki 层由 LLM 维护的一组 markdown 页面负责摘要、实体页、主题页、关联页、比较页和综合结论。Schema 层告诉 LLM 应该怎么维护这套 wiki比如页面怎么命名、什么时候更新、怎么处理冲突、怎么引用来源。真正关键的不是“生成一篇总结”而是持续维护。新资料来了以后它不是简单丢进索引里等以后查而是会触发这些动作更新相关页面补充新事实修正旧结论标记冲突信息建立交叉链接这时候知识就不是散落的片段而是越来越像一个可以长期工作的系统。AI wiki knowledge loopThis diagram shows how raw sources are compiled by an LLM into a maintained wiki, which then becomes a reusable knowledge layer for future queries and tasks.补充新资料原始资料文档 代码 记录 日志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 工程里一块很现实的短板。