AgenticRAG-Survey
AI Agent 嵌入 RAG 流水线,让大模型具备主动反思、多步规划与工具调用的检索增强系统
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
AI Agent 嵌入 RAG 流水线,让大模型具备主动反思、多步规划与工具调用的检索增强系统
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
试想这样一个场景:你是一家三甲医院的信息科工程师,医院部署了基于传统 RAG(Retrieval-Augmented Generation)的诊疗辅助系统。医生输入"老年男性患者,糖尿病史5年,近期出现间歇性跛行",系统返回了十几篇相关文献——但文献之间相互矛盾,有说需要立即做血管造影,有说先控制血糖观察三月。传统 RAG 的问题在于:它只负责检索,不负责判断。医生仍然需要自己读完所有文献、做综合判断。
Agentic RAG 正是为解决这个痛点而生。它将 AI Agent(智能体)嵌入 RAG 管道,让大模型不仅能检索知识,还能主动反思答案质量、规划下一步检索策略、调用外部工具验证假设、多智能体协作处理复杂问题。
本文要分析的项目 asinghcsu/AgenticRAG-Survey 是该领域目前最全面的综述仓库,配套发表在 arXiv 的学术论文(arXiv:2501.09136),系统梳理了 Agentic RAG 的理论基础、架构分类、实际应用与未来挑战。截至目前已收获 1661 颗 Stars,在 AI Agent 与 RAG 交叉领域具有较高的参考价值。
图1:Agentic RAG 中的规划模式(Planning)—— Agent 会主动分解复杂查询,制定多步检索策略
AgenticRAG-Survey 由研究人员 asinghcsu 主导维护,配套论文于 2025 年 1 月正式发布在 arXiv。该项目并非单纯的代码仓库,而是一个图文并茂的知识百科,包含超过 20 张高质量流程图、架构图和模式示意图,涵盖从基础概念到工业落地的完整知识图谱。
从 GitHub 数据来看,该仓库呈现典型的学术型项目特征:无主要编程语言标注(纯 Markdown 文档)、无活跃 Issue(0 个 open issues)、主要依靠 README 驱动的被动协作模式。尽管如此,它在短短一年多时间内获得了超过 1600 颗 Stars,说明 Agentic RAG 这个方向确实击中了广大 AI 研究者和工程师的痛点——大家都在找一份系统性的参考资料,而这个仓库恰好填补了这个空白。
Agentic RAG 的"智能"来源于四个核心模式,这是理解整个系统的关键。
Reflection(反思):Agent 会主动评估自己生成的答案质量,发现错误时主动修正。比如在医疗诊断场景中,Agent 发现初检结论与最新临床指南不符,会触发二次检索重新验证。这解决了传统 RAG"一检定终身"的最大缺陷——没有自我纠错能力。
Planning(规划):面对复杂查询,Agent 不是立即检索,而是先制定计划。例如金融风险分析场景中,Agent 会先规划"先查宏观指标、再查行业数据、最后交叉验证"的检索路径,而不是把所有关键词一股脑塞给向量数据库。
Tool Use(工具调用):Agent 可以调用外部工具——搜索引擎、API、计算器、数据库——扩展自己的能力边界。传统 RAG 只能查文档,Agentic RAG 还可以实时查股价、调用 Python 脚本做计算、访问第三方数据库。
Multi-Agent Collaboration(多智能体协作):多个专业 Agent 分工合作。例如客服场景中,一个 Agent 负责理解用户意图,一个负责知识检索,一个负责答案组装,一个负责质量审核。分工让每个 Agent 专注于单一职责,整体效果远优于单 Agent 穷尽式处理。
图2:单 Agentic RAG 架构——在传统 RAG 管道上叠加 Agent 决策层
Agentic RAG 并非一种固定技术,而是一族架构模式的集合。仓库将现有系统分为六大类:
Single-Agentic RAG(单智能体 RAG):最基础的形态,在传统 RAG 上叠加一个 Agent 负责协调检索与生成。适用于问答、文档总结等简单场景。
Multi-Agentic RAG(多智能体 RAG):多个 Agent 分工协作,每个 Agent 可专注于不同知识领域或不同任务阶段。适用于复杂的多领域综合分析。
Hierarchical Agentic RAG(层级式 RAG):Agent 形成树状层级结构,顶层 Agent 做全局规划,中层 Agent 负责子任务调度,底层 Agent 执行具体检索。适用于大规模知识库查询。
Corrective Agentic RAG(纠错式 RAG):在检索-生成流程中加入评估节点,发现低质量检索结果时自动触发重检。医疗、法律等高风险场景的核心模式。
Adaptive Agentic RAG(自适应 RAG):Agent 根据查询类型动态选择最优检索策略——简单事实查询走快速通道,复杂推理查询走多轮迭代通道。
Graph-based Agentic RAG(图结构 RAG):用知识图谱组织文档和检索路径,支持关系推理和多跳查询。例如查询"某公司的竞争对手的供应商",传统 RAG 需要两次独立检索,图结构 RAG 可以在图中直接推理出关联路径。
图3:多智能体 Agentic RAG 架构——多个专业 Agent 分工协作,提升系统整体处理能力
除了 RAG 增强之外,Agentic 工作流是 LLM 应用架构的另一大支柱。仓库专门引用了 Anthropic 的研究成果,将 Agentic 工作流分为五类:
Prompt Chaining(提示链):将复杂任务拆解为顺序执行的子步骤,每一步输出作为下一步输入。典型应用:先生成文章大纲 → 审核大纲完整性 → 撰写全文。优势是逻辑清晰、便于调试,代价是延迟增加。
Routing(路由):根据输入类型自动分配到不同的处理通道。例如简单问题走小模型快通道(节省成本),复杂推理走大模型深度通道(保证质量)。这是生产环境中平衡性能与成本的核心技巧。
Parallelization(并行化):多个独立任务同时执行,通过投票或合并输出提升置信度。典型场景:代码审查时多个模型同时检测漏洞,取并集作为最终结果。
Orchestrator-Workers(编排器-工作者):中央协调 Agent 动态分解任务、分派给专业 Worker、收集并整合结果。与 Multi-Agent RAG 的区别在于:编排器是动态的(根据输入决定分派哪些子任务),而非预先固定。
Evaluator-Optimizer(评估-优化):生成-评估-优化循环,直到输出质量达标。典型场景:多轮翻译优化、论文写作迭代、代码生成评审。
Agentic RAG 的价值最终体现在实际行业应用中。仓库列举了大量代表性案例:
医疗领域:MedRAG 系统通过多 Agent 协作,综合检索临床指南、医学文献、患者病史,生成个性化诊疗建议。Agent 还会主动标记不确定性并建议医生进一步检查。
法律领域:LawGlance 系统使用 Crew AI + LangChain + Chroma 构建的法律研究助手,能够根据用户提供的案情描述,自主规划检索策略,从大量判例和法律条文中提取相关内容,生成法律分析报告。
金融领域:投资研究 Agent 自动规划数据检索任务,综合分析宏观经济指标、行业动态、公司财报,给出风险评估和投资建议。
教育领域:自适应学习系统根据学生提问动态调整检索策略,从教材、论文、题库中检索相关内容,生成个性化学习路径。
作为一个学术综述项目,它的价值主要在于知识整理和方向指引,但在工程落地层面仍存在不少现实挑战:
多 Agent 协调开销:Agent 数量增加带来的通信延迟和状态管理复杂度呈指数级增长。在实时性要求高的场景(如客服对话)中,多 Agent 协作可能导致响应时间从毫秒级退化到秒级。
检索质量评估难题:Agent 的"反思"能力依赖于能够准确判断当前答案的质量。但在专业领域(如医学、法律),让 AI 准确评估自身答案的正确性,本身就是一个尚未解决的难题。
知识库时效性:Agentic RAG 回答的质量上限由底层知识库决定。当知识库内容陈旧时,再智能的 Agent 也只能"优雅地胡说八道"。动态知识更新机制仍是业界难题。
评估标准缺失:传统 RAG 有成熟的评估基准(BHU-GIF、RAGAS 等),但 Agentic RAG 的评估标准尚在探索中。多个 Agent 的协作效果如何量化评估,目前没有统一答案。
从 RAG 到 Agentic RAG 的演进,本质上是 AI 应用从"工具"向"助手"升级的缩影。传统 RAG 是被动的——用户问什么,它检索什么;Agentic RAG 是主动的——它会主动判断是否需要更多信息、该用什么策略检索、如何验证结论。
这个仓库的价值在于:它是目前 Agentic RAG 领域资料最全、结构最清晰的入口。无论是想了解该领域全景的研究者,还是在考虑技术选型的工程师,都可以把它当作第一手的参考手册。配合配套论文,可以快速建立从理论到实践的完整认知框架。
对于正在构建 RAG 系统的开发者,建议从这个仓库中学习两点:一是反思机制的设计——给 AI 加一个"审核自己答案"的步骤,往往比单纯增加模型规模更有效;二是多 Agent 分工的思路——不是让一个超级 Agent 处理所有事,而是让专业 Agent 做专业事。
图4:Graph-based Agentic RAG——利用知识图谱实现关系推理和多跳查询
本分析基于 AgenticRAG-Survey 仓库的 README 及配套资源,GitHub Stars: 1661,数据采集时间 2026-06-13。