Agentic RAG：从固定检索流水线到可规划工作流

解释 Agentic RAG 的查询规划、工具调用、多跳检索、自校验和生产边界。

普通 RAG 通常是固定流水线：用户问题进来，系统检索一次，模型生成答案。Agentic RAG 的变化是让系统先理解问题，再决定检索哪里、拆成几个子问题、是否调用工具、是否继续验证。

核心区别

普通 RAG 是 retrieval pipeline；Agentic RAG 是 retrieval workflow。前者强调稳定，后者强调根据问题动态决策。

典型工作流

Agentic RAG 并不是让模型自由发挥，而是把复杂检索过程拆成可控状态：理解、规划、检索、判断、生成、验证。每个状态都应该有输入、输出和停止条件。

场景	为什么适合 Agentic RAG
多跳问题	需要先查 A，再根据 A 的结果查 B。
多数据源	Wiki、SQL、Graph、API、搜索引擎都可能参与。
复杂对比	需要拆分多个维度分别检索再合并。
证据不足判断	需要决定继续检索、追问还是拒答。
工具协同	检索只是其中一步，还要计算、查询数据库或调用业务 API。

查询规划的目标不是把问题改写得更漂亮，而是把不可检索的问题拆成可检索任务。

常见 planner 输出应该包含：子问题、目标数据源、检索方式、期望证据类型、停止条件。否则 workflow 很快变成不可解释的模型循环。

Agentic RAG 常见工具包括：全文搜索、向量检索、SQL、Graph 查询、API 查询、网页搜索、计算器。工具越多，越要控制权限和成本。

Agentic RAG 的问题也很明确：延迟更高、成本更高、行为更难复现、评测更复杂。生产中不要把所有问题都交给 agent。

落地建议

关键路径保持确定性，复杂问题局部 agent 化。先用规则或分类器判断问题类型，再把少量复杂请求交给 Agentic RAG。

Agentic RAG 不能只评最终答案，还要评每一步决策。

Agentic RAG 的价值不是“更智能”，而是让系统在复杂问题上有继续查证和自我修正的能力。这个能力必须被 workflow、trace 和评测约束住。

讨论

有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。