检索增强生成（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 将经过提示词工程或工具绑定的 LLM 作为智能体引入检索工作流，由智能体结合当前查询与中间观察结果，动态控制 RAG 的执行走向——将原本固定的单次查询扩展为“分析问题 → 决定从一个或多个来源检索信息 → 核查或改写完善 → 生成最终回答”的自适应迭代过程。
智能体的主要能力：智能体系统具有基础 RAG 循环之外的能力，其中大部分已在上周介绍。
- 工具调用（Tool Use）：智能体可按需调用搜索引擎、数据库查询、计算器或自定义 API（在本课中核心工具是获取相关上下文的检索器），支持在运行期间引入外部新信息，或在单次会话中发起多次检索。
- 分步推理与查询规划（Step-by-Step Reasoning）：将复杂宽泛的问题拆解为多个子问题，并根据中间结果做条件判断（例如先判断“是否需要查找多项信息？应优先查找哪一项？”，再依次规划对应的检索步骤）。
- 记忆与状态维护（Memory & State）：通过消息历史或状态对象（短期记忆）记住前序步骤已检索到的内容与决策，避免重复操作；在长交互中还可配合缓存或历史存储（长期记忆）保持跨轮次一致性。
- 自主性与适应能力：具备上述能力后，智能体能够适应变化的需求。例如，一个知识来源无法提供答案时，可以尝试其他来源或方法。固定流程通常需要人工针对各种特殊情况调整提示；智能体则可以在合理限制内自行纠正，并通过迭代寻找解决方法。
核心改进：标准 RAG 通常仅查询单一向量库，而 Agentic RAG 可在单次交互中灵活调度多个知识库与外部 API；支持在首次检索结果存疑时主动复核与补充检索，有助于提升回答准确率；同时该架构可自然延伸至多模态数据检索与多智能体协作。
工程取舍：引入智能体并不适合所有场景。多步推理意味着更多的 LLM 调用次数、更高的端到端延迟与 API 费用，也增加了待评估和监控的组件数量；若缺乏严格约束，智能体仍可能混淆上下文、编造工具参数或陷入死循环。因此，工程落地时必须精心设计决策逻辑与循环熔断机制。
Agentic RAG 的常见架构模式
智能体增强的 RAG 没有适用于所有任务的唯一设计，具体架构取决于使用场景。常见模式包括：根据需要使用上下文的检索智能体、通过改写查询进行纠正的 Corrective RAG，以及使用多个检索工具的智能体。
1. 检索智能体（Retrieval Agent）：自主决定何时检索
一种简单的集成方式是让 LLM 判断回答问题是否确实需要外部知识。固定 RAG 流程会为每个查询检索文档，但用户问候或提出简单问题时，这一步可能没有必要。智能体可以在适当情况下跳过检索，直接回答。这样能够节省时间和计算资源，也能减少简单查询引入无关数据后产生的混淆。
工作方式：为 LLM 配置检索工具，并通过提示要求它仅在需要时使用。例如，在 LangGraph 中可以设置 generate_query_or_respond 节点，接收包含最新用户消息的对话状态，再调用 LLM。这个 LLM 绑定 retrieve_context 等工具，其本质是搜索向量数据库的函数。提示或少量示例应当明确说明：“如果用户提出的事实性问题可能需要外部信息，使用搜索工具查找相关内容。如果根据已有知识就能回答，或者用户正在进行日常交谈，则直接回答，无需调用工具。”
执行该节点时，LLM 可以直接输出回答，也可以输出需要调用工具的操作。在 LangGraph 中，图工作流程可以据此选择不同分支。具体而言，条件边检查模型是否调用了检索工具：如果调用，就进入 Retrieve 节点或通用 Tool 节点；如果模型已生成最终回答，则结束流程。可以使用一个简单函数检查模型最后一条消息中的工具调用，实现这种条件路由。
若发起工具调用，则路由至 Retrieve（或通用 Tool）节点执行向量检索，将召回片段封装为 ToolMessage 写入状态（此时状态中依次包含用户问题、助手的调用请求及工具返回的检索文本），再连回智能体节点基于检索上下文生成最终答案。
2. Corrective RAG（CRAG）：评估检索质量并改写重试
更进一步的模式处理首次检索失败或信息不足的情况。固定流程可能因此给出错误或缺少帮助的回答，智能体则可以识别问题并通过迭代纠正。这种模式通常称为 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 模型，也有助于可靠地解析判断结果并选择执行路径。
3. 多工具与多来源智能体（Multi-Tool & Multi-Source Agent）
复杂业务应用往往同时挂载多个异构检索器与外部工具（例如电商助手同时拥有“商品库存向量索引”、“买家评论向量索引”以及“合作商店网页搜索 API”）。多来源智能体能够按问题特征挑选合适的数据源，或跨多个工具串联检索：
路由选择知识源（Router）：通过前置分类器或 LLM 路由判断哪个数据源最匹配当前查询——例如提到“耳机现货”时调用 Available Items 库存检索器；提到“关于使用寿命的好评”时调用 Reviews 评论检索器（同时返回商品 ID 与评论片段）；若内部索引均无匹配，则回退至网页搜索。
跨工具串联调用（Sequential Tool Use）：针对复合问题依次调用多个工具。例如用户提问：“能否从现有商品中推荐一台笔记本电脑？同时请确认以往买家的评价足以证明推荐商品经久耐用。”智能体可先调用商品向量库检索符合规格的笔记本电脑列表，接着将评论检索器的过滤范围限定在上述候选商品 ID 内查找耐用性评价，最后综合两步结果给出推荐。
一种具体实现只需要两个主要节点：能够生成工具调用或最终回答的 Agent 节点，以及工具执行节点。Agent 节点输出最终回答，或者一个或多个工具调用。条件边在存在工具调用时进入 Tool 节点，否则进入 End。Tool 节点执行请求的工具，例如检索文档或执行其他操作，并将结果作为新消息附加到状态中。流程随后返回 Agent 节点，智能体读取工具结果，决定下一步。这相当于在 RAG 系统中实现 ReAct：智能体循环进行推理、工具操作和结果观察，直至能够回答问题。
功能完整的 Agentic RAG 系统
具体场景中的 Agentic RAG 形式需要根据需求确定。提高智能体自主程度通常会增加复杂度和延迟，同时有助于提高精确性及准确性。一个功能较为完整的系统可以采用以下结构。
- 分析查询
- 判断回答是否需要补充数据，需要时调用检索工具。
- 重排序检索结果
- 检索结果经过重排序，再用于生成答案。
- 分析答案
- 检查答案是否正确、是否与查询相关。
- 改写查询
- 答案需要改进时，改写查询并重新分析。
分阶段阅读 · 3 个阶段
- 分析与改写用户查询：基于 LLM 的智能体接收原始查询，按需执行一次或多次查询改写（生成一个或多个子查询），并判断回答该问题是否需要补充外部数据。
- 多源数据检索：若需补充数据，由一个或多个智能体选择匹配的来源执行检索（如包含用户当前位置的实时用户数据、企业内部文档库、网页搜索 API 等）。
- 结果汇总与重排序：汇集各路检索结果，使用表达能力强于普通 embedding 模型的重排序（Reranker）模型精排，大幅收敛候选上下文范围。
- 生成候选回答：在无需补充数据或已完成检索重排后，提示 LLM 生成最终候选回答（或一组候选操作）。
- 答案质量核查与闭环重试：分析并评估候选回答的事实正确性与切题程度；若达标则直接返回给用户，若仍需改进则触发查询改写并重新进入检索生成循环（严格受最大循环次数上限约束）。
设计时应尽可能保持流程简洁，仅在系统验证结果未达到要求时增加必要步骤。
智能体决策逻辑与实践建议
集成智能体需要仔细考虑每一步的决策逻辑，也就是智能体如何判断下一步操作。一部分决策由提示引导 LLM 完成，另一部分可以通过代码或图中的条件明确规定。RAG 智能体的多步骤决策可以采用以下做法。
- 编写边界清晰的提示词与工具描述：在系统提示词中明确界定何时直接作答、何时调用
retrieve_context，并在挂载多个工具时清晰说明各工具的适用边界（工具函数的 docstring 是决定调用准确率的关键提示词资产，也可通过后续介绍的 MCP Server 统一暴露）。 - 引入思维链（CoT）与正反示例：在 ReAct 提示词中引导模型先输出决策依据（
Thought）再输出动作（Action）；对于使用原生 function calling 的模型，可在提示词中提供两个对比示例（一个无需工具直接作答，一个调用检索工具作答），帮助模型把握检索与停止的边界。 - 限制循环并设置防护：多步骤智能体理论上可能持续循环，例如始终认为搜索结果不足。因此，应设置最大迭代次数。LangGraph 的图若包含循环，例如上周构建的 ReAct 智能体，应加入计数器或停止条件。例如，查询改写一次后停止，并利用已有信息回答。还可以检测重复查询，在智能体反复提出相同查询时终止循环。始终保留默认结束条件，确保在合理情况下能够到达终点，即使最终回答只能说明无法找到所需信息。
- 验证与内容审核：与使用 LLM 评定文档相关性类似，也可以验证最终回答，例如依据来源核查事实，或检查回答是否符合指定标准。生产系统适合增加评估输出安全性和正确性的步骤，也可以通过并行过程执行，必要时加入人工批准。例如，智能体生成回答草稿后，独立验证节点可以标记与已知数据矛盾或缺少引用的内容，要求智能体重新考虑。
- 可观测性与调试：多步骤推理较难追踪，因此需要记录智能体执行过程。记录可获得的推理说明和操作，有助于调试逻辑问题。如果智能体决策不佳，追踪记录能够显示当时的提示和状态，便于改进提示或逻辑。
- 实际约束：始终考虑用户体验和系统限制。工具较多或推理复杂时，响应会更慢，并非每种查询都适合等待。可以让复杂或重要查询使用完整智能体流程，简单查询使用较简单的路径。例如，在入口设置轻量分类器，判断请求属于简单事实问题还是日常对话，在不需要智能体时跳过相关步骤。这种混合方式能在单次 RAG 已足够时减少多步骤推理的开销。
基于真实业务数据测试与 A/B 对比：智能体在真实边缘输入下的表现往往难以预估（例如测试可能暴露出：即便内部向量库已有现成答案，智能体仍因提示词措辞不当而总是去调网页搜索，此时需修改提示词明确“优先查询内部知识库，内部无结果时再使用网页搜索”）。上线前应使用真实场景问题测试，并通过 A/B 测试对比 Agentic RAG 与固定 RAG 的准确率、用户满意度及成本，验证新增复杂度的实际收益。
总结：智能体推理如何增强 RAG
智能体可以通过以下方式改善检索，某些情况下也可以替代固定检索流程。
- 根据上下文选择检索：智能体可以结合上下文决定何时检索、检索什么内容。固定 RAG 通常执行相同操作，例如返回相似度最高的五项结果。智能体可以针对罕见术语选择关键词搜索，也可以在答案明确时跳过检索。这类判断有助于获取更相关的信息，减少不必要文本对 LLM 的干扰。
- 多轮渐进式深挖检索：根据首轮检索获得的线索提出更具针对性的后续子查询，像人类研究员一样逐步缩小范围，解答单次 RAG 难以应对的多跳综合问题。
- 跨工具协同处理（检索 + 计算/操作）：当用户询问“根据报告，X 与 Y 的比值是多少”时，固定 RAG 只能尝试用语言模型粗略心算或忽略计算；而智能体可先检索出 X 和 Y 的准确数值，再调用计算器工具算出精确比值后作答。
- 通过调整方法提高稳健性：初始方法无效时，智能体可以更换数据来源或重新表述问题。传统 RAG 的开发者通常需要提前考虑失败情况，编写替代处理逻辑，或者接受系统有时无法回答。智能体能够承担其中一部分工作，识别“没有找到有用信息”的情况，并根据已有线索重试。它仍然无法保证每次成功，但往往能够提高找到答案的概率。
在医疗、法律等高风险强合规领域，高确定性的固定检索流程配合人工复核可能依然更为稳妥；而在广泛的通用企业知识服务场景中，Agentic RAG 则是结合私有知识与动态推理的有效架构。
让 Agentic RAG 共用索引
在课程主线工程中，智能体的检索工具直接复用Sprint 0《实践环节》构建的 KnowledgeIndex，保持用户身份（principal）、资料版本与引用 ID 格式全局统一。即便智能体在循环中对查询进行了改写，每次重检仍必须执行完全相同的租户与用户可读权限过滤。将整个智能体循环硬性限制为最多三轮，并在评测中对比改写重试前后的召回文档 ID、答案事实依据及端到端延迟。
练习：记录本课所用配置、输入、预期结果与失败分支，并用脱敏数据复现。