Agentic RAG（代理式检索增强生成）
也叫： 代理式 RAG · 代理式检索增强生成 · agentic retrieval-augmented generation
Agentic RAG 是把检索增强生成重构成一个 Agent 循环：不是检索一次就生成，而是由模型规划查询、检索、判断结果够不够、改写查询或换来源，反复直到能作答。
经典的检索增强生成是一条固定的两步流水线：把用户问题做向量化，从向量库里取最匹配的若干片段，塞进提示词让模型据此作答。当答案集中在一处、且问题措辞和原文相近时，它效果不错。遇到多跳问题、措辞含糊、或者第一次检索没命中的情况，它就吃力了。
Agentic RAG 把检索变成由模型驱动的决策，放进一个循环里。模型规划要找什么，把检索作为一次工具调用发出去（function-tool-calling），读结果，然后判断：这够不够回答？还是需要换个更好的查询再搜一次、或者去查另一个来源？它可能把一个问题拆成几个子问题，各自检索，再合并。这个结构就是把 agent-loop / react-prompting 模式用到了检索上。
到 2026 年，这已经是主流的生产做法，而不是研究里的新奇玩意。代价是成本和延迟——好几次模型调用和检索往返，而不是一次——外加需要护栏让循环能停下来。它用在问题确实是多步、或知识分散在多个来源的场景；当问题不是这样时，朴素 RAG 仍然是对的选择。
怎么运作
这个循环通常包含：规划（需要什么信息，必要时拆成子查询）；路由（每一部分该用哪个索引、数据库、API 或网页搜索作为来源）；通过工具调用做检索；评估（结果相关且充分吗？由模型或一个单独的检查来判断）；以及改写（重写查询、换来源、或收窄/放宽）后再循环。当模型判断信息够了、或步数预算用尽时退出。和朴素 RAG 相比，多出来的机制就是模型对『查询怎么写、用哪个来源、什么时候停』的掌控——这些都不是事先定死的。
举个例子
问题：『我们支付服务依赖的那个框架，在我们锁定的版本之后有没有改过许可证？』朴素 RAG 会检索关于该框架许可证的片段，然后基本上有什么就答什么。Agentic RAG 会规划两个子问题——锁定的是哪个版本、许可证历史是怎样的——为第一个检索 lockfile，为第二个检索该框架的 changelog 和许可证文件，发现 changelog 的引用有歧义，针对具体版本区间重新查询，然后才作答，并引用两个来源。
和相关概念的区别
Agentic RAG 与经典 RAG：经典 RAG 做一次向量检索，把 top-k 片段按固定流水线交给模型。Agentic RAG 让模型迭代——改写查询、在多个来源中选择、拆解问题、决定何时停止——代价是更多模型调用、更高延迟，以及需要给循环设上限。
常见误解
常见问题
Agentic RAG 是什么？
Agentic RAG 和普通 RAG 有什么区别？
什么时候该用 Agentic RAG？
最近核实： 2026-08-30