核心摘要

传统的 RAG 架构本质上是一条从检索到生成的单向流水线:用户提问 -> 向量检索 -> 拼接上下文 -> LLM 生成。这条流水线简单高效,但在面对真实业务中的复杂查询时,它缺乏"判断力"——无法决定该不该检索、从哪里检索、检索结果够不够好。

Agentic RAG 正是为解决这个问题而生。它将一个 AI Agent 嵌入 RAG 管道的核心位置,赋予系统自主决策、动态路由、质量评估和迭代修正的能力。本文将深入剖析其架构设计、四大核心模式,并提供基于 LangGraph 的实战代码。

📋 目录

✨ 核心要点

  • 范式跃迁:Agentic RAG 将检索从"被动执行"升级为"主动思考",通过 Agent 闭环控制全链路。
  • 四大模式:路由 (Routing)、多步骤 (Multi-step)、自纠错 (Corrective) 和自适应 (Adaptive) 是核心设计模式。
  • 质量保障:引入"检索评估"环节,有效对抗模型幻觉,提高复杂问题的回答准确率。
  • 落地建议:生产环境需重点关注延迟控制、防止无限循环及完善的可观测性体系。

💡 快速工具: Awesome Prompt 提示词库 — 发现和优化你的 Agent 提示词,显著提升 Agentic RAG 的路由与评估准确率。

从 Naive RAG 到 Agentic RAG:范式跃迁

在深入 Agentic RAG 之前,有必要厘清 RAG 技术的三个演进阶段。如果你对基础 RAG 架构还不熟悉,建议先阅读 RAG 检索增强生成基础教程

三代 RAG 架构对比

维度 Naive RAG Advanced RAG Agentic RAG
检索策略 固定的 Top-K 向量检索 混合检索 + Rerank Agent 动态选择检索策略
流程控制 线性单次 线性但有预处理/后处理 图状、可循环、可分支
质量保障 静态阈值过滤 LLM 主动评估并自修正
数据源 单一向量库 单一向量库(优化索引) 多数据源动态路由
典型延迟 1-2s 2-4s 3-15s(视复杂度而定)

Naive RAG 的致命弱点在于它对所有查询一视同仁——无论用户问的是"你们公司的退款政策是什么"(简单事实查询)还是"对比你们最近三个季度的 ARR 增长趋势,并分析主要驱动因素"(复杂分析查询),系统都执行完全相同的检索-生成流程。

关于 Advanced RAG 中混合检索与 Rerank 的详细实现,可以参考 RAG 检索质量优化方案:从 Rerank 到 Hybrid Search

Agentic RAG 的核心思想

Agentic RAG 的本质是将 RAG 管道中的"检索"环节从一个被动执行的函数调用,升级为一个由 AI Agent 主动规划和执行的智能工作流。这个 Agent 具备以下核心能力:

  1. 意图识别:判断用户查询是否需要外部知识,还是 LLM 自身就能回答。
  2. 数据源路由:根据查询类型选择最合适的知识库(向量库、SQL 数据库、搜索引擎、API)。
  3. 查询改写:当原始查询过于模糊或宽泛时,Agent 会主动改写或拆解查询。
  4. 结果评估:对检索到的文档进行相关性评判,决定是否需要重新检索。
  5. 迭代推理:在多轮检索-评估的循环中,逐步逼近高质量的最终答案。

这种架构与 ReAct 框架 的 Thought-Action-Observation 循环高度一致——Agent 在每一步都进行显式推理,然后决定下一步行动。

四大 Agentic RAG 设计模式

Agentic RAG 并非一种单一架构,而是一个设计模式族。根据业务场景的复杂度,可以选择不同的模式或将它们组合使用。

模式一:路由 RAG (Routing RAG)

路由 RAG 是最基础的 Agentic 模式。Agent 的核心职责是根据用户查询的语义意图,将请求分发到最合适的数据源。

典型场景:企业客服系统需要同时对接产品文档库、FAQ 知识库、工单系统和结构化的产品参数数据库。

python
from langgraph.graph import StateGraph, END
from typing import TypedDict, Literal

class AgentState(TypedDict):
    query: str
    route: str
    documents: list
    answer: str

