本文配套一段 QA 对话整理而成。原对话给出了 Agentic RAG 的整体轮廓，但有若干用词/选型上的不准确之处，本文在「易错点澄清」一节集中给出更精确的版本，并在正文中扩展了完整架构、代码示例与工程经验。

一、Agentic RAG 是什么

Agentic RAG（代理式检索增强生成）是把「自主智能体（Agent）」的决策循环嵌入到 RAG 流程里的高级范式。

与其把它说成「传统 RAG 是线性流水线，Agentic RAG 是带 Agent 的流水线」，更准确的描述是：

• 朴素 RAG（Naive RAG）：固定流水线，Retrieve → Augment → Generate，只走一趟，对就是对、错就是错。
• 高级 / 模块化 RAG：在检索前后插入查询改写、Rerank、HyDE 等模块，但流程仍由开发者静态编排。
• Agentic RAG：把「下一步做什么」交给一个 LLM 驱动的 Agent 在运行时决策——它可以选择检索哪个数据源、改写查询、再检索一次、调用计算工具、放弃检索改用网页搜索、甚至判断「这题不用查、直接答就行」。

核心区别不在「是否使用了 LLM」（朴素 RAG 也用 LLM），而在于 控制流（control flow）是否由 LLM 自身决定。

注：原 QA 中说「大模型不再只是最后的”文字包装工”」容易引起误解。LLM 的角色并没有变，变的是架构层面给它授予了哪些权力——工具调用、自我反思、循环执行。

二、完整架构

一个生产级 Agentic RAG 系统通常包含五层。

┌─────────────────────────────────────────────────────────────┐
│                      用户问题 (Query)                          │
└──────────────────────────────┬──────────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────────┐
│ 1. 意图理解与路由 (Query Understanding & Routing)             │
│    - 改写 (Rewrite / HyDE / Step-Back)                       │
│    - 分类 (闲聊 / 简单事实 / 复杂多跳 / 计算 / SQL ...)        │
│    - 路由到下游工具/数据源                                     │
└──────────────────────────────┬──────────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────────┐
│ 2. 工具/动作层 (Tooling Layer)                                │
│    Vector Search │ BM25 │ SQL │ Graph │ Web │ Code Interpreter│
└──────────────────────────────┬──────────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────────┐
│ 3. 决策循环 (Reasoning Loop) ← Agentic RAG 的核心            │
│    Thought → Action → Observation → Reflection → ...         │
│    常见模式：ReAct / Plan-and-Execute / Reflexion             │
└──────────────────────────────┬──────────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────────┐
│ 4. 记忆 (Memory)                                              │
│    短期：对话历史、Scratchpad                                  │
│    长期：用户画像、过往结论（向量化或 KV 存储）                  │
└──────────────────────────────┬──────────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────────┐
│ 5. 答案合成与引用 (Synthesis & Citation)                       │
└─────────────────────────────────────────────────────────────┘

2.1 意图理解与路由

收到用户问题后的第一步，决定后续整条链路。常见子任务：

易错点：很多人在朴素 RAG 上直接套一个改写模块，就以为做了 Agentic。路由 + 反思才是 Agentic 的入门门槛。

2.2 工具/动作层

检索只是众多工具中的一种。一个典型工具箱：

• Vector Search：语义检索，处理「意思相近但措辞不同」的问题。
• BM25 / 关键词：处理专有名词、产品编号、错别字等向量检索翻车的情况。
• 混合检索 + RRF：BM25 与向量结果用 Reciprocal Rank Fusion 融合。
• SQL / Text-to-SQL：结构化数据。例如订单、报表。
• Graph / Cypher：知识图谱多跳查询。
• Web Search：实时信息（Tavily、Serper、Brave Search、Exa 等）。
• Code Interpreter：数学/统计/数据处理。
• 业务 API：天气、股价、内部 CRM 接口。

2.3 决策循环

这是 Agentic RAG 与传统 RAG 真正的分水岭。常见三种循环模式：

(a) ReAct（Yao et al., 2022）——Thought / Action / Observation 交错，最常用。

Q: 我们公司 2024 年的净利润比 2023 年增长了多少？
Thought: 我需要先找到 2023 和 2024 年的净利润数据。
Action: vector_search("2023 2024 年度净利润")
Observation: 检索到「2024 财报：营业收入 120 亿，净利润 8.4 亿；2023 财报：净利润 7.0 亿」
Thought: 拿到数据了，计算增长率 (8.4-7.0)/7.0 = 20%。
Action: finish("约 20%")

(b) Plan-and-Execute（Wang et al., 2023）——先一次性生成完整计划，再串行执行，适合复杂多步骤任务。

(c) Reflexion（Shinn et al., 2023）——在生成后增加一个「自我批评」步骤，发现错误就重做。

更专门的 RAG 反思模式：

• Self-RAG（Asai et al., 2023）：LLM 在生成过程中输出 [Retrieve] / [NoRetrieve] / [Critique] 等反思 token，自主决定何时检索、何时停止。
• CRAG（Corrective RAG）（Yan et al., 2024）：检索后用评估器打分，低质量结果触发网页搜索兜底或重写后重检。
• Adaptive-RAG（Jeong et al., 2024）：用一个小分类器根据问题复杂度选「不检索 / 单次检索 / 多步检索」。

2.4 记忆

• 短期记忆：当前会话上下文、ReAct scratchpad、已访问工具的中间结果。
• 长期记忆：跨会话的用户偏好、历史结论。可以放在向量库（语义查询）或 KV 库（精确查询）中。
• 实践上要小心：记忆不是越多越好，无关历史会污染检索和生成，需要做 summary 或滑动窗口裁剪。

