8 月，RAG 圈发生了两件小事。一篇叫 CoinRAG 的新论文，要把商用 RAG 服务的首 token 延迟压到 P99 100 毫秒以内——没错，2026 年了，还有人发论文把 RAG 的延迟一毫秒一毫秒往下抠。哔哩哔哩同一时期，据 B 站 AI 日报盘点，开源引擎 ragflow 又上了 GitHub 热门榜，官方定位已经变成"融合 RAG 与 Agent 能力"的上下文层引擎。
但与此同时，你在社区里搜"RAG 已死"，会发现这个口号已经喊了一年多：知乎上有人盘点过给 RAG 写讣告的文章，有的甚至登上过海外科技社区首页。知乎到 8 月中旬，B 站上还有标题为《RAG没死，百万上下文干不掉 RAG》的视频在更新。哔哩哔哩而开发者们天天用的 Claude Code，也确实把早期版本里的向量索引删掉、换成了 grep。所以到底死没死？我把过去一年双方的高赞讨论、一手资料和最新论文过了一遍，结论有点出乎意料：争论的双方，其实一直在吵两件事。
“死方”：死掉的是代码库场景的 RAG
死方的证据是实打实的。最出名的案例是 Claude Code：早期版本确实用过 RAG 加本地向量库，后来 Anthropic 团队自己把这套全删了，换成让模型直接调 grep 迭代搜索代码库。创建者 Boris Cherny 自己在播客里说，最后他们落到纯 agentic search 上，“效果好得不止一点”。知乎
这不是 Anthropic 一家的怪癖：Cline 直接把"No RAG, no embeddings, no vector databases"写进博客当宣言，OpenAI 的 Codex CLI 关掉了社区提的向量索引请求，连老牌代码搜索厂商 Sourcegraph 都把 embedding 暂时放一边。知乎
把两条路摆在一起看，差异一目了然：RAG 是一次性预处理管线——切 chunk、做 embedding、存向量库、召回 top-k、塞给模型，一条线走到底；agentic search 是一个循环——模型自己搜、自己看结果、不够就改关键词再搜，像人类工程师一样自我纠偏。
为什么 grep 在代码库场景赢了？核心是一笔成本账：索引方案的构建成本（切块、编码、入库）和维护成本（失效、重建、跟代码漂移对账）会随着代码变更量往上爬，而 grep 方案这两项是零，只付每次查询的几轮 LLM 往返。把成本交叉曲线画出来：对中小型、日常都在改的代码库来说，那个交叉点根本走不到，数学上算下来答案就是 grep。知乎再加上代码要的是精确匹配（grep 一个 getUserById 精确到行，向量检索却会把 getUserByEmail、getUserByName 一起捞回来），以及代码天天变、索引天然滞后——这三条足以解释编码 Agent 们的集体撤退。
也要留一个诚实的注脚：Boris 自己承认，这个"赢了全场"的判断一部分靠团队直觉和没公开的内部 benchmark，不是完全可复现的硬指标。所以这个结论放在代码场景里相当可信，但急着把它外推到一切知识场景，就是过度 extrapolation 了。
“没死方”：长上下文替代不了的三件事
没死方的战场是企业知识库。知乎一个 1500+ 赞的回答把话说透了：无限上下文解决的是"装得下"的问题，RAG 真正的战场从来不在这里。知乎
长上下文替代不了的，至少有三件事。一是时效：上下文再长，也只能装你主动放进去的内容，知识库今天更新一条新政策，RAG 只需更新向量库下次就能检索到，长上下文得重新塞一遍。二是可追溯：企业把 AI 接进内部知识库，法务第一个问题是"这回答基于哪份文件哪个段落"，RAG 能附来源出处、让用户点开核对原文，长上下文塞一百万 token 再生成答案是个黑盒，模型不会告诉你它重点看了哪一段——在医疗、法律、金融这些强合规行业，可追溯是准入门槛，不是锦上添花。三是成本：几万份文档的企业知识库，每次提问都把整库塞进上下文，成本会直接杀死大多数商业应用；而 RAG 检索出的片段通常只有几百到几千 token，差距是量级上的。
这笔账今年还有新的佐证。CoinRAG 那篇论文对比了 CAG 方案——把整个知识库预先缓存进 KV cache，基本等于"长上下文现成化"路线；结果在 P99 首 token 延迟 100ms 的商用 SLA 下，CAG 达不到要求，优化后的检索方案在同样延迟约束下平均提升答案质量 5.3%。哔哩哔哩也就是说，"全塞进去"就算优化到极致，在严苛的服务场景里依然过不了关。
更别说长上下文本身没有口号里那么靠谱：《Lost in the Middle》早就指出，模型对上下文头部和尾部的信息利用效率，显著高于中间部分；Chroma 的 Context Rot 研究也表明，窗口越长，模型自己先"rot"。知乎百万 token 的窗口，不等于百万吨的载重。
真正决定生死的，是三个变量
把双方论据摆齐，会发现"RAG 死没死"的答案其实取决于三个变量。第一，你的知识是什么形态：代码这种精确、结构化的符号，适合 grep 类精确检索；海量非结构化、需要语义理解的文档（合同、手册、客服知识库），才是向量 RAG 的主场。第二，知识变化多快：高频变更加中小规模，索引维护成本爆炸，不如让模型实时搜；相对稳定的大规模语料，一次性建索引的成本能被摊薄，检索质量更稳。第三，要不要追责：需要审计、追溯、附出处，RAG 是目前唯一成熟的路线；日常闲聊问答，长上下文就够了。
把这三个变量映射到象限图上，结论就很直观：语义概念加稳定文档，走 RAG；语义概念加海量高频变更，走混合方案；精确符号加小而稳定，走 agentic grep；精确符号加巨大且高频变更，走 grep 加索引。争论双方各自拿着图里的一个象限，所以才怎么都吵不到一块去。
RAG 没死，它只是改名了
再看 2026 年 8 月的新信号，行业其实已经用脚投了票：ragflow 上榜的方向，是"融合 RAG 与 Agent 能力，为 LLM 构建更优上下文层"的引擎。哔哩哔哩Google 6 月发布的叫 Agentic RAG，在事实性数据集上准确率比传统 RAG 最高提升了 34%，核心是让模型自己判断检索结果"够不够"、不够就再搜。知乎学术圈里，有人在抠延迟，有人在研究检索结果互相冲突时该信谁——没人在写讣告，大家都在搞装修。
更有意思的是，"死方"和"没死方"现在正往一起走：编码 Agent 在补 grep 为主、embedding 补长尾的混合检索，知识库阵营在给 RAG 加 agentic 循环、让模型自己决定要不要再搜一次。知乎RAG 没有死，它只是从"默认答案"分解成了一组可组合的检索能力。
所以给一个可执行的结论：
代码库、高频变更的结构化数据：优先 agentic search，别先建向量索引；
海量非结构化文档加合规、审计要求：向量 RAG 仍是主流，知识库不用拆；
文档量小、变更少、不需要追责：直接塞长上下文，别建管线自找麻烦；
复杂多跳、质量要求高：关注 Agentic RAG 和混合检索，这是这一轮装修的方向。
最后给已经把 RAG 知识库跑起来的人一句话：这场争论带来的真正风险，不是"技术过时"，而是"跟风拆家"。拆之前先问三句：你的知识是不是天天在变、要不要附出处、文档量是不是小到能塞进上下文？三个答案都是"否"的话，你的知识库好得很——该担心的不是 RAG 死没死，而是你从来没评测过它到底好不好。