def route_query(state: AgentState) -> AgentState:
    """Agent 根据查询意图决定路由"""
    query = state["query"]
    
    route_prompt = f"""分析以下用户查询,判断应该路由到哪个数据源:
    - "vector_store": 产品功能、使用方法等非结构化文档
    - "sql_database": 价格、库存、订单等结构化数据查询
    - "web_search": 需要最新信息、竞品对比等实时数据
    - "llm_direct": 通用常识问题,无需外部检索
    
    查询: {query}
    """
    
    result = llm.invoke(route_prompt)
    state["route"] = result.content.strip()
    return state

def retrieve_from_vector_store(state: AgentState) -> AgentState:
    docs = vector_store.similarity_search(state["query"], k=5)
    state["documents"] = docs
    return state

def retrieve_from_sql(state: AgentState) -> AgentState:
    sql_query = llm.invoke(f"将以下问题转换为SQL: {state['query']}")
    results = db.execute(sql_query.content)
    state["documents"] = [str(results)]
    return state

# 构建路由图
graph = StateGraph(AgentState)
graph.add_node("router", route_query)
graph.add_node("vector_retrieval", retrieve_from_vector_store)
graph.add_node("sql_retrieval", retrieve_from_sql)
graph.add_node("web_search", search_web)
graph.add_node("generate", generate_answer)

graph.set_entry_point("router")
graph.add_conditional_edges("router", lambda s: s["route"], {
    "vector_store": "vector_retrieval",
    "sql_database": "sql_retrieval",
    "web_search": "web_search",
    "llm_direct": "generate",
})

路由 RAG 的关键挑战在于路由准确率。在生产环境中,建议先用少量标注数据对路由 Prompt 进行评估,路由准确率低于 90% 时应考虑使用微调后的小模型(如 fine-tuned BERT 分类器)替代 LLM 路由。

模式二:多步骤 RAG (Multi-Step RAG)

当用户查询涉及多个知识点的交叉推理时,单次检索往往不够。多步骤 RAG 让 Agent 将复杂问题拆解为多个子查询,逐步检索并汇总信息。

这与 AI Agent 中的任务分解 (Task Decomposition) 原理一脉相承。Agent 使用 链式思考 将问题拆解,然后对每个子问题独立检索。

python
def decompose_query(state: AgentState) -> AgentState:
    """将复杂查询拆解为子查询"""
    decompose_prompt = f"""你是一个查询分析专家。请将以下复杂问题拆解为 2-4 个独立的子查询,
    每个子查询应该可以通过单次文档检索来回答。
    
    原始问题: {state["query"]}
    
    以 JSON 数组格式输出子查询列表。"""
    
    result = llm.invoke(decompose_prompt)
    state["sub_queries"] = json.loads(result.content)
    return state

def retrieve_for_sub_queries(state: AgentState) -> AgentState:
    """对每个子查询分别执行检索"""
    all_docs = []
    for sub_q in state["sub_queries"]:
        docs = vector_store.similarity_search(sub_q, k=3)
        all_docs.extend(docs)
    
    # 去重并保留最相关的文档
    state["documents"] = deduplicate_and_rank(all_docs)
    return state

def synthesize_answer(state: AgentState) -> AgentState:
    """基于多步检索的结果进行综合推理"""
    synthesis_prompt = f"""基于以下检索到的文档片段,综合回答用户的原始问题。
    注意:你需要跨多个信息源进行推理和关联分析。
    
    原始问题: {state["query"]}
    子查询及检索结果:
    {format_docs_with_sub_queries(state)}
    """
    
    state["answer"] = llm.invoke(synthesis_prompt).content
    return state

关于查询拆解的质量,直接决定了多步骤 RAG 的上限。好的拆解策略需要确保子查询之间既独立又互补。如果你的业务场景涉及实体间关系的推理,可以进一步参考 GraphRAG 工程化演进 中知识图谱的构建方法。

模式三:自纠错 RAG (Corrective RAG / CRAG)

自纠错 RAG 是 Agentic RAG 中最具实用价值的模式之一。它在生成答案之前,增加了一个 检索质量评估 (Retrieval Grading) 环节。如果评估结果不理想,Agent 会主动采取补救措施——改写查询重新检索,或者回退到 Web 搜索获取信息。

这种模式直接对抗了 RAG 系统中最常见的失败模式:检索到的文档看似相关,实际上并不包含回答问题所需的关键信息,最终导致 幻觉

