RAG越来越“没存在感”，问题出在哪？

Agent 还在搜资料、读文件，RAG 这个词却越来越少见了。它去哪了？

RAG 这个词为什么听着越来越远

最近在看 Agent 相关项目时，我有一个很明显的感受。

前两年学 Agent，折腾 Dify，很多教程都会先拿出一份 PDF。把长文拆成小段，给每一段算出一串数字，方便系统以后找到和问题意思接近的内容。用户提问时，系统先找几段，最后交给模型回答。

一圈配置折腾完，问题还没问，工程已经搭了半天。

RAG 用大白话说很简单。模型不知道你手里的私有资料，那就在回答前，先帮它找几份有用的。

后来数据库、检索和文件处理都逐渐被平台封装起来。开发者不用每次从头搭，RAG 这个词也就没有那么抢镜了。

张雪峰 Skill 这个例子很有意思

张雪峰去世后，GitHub 上出现了一个张雪峰 Skill 项目，现在已经有上万 Star。

项目里有一个示例。河南考生 560 分，想学金融。Skill 先问家里有没有金融行业资源，然后从就业去向和家庭条件继续往下问。

这个回答挺有张雪峰那个味儿。说话直，先问家庭条件，不陪你空谈梦想。

但考生在 2026 年能报哪些学校，还得查当年的招生计划、省排名、选科要求和学校章程。Skill 可以学他怎么问，却不会凭空知道河南今年哪所学校招多少人。

我又点开仓库看了一下。SKILL.md 大约 24 KB，后面还跟着 6 份研究材料，加起来约 60 KB。里面有著作、访谈、表达特征、外部评价、重要决策和人生时间线，另外还有对话示例。

所以这个 Skill 并没有靠一页 Markdown 把十几年经验全装进去。它更像一本经验手册，教 Agent 怎么问、怎么判断。当年招生数据仍然要现查。

这就是 Skill 和 RAG 很实际的分工。

Skill 和 Tool 为什么更容易火

想想我们平时让 Agent 干什么，答案其实很朴素。写代码、改文章、查网页、跑命令，偶尔再帮忙整理邮件和日历。

这些事情大多有现成工具。给 Agent 一个搜网页的 Tool，它就能找资料。给它读文件和跑命令的 Tool，它就能进项目干活。用户不用先整理一套知识库。

Skill 的传播也很简单。它就是一个能看懂的 Markdown 目录，放到 GitHub，别人下载后就能用。规则写得不对，打开文件就能改。这种东西天生适合截图、分享和做教程。

三者管的事情其实不一样。Skill 告诉 Agent 怎么做，Tool 让它有办法动手，RAG 帮它从大量材料里找出这次要用的几份。对大部分个人任务来说，前两个已经能把事情做完，RAG 自然少了出场机会。

Claude Code 一直在搜，只是没喊 RAG

Claude Code 的官方文档里也有一个很具体的例子。

你让它修一个登录问题，它会先搜相关文件，读几处实现，搞清楚调用关系后改代码，最后跑测试。

它没有一上来就把整个项目塞给模型。哪个文件有用，搜到再读。读完发现线索不够，就换个词继续搜。

Anthropic 把这种做法叫作“按需取回文件”。长期规则放在 CLAUDE.md 里，具体代码等用到时再搜。

Claude Code 官方终端图，图源 Anthropic

有人会说，这和早期那套 RAG 不完全一样。确实，它可以用文件名和关键词搜索，不一定要先建向量索引。

但对用户来说，动作没变。Agent 先找到材料，再带着材料干活。

OpenAI 的 file_search 更像大家熟悉的 RAG。开发者把文件上传，模型遇到问题时自己搜索，回答里还能带上文件引用。文档怎么拆、索引怎么建，平台已经帮你收拾了大半。

名字没了，活照干。

个人项目先省掉的是维护

早期做 RAG，麻烦不只在第一次搭建。文档更新了，旧内容得删，新内容得重新处理。同一份制度留下两个版本，Agent 还可能专门把过期那份找回来。

对个人开发者来说，这笔账很好算。代码每天在变，直接读硬盘上的当前文件，肯定比维护另一份索引轻松。网页内容会变，临时搜一次也比自己定时同步省心。

今天的向量存储可以用托管服务，也可以在本地跑，几份文档的费用不一定高。个人项目嫌麻烦，更多时候是不想再养一套数据导入、更新和清理流程。

