这句话今年被说得太多了。它有一半是对的，另一半是今年最贵的几个坑的来源。

先说对的那一半。传统 RAG 的骨架是 2023 年定下来的：把文档切块、向量化，用户提问时做一次相似度检索，把命中的几段塞进 prompt，让模型回答。一次检索，一次生成，中间没有任何环节问一句"我找对了吗"。这个骨架在单跳问答上表现不错，遇到需要跨文档拼证据的问题就塌了。

有组数据很说明问题：企业系统在单跳检索上能拿到 95% 的准确率，换成需要跨文档推理的问题，掉到 61%。MultiHopRAG 基准上，约 92% 的传统 RAG 系统在多跳查询上失败。

再说错的那一半。翻今年各家公司踩过的坑，反复出现的一句是：套在烂检索上的 agent，只会让你花更多钱、更自信地犯同样的错。检索层本来就召不回对的段落，你加了个循环让它多试几次，它还是召不回，只是多烧了几轮 token，然后用更完整的语气把错答案讲了一遍。

所以这篇不打算顺着那句话往下讲。我想说的是：问题从来不在"要不要换成 Agentic"，而在"你的检索基线有没有先做扎实"，以及"哪一类查询配得上多花的这笔钱"。

一、传统 RAG 卡住的地方，不是"不够聪明"

图 1｜毛病大多不在模型这层，在检索层

很多人以为传统 RAG 的瓶颈是模型理解力不够，其实不是。它的毛病出在四个很具体的地方，每一个都属于工程疏漏，跟模型智商无关。

切块切断了意义。固定长度切分是最省事的做法，也是最先把表格和表头分开、把条款和它的定义分开的做法。一个 chunk 里写着"折扣适用于超过阈值的订单"，而阈值定义在另一个 chunk 里——这个 chunk 单独被检索出来的时候，只能产生一个自信但不完整的答案。表格被切开更糟，比完全没有表格还糟，因为它会产生带错数字的答案。

纯向量检索找不到精确词。嵌入擅长语义，不擅长零件号、法规条款号、缩写。用户搜 "HR-114"，向量相似度给他返回一堆关于"人力资源政策"的泛泛段落，就是没有那一条。

top-k 是个钝器。你传了前 4 条，正确答案可能在第 7 条。这个问题在演示环境里永远看不出来。

没有接地检查。生成完之后，没有任何环节验证答案是否真的被检索到的文本支撑。模型会忽略掉关键内容，自己补上——这就是幻觉的来源。

这四个问题有一个共同点：它们都在检索层，而不在生成层。换个更强的模型，一个都解决不了。

二、Agentic RAG 改的是控制流，不是检索器

这是理解它最关键的一点。Agentic RAG 没有发明新的检索算法，它把"检索"从一个步骤变成了一个动作——模型可以决定要不要检索、检索几次、用什么方式检索、什么时候停。

传统 RAG 是个函数：输入查询，输出答案。Agentic RAG 是个状态机：拿到问题 → 拆成子问题 → 选数据源 → 检索 → 检查证据够不够 → 不够就换个说法再来一轮 → 够了才生成。

今年业界收敛出了三种主要形态：

三种里，真正在生产上跑得最多的是第三种。原因不浪漫：生产环境里 60%–70% 的查询是简单查询。给全部流量都套上循环，是纯粹浪费。Adaptive RAG 的价值不在"更聪明"，在于它承认了大部分问题不值得贵的那条路。

再往下拆，具体实现上有七种被反复使用的手法：查询分解（把复合问题拆成子问题并行检索）、迭代检索（每轮看完结果决定要不要再来）、多跳推理（上一轮的结论决定下一轮查什么）、工具调用（SQL、计算器、API、代码执行）、自我反思、重排与验证、多智能体分工（规划者/检索者/批评者/综合者）。

真实系统通常是几种叠着用。比如微软 Azure AI Search 的 agentic retrieval，一个托管服务里就同时做了查询分解、并行子查询派发、语义重排和模型驱动的规划。

这里有个必须写死的东西：循环必须有预算。token 预算在循环内部强制，时间预算在循环外部强制。两个都没有的话，一个刁钻问题可以悄悄烧掉一个月的推理费用。典型配置是 5–6 轮上限。

三、代价：三个数，以及一种新出现的失败

图 2｜三个数：成本、延迟，和一种新的失败类型

Agentic RAG 不是免费的升级。先把账算清楚。