python
def grade_documents(state: AgentState) -> AgentState:
    """评估检索到的文档与查询的相关性"""
    graded_docs = []
    
    for doc in state["documents"]:
        grade_prompt = f"""判断以下文档是否包含回答问题所需的关键信息。
        
        问题: {state["query"]}
        文档: {doc.page_content}
        
        输出 "relevant" 或 "irrelevant",并简要说明理由。"""
        
        result = llm.invoke(grade_prompt)
        if "relevant" in result.content.lower():
            graded_docs.append(doc)
    
    state["documents"] = graded_docs
    state["doc_quality"] = "sufficient" if len(graded_docs) >= 2 else "insufficient"
    return state

def rewrite_query(state: AgentState) -> AgentState:
    """当检索质量不足时,改写查询"""
    rewrite_prompt = f"""原始查询未能检索到足够相关的文档。请改写查询以提高召回质量。
    
    原始查询: {state["query"]}
    已检索但被判为不相关的文档主题: {state.get("irrelevant_topics", [])}
    
    输出改写后的查询。"""
    
    state["query"] = llm.invoke(rewrite_prompt).content
    state["retry_count"] = state.get("retry_count", 0) + 1
    return state

# 构建自纠错流程图
graph = StateGraph(AgentState)
graph.add_node("retrieve", retrieve_documents)
graph.add_node("grade", grade_documents)
graph.add_node("rewrite", rewrite_query)
graph.add_node("web_fallback", web_search_fallback)
graph.add_node("generate", generate_answer)

graph.set_entry_point("retrieve")
graph.add_edge("retrieve", "grade")

# 关键的条件路由逻辑
graph.add_conditional_edges("grade", decide_next_step, {
    "sufficient": "generate",      # 质量达标,直接生成
    "rewrite": "rewrite",          # 质量不足,改写查询
    "fallback": "web_fallback",    # 多次重试后仍不足,回退到 Web 搜索
})

graph.add_edge("rewrite", "retrieve")  # 形成重试循环
graph.add_edge("web_fallback", "generate")

def decide_next_step(state: AgentState) -> str:
    if state["doc_quality"] == "sufficient":
        return "sufficient"
    if state.get("retry_count", 0) >= 2:
        return "fallback"
    return "rewrite"

自纠错 RAG 中的 retry_count 上限设置至关重要。在生产环境中,必须设置明确的最大重试次数(通常为 2-3 次),防止 Agent 陷入无限重试循环。每次重试意味着额外的 LLM 调用和检索延迟,需要在回答质量与响应速度之间找到平衡。

模式四:自适应 RAG (Adaptive RAG)

自适应 RAG 是上述三种模式的有机融合,代表了 Agentic RAG 的最高形态。它的 Agent 不仅能路由、能拆解、能自纠错,还能在流程的每一个决策点上做出最优选择。

其核心架构可以用以下 TypeScript 伪代码描述:

typescript
interface AdaptiveRAGState {
  query: string;
  queryType: 'simple' | 'complex' | 'realtime' | 'no_retrieval';
  documents: Document[];
  subQueries?: string[];
  gradeResult?: 'pass' | 'fail';
  retryCount: number;
  finalAnswer: string;
}

// 第一层决策:是否需要检索?
function classifyQuery(state: AdaptiveRAGState): AdaptiveRAGState {
  // Agent 分析查询,判断是否需要外部知识
  // "今天天气如何" -> realtime (需要搜索引擎)
  // "什么是面向对象编程" -> no_retrieval (LLM 直接回答)
  // "你们产品的退款政策" -> simple (单次检索)
  // "对比 Q1-Q3 的运营数据并分析趋势" -> complex (多步骤检索)
  return { ...state, queryType: classifiedType };
}

// 第二层决策:选择检索策略
function selectStrategy(state: AdaptiveRAGState): string {
  switch (state.queryType) {
    case 'no_retrieval': return 'direct_generate';
    case 'realtime': return 'web_search';
    case 'simple': return 'single_retrieval';
    case 'complex': return 'multi_step_retrieval';
  }
}

// 第三层决策:检索后的质量控制
function postRetrievalGate(state: AdaptiveRAGState): string {
  if (state.gradeResult === 'pass') return 'generate';
  if (state.retryCount >= MAX_RETRIES) return 'fallback_generate';
  return 'rewrite_and_retry';
}

