Agentic RAG实战：原理剖析与LangChain代码实现指南

传统RAG系统的局限性正在被越来越多的开发者感知到：检索不到答案就直接返回空结果、无法回答"知识库有哪些文档"这类元数据问题、缺乏多轮迭代纠错的能力。2025年，Agentic RAG正在成为大模型应用开发的核心范式。本文将从传统RAG的实现原理出发，深入剖析Agentic RAG的架构设计，并给出基于LangChain和LangGraph的完整代码实现。

传统RAG的实现流程与致命局限

离线流程：文档切片→向量化→存储

传统RAG的第一个核心流程是离线预处理。首先将PDF、Word、TXT等格式的文档加载到内存中，然后进行文本切片。由于完整文档可能包含上万字，无法一次性送入大模型的上下文窗口，因此需要将文档切分成固定长度的段落（如256个字符），段落之间保留一定的重叠区域以保证语义连贯性。

切片完成后，每个段落通过Embedding模型（如千问Embedding 0.6B）转换为固定维度的向量表示，最后存储到向量数据库（如ChromaDB）中。这个过程与用户查询完全无关，属于系统初始化阶段。

关于Embedding模型的技术背景：Embedding模型是将自然语言文本映射到高维向量空间的神经网络模型。其核心思想源自分布式语义假设——语义相近的词语在向量空间中距离也相近。早期的Word2Vec、GloVe只能处理单词级别的表示，而现代Embedding模型（如OpenAI的text-embedding-ada-002、阿里的千问Embedding系列）能够将整个句子或段落编码为固定维度的稠密向量（通常为768维或1024维）。向量相似度计算通常采用余弦相似度或内积距离，这使得语义检索能够突破传统关键词匹配的局限，捕捉同义词、近义表达等深层语义关联。

关于ChromaDB：ChromaDB是一款开源的嵌入式向量数据库，专为AI应用设计。与Pinecone、Weaviate等云原生向量数据库不同，ChromaDB可以完全在本地运行，无需网络连接，非常适合原型开发和中小规模应用。它支持多种距离度量（余弦相似度、欧氏距离、内积），内置了文档的自动分块和元数据过滤功能。在生产环境中，如果数据规模超过百万级向量，通常需要考虑Milvus、Qdrant等支持分布式部署和HNSW索引优化的向量数据库方案。

离线流程示意

在线流程：检索→拼接Prompt→生成回答

当用户提出问题后，系统首先对问题进行Query改写，使其更适合检索匹配。然后通过两种方式进行检索：一是BM25关键词检索，二是向量相似度匹配。两种方式各返回若干片段后进行合并和重排序，最终将Top-K的文档片段注入到Prompt模板中，交给大模型生成答案。

关于BM25与混合检索策略：BM25（Best Matching 25）是信息检索领域经典的概率排序算法，由Stephen Robertson等人在1990年代提出。它基于词频（TF）、逆文档频率（IDF）和文档长度归一化三个因素对文档进行相关性打分。与纯向量检索相比，BM25在精确关键词匹配（如专有名词、代码片段、数字编号）方面具有天然优势。混合检索（Hybrid Search）将BM25的精确匹配能力与向量检索的语义理解能力结合，通过Reciprocal Rank Fusion（RRF）等融合算法对两路结果进行重排序，在实际生产环境中通常能获得比单一检索方式高10-20%的召回率提升。

Prompt模板通常比较直接："你是一个专业助手，请根据以下参考文档回答问题。Context: {检索到的文档片段}，Question: {用户问题}"。如果检索到的片段不包含答案，模型只能回复"不知道"。

传统RAG为什么不够用？

整个过程是单向、固定、一次性的。从用户问题到检索、拼接上下文、生成答案，一条直线走到底。当第一轮检索未能命中相关内容时，系统没有能力重新检索、换一种查询方式、或者主动补充上下文。这就是传统RAG最根本的局限——没有反馈回路，也没有自我纠错机制。

Agentic RAG：从固定流水线到智能决策闭环

核心理念：将检索能力封装为可调用工具

Agentic RAG是对整个RAG流程的根本性升级。它将RAG中的各个环节——Query改写、向量检索、关键词搜索、文件读取等——全部封装成可调用的工具（Tool），并赋予大模型自主决策的权利。

Agentic RAG核心流程

模型不再被动地执行固定流程，而是进入一个思考→调用工具→观察结果→再思考的循环闭环。只有在获取到足够的信息后，才生成最终答案。这正是Agent（智能体）的典型行为模式。

Agentic RAG的三大核心能力

Agentic RAG的实现依赖模型具备三类关键能力：

规划能力（Planning）：模型能够在Chain-of-Thought推理过程中规划行动步骤，判断下一步该做什么
工具调用能力（Tool Use）：模型能够根据当前需求选择并调用合适的工具，甚至进行多Agent协作
多步迭代能力（Iteration）：模型可以在生成最终答案之前进行多轮工具调用，不断完善和补充信息

这三种能力的组合，让Agentic RAG具备了传统RAG完全不具备的自适应检索和动态纠错特性。

关于ReAct模式的理论基础：ReAct（Reasoning + Acting）模式由普林斯顿大学和Google Brain团队在2022年提出，论文标题为《ReAct: Synergizing Reasoning and Acting in Language Models》。该方法的核心创新在于将Chain-of-Thought推理与外部工具调用交织进行——模型在每一步先生成推理轨迹（Thought），然后决定执行一个动作（Action），观察动作返回的结果（Observation），再基于观察继续推理。这种交替进行的模式解决了纯推理容易产生幻觉、纯行动缺乏规划能力的问题。ReAct模式已成为当前主流Agent框架（如LangChain、AutoGPT、CrewAI）的底层执行范式。

