为什么现在 RAG 越少越少提及了

双越AI_club

2026-04-23 1,627 阅读9分钟

关注

大家好，我是双越。[wangEditor](https://link.juejin.cn/?target=https%3A%2F%2Fwww.wangeditor.com%2F "https://www.wangeditor.com/") 作者，前百度滴滴资深前端工程师，慕课网金牌讲师，PMP，[前端面试派](https://link.juejin.cn/?target=https%3A%2F%2Fwww.mianshipai.com%2F "https://www.mianshipai.com/") 作者。

我正致力于两个项目的开发和升级，感兴趣的可以私信我，加入项目小组。

[【划水AI】](https://link.juejin.cn/?target=https%3A%2F%2Fwww.huashuiai.com%2F "https://www.huashuiai.com/") Node 全栈 AIGC 知识库，包括 AI 写作、多人协同编辑。复杂业务，真实上线。
[【智语】](https://link.juejin.cn/?target=https%3A%2F%2Fzhitalk.chat%2F "https://zhitalk.chat/") AI Agent 智能体项目。一个智能面试官，可以优化简历、模拟面试、解答题目等。

本文分析一个现象：为什么现在 RAG 越少越少提及了，欢迎留言评论。

记得去年，学 Agent 必学 RAG

2024、2025 年，如果你在学习 AI Agent，RAG（检索增强生成）几乎是绕不开的话题。

各种教程、课程、YouTube 视频，开篇必讲 RAG。什么是向量数据库、什么是 Embedding、如何做文档切片、如何调相似度阈值……学完之后还要折腾 Pinecone、Weaviate、Chroma，踩一堆坑。

那时候的感觉是：不懂 RAG，就不算真的懂 Agent。

但最近一年，情况悄悄变了。

打开各种 Agent 框架的文档，看社区里大家在讨论什么，听播客里在聊什么——RAG 的出现频率越来越低了。取而代之的是另一套词汇：Skills、Tools、MCP、Memory、Context Files、Cron、Channels……

RAG 去哪儿了？它消失了吗？还是说我们的认知需要更新？

我认为有以下几个原因。

原因一：Skill + Tool 已经足够用了

先说最直接的原因：对于绝大多数 Agent 的日常使用场景，Skill 和 Tool 完全够用。

想一想你平时用 Agent 在做什么？

写代码、调试、重构
写文章、做分析报告
查资料、整理信息
发邮件、管日历

这些场景，一个 web_search tool、一个 run_code tool、一个 read_file tool，基本上全搞定了。

更重要的是，Skill 和 Tool 的传播成本极低。

一个 skill 文件，就是一段文字描述，告诉 Agent 怎么做某件事。你可以通过 GitHub 分享，别人下载下来就能用，几乎零配置。Claude Code、OpenClaw 这类产品，社区里有人做好了各种 skill，直接拿来用就行。

而且效果好，用起来直觉，出了问题也容易排查。这种简单、易传播、效果好的特性，让 skill/tool 迅速成为 Agent 生态的主流选择。

原因二：RAG 的成本真的不低

RAG 听起来很美，但真正用起来，你会发现成本比想象中高很多——不只是钱，还有时间和精力。

搭建成本：

你需要选一个向量数据库（Pinecone？Weaviate？Qdrant？），注册账号，搞明白它的 API，写数据导入的逻辑，处理文档切片（chunk size 多少？overlap 多少？），跑 Embedding 模型把文本向量化……光是把这套流程跑通，没有一两天搞不定。

费用成本：

主流向量数据库几乎都不免费。Embedding 模型调用要花 token 费用，存储要花钱，查询要花钱。对于个人开发者或者小项目来说，这些费用加起来并不便宜。

维护成本：

数据不是一次性的。文档更新了怎么办？要重新 Embedding，要更新向量库，要处理增量同步……这套维护逻辑，比代码本身还麻烦。

相比之下，一个 tool 就是一次 API 调用，很多还是免费的（搜网页、读本地文件）。

对于个人开发者，这笔账很好算：能用 tool 解决的，为什么要搭一套 RAG pipeline？

原因三：LLM 自身能力在不断填平 RAG 的价值

这是最根本的原因，也是最容易被忽视的一个。

RAG 的核心能力是什么？语义搜索——从大量文本里，找出跟当前问题最相关的内容。

但问题是：LLM 天生就支持语义理解，而且理解能力已经比早期的 Embedding 模型强太多了。

RAG 出现的时候，LLM 有两个硬伤：

Context Window 太小，4K token 根本装不下多少内容，必须先筛选再喂给模型
理解能力有限，需要专门训练的 Embedding 模型来做向量相似度计算

所以 RAG 的逻辑是：先用向量搜索把候选内容缩小到几条，再把这几条喂给 LLM。

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

Context Window 从 4K 涨到了 128K，再到 200K+，很多内容根本不需要预筛选，直接全塞进去就行
LLM 的语义理解能力远超当年，让它自己在一大堆内容里找答案，反而更准

举一个具体例子：Tool 选择问题。

早期 Agent 如果有几百个 tool，context 装不下，就得用 RAG：先把问题向量化，检索出最相关的几个 tool，再交给 LLM 选择。

现在呢？直接把所有 tool 的描述全部发给 LLM，让它自己判断用哪个。多花了一点 token，但省掉了整套向量检索的基础设施。

多花一点 LLM token 的费用，远比维护一套 RAG 服务的费用和复杂度要低得多。

这种替代正在悄悄发生在很多场景里。LLM 越来越强，它能直接"内化"的事情越来越多，中间那层"预处理"的必要性就越来越低。

原因四：张雪峰.skill 给我的启发

前段时间，考研指导领域的知名博主张雪峰不幸因心源性猝死离世，年仅 41 岁，令人惋惜。

他做了十几年的考研、志愿填报指导，粉丝数千万，内容跨越无数场直播、课程、视频。按理说，这么多年积累的"知识量"应该是海量的。

但让我没想到的是，有人在他去世后，把他生前的核心语录和方法论，整理成了一个 `张雪峰.skill`（GitHub 上可以找到），让 Agent 用他的风格和逻辑回答升学问题。

一个 skill 文件，就装下了他十几年的精华。

这件事让我重新思考了一个问题：我们普通人积累的"专业知识"，到底有多少？

答案可能是：没有我们想象中那么多。

绝大多数人的"专业知识"，本质上是：

一套判断框架（遇到这种情况，应该怎么分析）
一些经验规则（这个专业就业不好，那个城市机会更多）
一种表达风格（接地气、直白、不绕弯子）

这些东西，高度结构化，完全可以被一个 skill 的 system prompt 压缩表达。

真正需要 RAG 的，是那种无法被规则化的细粒度数据——比如企业里每一条客户记录、每一份合同原文、每一个历史订单的具体信息。张雪峰的知识属于前者，所以一个 skill 就够了。

这个例子，把 RAG 和 skill 的边界说得很清楚：

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

原因五：现在的 Agent 产品几乎全是 toC 的

把上面所有原因加在一起，还有一个更宏观的视角：当前 Agent 生态，主角是 toC 产品。

Claude Code、OpenClaw、Cursor、Devin……这些让社区兴奋的明星产品，针对的都是个人用户。

个人用户的特点是什么？

数据量不大。你的代码库、你的笔记、你的文档，说到底就那么多，完全不需要向量数据库来管理
成本敏感。个人用户不愿意为了一个功能额外付费订阅第三方服务
追求开箱即用。下载安装，马上能用，才会被推荐传播

这三点加在一起，直接决定了：toC 的 Agent 产品，天然排斥 RAG，天然偏向 skill/tool。

以 OpenClaw 为例，它内部没有 RAG，也没有向量数据库，照样能正常运行完整的 memory、tools、skills 机制。靠的就是 LLM 自身的强大能力，加上精心设计的 skill 体系。

反观 toB 的场景：企业有海量的私有数据，有精确检索的需求，有合规审计的要求，成本相对不敏感……这些特征，全部指向 RAG。

但问题是：目前还没有出现一个现象级的 toB Agent 明星产品。

Salesforce Agentforce、ServiceNow 的 AI Agent 在做，一些垂直领域（法律、医疗、金融）也有探索，但都还没有"出圈"——没有达到 Claude Code 那种让整个开发者社区都在讨论的程度。

这不是偶然的。toB 的 Agent 落地有更高的壁垒：

企业数据敏感，不能随便上云，私有化部署的模型能力又差一截
接入企业已有系统（ERP、CRM、几十年的遗留系统）成本极高
决策链条长，IT、法务、采购都要过，推进慢
出错代价高，Agent 搞错了一条生产数据，比开发者看到一段错误代码严重得多

所以 toB Agent 还在蓄力，还没到爆发的时候。

总结：RAG 没有消失，只是在等待自己的主场

把所有原因梳理在一起：

| 原因 | 对 RAG 的影响 | | --- | --- | | Skill/Tool 足够用 | 大多数场景不需要 RAG | | RAG 成本高 | toC 用户主动回避 | | LLM 能力增强 | 语义搜索可以被模型内化 | | Context Window 变大 | 不再需要预筛选 | | Agent 以 toC 为主 | 个人数据量小，RAG 无用武之地 |

五个力量同时在压缩 RAG 的生存空间。

但 RAG 并没有消失，它只是从"前台明星技术"退到了"后台等待区"。

就像 HTTP 协议，你不会每次聊起 Web 开发都专门提它，但它一直在那里。很多云厂商的 AI 服务已经把 RAG 封装好了，开发者不需要手搓，自然就少被专门讨论。

更重要的是，当 toB Agent 真正爆发的那一天，RAG 很可能重回大众视野。

企业场景天然就是：海量私有数据、精确检索、权限隔离、合规审计。这些全是 RAG 的主场。

所以，正确的理解不是"RAG 死了"，而是：

当前 Agent 生态以 toC 为主，个人产品的场景和约束，让 Skill/Tool 成为主角，RAG 暂时退场。一旦 toB Agent 起来，RAG 还会回来。

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

RAG 现在的沉寂，只是在等一个更大的舞台。

标签：

Agent 人工智能

Image 3: avatar

0/ 1000

标点符号、链接等不计算在有效字数内

⌘ + Enter

发送

登录 / 注册即可发布评论！

最热

相关推荐

[掘友们，一人说一个你买过夯到爆的东西 | 沸点周刊 4.23 708阅读 · 13点赞](http://juejin.cn/post/7631615998697291827 "掘友们，一人说一个你买过夯到爆的东西 | 沸点周刊 4.23")[我从 Nano Banana 回来了，GPT-Image-2 真的太强了 379阅读 · 3点赞](http://juejin.cn/post/7631394312985755699 "我从 Nano Banana 回来了，GPT-Image-2 真的太强了")[智谱CodingPlan老套餐绝版了，全网token收拢！ 1.5k阅读 · 15点赞](http://juejin.cn/post/7631506248647917609 "智谱CodingPlan老套餐绝版了，全网token收拢！")[马斯克 600 亿美元收购 Cursor！史上最贵「分手费」100 亿，xAI 代码能力要起飞了 328阅读 · 2点赞](http://juejin.cn/post/7631473695153700890 "马斯克 600 亿美元收购 Cursor！史上最贵「分手费」100 亿，xAI 代码能力要起飞了")[AI圈又出“爱马仕“了：一个打了工人钱包，一个打了中国团队的脸 3.0k阅读 · 9点赞](http://juejin.cn/post/7630250341712707584 "AI圈又出“爱马仕“了：一个打了工人钱包，一个打了中国团队的脸")

精选内容

[Flutter进阶：用OverlayEntry 实现所有弹窗效果 SoaringHeart · 102阅读 · 2点赞](http://juejin.cn/post/7632207921896914998 "Flutter进阶：用OverlayEntry 实现所有弹窗效果")[写 HTML 就能做视频？HeyGen 开源的这个工具有点意思奇舞精选 · 92阅读 · 0点赞](http://juejin.cn/post/7632207921896865846 "写 HTML 就能做视频？HeyGen 开源的这个工具有点意思")[LangGraph 使用指南 remember_me · 40阅读 · 0点赞](http://juejin.cn/post/7632142002248532019 "LangGraph 使用指南")[基于动态 NFT 的奢侈品腕表全生命周期溯源系统：Solidity 合约设计与 Hardhat/Viem 测试实践木西 · 28阅读 · 0点赞](http://juejin.cn/post/7631972087611605002 "基于动态 NFT 的奢侈品腕表全生命周期溯源系统：Solidity 合约设计与 Hardhat/Viem 测试实践")[「前端何去何从」事件循环是 Node.js 的心跳从文处安 · 27阅读 · 0点赞](http://juejin.cn/post/7632222240524533760 "「前端何去何从」事件循环是 Node.js 的心跳")

找对属于你的技术圈子

回复「进群」加入官方微信群

Staticy
7年前
5.3k
55
1

[TypeScript](http://juejin.cn/tag/TypeScript "TypeScript")

* [为什么Web前端语言只有JavaScript?](http://juejin.cn/post/6844903863506436103 "为什么Web前端语言只有JavaScript?") 2.JavaScript作为浏览器时代最早产生且经过浏览器大战及历史的沉淀中脱颖而出的语言，且成Web前端第一套标准，也是Web前端唯一一套成熟的标准。 1.javaScript作为所有浏览器内核兼容性最好、性能最优的前提，作为Web前端支持语言中的王者也是必然。 2.java…

Eric_V
6年前
435
点赞
评论

[HTML](http://juejin.cn/tag/HTML "HTML")

* [永远学习：为什么人工智能难以适应新挑战](http://juejin.cn/post/7411406818025783306 "永远学习：为什么人工智能难以适应新挑战") 理解深度学习的局限性并追求真正的持续适应编辑欢迎来到雲闪世界。近年来，人工智能取得了长足的进步。所有这些系统都以某种形式使用了人工神经元。这些算法的灵感来自它们的生物对应物。例如，神经元会聚

雲闪世界
1年前
201
点赞
评论

[前端](http://juejin.cn/tag/%E5%89%8D%E7%AB%AF "前端")[后端](http://juejin.cn/tag/%E5%90%8E%E7%AB%AF "后端")

* [[英] 顾虑越少，设计越好](http://juejin.cn/post/6844903443652411405 "[英] 顾虑越少，设计越好") 或许提升 UI 设计的最佳途径就是减少一些自己的顾虑。该文章正在掘金翻译计划 (https://github.com/xitu/gold-miner) 中翻译，请译者重新翻译题目，大家可以持续关注掘金翻译计划标签以获取最新译文。

小菜一只
9年前
1.7k
27
2

[设计](http://juejin.cn/tag/%E8%AE%BE%E8%AE%A1 "设计")[设计师](http://juejin.cn/tag/%E8%AE%BE%E8%AE%A1%E5%B8%88 "设计师")

![Image 15: [英] 顾虑越少，设计越好](https://p1-jj.byteimg.com/tos-cn-i-t2oaga2asx/leancloud-assets/783dc6067da5bd0df4e8.jpeg~tplv-t2oaga2asx-jj:108:72:0:0:q75.avis)

* [程序员的代码行数是越少越好吗？](http://juejin.cn/post/6844903958842966030 "程序员的代码行数是越少越好吗？") 作为开发人员，你会听到许多有关“代码行数”的令人难以置信的疯狂理论——不要相信他们！以代码行数作为决策依据是一件非常荒谬的事情。在极少数情况下，代码行数可能还有那么一丁点意义，在绝大数情况下，代码行数什么都代表不了。根据代码行数做决策就好像按照页数评价书籍的水准。有些人可能会…

千锋Python的大橙子
6年前
274
点赞
评论

[Python](http://juejin.cn/tag/Python "Python")

* [AI火了,知识图谱反而更尴尬了](http://juejin.cn/post/7367577126856867874 "AI火了,知识图谱反而更尴尬了") 上一轮 AI 革命的主角之一的知识图谱, 在实践中却很少再被提及, 人们宁愿用搜索结合大模型(RAG), 而不是用精致复杂的知识图谱。甚至有人认为它的位置更加尴尬了。本文将探讨其背后的原因

深度不学习
1年前
5.1k
38
15

[后端](http://juejin.cn/tag/%E5%90%8E%E7%AB%AF "后端")[人工智能](http://juejin.cn/tag/%E4%BA%BA%E5%B7%A5%E6%99%BA%E8%83%BD "人工智能")

* [TypeScript入门与实践](http://juejin.cn/post/6844903664973250573 "TypeScript入门与实践") 初衷：当我使用一些常见的前端框架和库，发现现在很多框架和库都已经使用了TypeScript的时候；当我在项目中使用某些库产生了bug，因为时间问题我急着解决问题，自己去找库的bug，然而我发现这些ts编写的文件让我无处下手的时候；当我想看用TypeScript编写的antd d…

童话镇
7年前
532
点赞
1

[React.js](http://juejin.cn/tag/React.js "React.js")[JavaScript](http://juejin.cn/tag/JavaScript "JavaScript")[前端](http://juejin.cn/tag/%E5%89%8D%E7%AB%AF "前端")

* [MySQL为什么有时候会选错索引？我们怎么解决呢？](http://juejin.cn/post/7011514237189095431 "MySQL为什么有时候会选错索引？我们怎么解决呢？") 我们需要知道的第一个知识是使用哪个索引是由 MySQL来确定的。在数据库里面，扫描行数是影响执行代价的因素之一。扫描的行数越少，意味着访问磁盘数据的次数越少，消耗的 CPU 资源越少。 mysql中扫

小饶coding
4年前
163
点赞
评论

[MySQL](http://juejin.cn/tag/MySQL "MySQL")

* [少写代码少填坑 – Medium](http://juejin.cn/post/6844903443547553800 "少写代码少填坑 – Medium") 我不是这个世界上最有才的程序员。是的，我知道这是真的。所以我尝试尽可能少写代码。我写得越少，破坏越少，调整和维护的工作量也就越少。我也很懒，所以觉得一切过得去就行了。然而，事实证明让 Web 变得高效的唯一行之有效的方法也只是少写代码。 https://medium.com/@Heydon/writing-less-damn-code-27ec8b844503#.8xk7jiw1o

AleCC
9年前
2.8k
82
2

[CSS](http://juejin.cn/tag/CSS "CSS")[前端](http://juejin.cn/tag/%E5%89%8D%E7%AB%AF "前端")[代码规范](http://juejin.cn/tag/%E4%BB%A3%E7%A0%81%E8%A7%84%E8%8C%83 "代码规范")

* [为什么要分库分表?](http://juejin.cn/post/6854573219114909704 "为什么要分库分表?") 其实这块肯定是扯到高并发了，因为分库分表一定是为了支撑高并发、数据量大两个问题的。而且现在说实话，尤其是互联网类的公司面试，基本上都会来这么一下，分库分表如此普遍的技术问题，不问实在是不行，而如果你不知道那也实在是说不过去！说白了，分库分表是两回事儿，大家可别搞混了，可能是光…

松华说
5年前
4.3k
26
1

[Java](http://juejin.cn/tag/Java "Java")

* [MySQL选错索引了怎么办？](http://juejin.cn/post/7146219347449479182 "MySQL选错索引了怎么办？") 在 MySQL 中一张表是可以支持多个索引的。但是，你写 SQL 语句的时候，并没有主动指定使用哪个索引。也就是说，使用哪个索引是由 MySQL 来确定的。不知道你有没有碰到过这种情况，一条本来可以

杨同学technotes
3年前
473
22
评论

[MySQL](http://juejin.cn/tag/MySQL "MySQL")

* [为什么MySQL索引结构采用B+树？](http://juejin.cn/post/7111211722890805278 "为什么MySQL索引结构采用B+树？") 一位6年经验的小伙伴去字节面试的时候被问到这样一个问题，为什么MySQL索引结构要采用B+树？这位小伙伴从来就没有思考过这个问题。只因为现在都这么卷，后面还特意查了很多资料，他也希望听听我的见解。另

Tom弹架构
3年前
3.0k
23
3

[程序员](http://juejin.cn/tag/%E7%A8%8B%E5%BA%8F%E5%91%98 "程序员")[编程语言](http://juejin.cn/tag/%E7%BC%96%E7%A8%8B%E8%AF%AD%E8%A8%80 "编程语言")

* [使用coze扣子搭建智能bot「程序员的工具箱」的思考和总结](http://juejin.cn/post/7361323113156755482 "使用coze扣子搭建智能bot「程序员的工具箱」的思考和总结") 使用coze扣子搭建智能bot「程序员的工具箱」的思考和总结：大模型已经火了快 2 年的时间了，从简单的文字处理的单一场景到到现在的企业迫切需要 LLM 在更多的场景赋能的时代。大众也从简单问答

demo007x
2年前
4.4k
26
5

[LLM](http://juejin.cn/tag/LLM "LLM")[程序员](http://juejin.cn/tag/%E7%A8%8B%E5%BA%8F%E5%91%98 "程序员")[人工智能](http://juejin.cn/tag/%E4%BA%BA%E5%B7%A5%E6%99%BA%E8%83%BD "人工智能")