成本是 3–10 倍，而且是复利式的。单次 RAG 大概 2000 token；带三轮迭代的 agent 循环，在生成开始之前就可能走到 6000–20000 token。之所以不是线性的，是因为每一轮迭代的上下文里都带着前面所有轮次的内容。折成钱：单次查询从 0.002 美元变成 0.02 美元，百万查询/月的管线从 2000 美元变成 20000 美元。

延迟从 1–2 秒变成 4–15 秒（p95）。有一条是硬止：如果你的延迟预算在 500 毫秒以下，直接放弃这条路。光是模型的推理调用就已经超过整个预算了，架构上做不到，再怎么调 prompt 也没用。

它带来了一种此前不存在的失败类型。这是最容易被忽略的一点。有组基准数据显示，23% 的错误答案来自 agent 选错了工具、或者误读了工具的输出，而不是生成环节出错。传统 RAG 出错的时候，原因通常很单纯——一个坏掉的 chunk。Agentic RAG 出错的时候，原因可能在路由、在检索、在评估、在最后的生成，四处都有可能。你的值班工程师从此需要读懂 LLM 的推理轨迹，而不只是看管线日志。

还有两个实操中常见的：agent 忘了自己已经看过某份文档，把它检索了三遍；工具描述写得含糊，agent 反复选错。

四、长上下文来了，那 RAG 是不是可以删了

图 3｜窗口再大，也装不下企业语料

这是今年被问得最多的问题，答案很干脆：不能，而且理由跟上下文窗口多大无关。

到 2026 年，1M token 的窗口已经是标配，不是卖点。Gemini 3 系列 1M，部分企业配置到 2M；GPT-5.5 是 OpenAI 第一个 1M token 的 API 模型；Claude 这边也是 1M 级别。

但"标称窗口"和"可用窗口"是两件事。MRCR v2 的召回数据是今年被引用最多的：

• Claude Opus 4.6：256K 时召回 93%，到 1M 时掉到 76%
  
• Gemini 3.1 Pro：1M 时约 70%
  
• Gemini 1.5 Pro（2M 窗口）：只有 55%–65%
  

窗口更大，不等于召回更好。还有个叫 context rot 的现象：测了 18 个前沿模型，放在上下文中部的事实，准确率从 70%–75% 掉到 55%–60%——远在窗口填满之前就开始掉了。模型对开头和结尾的信息更敏感。

另一组数字更直接：SummHay 基准上，不带检索器的长上下文系统得分不到 20%，人类水平是 56%。这个基准问的是"覆盖重复出现的观点并引用来源文档"，比找一根针更接近真实的企业问答。

成本和延迟的差距更悬殊。一次 1M token 的请求在 Claude Opus 4.6 上通常要 60–120 秒；调优过的 RAG 是几百毫秒。端到端算下来，1M 请求比 RAG 管线慢 30–60 倍，单次成本约 1250 倍。

所以长上下文解决的是另一类问题。RAG 解决的这四件事，窗口再大也不会自动消失：

语料超出任何窗口。企业知识库动辄数十亿 token，没有窗口装得下。

文档级权限。检索可以在 chunk 到达模型之前按权限过滤。把整个语料塞进上下文，意味着每个会话都碰了一遍全部内容——只要有两个客户共用一个索引，这就是合规事故。

不用重处理的鲜度。向量索引里更新一篇文档，下一条查询就能看到。缓存的长上下文 prompt 更新一篇文档，你得重新编码整个东西。

出处与审计。检索步骤天然给你一份可记录的清单：模型在回答之前看见了什么。一百万 token 的 prompt 是一坨无从分辨的东西，除非你另建追踪。

2026 年真正的默认架构是混合的：先检索出一个 5 万到 20 万 token 的候选集，再交给长上下文模型去综合。检索当注意力的导演，长上下文当综合层。在这个结构里，检索质量的重要性不是下降了，是上升了——瓶颈从"装得下吗"变成了"我们有没有把对的那 50 份文档捞出来"。

五、2026 年该按什么顺序做

图 4｜顺序比架构更能决定成败

如果你的 RAG 效果不好，问题大概率不在缺个 agent。按这个顺序来，前四步解决掉的问题，比加循环多得多。

