技术演进视角：RAG失宠背后的五重逻辑与开发者应对策略

我是从2024年开始系统研究AIAgent技术栈的开发者。那一年，RAG几乎等于Agent入门的门票，不懂向量检索、不跑过Chroma实例，仿佛就不是真正的Agent开发者。

两年后的今天，当我再次审视主流Agent框架的代码仓库和社区讨论，一个明显的变化正在发生：RAG的存在感断崖式下滑，取而代之的是Skills、Tools、MCP、Memory这一套新词汇。

从必修课到被遗忘：RAG的技术定位变迁

RAG诞生的技术背景很清晰：早期LLM有两个硬伤——ContextWindow极小（4Ktoken天花板）、语义理解能力不足以在大规模文本中精准定位答案。于是业界发明了折中方案：先把文档向量化，用向量相似度做预筛选，再把最相关的几条结果喂给模型。

这套方案需要掌握向量数据库选型（Weaviate/Qdrant/Pinecone各有优劣）、Embedding模型调参、chunksize与overlap的配比优化。对于有追求的开发者，还要折腾增量同步、混合检索、rerank策略。一套完整的RAGpipeline，没有两三天根本跑不通。

Skill的本质是一个结构化的prompt文件，Tool是标准化的API调用封装。这两者能解决的问题，恰好覆盖了个人开发者90%以上的使用场景。

web_search处理信息检索、run_code完成代码执行、read_file访问本地文件——三板斧下去，日常工作全覆盖。更关键的是，Skill的传播成本趋近于零：写完push到GitHub，别人clone下来直接用，没有账号注册、没有服务部署、没有数据迁移。

这种极低的传播摩擦，让Skill生态在短时间内形成了正向飞轮。ClaudeCode社区里，一个上午冒出来几十个精选skill，覆盖单元测试、代码审查、文档生成各种场景。

技术演进的速度超出了多数人的预期。ContextWindow从4K到128K再到200K+，中间那层向量预筛选变得多余——与其先向量检索再喂给模型，不如直接把全部内容怼进去，让模型自己判断相关性。

语义理解能力的提升更是釜底抽薪。当LLM自己就能在一堆文本里精准定位答案时，专门训练Embedding模型来做向量相似度的价值何在？多花的token费用，远低于维护整套RAG基础设施的人力和金钱成本。

当前Agent市场的格局很清晰：明星产品清一色ToC，ClaudeCode、Cursor、Devin全部面向个人开发者。这个用户群体的特征决定了RAG的天然劣势。

个人用户数据量有限（一个代码库、一份笔记能有多少内容），成本敏感（不愿意为向量数据库付费订阅），追求开箱即用（下载安装立刻能用才会被传播）。三个约束条件叠加，ToCAgent天然排斥RAG。

反观ToB场景：企业有海量私有数据、有精确检索需求、有合规审计要求、有成本不敏感的付费意愿——这完全是RAG的主场。但ToBAgent落地存在高壁垒：数据敏感性限制了云端部署、企业遗留系统的接入成本高、决策链条长导致推进慢。ToBAgent还在蓄力阶段，RAG随之蛰伏。

面对这场技术变迁，开发者需要建立清晰的判断逻辑：能用Skill/Tool解决的首选Skill/Tool，这两者搞不定的再考虑RAG。判断标准很简单——知识是否能被规则化表达，能的话就塞进prompt，不能才需要RAG。

RAG没有死，它只是在等待自己的主场。当ToBAgent市场爆发时，这项技术大概率会重回舞台中央。