Agentic RAG实战：基于LangGraph构建会思考、会纠错、会联网的智能知识库

在 RAG 项目里折腾了大半年我最大的感受就是传统 RAG 是个“哑巴工具”你问一句它答一句看似沾了点大模型的边实际上笨得让人着急。用户问个需要推理的问题它给你吐一堆不相关文档文档库里没答案的时候它也一本正经地编想让它查点实时信息抱歉它的知识截止日期永远是昨天。这些问题不是调调 chunk 大小、换换 embedding 模型就能解决的而是整套架构的“脑子”不够用。所以这一篇我不打算再讲那些“文档加载-切块-向量化-检索-拼接-生成”的老套路而是把目光放在现在真正能落地的方案上Agentic RAG。简单来说就是让 RAG 从“单次检索”升级成“自主决策循环”让系统自己判断要不要检索、检索得够不够好、要不要换个方式再查一次、甚至要不要调用外部工具补充信息。配合 LangGraph这套逻辑可以变得非常可控、可追踪、容易调试。这篇文章我会完整拆解一个能“会思考、会纠错、会联网”的 Agentic RAG 是怎么设计与实现的核心用 LangGraph 来编排。全程用我实际踩坑后的经验来讲代码可以直接抄但更重要的是把每一步的“为什么”讲清楚。适合已经被传统 RAG 折磨过、想换个解题思路的朋友。1. 传统 RAG 的“死板”体现在哪先看清病根再开药想理解 Agentic RAG 的价值得先接受一个现实传统 RAG 最大的问题不是“检索质量差”而是“没有反馈回路”。1.1 一次问答只有三拍召回、拼接、生成传统 RAG 的流程闭着眼睛都能背出来。用户输入问题后系统把问题做 embedding去向量库里做相似度检索取回 Top-K 条文档然后一股脑拼到 prompt 里扔给大模型生成答案。整个过程是线性的一条道走到黑。如果第一步检索就偏了后面再怎么调 prompt 都救不回来。我在一个企业知识库项目里就遇到过典型的例子。用户问“我们公司年假制度里说的‘连续工作满一年’包含试用期吗”这句话里有“年假制度”“连续工作”“试用期”好几个可能命中的实体。传统 RAG 的 embedding 检索会把“试用期”这个词的相似度权重拉得很高结果召回了大量关于“试用期考核”的文档而真正规定年假计算规则的条款反而没排进 Top-K。最后大模型就基于错误的上下文给出答案还说得头头是道。这就是死板 RAG 的典型症状查询是一次性的召回是错误的且错误无法在后续环节被感知和纠正。1.2 三个最容易让传统 RAG 翻车的典型场景结合我自己的项目经验下面三类问题靠“调参”基本解决不了必须在架构层面想办法第一类是多跳问题。用户问“A 项目的负责人所在部门今年发了哪些制度文件”这需要先定位 A 项目、再找到负责人、再定位部门、再检索该部门的制度文件。传统 RAG 一步到位式检索没有中间推理过程基本必挂。第二类是检索质量不可控问题。查询改写、混合检索、rerank 这些手段能提高“平均分”但系统永远不知道自己这次召回的文档到底够不够用。没有反馈回路就没有纠错能力。第三类是信息时效性问题。知识库再大也是静态的用户问“昨天发布的新政策”向量库里根本没有传统 RAG 再努力也只能一本正经地胡说。1.3 从“检索即结束”到“检索是决策的一环”想解决上述问题关键在于改变思考模型。传统 RAG 把“检索”当作一个函数的执行结果而 Agentic RAG 把“检索”当作 Agent智能体的一个“可调用工具”。这里的区别很微妙但极其重要。函数是被动执行的它不知道为什么要调用、调用结果是否满足需求而 Agent 会先做规划——“用户这个问题我需要查一下知识库”——再执行调用然后评估结果——“这批文档相关但不够具体我得换个关键词再查一次或者去网上找最新信息”。这个“规划-执行-评估-再规划”的循环就是 Agentic RAG 的灵魂。LangGraph 恰恰提供了实现这种循环的最佳工程框架。它允许你把循环逻辑画成一张图每个节点只做一件明确的事节点之间通过状态传递数据还能随时在某个节点停下来等人工介入。下一章我们细聊为什么选 LangGraph以及它和普通 LangChain 链式调用的本质差异。2. 为什么偏偏是 LangGraph状态机思维碾压链式调用很多朋友问我用 LangChain 的 LCELLangChain Expression Language能不能写 Agentic RAG能写但会很别扭。LCEL 本质上是为“管道”设计的A 的输出进 BB 的输出进 C每条路都是静态的、预定义的。而 Agent 需要的是“循环”和“分支”是拿到当前状态后动态决定下一步走哪条路。2.1 LangGraph 的底层逻辑把流程画成一张图LangGraph 的抽象非常直接StateGraph。你定义整个流程的状态结构State定义一批节点Node每个节点是一个函数接收当前状态、返回更新后的状态。然后在节点之间连边Edge最后设置一个入口节点和若干结束节点。最妙的是条件边Conditional Edge。你可以写一个路由函数它的返回值是字符串决定下一步走向哪个节点。这一步就是“会思考”的落点大模型决定走“直接回答”还是“需要检索”走“普通检索”还是“联网检索”全部由条件边路由实现。早期版本还需要自己定义状态类型写 reducer 合并逻辑稍微有点繁琐。现在 LangGraph 提供了命令式 API比如Command(gotonode_name)你可以在节点函数里直接指定下一步跳转目标代码直观很多。我后面给出的代码示例会用这种更清晰的方式。2.2 LangChain 和 LangGraph 的分工别把两者搞混LangChain 和 LangGraph 经常被拿来做对比但严格来说它们不是替代关系而是不同层级的工具。LangChain 提供的是大模型调用封装、Prompt 模板、文档加载器、向量存储等“零件”LangGraph 负责把这些零件组装成一棵可以无限循环、动态分支的“流程状态机”。打个比方LangChain 是工具箱LangGraph 是施工图纸加工程监理。你既需要图纸也需要工具。在实践中我们通常用 LangChain 去调用模型、做 prompt 管理用 LangGraph 编排整体的 Agent Loop。这也是我在项目中的标准姿势。2.3 比自研状态机省心在哪可观测性与断点续跑我在最早尝试手写 Agent 循环时用的是 while True 加 if else虽然逻辑能跑通但一旦中间某一步出错根本不知道当时的状态是什么调试全靠 print 大法。用 LangGraph 之后最大的体感优势有两个第一LangGraph 有完整的 trace 机制。你可以把每一步节点输入输出、大模型的完整响应、工具的调用参数全部记录下来出问题时直接把轨迹甩给同事或者自己复盘比对着日志猜快得多。第二LangGraph 支持 Checkpointer检查点。配合langgraph-checkpoint使用状态在执行到任意节点时可以持久化保存后续可以恢复、重置甚至从中间节点“续跑”。做 Human-in-the-loop 或者失败重放的时候这个功能真的是救命的。当然自研方案在极度简单的场景下更轻量但只要你需要“循环”“分支”“容错”“人工介入”这四个能力中的任何一个LangGraph 都是更稳的选择。下面我们正式进入实战。3. 动手实现前必须想清楚的架构目标不是“能跑”而是“可控”这部分是全文最核心的分水岭。我见过太多人一上来就写代码结果写了三百行后开始崩溃系统什么时候该检索检索结果不好怎么办联网搜索和知识库检索的优先级是什么这些问题没想清楚代码写得再漂亮都是空中楼阁。3.1 核心能力拆解思考、纠错、联网分别落到哪个环节标题里说的“会思考、会纠错、会联网”在工程实现上对应着三个不同模块。“会思考”对应的是 Agent 的意图识别与规划能力。系统拿到用户问题后不能默认“必须检索”而是先判断这个问题需要知识库吗如果能直接回答就直接回答如果问题有歧义先问清楚再答如果需要拆解成多个子问题先拆分再逐个检索。“会纠错”对应的是检索质量自评与重试机制。系统检索到文档后不能默认为“结果可用”而是让大模型或者专门的质量判分模型对召回内容进行“相关性打分”判断是否满足回答条件如果不满足则自动触发改写查询、调整检索参数、换一种检索方式等重试逻辑。“会联网”对应的是外部工具调用能力。系统在知识库没有答案、或者问题本身包含强时效性信息时能够自主决定调用一个联网搜索工具把搜索结果作为额外上下文接入生成环节。3.2 整体状态设计用一个 State 把全局信息管起来在 LangGraph 中状态设计直接影响后续所有节点函数的签名。我把 State 定成下面这样简洁但足够支撑完整流程逻辑from typing import TypedDict, List, Annotated, Literal class AgentState(TypedDict): question: str rewritten_question: str search_mode: str # normal | web | clarify retrieved_docs: List[str] web_results: List[str] answer: str retry_count: int need_clarification: bool clarification_question: str把retry_count放进状态非常关键。它决定了纠错循环什么时候终止防止系统无限改写查询、反复检索。我来实现时会把最大重试次数设成 2超过后放弃检索、直接让模型基于已有上下文尽力回答。3.3 LangGraph 的图结构一眼看清 Agent Loop 的骨骼节点规划如下。handle_initial_query入口节点接收用户原始问题。classify_intent判断是否需要检索、是否需要联网。rewrite_query对需要检索的问题做查询改写。retrieve_knowledge_base调用向量知识库检索。assess_retrieval_quality对检索结果做质量评估。web_search调用联网搜索工具。generate_answer生成最终回答。clarify_question生成澄清问题请求用户补充信息。我建议不要用太复杂的图结构。一个清晰的线性主流程加一个条件循环就足以覆盖绝大多数 Agentic RAG 场景。别一上来就画十几个节点后面维护成本极高。4. LangGraph 实战从零搭建会思考、会纠错、会联网的完整流程下面进入代码部分。我用 langgraph 0.2 以上版本的命令式 API 来写整体的可读性更好。为了不让文章过长代码里会省略一些无关紧要的配置项但核心逻辑都是能直接跑的。4.1 第一步准备模型、向量库与两个核心工具先准备好大模型和检索工具。我这里以 OpenAI 接口为例你用国内任意兼容 OpenAI SDK 的模型都可以。from langchain_openai import ChatOpenAI from langchain_community.vectorstores import FAISS from langchain_core.tools import tool from langchain_core.documents import Document # 这里假设你已经完成了一版文档切块和向量化 vectorstore FAISS.load_local(kb_index, embeddingsembeddings_model, allow_dangerous_deserializationTrue) retriever vectorstore.as_retriever(search_typesimilarity, search_kwargs{k: 5}) llm ChatOpenAI(modelgpt-4o-mini, temperature0)联网工具可以用 SerpAPI、Bing Search API 等任意服务我用一个 mock 函数示意方便你替换成真实服务。tool def web_search(query: str) - str: Search the web for the latest or real-time information. # 替换为实际的搜索 API 调用 return mock web search result4.2 第二步意图分类节点让系统学会“思考”这是“会思考”的关键一步。系统拿到用户问题后先判断属于哪种情况需要知识库检索需要联网检索最新信息问题本身信息不足需要澄清闲聊或通用问题可以直接回答。用结构化输出调用大模型返回结果更干净。from pydantic import BaseModel, Field class Intent(BaseModel): mode: Literal[kb, web, clarify, direct] reason: str Field(descriptionWhy this mode is chosen) def classify_intent(state: AgentState) - AgentState: prompt fClassify the following user question into one of four modes: - kb: needs internal knowledge base retrieval - web: needs latest real-time info or the question asks about very recent events - clarify: the question is ambiguous or missing key details - direct: can be answered directly without retrieval User question: {state[question]} structured_llm llm.with_structured_output(Intent) intent structured_llm.invoke(prompt) return { search_mode: intent.mode, reason: intent.reason, }实际跑下来这个分类的准确率在绝大多数场景下都能做到 90% 以上。真正容易翻车的点在于用户问题里既有知识库相关内容又有时效性信息比如“今年的年假政策是什么时候发布的”这种情况只靠分类进单一模式会丢信息。我的解法是在后面加一个“知识库优先、联网补强”的策略在知识库检索质量不足时再触发联网搜索这个逻辑放到 4.4 节讲。4.3 第三步查询改写与知识库检索查询改写是传统 RAG 与 Agentic RAG 的一个显著分水岭。传统 RAG 拿原始问题直接查向量库用户口语化表达稍一变体检索效果就断崖式下跌。Agentic RAG 会让大模型先把问题改写成更适合检索的表述。举个例子用户问“那个做用户增长的小组他们最近招人有啥要求”原始句子里的“那个做用户增长的小组”指代不明但知识库里可能有明确的部门名。改写模型的任务是把这种口语指代转换成知识库索引中可能出现的正式表达例如“用户增长团队 招聘要求 2025”。def rewrite_query(state: AgentState) - AgentState: prompt fRewrite the following user question into 2 distinct search queries for a knowledge base. - Keep the core meaning intact. - Replace ambiguous references with likely formal names. - Return as a comma separated list. Question: {state[question]} rewritten llm.invoke(prompt).content return {rewritten_question: rewritten}检索节点就比较常规了。我用 rewrite 后的多查询串去检索取回 Top-K 文档。def retrieve_knowledge_base(state: AgentState) - AgentState: queries [q.strip() for q in state[rewritten_question].split(,)] all_docs [] for q in queries: all_docs.extend(retriever.invoke(q)) # 去重保留前 6 个文档 seen set() unique_docs [] for doc in all_docs: if doc.page_content not in seen: seen.add(doc.page_content) unique_docs.append(doc) if len(unique_docs) 6: break return {retrieved_docs: [doc.page_content for doc in unique_docs]}注意这里有个细节用多条改写后的查询去召回再合并去重比单独一条查询直接 Top-K 的质量要高很多。原因在于多条查询从不同侧面接近目标知识哪怕有一条偏了其他条目也能兜底。4.4 第四步检索质量评估给系统装上“纠错机制”这是“会纠错”的核心节点。检索结果到底行不行不能靠猜得让大模型以判官身份打分。def assess_retrieval_quality(state: AgentState) - AgentState: retrieved_text \n\n.join(state[retrieved_docs])[:3000] prompt fYou are evaluating whether the retrieved documents are sufficient to answer the question. Question: {state[question]} Retrieved docs: {retrieved_text} Rate from 1 to 10 on whether these docs provide enough relevant information to answer the question. Answer with only a number. score_text llm.invoke(prompt).content.strip() try: score int(score_text) except: score 5 if score 6: return {retry_count: state.get(retry_count, 0) 1} return {retry_count: 0}这里我把打分逻辑简化成了“够用与否”实际生产里可以分维度评分比如“相关性”“完整性”“时效性”。打分通过后进入生成节点。打不过怎么办进入路由逻辑如果检索质量不过关且重试次数小于 2则回到rewrite_query节点换个角度改写问题再查一次如果重试次数已经用完则触发web_search节点用外部信息兜底如果知识库检索本身成功但问题带有强时效性成分也可以主动调用web_search做补充。路由逻辑写在条件边里def should_retry_or_web(state: AgentState) - str: if state.get(retry_count, 0) 2: return web_search if state[search_mode] web: return web_search return rewrite_query为啥重试两次就停这是我多次实验后的经验值。超过两次后改写查询基本只是在换同义表述对检索质量提升的边际收益趋近于零而且每多一轮检索延迟和 token 成本都翻倍用户体验会明显变差。与其死磕不如转向联网搜索或直接让模型基于已有上下文作答。4.5 第五步联网搜索工具接入联网搜索在 LangGraph 里就是普通节点函数只不过它调用的不是向量库而是外部搜索 API。def web_search_node(state: AgentState) - AgentState: results web_search.invoke(state[question]) return {web_results: [results]}这里我故意不做复杂处理保持节点职责单一。如果你的项目对搜索质量要求高可以拆成“搜索-解析-去重-提取正文”多个子步骤但核心思想不变联网搜索是 Agent 的一个工具由前序节点决定何时调用由后序节点决定如何消费结果。4.6 第六步生成回答生成节点把知识库检索到的文档与联网搜索到的信息拼接起来一同交给大模型生成最终答案。需要强调的是生成阶段的 prompt 要明确指出信息来源避免大模型把知识库和网络信息混在一起“融会贯通”成虚假事实。def generate_answer(state: AgentState) - AgentState: context_parts [] if state.get(retrieved_docs): context_parts.append(### Knowledge base docs\n \n\n.join(state[retrieved_docs])) if state.get(web_results): context_parts.append(### Web search results\n \n.join(state[web_results])) context \n\n.join(context_parts) prompt fAnswer the question based on the provided context. If the context is insufficient, say so explicitly. Do not mix knowledge base info with web info; label each source in your answer. Question: {state[question]} Context: {context} answer llm.invoke(prompt).content return {answer: answer}加粗那句label each source是我从实际项目里总结出来的重要细节。当知识库和联网结果同时作为上下文时如果不强制模型区分来源模型极大概率会把两边的信息缝合在一起。用户问“最新的芯片发布时间”模型可能拿知识库里的旧数据加网络上的小道消息拼出一个“全新发布计划”非常致命。4.7 第七步组装 LangGraph跑通完整 Agentic RAG所有节点定义好之后组装图结构就很简单了。用命令式 API 写起来很自然。from langgraph.graph import StateGraph, START, END from langgraph.types import Command builder StateGraph(AgentState) builder.add_node(classify_intent, classify_intent) builder.add_node(rewrite_query, rewrite_query) builder.add_node(retrieve_knowledge_base, retrieve_knowledge_base) builder.add_node(assess_retrieval_quality, assess_retrieval_quality) builder.add_node(web_search, web_search_node) builder.add_node(generate_answer, generate_answer) builder.add_node(clarify_question, clarify_question) builder.add_edge(START, classify_intent) # 根据意图走分支 builder.add_conditional_edges( classify_intent, lambda state: state[search_mode], { kb: rewrite_query, web: web_search, clarify: clarify_question, direct: generate_answer, }, ) builder.add_edge(rewrite_query, retrieve_knowledge_base) builder.add_edge(retrieve_knowledge_base, assess_retrieval_quality) # 纠错重试 / 联网兜底 builder.add_conditional_edges( assess_retrieval_quality, should_retry_or_web, { rewrite_query: rewrite_query, web_search: web_search, }, ) builder.add_edge(web_search, generate_answer) builder.add_edge(generate_answer, END) graph builder.compile()跑一个测试result graph.invoke({question: 今年公司人才盘点什么时候启动具体流程是什么, retry_count: 0}) print(result[answer])整条链路就是先判断这个公司内部制度问题该走知识库改写查询去检索假设第一次检索返回了“年度重点工作安排”这类相关但不够精准的文档质量评估不通过回到改写节点把查询改成“人才盘点 启动时间 流程”二次检索命中制度原文生成答案。如果两次都不行自动联网查公开信息。4.8 一个很容易被忽略的节点澄清问题很多初级实现会漏掉clarify_question这个分支但实际上它非常能提升用户体验。有些用户问题天然不够完整比如“那个文件怎么下载”哪个文件文件名是什么系统与其瞎猜去检索不如先反问用户。def clarify_question(state: AgentState) - AgentState: prompt fThe user question is too ambiguous to search. Ask a concise clarifying question to identify the specific information needed. Question: {state[question]} ask llm.invoke(prompt).content return { need_clarification: True, clarification_question: ask, }用户回答了之后再带着完整的实体信息进入正常检索流。这个机制在客服问答场景里效果尤其明显一问一答之间反而让人觉得系统“挺智能”。5. 实战中的高频告警与问题排查每个坑我都替你踩过了代码能跑通只是起点。部署到真实业务中你会遇到很多文档里不会写、但生产环境一定会冒出来的问题。下面这些是我用 LangGraph 做 Agentic RAG 时高频踩中的坑按严重程度排序。5.1 循环收不住系统陷入死循环条件边写好后最常见的 bug 是图结构在运行时陷入无限循环查询质量评估不通过、回改写、又去检索、又不过、再改写……如果状态里没有retry_count作为熔断开关这个循环会把 API 调用费烧到让你怀疑人生。我的解法就是前面代码里体现的两层保险第一retry_count超过阈值后强制走web_search或直接结束第二在 LangGraph 里可以给编译图设置递归上限例如recursion_limit10从框架层面兜底。graph.invoke(initial_state, config{recursion_limit: 10})提示调大recursion_limit解决不了逻辑问题它只是保险丝不是修复方案。真正常用的还是靠retry_count控制重试次数。5.2 检索结果“看似相关、实际无用”评估形同虚设质量评估节点刚上线时我遇到过离谱的情况打分模型给每个结果都打 8 分以上纠错机制完全失效。原因是大模型天然有“讨好倾向”你让它给检索材料打分它倾向于认为材料都有用。换一个 prompt 设计可以显著改善这个问题。不要问“这些资料够不够”而是问“这些资料如果缺少某部分请给出你判断的具体依据”。把评估从“打分”转变成“找茬”模型会变得严格很多。另外用更小的专用判分模型如基于 embedding 的交叉编码器来做初筛用大模型做终审效果更稳。5.3 联网搜索的内容质量参差不齐垃圾信息污染答案联网搜索看起来美好接进来之后才会发现搜索结果页 snippet 几乎全是 SEO 垃圾文。直接把这些文本塞进 prompt结果就是答案里混入大量野鸡资讯。我的处理方式是加一层“搜索结果清洗”的中间节点。抓取搜索结果的正文前先过滤掉广告类、低质聚合类域名再用大模型对正文做 20 字以内摘要最后才进生成上下文。注意这一步会额外增加延迟可以考虑只在高置信度需要联网时才启用。5.4 状态污染上一条对话的文档出现在下一条回答里LangGraph 的状态默认在单次 invoke 内是独立的但如果你在服务端做了全局 State 复用或者把对话多轮历史一股脑塞进question字段很容易出现上下文串味。最典型的例子是用户第一轮问 A第二轮问“那 B 呢”系统如果没把“那 B 呢”关联到 A 的主题检索方向就会完全跑偏。解决方案是引入对话记忆管理。在进入classify_intent节点前先把多轮历史压缩成“当前问题 精简对话摘要”合并成新的question再进入 Agent 循环。不要把十几轮历史原样塞进上下文token 消耗大且信息表意会越来越模糊。5.5 延迟过高用户等得不耐烦一个完整 Agentic RAG 循环最差路径是“意图分类 查询改写 知识库检索 质量评估 再改写 再检索 再评估 联网搜索 生成”粗算一下至少五次大模型调用每次两秒总延迟奔着十五秒去了。这在聊天场景里基本不可接受。用 LangGraph 本身没法直接降低推理延迟但可以靠“并行化”救一部分。比如知识库检索和联网搜索其实互相独立完全可以在同一层级的两个节点上并行执行等全部结果汇聚后再统一进入生成节点。LangGraph 支持用Command一次跳转到多个节点或者用fanout模式实现并行分支实际部署时把延迟敏感的两条路径并行起来tokens 消耗差不多体感延迟能砍掉 40% 左右。注意并行会引入“谁先谁后”的同步问题LangGraph 的状态合并机制需要定义清晰的 reducer否则容易丢数据。成本问题也得正视。Agentic RAG 的单次调用 token 消耗是传统 RAG 的 3 到 6 倍前期验证阶段建议用小模型做分类和改写只有生成阶段用大模型能把成本压回一个可接受区间。6. 什么场景真正适合上 Agentic RAG先算账再做决定如果你只是做个五六篇文档的“玩具级”知识库或者对回答准确度要求不高的内部小工具直接上 Agentic RAG 是杀鸡用牛刀。复杂的循环、联网、纠错带来的延迟和成本在简单场景下的收益几乎为零。但下面三种情况强烈建议投入 Agentic RAG第一种是问题复杂度高、需要多步推理或信息整合的知识密集场景。比如企业规章制度问答一个“离职时社保缴纳到哪个月”的问题可能要关联劳动合同法条、公司内部制度、社保操作手册等多份文档一步步检索、评估、再检索才能答对。第二种是知识库更新频繁、且用户大量询问时效性内容的场景。比如政策解读类知识库库里既有历史政策原文又有最新补充条款系统必须能判断什么时候该用旧文档、什么时候该上网查最新发布。第三种是问答结果的“可解释性”有要求的场景。企业内部合规问答、医疗健康信息问答用户不光要一个答案还要知道答案来自哪份文档、经过了什么检索路径。LangGraph 的节点链路天然留下完整轨迹这比传统 RAG 一段裸 prompt 生成结果的解释性要强太多。反过来说如果只是做“常见问题自动回复”用户问题高度固定且覆盖范围窄传统 RAG 加一个规则兜底已经足够没必要把系统复杂度推高一个量级。7. 评估 Agentic RAG别让系统“看起来很强”骗了你做 Agentic RAG 特别容易陷入一个误区Demo 演示时各种刁钻问题都能答上一上生产就露馅。原因在于 Agent 的能力上限很高但下限也低得惊人——因为多一次循环就多一个出错的可能。评估体系必须单独设计。传统 RAG 看召回率、准确率就差不多了Agentic RAG 至少要观察以下指标检索触发准确率不该检索的时候是不是瞎检索了该检索的时候有没有漏纠错有效率触发二次检索后最终答案质量有没有显著提升如果每次都触发但答案没变化说明评估节点是摆设。工具调用正确率联网搜索在什么场景被错误触发了触发后是补充了信息还是引入了噪声端到端延迟与成本每次问答平均几轮调用token 消耗多少我是用一套“二十问”测试集来做回归的挑二十个覆盖多跳、时效性、知识库外问题的高难度问题每次改完 prompt 或流程后全量跑一遍记录每个问题的“第一轮是否答对”。跑过三轮之后系统到底几斤几两心里基本就有数了。再说一个容易被忽略的细节测试集里的问题必须来自真实用户日志不能自己拍脑袋编。因为自己编的问题往往带着“我已经知道答案”的偏见测不出系统的真实盲区。8. 后续还可以怎么扩展Agentic RAG 的进阶想象空间如果你已经做完了上面这套流程我会建议先稳住别急着上更多花活。但如果你所在的场景确实需要更强的能力下面几个扩展方向可以参考。第一个是 Multi-Agent 架构。把“检索 Agent”“联网 Agent”“知识库管理 Agent”“问答 Agent”拆成多个独立智能体由一个 Router Agent 统一调度。这样做的好处是每个 Agent 的职责极度单一、可独立调优坏处是系统复杂度指数上升调试成本也同步增加。第二个是引入记忆机制。LangGraph 的持久化检查点再配合外部记忆存储可以让 Agent 记住用户偏好、历史查询习惯降低重复改写和无效检索的概率。客服场景尤其适合。第三个是把知识库管理本身也变成 Agent 的一环。系统不只是被动调知识库还能主动发现“这个问题的答案在知识库中缺失”然后触发知识库更新流程形成知识生产闭环。这个方向很重但离“企业知识大脑”更近一步。我个人测试下来的感受是第三阶段的收益最大但投入也最大建议先完成基础版 Agentic RAG 形成稳定基线再按需逐步迭代。最后再分享一个实操体会整个实现过程中花费最久的地方一定不是写代码本身而是“意图分类”和“质量评估”这两个节点的 prompt 调优。它们一个决定了系统会不会在没必要的时候强行检索另一个决定了系统能不能诚实地承认“自己找的资料不够用”。这两个节点的进准度直接决定了 Agentic RAG 到底是“智能助手”还是“更贵的弱智工具”值得你花多轮实验去打磨。