大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



大家好，我是双越。wangEditor 作者，前百度 滴滴 资深前端工程师，慕课网金牌讲师，PMP，前端面试派 作者。

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

• 【划水AI】 Node 全栈 AIGC 知识库，包括 AI 写作、多人协同编辑。复杂业务，真实上线。
• 【智语】 AI 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 去哪儿了？它消失了吗？还是说我们的认知需要更新？

我认为有以下几个原因。

先说最直接的原因：对于绝大多数 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 听起来很美，但真正用起来，你会发现成本比想象中高很多------不只是钱，还有时间和精力。

搭建成本：

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

费用成本：

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

维护成本：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

能被规则化、结构化表达的知识 → Skill

必须逐条精确检索的数据 → RAG

把上面所有原因加在一起，还有一个更宏观的视角：当前 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 并没有消失，它只是从"前台明星技术"退到了"后台等待区"。

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

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

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

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

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

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

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