RAG 没死，但它一直在做无用功：Agent 有 85% 的算力花在”重新发现”上
AI飞行客 RAG 没死，但它一直在做无用功：Agent 有 85% 的算力花在”重新发现”上
先说一个数据，Pinecone 估算的：
Agent 有 85% 的计算精力，消耗在”重新发现”的循环上，而不是真正的任务完成。
你没看错。一个 Agent 跑起来，绝大部分算力不是用来解决问题的，是用来反复搞清楚”我要查的东西在哪儿”。
这就是 RAG 走到今天真正的困境。不是检索不准，是每一次查询都从零开始。
朴素 RAG 的结构性缺陷：搜得准 ≠ 搜得对
过去两年，RAG 是 LLM 落地企业知识场景的标配。逻辑很直白：模型不懂的就现查，查到了再回答。
但真正搬进生产环境后，一个共识正在形成：RAG 很好，但远不够好。
朴素 RAG 的本质是一条单行道：查询 → 嵌入 → 相似度排序。
问题在于：相似不等于相关，相关不等于正确。
– 精确日期查询（”2025 年 Q3 营收是多少？”）：向量搜索只会捞回一堆语义相近但毫不相关的噪音 – 模糊概念问题（”微服务架构的核心思想？”）：Grep 根本找不到，因为没人会在文档里写下和你查询一模一样的那句话 – 有些答案不在单个文档块里，得先定位一批候选文档，再逐个精读
单一通路无法覆盖多样化的查询类型。这是结构性缺陷，不是调参能解决的。
高级 RAG 的困境：复杂度换不来效果
于是有了高级 RAG。GraphRAG 用知识图谱、RAPTOR 用递归摘要树、Contextual Retrieval 用上下文感知分块……
每一个方案都有自己的论文、自己的 Benchmark、自己的拥趸。
但问题是：这些方案的部署维护成本急剧上升，效果提升却远未达到预期。
最典型的例子是 GraphRAG。它把碎片化的图状结构作为检索主来源，消耗了大量 Token，但只在部分多跳问答场景下有改善。更糟的是，这些复杂方案让系统变得难以解释、难以调试、难以维护。
一句话总结：一个需要专家才能调优的 RAG 系统，在真实的企业生产环境里站不住脚。
2026 年两个事件，把 RAG 推到了十字路口
事件一：Karpathy 的 “LLM Wiki”。
他主张把原始笔记当作源材料，用 LLM 编译成一份持续更新、带明确引用、可逐字阅读的 Wiki。
核心那句话很关键：
> 知识被编译一次，然后保持更新，而不是在每个查询上重新推导。
这个想法从个人知识管理溢出到企业 RAG 领域，引发了对传统范式的普遍质疑。
事件二：PwC 的《Is Grep All You Need?》。
研究人员给 Agent 同时配了向量搜索和 Grep，结果发现 Grep（精确字符串匹配）常常比语义搜索准确率更高。
更进一步：仅用字符串匹配实现的 Agentic RAG，质量已经接近 LLM-Compiled Wiki。
这个结论在行业里被简化成了”Grep 取代 RAG”——但这是过度解读。更准确的说法是：
> 一个设计良好的 Agent Harness，即使只配 Grep 这种简单工具，在很多场景下也能达到接近甚至超过复杂 RAG 的效果。
它挑战的不是”要不要检索”，而是”检索必须依赖复杂架构”这个假设。
为什么 Grep 能赢：因为用户变了
这里有个特别容易被忽略的细节。
OpenAI 对 GPT-5 在 BrowseComp-Plus 数据集上的搜索行为做过分析：
– 98% 的会话中使用了引号搜索（远高于人类用户） – 查询长度中位数超过了人类的 99 分位数
也就是说，AI 使用精确匹配时比人类更”精确”、更”结构化”。它能一次性构造出人类不太可能输入的、带多个约束的复杂查询。
Grep 本身没变，但用它的从人类变成了 Agent，使用方式发生了质变。
这才是”Grep 打败 RAG”的真正原因。不是字符串匹配比语义理解强，是当使用者是一个不知道疲倦、可以连续试错五十次的 Agent 时，精确工具的劣势被极大弥补了。
但 Harness + Grep 也有天花板
问题来了：如果 Grep 这么强，还要 RAG 干什么？
答案是规模。
当数据规模扩大，完全靠 Harness 的迭代探索 + Grep 的精确匹配，会带来两个严重后果：
1. 慢：每次 Grep 都是一次 IO，迭代次数线性增长，响应时间急剧上升 2. Token 消耗高：每次迭代都把搜索结果载入上下文，多轮累积下来是巨大的
更麻烦的是：面对每一个新的上下文窗口，Agent 都要重新学一遍”什么搜索策略是有效的”。
这就是那个 85% 的由来。
真正的答案：知识编译，而不是更强的召回
到这里，文章的核心主张就清楚了：
> Search Harness 是 Agentic Search 的引擎；知识编译是它的上下文供给层。
注意这不是”用知识编译取代 Grep”。而是：
– Harness 负责编排：决定查什么、怎么查、什么时候停 – 知识编译负责供给：为 Harness 提供更丰富、更压缩、更可追溯的知识工件
把一部分”理解”工作从查询时移到索引时。
传统 RAG 是：每次查询，从零理解一遍知识库里有什么、文档之间什么关系、哪些来源权威。
知识编译是：在索引阶段就把这些理解固化下来，查询时直接调用。
这个区别听起来很小，但它的影响是复利级的。因为理解的成本只付一次，而不是每次查询都付。
微软的做法：给 Harness 配三把工具，而不是一把
微软在企业级 AgenticRAG 上的设计，给了一个很具体的方向：为 Harness 配备更丰富的工具。
核心是三类原子操作：
– SEARCH：广域召回，先把范围缩小 – FIND：精确定位，在候选里找到确切位置 – OPEN：深度阅读，获取完整上下文
这套组合把”搜索”提升成了 Agent 可编排的原子操作。
微软报告在 BRIGHT、WixQA、FinanceBench 上都有显著提升。消融实验显示，最大提升来自”从单次检索转向 Agentic 工具使用”。
还有个更实用的发现：BM25 + Grep 的组合就能让 Harness 表现更好。BM25 单次检索表现弱，但在 Agent Loop 内部却强得多。
也就是说——你不需要复杂的 Embedding 模型和向量数据库，仅靠词汇层面的检索工具组合，就能给 Harness 提供足够强的检索能力。
这对想落地的人来说是个好消息。少买一套基础设施，也能做出能用的东西。
我的判断
第一，”RAG 死了”和”RAG 万岁”都是错的，真正死的是”查询→匹配→排序”这个范式。
检索的核心正在从”设计一个更强的召回算法”，转向”设计一套能在多工具之间动态编排的决策框架”。
搜索不再是引擎，而是 Harness 的一部分。 这句话是这篇技术文章里最有价值的一句。
第二，85% 这个数字应该让所有做 RAG 的人停下来算一笔账。
如果你的系统每次查询都在重新理解知识库结构、重新判断哪些文档相关、重新学习什么搜索策略有效——那你付的不只是 Token 费用，是你在一遍一遍买同一个东西。
知识编译的价值不在于”检索得更准”，在于”不用再检索那么多次”。
第三，也是我最想说的：这件事的本质，是从”每次重算”到”编译一次”的范式迁移。
你如果做过编译器，会立刻认出这个模式。
解释型语言每次执行都要重新解析源码；编译型语言只解析一次，之后直接跑机器码。
今天的 RAG 就是解释型的——每次查询都在重新解析。知识编译就是把 RAG 变成编译型的。
这也解释了为什么 Karpathy 那个”LLM Wiki”的想法能这么快引起共鸣。不是因为它新，是因为它熟——每个程序员都见过这个模式，只是没人想到把它套到 RAG 上。
第四，对想动手的人：先别急着上 GraphRAG。
从这篇文章的证据看，一个务实的落地路径是：
1. 先做 Harness + Grep/BM25，把编排做好 2. 加 SEARCH/FIND/OPEN 三类工具，让 Agent 能分层操作 3. 再考虑知识编译，把重复的理解工作固化成可复用工件 4. GraphRAG 和向量库，放到最后
因为前三步解决的是架构问题，第四步解决的是算法问题。架构问题的收益比算法问题大得多，成本比算法问题低得多。
顺序反了，你会花很多钱，换回来一个需要专家才能维护的黑箱。
—
*核心概念：Agent Native Database / 知识编译（Knowledge Compilation）* *关键数据：Pinecone 估算 Agent 85% 算力用于”重新发现”* *关键研究：PwC《Is Grep All You Need?》、Karpathy “LLM Wiki”、微软 AgenticRAG（SEARCH/FIND/OPEN）* *工具组合：BM25 + Grep 在 Agent Loop 内表现优于单次检索* *开源实现：RAGFlow 1.0（Go 编写，首个开源 ANDB）* *来源：36氪 / RAGFlow 技术文档*