自适应 RAG 将路由、分解、评估三个维度的决策统一编排,其工作流可以用一张图概括:

code
用户查询 -> 意图分类 -> [直接回答 | Web搜索 | 单次检索 | 多步检索]
                                                  |
                                          检索结果评估 -> 通过 -> 生成答案
                                                  |
                                              不通过 -> 查询改写 -> 重新检索 (循环)
                                                  |
                                         超过重试上限 -> 降级回答 + 标记低置信度

使用 LangGraph 构建完整的 Agentic RAG

下面我们用 LangGraph 实现一个融合了路由和自纠错的 Agentic RAG 系统。这是一个可以直接用于原型验证的完整示例。

python
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_core.documents import Document
from typing import TypedDict, List, Optional
import json

# ========== 状态定义 ==========
class RAGState(TypedDict):
    query: str
    route: Optional[str]
    documents: List[Document]
    doc_grade: Optional[str]
    retry_count: int
    answer: Optional[str]

llm = ChatOpenAI(model="gpt-4o", temperature=0)
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma(embedding_function=embeddings, collection_name="knowledge_base")

# ========== 节点定义 ==========
def analyze_and_route(state: RAGState) -> RAGState:
    """入口节点:分析查询并决定路由"""
    response = llm.invoke(
        f"""分析查询意图,输出JSON格式:
        {{"route": "vector_db" | "web_search" | "direct"}}
        查询:{state['query']}"""
    )
    route_data = json.loads(response.content)
    return {**state, "route": route_data["route"]}

def vector_retrieve(state: RAGState) -> RAGState:
    """从向量数据库检索"""
    docs = vectorstore.similarity_search(state["query"], k=4)
    return {**state, "documents": docs}

def grade_retrieval(state: RAGState) -> RAGState:
    """评估检索质量"""
    if not state["documents"]:
        return {**state, "doc_grade": "fail"}
    
    doc_summaries = "\n".join([d.page_content[:200] for d in state["documents"]])
    response = llm.invoke(
        f"""评估这些文档是否能充分回答问题。输出 "pass" 或 "fail"。
        问题:{state['query']}
        文档摘要:{doc_summaries}"""
    )
    grade = "pass" if "pass" in response.content.lower() else "fail"
    return {**state, "doc_grade": grade}

def rewrite_and_retry(state: RAGState) -> RAGState:
    """查询改写并重新检索"""
    response = llm.invoke(
        f"改写以下查询以提高检索效果,直接输出改写结果:{state['query']}"
    )
    new_query = response.content.strip()
    docs = vectorstore.similarity_search(new_query, k=4)
    return {
        **state,
        "query": new_query,
        "documents": docs,
        "retry_count": state["retry_count"] + 1,
    }

def generate_answer(state: RAGState) -> RAGState:
    """生成最终回答"""
    context = "\n\n".join([d.page_content for d in state["documents"]])
    response = llm.invoke(
        f"""基于以下上下文回答问题。如果上下文不足以完全回答,请如实说明。
        问题:{state['query']}
        上下文:{context}"""
    )
    return {**state, "answer": response.content}

def direct_answer(state: RAGState) -> RAGState:
    """LLM 直接回答(无需检索)"""
    response = llm.invoke(state["query"])
    return {**state, "answer": response.content}

# ========== 路由函数 ==========
def route_decision(state: RAGState) -> str:
    return state["route"]

def grade_decision(state: RAGState) -> str:
    if state["doc_grade"] == "pass":
        return "pass"
    if state["retry_count"] >= 2:
        return "max_retries"
    return "retry"

# ========== 构建图 ==========
workflow = StateGraph(RAGState)

workflow.add_node("analyze", analyze_and_route)
workflow.add_node("vector_retrieve", vector_retrieve)
workflow.add_node("grade", grade_retrieval)
workflow.add_node("rewrite", rewrite_and_retry)
workflow.add_node("generate", generate_answer)
workflow.add_node("direct", direct_answer)

workflow.set_entry_point("analyze")

workflow.add_conditional_edges("analyze", route_decision, {
    "vector_db": "vector_retrieve",
    "web_search": "vector_retrieve",  # 简化:web_search 也走向量库
    "direct": "direct",
})