1. 结构感知切分。按标题、章节、表格边界切，不按字符数。每个 chunk 带上它的上下文头——"休假制度 › 产假 › eligibility"这样的路径，对检索质量的影响非常大。表格保持完整。10%–15% 的重叠用来兜住跨边界的答案。512–1024 token 是个合理的起点。

2. 混合检索。稠密向量加 BM25 关键词，用 RRF 融合。纯向量搜索今年已经被视为架构错误了。我们自己在评估里看到的是，混合检索加交叉编码器重排，比单独用任何一种高出 15–25 个百分点的答案准确率。

3. 元数据过滤。这一条被低估得最厉害。那个"引用了 2023 年就废止的政策"的事故，跟模型一点关系都没有，是检索问题——旧文档还在索引里，而且没有任何东西标记它过期。每个 chunk 都该带上生效日期、失效日期、所属部门、文档状态、访问级别。检索时先按这些过滤，再谈相似度。过期文档不该被引用，因为它压根不该成为候选。

4. 先建评测集，再调 prompt。这是团队最爱跳的一步，也是区分演示和系统的那一步。从真实用户问题里抽 100–200 条问答对，让懂业务的人过一遍，其中要包含系统应该拒答的问题。然后分开测两件事：检索召回（正确的 chunk 有没有进候选集）和答案忠实度（模型有没有守着检索到的内容）。如果正确的 chunk 根本没被召回，调 prompt 是浪费时间。

有个比喻很到位：没有评测集的 prompt 调优是迷信。

5. 把拒答当成功能来设计。一个什么都答的助手，不如一个答对 70%、并清楚告诉你"这条我没有，建议问谁"的助手。后者建立信任，前者在有人按错误答案行动的那一天把信任一次性毁掉。设一个检索分数阈值，低于它就拒答，而不是硬凑。

6. 这时才加循环，并且带预算。把检索暴露成工具，允许查询分解、重试、换源，同时给工具调用次数、运行时长、token 都设上限。

7. 最后做路由。用一个轻量分类器（或者让模型自己）判断问题简单还是复杂，简单的走快路径，复杂的才升级到 agent 循环。

时间上的现实预期：语料审计 1–2 周，入库切分 2 周，评测集 1 周（可并行），检索调优 2–3 周，护栏与集成 2 周，试点迭代 4 周。一个季度，不是一个下午。当然也可以一下午搭个原型，它的用处是帮你判断这个季度值不值得花。

好消息是这个成本在快速下降。2024 年需要两个工程师做六周的东西，2025/26 年一个工程师四周能做完，而且运行时质量更高——模式标准化了，工具链也成熟了。

六、四个问题，判断你要不要上

不用开会讨论，把自己的情况往这四个问题上套一遍就有答案。

你的查询里，有多少条真的需要跨文档？从日志里拉 50 条真实查询，数一数有多少条需要从两个以上文档里取证据。如果答案是"没几条"，别上。

单次检索的首轮命中率是多少？把这 50 条跑一遍标准 RAG，看有多少条在 top-5 里就拿到了正确文档。如果 90% 都能拿到，agent 循环加不上任何东西——你是在花 4–10 秒的延迟去修一个不存在的问题。

延迟预算卡在哪？低于 500 毫秒一票否决。搜索框、自动补全、任何用户期待即时反馈的界面，都不该走这条路。

有没有人维护它？Agent 循环不是设好就忘的系统。停止条件要调，工具描述要维护，出错了要读推理轨迹。如果你的团队是一个工程师兼着另外三个服务，别给自己加这个负担。

这四条里只要有一条答不上来，就该先把检索基线做扎实，而不是加循环。

最后

RAG 这个词其实已经有点过时了。它诞生的时候，要解决的问题是"上下文窗口太小，装不下数据"。到 2026 年，这个问题不存在了，但这个缩写留了下来，把一大批本来属于"检索工程"的工作全塞进了它的名下——数据治理、切分策略、混合召回、重排、权限过滤、评测、拒答设计。

Agentic RAG 是这批工作里的一环，而且是被讨论得最多的那一环，恰恰因为它最容易被演示：一个循环跑起来，看着像在思考。但决定系统好不好用的，仍然是那些没法演示的部分。

有句话我一直记得：企业 AI 里最难的从来不是模型，而是搞清楚你的文档里哪一份现在还是真的。

所以，别急着把管线推倒重写。先去问一句：我们知识库里那份文件，上一次有人确认它还是最新的是什么时候？这个问题的答案，比选什么架构更能决定你的系统成不成。