模型的上下文也从早期的几千 token 涨到了十几万甚至更多。原来放不下的几十份资料，现在可以直接读。Agent 还能先搜一次，看完再换个问法继续搜。固定的一次检索，就这样变成了 Agent 自己控制的多次查找。

工具选择也一样。Agent 手里只有几十个 Tool，把说明全部发给模型就行。工具多到几百、几千个，检索和按需加载又会回来。长上下文只是把这条分界线往后推了，没有把检索抹掉。

几十份资料和 10 万份资料是两回事

长上下文确实让不少小项目省事了。

Anthropic 在 Contextual Retrieval 的文章里给过一个参考。知识库小于 20 万 token，大约 500 页材料时，可以先把全部内容放进提示词，再配合缓存降低重复输入的费用。

这个数字不是通用标准，但方向很清楚。个人手里只有几十份资料，直接让模型读就行，没必要先给自己加一堆工程活。

但如果是 10 万份呢？

Morgan Stanley 和 OpenAI 做了一个面向理财顾问的内部问答助手。顾问碰到客户问题，可以直接去公司的研究和流程文档里找答案。

Morgan Stanley 的 AI 助手工作场景，图源 OpenAI

OpenAI 公布的案例里提到，这套系统已经能处理约 10 万份文档。超过 98% 的理财顾问团队在使用它，员工能找到的内部文档比例从 20% 提高到 80%。

文档接上去还不算完。理财顾问和提示词工程师会给回答打分，看它准不准、说得通不通，再反过来调整搜索方法。后来加上多语言检索，他们又补了一套翻译测试。

这些工作听着没有“超长上下文”那么酷。企业敢把系统交给员工用，靠的就是这些细活。

RAG 早就在企业里干活了，只是它们更常被叫作“内部问答”“知识助手”或“信息检索”。企业内部一个工具上线，也不会像新出的开源 Agent 那样天天上热榜。

这也是我觉得 RAG “声音变小”的另一个原因。技术社区每天看到的明星产品，大多面向开发者和个人用户。个人数据少一些，对成本敏感，还希望下载后马上能用。Skill 和 Tool 刚好符合这些条件。

企业的知识助手藏在内部账号和权限后面，既不能发到 GitHub，也很难拍一段三分钟视频让大家复制。社区里谁的声音大，更多取决于谁容易被看见和分享，并不能直接代表企业里的部署量。

搜到了相似内容，还是可能答错

RAG 现在最麻烦的地方，已经不是数据库怎么搭了。它经常能搜到看着很像的内容，拿回来却用不上。

Anthropic 举过一个财报例子。用户问 ACME 公司 2023 年第二季度的营收增长，原文中恰好有一句“该公司营收较上季度增长 3%”。

单独把这句话拎出来，就像在群聊截图里看到一句“他还欠我 100 块”。话挺清楚，“他”是谁，什么时候欠的，全不知道。

财报库里可能有几百句相似表述，系统很容易拿错。

Anthropic 的处理方式很直接。在这句话前面补上公司名、季度和前一季营收，然后再建立索引。这样搜索时就知道它属于谁、属于什么时间了。

他们用不同领域的知识库做了测试。普通做法下，相关材料没有进入前 20 条搜索结果的比例是 5.7%。补全上下文，同时搜关键词，这个数字降到 2.9%。再把候选结果重新排一遍，可以降到 1.9%。

Anthropic 公布的检索失败率对比

所以现在做 RAG，费时间的地方往往在后面。新旧版本会不会一起被搜出来，用户有没有权限看这份文档，搜索结果到底准不准。这些问题没处理好，前面接的模型再强也白搭。

RAG 没失业，只是换了工牌

我现在再看这个问题，答案已经比较清楚了。

文档少，模型直接读。代码经常变，Agent 边搜边读。内部资料多到 10 万份，就老老实实建索引、做权限、跑评测。

以前大家把整套流程叫 RAG。现在它可能叫文件搜索、知识助手，也可能被放进上下文工程里。

技术圈往往都这样。一件事需要大家手动折腾时，教程满天飞。等平台把它收进一个按钮里，讨论度就下来了。

RAG 没走，也没在等什么大舞台。

它一直在后面干活，只是现在不怎么抢镜了。