2.5 答案合成与引用

• 收敛多轮观察得到的证据，组装成最终 Prompt。
• 强制要求 LLM 在答案中引用来源（chunk_id / URL / 表名），便于追溯和审计。
• 对于高风险场景（医疗/法律/金融），加一道事实校验（claim verification）。

三、技术栈选型

易错点：很多教程仍然推荐 GPT-4o / Claude 3.5 Sonnet / Bing Search API——这些在 2026 年都已过时。选型时记得查最新型号；本博客的 claude-api 参考表里有 Claude 全系最新 ID。

四、最小可运行示例（LangGraph）

下面给出一个能跑通的最小 Agentic RAG：路由 → 工具循环 → 反思 → 答案。

# pip install langgraph langchain langchain-anthropic langchain-community
from typing import TypedDict, Annotated, List
from langgraph.graph import StateGraph, END
from langgraph.graph.message import add_messages
from langchain_anthropic import ChatAnthropic
from langchain_core.messages import HumanMessage, AIMessage, ToolMessage
from langchain_core.tools import tool

# ---- 1. 工具定义 ----
@tool
def vector_search(query: str) -> str:
    """从公司内部知识库做语义检索，返回相关片段。"""
    # 这里替换成你的 Milvus / Qdrant 检索
    return f"[KB] 与「{query}」最相关的 3 段内容：..."

@tool
def web_search(query: str) -> str:
    """当内部知识库不足以回答（如时效性问题）时，调用 Tavily 联网搜索。"""
    # 这里替换成 tavily / serper SDK
    return f"[WEB] 搜索「{query}」的前 5 条结果摘要：..."

@tool
def python_repl(code: str) -> str:
    """执行 Python 计算（数学、统计、单位换算）。"""
    # 生产环境用沙箱
    return str(eval(code, {"__builtins__": {}}, {}))

tools = [vector_search, web_search, python_repl]

# ---- 2. 状态 ----
class AgentState(TypedDict):
    messages: Annotated[List, add_messages]

# ---- 3. LLM（开启 tool calling） ----
llm = ChatAnthropic(model="claude-sonnet-4-6").bind_tools(tools)

# ---- 4. 节点 ----
def agent_node(state: AgentState):
    """大脑：决定下一步是调工具还是直接答。"""
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

def tool_node(state: AgentState):
    """执行 LLM 选中的工具。"""
    last = state["messages"][-1]
    outputs = []
    for call in last.tool_calls:
        fn = {t.name: t for t in tools}[call["name"]]
        result = fn.invoke(call["args"])
        outputs.append(ToolMessage(content=str(result), tool_call_id=call["id"]))
    return {"messages": outputs}

def should_continue(state: AgentState) -> str:
    """循环条件：LLM 还要不要继续调工具？"""
    last = state["messages"][-1]
    return "tools" if last.tool_calls else END

# ---- 5. 组图 ----
graph = StateGraph(AgentState)
graph.add_node("agent", agent_node)
graph.add_node("tools", tool_node)
graph.set_entry_point("agent")
graph.add_conditional_edges("agent", should_continue, {"tools": "tools", END: END})
graph.add_edge("tools", "agent")  # 关键：执行完工具回到 agent，形成循环

app = graph.compile()

# ---- 6. 跑一下 ----
SYSTEM = """你是带工具的助手。回答前请思考：
1) 这个问题需要查内部知识库吗？→ vector_search
2) 涉及时效性（新闻/最新数据）吗？→ web_search
3) 需要计算吗？→ python_repl
4) 检索结果不充分时，请改写查询再试一次（最多 3 次）。
最终答案需引用证据来源。"""

result = app.invoke({
    "messages": [
        AIMessage(content=SYSTEM),
        HumanMessage(content="我们 2024 年的客户留存率比 2023 年提升了多少个百分点？")
    ]
})
print(result["messages"][-1].content)

这段代码的循环结构 agent ⇄ tools 就是 Agentic RAG 的骨架。你可以在 agent_node 之后再插一个 reflect_node 来实现 Reflexion，或者在入口加一个 route_node 实现路由式分发。

五、易错点澄清（针对原 QA 对话）

六、什么时候不要用 Agentic RAG

Agentic RAG 不是银弹。以下场景反而应该退回简单 RAG：

• 延迟敏感：多轮工具调用容易让响应时间从 2s 涨到 20s+。客服首屏问答慎用。
• 成本敏感：每一次 Thought 都是一次 LLM 调用，token 消耗成倍。
• 任务足够单一：固定的产品手册问答、单一 SQL 报表查询，写死的流程更稳。
• 可解释性要求极高：Agent 的循环路径有时不可重复，审计困难。

经验法则：先把 Naive RAG / Hybrid RAG 调到位，再决定哪一段加 Agent。

七、小结

• Agentic RAG 的本质是把「下一步做什么」从开发者手里交给 LLM，靠工具调用 + 反思循环获得更强的鲁棒性。
• 完整架构 = 路由 + 工具层 + 决策循环 + 记忆 + 合成；五层缺一不可。
• 选型上记得跟上模型迭代（Claude 4.X / GPT-5），并选用合适的编排框架（LangGraph 是当前事实标准）。
• 工程化落地的关键不在算法，而在 观测 + 评测 + 兜底。

延伸阅读：

• Self-RAG：Asai et al., 2023
• CRAG：Yan et al., 2024
• Adaptive-RAG：Jeong et al., 2024
• ReAct：Yao et al., 2022
• Reflexion：Shinn et al., 2023
• LangGraph 官方教程：https://langchain-ai.github.io/langgraph/