小編精選 - 技術文章翻譯 · 04月26日

為什麼現在越來越少提及 RAG 了

為什麼現在 RAG 越來越少被提及了

大家好，我是雙越。[wangEditor](https://link.juejin.cn?target=https%3A%2F%2Fwww.wangeditor.com%2F) 作者，前百度、滴滴 資深前端工程師，慕課網金牌講師，PMP，[前端面試派](https://link.juejin.cn?target=https%3A%2F%2Fwww.mianshipai.com%2F) 作者。

我正致力於兩個專案的開發和升級，有興趣的可以私訊我，加入專案小組。

【划水 AI】 Node 全端 AIGC 知識庫，包括 AI 寫作、多人協作編輯。複雜業務，真實上線。
【智語】 AI Agent 智能體專案。一個智慧面試官，可以優化履歷、模擬面試、解答題目等。

本文分析一個現象：為什麼現在 RAG 越來越少被提及了，歡迎留言評論。

記得去年，學 Agent 必學 RAG

2024、2025 年，如果你在學習 AI Agent，RAG（檢索增強生成）幾乎是繞不開的話題。

各種教學、課程、YouTube 影片，開篇必講 RAG。什麼是向量資料庫、什麼是 Embedding、如何做文件切片、如何調相似度閾值……學完之後還要折騰 Pinecone、Weaviate、Chroma，踩一堆坑。

那時候的感覺是：不懂 RAG，就不算真的懂 Agent。

但最近一年，情況悄悄變了。

打開各種 Agent 框架的文件，看社群裡大家在討論什麼，聽 Podcast 裡在聊什麼——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 足夠用大多數場景不需要 RAGRAG 成本高toC 使用者主動迴避LLM 能力增強語意搜尋可以被模型內化Context Window 變大不再需要預先篩選Agent 以 toC 為主個人資料量小，RAG 無用武之地五個力量同時在壓縮 RAG 的生存空間。

但 RAG 並沒有消失，它只是從「前台明星技術」退到了「後台等待區」。

就像 HTTP 協議，你不會每次聊起 Web 開發都專門提它，但它一直都在。很多雲端廠商的 AI 服務已經把 RAG 封裝好了，開發者不需要手刻，自然就少被專門討論。

更重要的是，當 toB Agent 真正爆發的那一天，RAG 很可能重回大眾視野。

企業場景天生就是：海量私有資料、精確檢索、權限隔離、合規稽核。這些全是 RAG 的主場。

所以，正確的理解不是「RAG 死了」，而是：