workflow.add_edge("vector_retrieve", "grade")

workflow.add_conditional_edges("grade", grade_decision, {
    "pass": "generate",
    "retry": "rewrite",
    "max_retries": "generate",  # 超过重试上限,用现有文档尽力生成
})

workflow.add_edge("rewrite", "grade")
workflow.add_edge("generate", END)
workflow.add_edge("direct", END)

# 编译并运行
app = workflow.compile()

result = app.invoke({
    "query": "对比上季度和本季度的客户流失率变化趋势",
    "documents": [],
    "retry_count": 0,
})
print(result["answer"])

这段代码的核心在于 grade 节点和 rewrite 节点之间形成的 条件循环。这正是 Agentic RAG 区别于传统 RAG 的本质特征——系统具备了自我反思和修正的能力。

生产环境最佳实践

将 Agentic RAG 从原型推向生产,需要重点关注以下几个工程维度。

延迟与成本控制

Agentic RAG 的每一次"思考"都意味着一次 LLM 调用。一个完整的自适应 RAG 流程可能涉及 3-6 次 LLM 调用(分类 1 次 + 检索 1 次 + 评估 1 次 + 可能的改写 1 次 + 生成 1 次 + 可能的生成质量评估 1 次)。

优化策略

  • 分级模型策略:路由和评估等"判断类"任务使用轻量模型(如 GPT-4o-mini 或 Claude 3.5 Haiku),仅在最终生成环节使用大模型。
  • 并行执行:当多个子查询互相独立时,使用异步并行检索,而非串行。
  • 缓存机制:对高频查询的路由结果和检索结果进行缓存,避免重复计算。
  • 流式输出:在 Agent 思考的过程中,先流式输出"正在分析您的问题..."等中间状态,降低用户的感知延迟。

防止无限循环

Agent 陷入无限循环是 Agentic 系统的经典故障模式。当检索质量持续不达标时,Agent 可能无限地改写查询-重新检索-再次评估不通过。

python
# 必须设置硬性上限
MAX_RETRIES = 3
MAX_TOTAL_STEPS = 10

def should_continue(state: RAGState) -> str:
    if state["retry_count"] >= MAX_RETRIES:
        return "force_generate"
    if state.get("total_steps", 0) >= MAX_TOTAL_STEPS:
        return "force_generate"
    return "continue"

同时建议在降级生成时,明确告知用户当前回答的置信度较低,并提供相关文档链接供用户自行查阅。

可观测性

Agentic RAG 的调试难度远高于传统 RAG,因为问题可能出现在任何一个决策节点。必须建设完善的可观测性体系:

  • 全链路追踪:记录每个节点的输入、输出、耗时和 LLM 的原始响应。
  • 决策日志:记录每次路由决策、质量评估结论和查询改写的具体内容。
  • 指标监控:追踪平均重试次数、路由分布、评估通过率等关键指标。

LangSmith(LangChain 的追踪平台)可以直接对接 LangGraph,为每次运行生成完整的执行轨迹图。

评估体系

Agentic RAG 的评估不能只看最终答案质量,还需要评估中间决策的准确性:

评估维度 指标 目标
路由准确率 路由正确的查询占比 > 90%
检索召回率 评估节点标记为相关的文档中,实际相关的占比 > 85%
自纠错有效率 重试后答案质量提升的占比 > 60%
端到端准确率 最终回答的正确率(人工评估) > 80%
平均延迟 从查询到回答的总耗时 < 10s (P95)

与工具调用的结合

在更高级的场景中,Agentic RAG 的 Agent 不仅能检索文档,还能通过 Function CallingTool Use 调用外部 API。例如:

  • 向量数据库 检索产品文档
  • 调用内部 API 查询用户的订单状态
  • 调用计算器工具进行数值推导
  • 调用代码解释器执行数据分析

这使得 Agentic RAG 逐渐演化为一个通用的 Agentic Workflow,检索只是 Agent 工具箱中的一个工具而已。关于 AI Agent 的整体架构设计,可以参考 AI Agent 架构设计与代码实战指南

Agentic RAG 与相关技术的关系

