去年你上线了 RAG 系统，今年你又花了大价钱升级成 Agentic RAG——结果发现，系统倒是聪明了，但莫名其妙地开始发疯：有时候一个问题查了 20 轮还不停，有时候调起一堆工具把响应拖慢到无法接受，有时候答案倒是出来了但上下文爆棚根本装不下。
别慌，这些都是 Agentic RAG 的”经典名场面”。今天我们就来聊聊三种最常见的失败模式：Retrieval Thrash（检索震荡）、Tool Storm（工具风暴）和Context Bloat（上下文膨胀），顺便说说怎么识别和规避。
先说本质区别
在讲坑之前，先快速对齐一下认知：传统 RAG 是一条固定流水线，你问问题，它查一次资料，生成回答，结束。
Agentic RAG 是控制循环（Control Loop）：生成 → 检查 → 判断要不要再查 → 再查 → 再检查 → 直到满意或达到上限。
这个区别听起来很美好——系统能自主判断答案够不够好，不够就继续查。但问题也出在这里：当这个循环失控时，你根本不知道它在干什么。
打个比方：传统 RAG 像一台按固定程序运转的洗衣机，你设定好模式，它转完就停。Agentic RAG 像一台装了 AI 的洗衣机——它会自己判断衣服洗干净没有，没干净就继续转。但 AI 判断失误时，它可能认为永远没洗干净，转到天荒地老。
坑一：Retrieval Thrash（检索震荡）
什么是检索震荡
Retrieval Thrash 指的是 Agent 在检索循环里反复查同一类内容，但每次都像在原地打转，查不出新东西，却还在继续查。
举个例子。你问 Agent：“我们公司去年Q3收入最高的产品线是哪个？”
Agentic RAG 开始工作：
- 第一轮检索：查到”Q3 收入数据”
- 检查结果：发现了数据，但数据里没有产品线分类字段
- 第二轮检索：专门查”产品线分类”
- 检查结果：产品线分类找到了，但Q3的还没找到
- 第三轮检索：再查”Q3产品线收入”……
几轮下来，系统一直在查”Q3”+“产品线”+“收入”的排列组合，但每次检索的内容重叠度极高，没有实质性进展。这就是检索震荡。
怎么识别
有几个明显的信号：
- 单次请求触发了 10+ 轮检索循环
- 每一轮的检索关键词高度相似，只是排列组合不同
- 最终答案和第一、二轮能查到的内容差不多
怎么规避
设置明确的停止条件。比如：最多循环 3 轮；如果连续两轮检索结果重合度超过 80%，强制停止。用缓存避免重复检索——如果上一轮已经查过”Q3收入”，下一轮就不需要再查同样的东西。加上路由层，让 Agent 在第一轮就判断这个问题到底复不复杂，简单问题走轻量路径，根本不进入循环。
坑二：Tool Storm（工具风暴）
什么是工具风暴
Tool Storm 指的是 Agent 面对一个问题时，一下子把所有能调用的工具全用上了，而不是按需选择。
你设计了一个 Agentic RAG，给它配了：网页搜索、数据库查询、PDF 读取、表格解析、图像识别……七个工具。结果它遇到一个问题，哗一下全调起来了。
这还不是最惨的。最惨的是 Agent 在循环里每轮都调用全部工具，导致一次请求触发了几十条 API 调用，成本直接爆炸，响应时间从几百毫秒变成几十秒。
打个生活化的比方：你只是想查一下明天天气，Agentic RAG 给你调起了卫星云图分析、气象局数据库查询、气象论文检索……全套气象工具。
怎么识别
Tool Storm 有几个典型症状：
- 单次请求触发的工具调用次数是预期的 5-10 倍
- 日志里出现大量并发或连续的工具调用
- 响应时间异常长，但最终答案质量并没有显著提升
- API 账单明显超出预期
怎么规避
限制每次循环可调用的工具数量，比如一轮最多调用 2 个工具。给工具加上使用条件，不是所有问题都需要 PDF 解析，只有当检索结果显示需要读文档时才激活。加上工具选择评估，让 Agent 在调用工具之前先问自己：“这个问题真的需要调用这个工具吗？“
坑三：Context Bloat（上下文膨胀）
什么是上下文膨胀
这是最隐蔽的一个坑。Agentic RAG 因为有多轮检索，每一轮的结果都会积累到上下文里。如果不加控制，上下文会越滚越大，最后模型要么溢出来装不下，要么装得下但推理质量严重下降。
举个例子。用户问了一个复杂问题，比如”分析我们公司近三年战略规划的演变，以及对组织架构的影响”。这个问题需要查多份文档，Agentic RAG 拆成 5 轮检索，每轮返回 5 条文档片段，结果上下文里堆了几十段文字。
而这些片段很可能互相重复、信息密度低，真正有用的内容淹没在噪声里。
怎么识别
Context Bloat 的信号：
- 最终答案开始出现自相矛盾的说法（上下文太嘈杂，模型被干扰了）
- 生成的回答包含引用来源但内容空洞（有效信息被淹没）
- 长文档检索后出现明显的回答质量下降
怎么规避
定期压缩上下文，而不是无限累积。可以采用”摘要替换”策略——把前几轮检索的内容压缩成一段摘要，再继续往后加新内容。选择性保留，只把与最终答案直接相关的片段加入上下文，其他片段要么丢弃，要么标记为”备用参考”。加上召回过滤，在把检索结果加入上下文之前，先用一个轻量模型判断这段内容跟问题的相关度，低于阈值就丢弃。
三个坑之间的关系
有意思的是，这三个坑往往会连锁触发。
检索震荡 → 每次震荡都在积累上下文 → Context Bloat 工具风暴 → 每次风暴都在调用新工具获取新数据 → 上下文快速膨胀 → Context Bloat Context Bloat → 模型上下文装不下 → 检索结果判断失误 → 更多无意义的检索轮次 → Retrieval Thrash
所以如果你在生产环境里看到 Agentic RAG”越转越慢、越答越乱”，很可能不是单一问题，而是三个坑在互相放大。
一句话总结
Agentic RAG 的控制循环让它比传统 RAG 强大得多，但循环失控时也比传统 RAG 难排查得多。上线前一定要设置好停止条件、工具限制和上下文管理三道闸——不然你的 Agentic RAG 不是变强了，是变贵了、变慢了、变离谱了。