RAG 去哪儿了？从爆火到“退场”，它真的消失了吗？

不知处
0 阅读6分钟

曾经“不懂 RAG 就不算懂 Agent”，如今为何鲜少被提及？本文用一张全景图、五个核心原因和一张对比表，说透 RAG 的“沉寂”真相。

一年多前，如果你在捣鼓 AI Agent，RAG（检索增强生成） 几乎是必选项。向量数据库、Embedding、文档切片……这些概念是技术圈的“顶流”。

但最近你可能会发现，社区里聊 RAG 的声音越来越小。取而代之的是 Skills、Tools、MCP、Memory 这些词。RAG 过气了吗？还是说，我们对它的认知需要一次彻底的更新？

我梳理了背后的五个关键原因，这或许能帮你看清当前 AI 应用架构的一次重要演进。

📊 一张图看懂 RAG 的“退场”逻辑

在展开之前，先看这张全景图。五个力量共同将 RAG 从 C 位拉向了后台，但它们并非要“消灭”RAG，而是在重新定义它的战场。

flowchart LR
    subgraph A [ 五重力量压缩RAG生存空间 ]
 direction LR
        A1[Skill/Tool<br>足够好用] --> C((RAG<br>暂时退场))
        A2[RAG<br>成本不低] --> C
        A3[LLM自身<br>能力增强] --> C
        A4[Context Window<br>持续变大] --> C
        A5[Agent生态<br>以ToC为主] --> C
    end

    C --> D{等待新主场}
    D --> E[ToB Agent爆发<br>海量私有数据/精确检索]
    E --> F[RAG重回<br>大众视野]

原因一：Skill + Tool，简单到无法拒绝

最直接的原因：对大多数个人开发者和日常场景，Skill 和 Tool 已经完全够用，而且出奇地“轻”。

  • 用 Agent 在做什么？ 写代码、搜资料、整理信息、管理日程……一个web_search工具、一个run_code工具基本全覆盖。
  • Skill 是什么？ 它就是一个用自然语言写的“说明书”文件，告诉 Agent 在某类任务上应该遵循的规则、风格和流程。
  • 为何传播快？ 零配置。一个文件，分享下载即用。在 Claude Code、OpenClaw 这类产品里，社区贡献的 Skill 开箱即用，效果直观，出了问题也容易排查。

原因二：RAG 的成本，远比想象中高

RAG 的流程听起来很优雅，但实际落地时，成本体现在三个层面：

  1. 搭建成本高：选型纠结、文档切片调参、跑通 Embedding 流程……没有一两天搞不定。
  2. 费用成本不菲：主流的向量数据库、Embedding 模型调用、存储和查询，几乎都要付费。对个人或小项目，积少成多。
  3. 维护成本惊人：数据不是静态的。源文档一更新，就需要重新切片、Embedding、增量同步。这套维护逻辑的复杂度，甚至超过了业务代码本身。

对比一个只需 API 调用的免费 Tool，个人开发者自然会用脚投票。

原因三：LLM 自己，正在“内化”RAG 的价值

这是最根本的技术原因。RAG 的核心——语义搜索，正被越来越强的 LLM 自身能力覆盖。

RAG 当初要解决两大硬伤：Context Window 太小 和 理解能力有限。所以需要先检索筛选，再喂给模型。

但现在，这两块短板在快速消失：

  • 上下文窗口从 4K 暴涨到 128K、200K+，很多内容根本不需要预筛选，直接全塞进去即可。
  • 模型理解力远超当年的专用 Embedding 模型，让 LLM 自己从大量内容里找答案，反而更准。

一个典型例子是 Tool 选择问题。过去几百个 Tool 需要 RAG 预筛选，现在直接把所有 Tool 描述全部发给 LLM，让它自行判断。多花一点 Token 费用，远低于维护整套 RAG 服务的成本。这种“替代”正在许多场景悄悄发生。

原因四：张雪峰.skill 的深刻启发

前阵子，考研名师张雪峰不幸离世后，有人将他十几年的核心方法论和表达风格，整理成了一个张雪峰.skill 文件，让 Agent 能用他的风格回答问题。

这件事揭示了一个关键洞察：绝大多数人的“专业知识”，本质上是一套可以被高度结构化压缩的判断框架、经验规则和表达风格。 这些东西，一个精心编写的 System Prompt 就能承载。

真正需要 RAG 的，是无法被规则化的、必须逐条精确检索的细粒度数据，比如企业的海量客户记录、合同原文。这清晰地画出了两者的边界：

  • ❓ 能被规则化、结构化的知识 → Skill
  • ❓ 必须逐条精确检索的碎片化数据 → RAG

原因五：当下的 Agent 明星产品，几乎全是 ToC

把这五点串联起来的宏观视角是：当前令人兴奋的 Agent 产品，全是面向个人（ToC）的。

Claude Code、Cursor、Devin……它们的目标用户是个人开发者。这决定了一切：

  1. 数据量不大：个人代码库、笔记，完全用不上向量数据库。
  2. 成本极度敏感：不愿为功能额外付费。
  3. 追求开箱即用：下载必须立刻能用，才能广泛传播。

这三点，天然排斥重而贵的 RAG，天然偏好轻而快的 Skill/Tool。例如 OpenClaw 内部没有 RAG，完全靠 LLM 自身能力和 Skill 体系就运转流畅。

而 RAG 真正的用武之地——ToB 场景，企业虽有海量私有数据和精确检索的刚需，但因为数据敏感、系统接入壁垒高、决策链长、容错率低等问题，现象级的 ToB Agent 产品尚未出现。RAG 还在等待自己的主场。

总结：RAG 没有消失，它只是在等更大的舞台

最后，我们用一张表来清晰对比 Skill/Tool 与 RAG 的“此消彼长”，以及它们的本质区别：

特性对比🛠️ Skill / Tool🗄️ RAG (检索增强生成)
核心载体自然语言描述文件 (Skill) 或 API 调用 (Tool)向量数据库 + Embedding 模型 + 切片逻辑
处理知识类型可规则化、可结构化的知识 (判断框架、风格)海量、细粒度、必须精确检索的碎片化数据
使用成本极低，分享即用，多免费高 (算力、存储、维护)
维护复杂度极低，修改 Prompt 即可高，需处理数据同步、更新、失效
当前主战场ToC 应用 (个人知识库、代码辅助等)等待中的 ToB 应用 (企业数据、合规审计等)
一句话本质AI Agent 的思维框架与工具箱AI Agent 按需调阅的外部专业档案馆

技术没有好坏，只有适不适合当下的场景。

RAG 并没有“死”，它只是从需要开发者手搓的“明星技术”，变成了被云厂商封装好的后台基础能力，就像 HTTP 协议，无处不在但鲜被专门讨论。它暂时的沉寂，只是在等待企业级 Agent 应用真正爆发的那一天。到那时，RAG 将作为不可或缺的核心组件，重返舞台中央。

感谢阅读！ 如果你觉得这篇文章理清了思路，欢迎点赞、收藏和转发。你对 RAG 或 Skill 的未来怎么看？评论区聊聊。

avatar
文章
阅读
粉丝