在 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 的 LCEL（LangChain Expression Language）能不能写 Agentic RAG？能写，但会很别扭。LCEL 本质上是为“管道”设计的，A 的输出进 B，B 的输出进 C，每条路都是静态的、预定义的。而 Agent 需要的是“循环”和“分支”，是拿到当前状态后动态决定下一步走哪条路。
2.1 LangGraph 的底层逻辑：把流程画成一张图
LangGraph 的抽象非常直接：StateGraph。你定义整个流程的状态结构（State），定义一批节点（Node），每个节点是一个函数，接收当前状态、返回更新后的状态。然后在节点之间连边（Edge），最后设置一个入口节点和若干结束节点。
最妙的是条件边（Conditional Edge）。你可以写一个路由函数，它的返回值是字符串，决定下一步走向哪个节点。这一步就是“会思考”的落点：大模型决定走“直接回答”还是“需要检索”，走“普通检索”还是“联网检索”，全部由条件边路由实现。
早期版本还需要自己定义状态类型，写 reducer 合并逻辑，稍微有点繁琐。现在 LangGraph 提供了命令式 API，比如Command(goto="node_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", embeddings=embeddings_model, allow_dangerous_deserialization=True) retriever = vectorstore.as_retriever(search_type="similarity", search_kwargs={"k": 5}) llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)联网工具可以用 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 result"4.2 第二步：意图分类节点，让系统学会“思考”
这是“会思考”的关键一步。系统拿到用户问题后，先判断属于哪种情况：
- 需要知识库检索；
- 需要联网检索最新信息；
- 问题本身信息不足，需要澄清；
- 闲聊或通用问题，可以直接回答。
用结构化输出调用大模型，返回结果更干净。
from pydantic import BaseModel, Field class Intent(BaseModel): mode: Literal["kb", "web", "clarify", "direct"] reason: str = Field(description="Why this mode is chosen") def classify_intent(state: AgentState) -> AgentState: prompt = f"""Classify 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 = f"""Rewrite 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 = f"""You 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 = f"""Answer 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 = f"""The 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_limit=10），从框架层面兜底。
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 到底是“智能助手”还是“更贵的弱智工具”，值得你花多轮实验去打磨。
