检索增强生成（Retrieval-Augmented Generation，RAG）将大语言模型与外部知识库结合，以生成准确、有上下文依据的回答。传统 RAG 流程采用固定步骤：收到查询后检索相关文档，再将文档交给 LLM，一次生成回答。引入智能体的 RAG 通常称为 Agentic RAG，它在流程中加入 AI 智能体，由智能体动态决定何时以及如何使用检索或其他工具。上周已经构建了一个简单的 Agentic RAG 系统。本周将进一步研究完整流程的可能形式，以及智能体系统的一般设计模式。本课讨论 Agentic RAG 的用途、常见架构模式、智能体的决策逻辑，以及智能体操作与检索器之间的接口。
回顾：传统 RAG 流程及其限制
传统 RAG 流程：在基础 RAG 系统中，embedding 模型将用户查询转换为向量，并从向量数据库，也就是知识库中，检索相似文档。检索得到的上下文与查询一起传给 LLM，用于生成回答。更完善的 RAG 实现还可能包括混合搜索，将向量相似度搜索与关键词搜索结合；对检索结果重新排序；使用提示模板使回答更有依据；以及通过提示或工具注册表管理多种资源。
固定 RAG 流程的限制：固定 RAG 流程虽然有效，却存在几项已知限制。首先，它受限于向量数据库中的数据，难以获取实时数据或已经建立索引的知识之外的信息。如果用户询问刚刚发生的事件，或者索引所涵盖领域之外的问题，系统就缺少查找相关信息的机制。其次，每个查询只执行一次检索。如果查询表达不佳，或者 embedding 没有正确匹配，检索可能返回无关文档。LLM 此时可能无法回答，也可能依据无关上下文生成幻觉。固定流程没有反馈循环，无法自行检查和纠正问题，也不知道检索数据是否相关、是否充分。最后，这类流程的适应能力有限：每个查询独立处理，始终沿用固定顺序，无法为复杂问题规划多步骤策略。这些限制促使我们在流程中加入具有推理和决策能力的智能体。
Agentic RAG：通过 AI 智能体进行自适应检索
Agentic RAG 利用 AI 智能体提高 RAG 的灵活性和准确性。这里的智能体是通过适当的提示工程获得决策和工具使用能力的 LLM。系统可以依据查询及中间结果，决定是否检索、何时检索、如何检索，还可以使用检索之外的工具。智能体由此控制 RAG 工作流程。它可以执行多步骤推理：分析查询，决定从一个或多个来源获取信息，必要时核查或完善信息，最后形成回答。单次固定查询因而可以扩展为自适应的迭代过程。
智能体的主要能力：智能体系统具有基础 RAG 循环之外的能力，其中大部分已在上周介绍。
- 工具使用：智能体，也就是 LLM，可以调用搜索引擎、数据库查询、计算器或其他 API 等外部函数。本课主要使用的工具是获取相关上下文的检索器。工具调用使智能体能够在执行期间引入新信息，也可以在一次交互中执行多次搜索。
- 逐步推理：智能体可以将复杂任务划分为多个步骤，或通过反复查询推进任务。这包括查询规划，即将复杂问题分为更简单的问题，以及依据中间结果进行条件判断。例如，面对范围较广的问题，智能体可以判断：“是否需要查找多项信息？应当首先查找哪项信息？”然后规划相应的检索。
- 记忆与状态：智能体能够在多次交互之间保留状态，记住先前检索到的信息和作出的决定。短期记忆通常通过消息历史或状态对象维护，使智能体能够继续利用已有工具结果。在更长的交互中，缓存或对话历史等长期记忆也有助于维持一致性。
- 自主性与适应能力：具备上述能力后，智能体能够适应变化的需求。例如，一个知识来源无法提供答案时，可以尝试其他来源或方法。固定流程通常需要人工针对各种特殊情况调整提示；智能体则可以在合理限制内自行纠正，并通过迭代寻找解决方法。
相较传统 RAG 的改进：Agentic RAG 可以在一次会话中灵活获取多个知识库或 API 的数据，标准 RAG 流程通常只查询一个向量数据库。它能够根据实际情况形成工作策略，提高流程的适应能力。智能体还可以核查并完善结果，在首次检索结果可疑时继续检查，因此有机会提高准确性。这种架构也可以扩展到多模态数据及多智能体协作。
需要权衡的因素：Agentic RAG 并不适用于所有情况。能力增强会带来更高复杂度。多步骤推理需要更多 LLM 调用，增加延迟和 API 成本，也引入更多需要可靠处理及评估的组件。智能体仍然可能产生混淆、编造工具用法，或者在缺少约束时反复循环。因此，工程实现需要仔细设计决策逻辑和防护措施。接下来讨论如何使用 LangGraph 实现这些智能体。
Agentic RAG 的架构模式
智能体增强的 RAG 没有适用于所有任务的唯一设计，具体架构取决于使用场景。常见模式包括：根据需要使用上下文的检索智能体、通过改写查询进行纠正的 Corrective RAG，以及使用多个检索工具的智能体。
检索智能体：决定何时检索
一种简单的集成方式是让 LLM 判断回答问题是否确实需要外部知识。固定 RAG 流程会为每个查询检索文档，但用户问候或提出简单问题时，这一步可能没有必要。智能体可以在适当情况下跳过检索，直接回答。这样能够节省时间和计算资源，也能减少简单查询引入无关数据后产生的混淆。
工作方式：为 LLM 配置检索工具，并通过提示要求它仅在需要时使用。例如，在 LangGraph 中可以设置 generate_query_or_respond 节点，接收包含最新用户消息的对话状态，再调用 LLM。这个 LLM 绑定 retrieve_context 等工具，其本质是搜索向量数据库的函数。提示或少量示例应当明确说明：“如果用户提出的事实性问题可能需要外部信息，使用搜索工具查找相关内容。如果根据已有知识就能回答，或者用户正在进行日常交谈，则直接回答，无需调用工具。”
执行该节点时，LLM 可以直接输出回答，也可以输出需要调用工具的操作。在 LangGraph 中，图工作流程可以据此选择不同分支。具体而言，条件边检查模型是否调用了检索工具：如果调用，就进入 Retrieve 节点或通用 Tool 节点；如果模型已生成最终回答，则结束流程。可以使用一个简单函数检查模型最后一条消息中的工具调用，实现这种条件路由。
与检索器交互：检索器与普通 RAG 系统中的检索器相同，只是封装为智能体可调用的工具。收到调用请求后，LangGraph 的工具处理节点执行检索，并将结果作为消息写入智能体状态；在 LangChain 中，这类消息标记为 ToolMessage。下一步，智能体便能从对话上下文读取检索文档。状态中依次包含用户问题、助手的工具调用操作，以及工具返回的检索文本。智能体可以依据这些信息继续推理。如果选择了无需检索的路径，则直接生成回答并结束。这种模式通过判断检索是否必要，更高效地处理简单查询，改善使用体验。
Corrective RAG：通过改写查询执行多步骤检索
更进一步的模式处理首次检索失败或信息不足的情况。固定流程可能因此给出错误或缺少帮助的回答，智能体则可以识别问题并通过迭代纠正。这种模式通常称为 Corrective RAG，与 Corrective Retrieval-Augmented Generation（CRAG）的策略相近。其主要过程是核查检索文档的质量，再决定生成回答，或者完善查询后重试，必要时改用网页搜索等其他工具。
工作流程：收到新问题后，智能体首先从向量数据库检索文档。接下来执行评定步骤，由基于 LLM 的函数检查检索文本，判断其是否与问题相关。例如，可以设置 grade_documents 节点，输入问题和检索上下文，输出“相关”或“不相关”的判断。评定模型的提示可以写为：“以下是用户问题和一份检索文档。文档中是否包含有助于回答问题的信息？请回答 yes 或 no。”如果文档充分，流程进入回答生成步骤。如果文档无关，或者完全没有检索结果，就启动查询改进流程。通常包括两步：首先由 LLM 将用户问题改写为更有效的查询，例如提高具体程度或使用其他关键词；然后使用网页搜索 API 或另一个向量数据库等检索工具，依据改写后的查询获取补充信息。最后，将向量数据库和网页等来源中的相关内容结合，生成最终回答。
在 LangGraph 中，可以使用带条件边的有向节点图组织整个循环，将不同逻辑清楚地分配给各个节点。智能体首先可能使用工具，随后由评定节点选择回答节点或改写节点；改写节点再返回检索步骤。评定后的条件边读取模型输出：结果为“yes，相关”时进入回答节点，为“no”时进入查询改写节点。改写节点生成新的用户查询，在状态中替换或完善原问题，然后再次执行检索，也可以改用 web_search_tool 等工具。流程可以多次循环，但在实际应用中，通常为了效率只允许一次或有限次数的重试。
作用：这种纠正模式有助于提高稳健性。智能体在回答前主动核查知识，减少使用无关数据或产生幻觉的机会。如果自身知识库没有相关答案，可以获取实时或外部数据作为补充。例如，用户询问企业聊天助手“本季度营收”，但向量数据库中的资料只更新到去年。固定 RAG 流程可能返回过时回答；Agentic RAG 可以发现没有检索到相关文档，重新组织查询，再使用网页搜索或数据库查询获取最新信息。这个设计同时处理知识过时和上下文无关的问题，通过实时数据及迭代核查补充已有知识。
从工程角度看，可以为检索、评定、改写和回答分别编写规模较小、便于测试的函数，将决策路由交给 LangGraph。这种模块化设计便于替换网页搜索工具或调整评定标准，无需重写全部智能体逻辑。评定和改写应当分别使用专门设计的提示，与最终回答提示区分。使用结构化输出，例如输出布尔值的 Pydantic 模型，也有助于可靠地解析判断结果并选择执行路径。
多工具与多来源智能体
复杂应用可能为智能体提供多个检索器和其他工具。例如，购物助手可以具有商品库存的向量索引、用户评论的向量索引，以及网页搜索 API。固定流程较难结合这些来源，或为特定问题选择适当来源；智能体可以根据问题选择工具，并汇集多个来源的信息。
选择适当的知识来源：可以使用路由智能体，也称 router，分析查询并判断哪个工具或知识库最可能提供答案。这个过程可以实现为分类步骤，例如简单的 if/else 判断，或输出工具名称的 LLM 提示。查询提到“耳机”时，可以使用 Available Items 检索器；提到“关于使用寿命的好评”时，可以使用 Reviews 检索器，并同时返回商品 ID 和上下文片段；如果问题较为一般，或这些来源没有相关信息，则通过网页搜索查找合作商店中的选项。在 LangGraph 中，可以通过工具说明让 LLM 自行选择，也可以单独设置预处理步骤。Agentic RAG 因而能够访问多个数据来源，并使用检索之外的工具；标准 RAG 通常围绕单个数据集运行。
依次使用多个工具：智能体还可以连续调用多种工具回答同一个问题。例如，用户询问：“能否从现有商品中推荐一台笔记本电脑？同时，请确认以往买家的评价足以证明推荐商品经久耐用。”智能体可以依次执行：使用向量数据库工具查找符合一般要求的笔记本电脑；通过另一个向量数据库工具，先将索引限制在首次检索所得商品范围内，再搜索用户评论；最后返回符合最初查询、耐用性评价良好的商品。在 LangGraph 中，工具调用后可以返回智能体节点，形成类似 ReAct 的推理模式。LLM 节点负责推理，Tool 节点执行操作，两者交替运行。状态持续保留，因此后续操作可以依据之前获取的全部信息。
一种具体实现只需要两个主要节点：能够生成工具调用或最终回答的 Agent 节点，以及工具执行节点。Agent 节点输出最终回答，或者一个或多个工具调用。条件边在存在工具调用时进入 Tool 节点，否则进入 End。Tool 节点执行请求的工具，例如检索文档或执行其他操作，并将结果作为新消息附加到状态中。流程随后返回 Agent 节点，智能体读取工具结果，决定下一步。这相当于在 RAG 系统中实现 ReAct：智能体循环进行推理、工具操作和结果观察，直至能够回答问题。
功能完整的 Agentic RAG 系统
具体场景中的 Agentic RAG 形式需要根据需求确定。提高智能体自主程度通常会增加复杂度和延迟，同时有助于提高精确性及准确性。一个功能较为完整的系统可以采用以下结构。
- 分析查询
- 判断回答是否需要补充数据，需要时调用检索工具。
- 重排序检索结果
- 检索结果经过重排序，再用于生成答案。
- 分析答案
- 检查答案是否正确、是否与查询相关。
- 改写查询
- 答案需要改进时，改写查询并重新分析。
分阶段阅读 · 3 个阶段
- 分析用户查询：将原始查询交给基于 LLM 的智能体。智能体可以一次或多次改写查询，生成后续流程使用的一个或多个查询，并判断回答问题是否需要其他数据来源。
- 需要补充数据时，执行检索。一个或多个智能体负责选择数据来源，例如实时用户数据，包括用户当前位置；用户可能需要的内部文档；通过网页搜索工具获取的数据，以及其他来源。
- 汇集检索数据，使用比普通 embedding 模型能力更强的模型进行重排，大幅缩小候选数据范围。
- 无需补充数据时，通过提示 LLM 尝试生成最终回答，也可以生成多个回答或一组操作。
- 分析、归纳并评估回答的正确性和相关性。如果智能体认为回答达到要求，就将其返回用户；如果仍需改进，则尝试改写用户查询，重新执行生成循环，并为循环次数设置上限。
设计时应尽可能保持流程简洁，仅在系统验证结果未达到要求时增加必要步骤。
智能体决策逻辑与实践建议
集成智能体需要仔细考虑每一步的决策逻辑，也就是智能体如何判断下一步操作。一部分决策由提示引导 LLM 完成，另一部分可以通过代码或图中的条件明确规定。RAG 智能体的多步骤决策可以采用以下做法。
- 清楚的提示说明：使用系统提示和示例规定行为。例如，检索或回答智能体可以明确遵循：“如果已有上下文足以回答用户问题，直接回答；否则使用
retrieve_context查找相关信息。”这样的规则能够减少随意行为。使用多个工具时，也应说明各工具适用的情况。即使是能力很强的 LLM，也需要这种通过提示工程设定行为的方法。根据上周的内容，工具使用所需的提示工程通常体现在工具函数准确、清楚的 docstring 中；这些工具也可以通过本周将进一步讨论的 MCP Server 提供。 - Chain-of-Thought 与决策依据：鼓励智能体在操作前进行内部推理。在 ReAct 风格提示中，模型可能先生成说明原因的 Thought，再生成 Action。使用 function calling 的模型可能不会显示这个过程，但可以通过少量示例演示相应的决策方式。目标是让智能体在确实缺少答案或需要证据时调用检索器。提示中可以提供两个问答示例，一个无需工具，另一个需要工具，帮助模型根据上下文判断何时停止、何时继续搜索。
- 限制循环并设置防护：多步骤智能体理论上可能持续循环，例如始终认为搜索结果不足。因此，应设置最大迭代次数。LangGraph 的图若包含循环，例如上周构建的 ReAct 智能体，应加入计数器或停止条件。例如，查询改写一次后停止，并利用已有信息回答。还可以检测重复查询，在智能体反复提出相同查询时终止循环。始终保留默认结束条件，确保在合理情况下能够到达终点，即使最终回答只能说明无法找到所需信息。
- 验证与内容审核：与使用 LLM 评定文档相关性类似，也可以验证最终回答，例如依据来源核查事实，或检查回答是否符合指定标准。生产系统适合增加评估输出安全性和正确性的步骤，也可以通过并行过程执行，必要时加入人工批准。例如，智能体生成回答草稿后，独立验证节点可以标记与已知数据矛盾或缺少引用的内容，要求智能体重新考虑。
- 可观测性与调试：多步骤推理较难追踪，因此需要记录智能体执行过程。记录可获得的推理说明和操作，有助于调试逻辑问题。如果智能体决策不佳，追踪记录能够显示当时的提示和状态，便于改进提示或逻辑。
- 实际约束：始终考虑用户体验和系统限制。工具较多或推理复杂时，响应会更慢，并非每种查询都适合等待。可以让复杂或重要查询使用完整智能体流程，简单查询使用较简单的路径。例如，在入口设置轻量分类器，判断请求属于简单事实问题还是日常对话，在不需要智能体时跳过相关步骤。这种混合方式能在单次 RAG 已足够时减少多步骤推理的开销。
使用真实数据测试：使用实际场景中的问题测试集成后的系统。智能体在特殊情况下的行为可能难以预料。例如，测试可能发现，即使向量数据库已有答案，智能体仍总是使用网页搜索，原因可能与提示措辞有关。这样的发现有助于调整提示或工具说明，例如强调优先使用内部数据，在内部来源不足时再使用网页搜索。根据回答准确性、用户满意度等指标，对 Agentic RAG 和固定 RAG 进行 A/B 测试，可以量化收益，并判断新增复杂度是否合理。
智能体推理如何增强 RAG
智能体可以通过以下方式改善检索，某些情况下也可以替代固定检索流程。
- 根据上下文选择检索：智能体可以结合上下文决定何时检索、检索什么内容。固定 RAG 通常执行相同操作，例如返回相似度最高的五项结果。智能体可以针对罕见术语选择关键词搜索，也可以在答案明确时跳过检索。这类判断有助于获取更相关的信息，减少不必要文本对 LLM 的干扰。
- 通过迭代逐渐深入搜索：首次检索提供线索后，智能体可以提出更有针对性的后续问题，继续获取更具体的信息。这个过程类似研究人员逐渐缩小范围、寻找答案，能够处理需要综合多项信息或经过多步骤推理的复杂问题，而单次 RAG 通常较难完成这类任务。
- 结合多种工具：智能体可以使用文档检索之外的工具。例如，用户询问“根据报告，X 与 Y 的比值是多少”，固定 RAG 可能只能以文本近似计算，或者忽略计算要求。智能体可以检索相关数值，调用计算器计算比值，再报告结果。多工具能力扩大了 AI 系统能够自主处理的任务范围，使 Agentic RAG 可以发展为能够获取信息，并根据需要执行操作或转换信息的助手。
- 通过调整方法提高稳健性：初始方法无效时，智能体可以更换数据来源或重新表述问题。传统 RAG 的开发者通常需要提前考虑失败情况，编写替代处理逻辑，或者接受系统有时无法回答。智能体能够承担其中一部分工作，识别“没有找到有用信息”的情况，并根据已有线索重试。它仍然无法保证每次成功，但往往能够提高找到答案的概率。
这些能力需要配合审慎的监督和权衡。在医疗或法律等重要应用中，确定性较强的检索流程加上人工核查可能仍然更加适合。对于许多企业和一般应用，Agentic RAG 则提供了一种结合知识与推理、构建更智能且更自主的助手的方法。