ChatBoss开源项目：Agentic RAG架构实战解析

架构设计思路：用时间换智能

以开源项目ChatBoss为例，其Agentic RAG的实现逻辑非常值得参考。当用户发送问题后，系统首先判断当前模型是否支持工具调用：

ChatBoss实现逻辑

不支持工具调用的降级方案：通过Prompt判断问题是否需要检索。如果不需要，直接回复；如果需要，则进行语义搜索，将相关片段注入上下文后生成答案。这种"先判断再检索"的方式，比在Prompt中让模型忽略无关Context的效果更好。

支持工具调用的完整方案：将所有工具集合注册到模型中，由模型自主决策调用哪些工具、以什么顺序调用。从用户输入问题的那一刻起，大模型就开始参与决策，而不是只在最后的生成阶段才介入。

四大核心工具设计

ChatBoss设计了四个核心工具，充分体现了Agentic RAG的设计精髓：

工具名称	功能说明	解决的问题
Search Query	基础的语义检索	标准RAG检索能力
List Files	列出知识库中的文件清单	传统RAG无法回答"有哪些文档"的问题
Read File	按文档ID精确读取片段	信息不完整时主动补充前后上下文
Gather File Meta	读取文件元数据	获取文档的结构化信息

关于Agent工具设计原则：在Agentic系统中，工具（Tool）的设计质量直接决定了Agent的能力边界。优秀的工具设计需要遵循几个原则：首先是原子性，每个工具应该只完成一个明确的功能，避免功能耦合；其次是描述清晰性，工具的名称和描述（description）必须让模型能够准确理解其用途和调用时机，因为模型完全依赖文本描述来决策；第三是参数规范性，输入输出的Schema定义要严格，减少模型生成非法参数的概率；最后是容错性，工具应该能够优雅地处理异常情况并返回有意义的错误信息，而不是直接崩溃，这样Agent才能基于错误信息调整策略。

其中，List Files工具让模型能够回答"知识库里有哪些文档"这类传统RAG完全无法处理的元数据查询。Read File工具则允许模型在发现检索片段信息不完整时，主动读取前后相邻片段来补充上下文，不再完全依赖语义相似度检索。

传统RAG与Agentic RAG对比

实际效果对比

以一个具体场景来说明两者的差异：

传统RAG：用户查询→向量检索→返回结果→直接生成答案（一步到位，无纠错机会）
Agentic RAG：第一轮搜索→发现命中率低→自动改写查询词→第二轮搜索→命中相关片段→第三轮搜索获取补充文档→基于整合后的完整信息生成高质量答案

代码实现：传统RAG与Agentic RAG对比

传统RAG的LangChain代码实现

基于LangChain框架，传统RAG的实现分为离线和在线两部分：

离线部分：加载文档→文本切分（设置chunk_size和overlap）→Embedding向量化→存储到ChromaDB。核心就是三个参数：文档块大小、重叠区域、Embedding模型选择。

在线部分：加载ChromaDB→构造用户Query→调用similarity_search（设置K=3返回最相关的3个片段）→读取PageContent→拼接到Prompt模板→大模型生成答案。

说个细节，在实际项目中，离线流程的质量决定了RAG系统的效果上限。如何切分文档、选择什么Embedding模型、是否需要缓存策略——这些都直接影响最终注入Prompt的Context质量。

Agentic RAG的LangGraph代码实现

Agentic RAG的实现核心是LangGraph中的create_react_agent函数，它实现了ReAct（Reasoning + Acting）模式：

# 1. 定义工具列表
tools = [search_query, list_files, read_file, gather_file_meta]

# 2. 编写系统Prompt，引导模型合理使用工具
system_prompt = \"你是一个Agentic RAG助手，请按以下步骤...\"

# 3. 创建ReAct Agent
agent = create_react_agent(
    llm=model,           # 大模型
    tools=tools,         # 工具列表
    system_message=system_prompt  # 系统提示
)

# 4. 运行Agent
result = agent.invoke({\"messages\": [user_query]})

关于LangGraph框架：LangGraph是LangChain团队在2024年推出的Agent编排框架，专门用于构建有状态的、多步骤的AI应用。与LangChain的线性Chain不同，LangGraph基于有向图（Directed Graph）的抽象，允许开发者定义节点（Node）和边（Edge）来描述复杂的控制流，包括条件分支、循环、并行执行等。其核心优势在于内置了状态管理和检查点机制，使得Agent可以在多轮交互中保持上下文记忆，并支持人机协作（Human-in-the-loop）场景。create_react_agent是LangGraph提供的高层API，封装了ReAct循环的完整逻辑，开发者只需定义工具和提示词即可快速构建功能完备的Agent。

代码看上去简洁，但它赋予了模型自主决策、动态调整的能力。模型会在"思考-行动-观察"的循环中不断调用工具，直到收集到足够信息才输出最终答案。

有一个容易踩的坑需要注意：Prompt中必须对模型的回复格式进行严格约束，否则模型可能会去掉引号或括号等符号，导致工具调用的参数解析失败。

总结：工具赋予能力，智能在于选择

传统RAG是固定流程的"流水线"，简单直接但缺乏灵活性和纠错能力；Agentic RAG则是具备智能体行为的"闭环系统"，能够自主规划、调用工具、反思结果并迭代优化。

从技术实现角度看，Agentic RAG的核心逻辑并不复杂——将检索能力封装为工具，借助ReAct模式让模型自主决策。真正的差异化竞争力在于三个方面：工具设计的完备性、Prompt工程的精细度、以及对各种边界情况的鲁棒处理。

工具赋予能力，而智能在于选择。真正的Agentic RAG，始于检索，成于决策。