为了帮助你更好地定位 Agentic RAG 在技术版图中的位置,这里梳理它与几项相关技术的关系:

  • GraphRAG:GraphRAG 专注于用知识图谱增强检索的深度,Agentic RAG 专注于用 Agent 增强检索的灵活度。两者可以结合——Agent 将 GraphRAG 作为一个高级检索工具来调用。详见 GraphRAG 工程化演进教程
  • 多 Agent 系统:当单个 Agent 难以同时处理路由、检索、评估、生成时,可以将这些职责拆分给多个专业 Agent 协作完成。
  • 语义搜索 / Embedding:这些是 Agentic RAG 底层的检索基础设施。Agent 不替代它们,而是在它们之上进行智能编排。
  • 提示工程:Agent 在每个决策节点的表现高度依赖 Prompt 的质量,特别是路由和评估环节的 Prompt 需要精心设计和持续调优。
  • Guardrails:在 Agent 拥有多工具调用能力后,安全护栏变得更加重要——需要限制 Agent 能访问的数据范围和能执行的操作类型。

何时不需要 Agentic RAG

Agentic RAG 并非银弹。在以下场景中,更简单的方案可能是更好的选择:

  • 查询模式单一:如果 95% 的查询都是同一类型的事实提取,Advanced RAG(混合检索 + Rerank)就足够了。
  • 延迟要求极高:如果业务要求 P95 延迟在 2 秒以内,多次 LLM 调用的开销难以接受。
  • 数据源单一:只有一个向量库,不需要路由决策。
  • 成本敏感:每次查询 3-6 次 LLM 调用的成本在高 QPS 场景下可能不可接受。

RAG 分块策略多模态 RAG 等基础优化做好的前提下,很多场景下 Advanced RAG 已经能满足需求。Agentic RAG 应该在这些基础优化都到位之后,针对确实需要动态决策的场景再引入。

总结

Agentic RAG 代表了 RAG 技术的下一个演进方向。它的核心贡献不是发明了新的检索算法,而是将 Agent 的自主决策能力引入了检索管道,让系统从"被动执行"升级为"主动思考"。

四大设计模式——路由、多步骤、自纠错、自适应——提供了从简单到复杂的渐进式落地路径。你不需要一步到位地实现最复杂的自适应 RAG,而是可以从路由 RAG 开始,逐步根据业务需求叠加自纠错和多步骤能力。

最关键的是,在追求 Agentic 能力的同时,不要忽视基础功的重要性。高质量的 Embedding 模型、精心设计的分块策略、稳健的 混合检索 管道——这些基础设施的质量,决定了 Agent 手中工具的上限,而工具的上限,也就是整个 Agentic RAG 系统的上限。

常见问题 (FAQ)

Q1: Agentic RAG 与传统 RAG 的核心区别是什么?

传统 RAG 是一条固定的流水线(检索 -> 生成),而 Agentic RAG 引入了 AI Agent 作为决策中枢,能够自主判断是否需要检索、选择哪个数据源、评估检索结果的质量,并在质量不达标时主动发起重新检索或改写查询,形成动态的闭环推理。

Q2: Agentic RAG 有哪些主要的设计模式?

业界公认的四大模式包括:路由 RAG(根据查询意图分发到不同数据源)、多步骤 RAG(将复杂问题拆解为子查询逐步检索)、自纠错 RAG(对检索结果进行质量评估并自动修正)、以及自适应 RAG(动态决定是否需要检索以及使用何种检索策略)。

Q3: 为什么 LangGraph 适合实现 Agentic RAG?

LangGraph 将 Agent 的工作流建模为有状态的图(Graph),每个节点代表一个操作(如检索、评估、生成),边则代表条件路由逻辑。这种图结构天然契合 Agentic RAG 中复杂的分支、循环和条件判断需求,且支持持久化状态和人机协作断点。

Q4: Agentic RAG 在生产环境中面临哪些挑战?

主要挑战包括:多次 LLM 调用导致的延迟累积与成本增加、Agent 陷入无限循环的风险、检索质量评估的准确性、以及多数据源路由的一致性。需要通过设置最大迭代次数、缓存中间结果、异步并行执行等策略来缓解。

Q5: Agentic RAG 适用于哪些业务场景?

它特别适用于需要跨多个知识库回答复杂问题的场景,例如企业级客服系统(需路由到产品文档、FAQ、工单系统)、法律合规审查(需要多步骤检索并交叉验证)、以及金融研报分析(需要从结构化数据和非结构化报告中联合推理)。

相关资源