企业官网建设流程全解析

1. 从传统RAG到Agentic RAG：为什么我们需要一次架构升级

先从我最近被问得最多的问题说起。不少做知识库问答、企业文档检索的同学都在问同一个问题：我用了向量数据库、用了RAG方案，为什么复杂一点的问答效果还是不行？

比如用户问“帮我对比一下我们上季度和本季度各区域的销售额差异，并分析可能的原因”，传统RAG流程基本是：把问题向量化，去库里捞Top K个相似片段，塞给大模型让它“总结”。结果呢？要么检索到的片段缺关键字段，要么模型拿着几个不相关的段落硬编，答得看似完整但其实经不起推敲。问题不在于模型本身不够聪明，而在于整个流程太“单线程”了。

Agentic RAG的核心思路，就是对这一整套流程做一次架构升级——不是换一个更贵的模型，也不是把Chunk Size改一改，而是让“Agent”这个概念进入检索生成的循环中。说得直白一点，传统RAG是“一次检索，一次回答”，Agentic RAG则是“按需规划、多次检索、灵活调用工具、自主判断信息是否足够再作答”。这个标题里说的“智能检索生成技术新突破”，突破的并不是某一个算法指标，而是把RAG从一个“管道”变成一个有决策能力的“系统”。

这篇文章我会从Agentic RAG的架构设计、核心组件、落地实现、参数调优到实战踩坑，完整拆解一遍。适合已经在做RAG应用、想让系统在复杂问题上表现更好的开发者，也适合正准备从零选型、想搞清楚这个方向到底值不值得投入的团队。

2. Agentic RAG的核心架构与设计思路

2.1 传统RAG的瓶颈：为什么它搞不定复杂问题

要理解Agentic RAG的必要性，得先复盘传统RAG的局限。标准流程是“Embedding + 向量检索 + 生成”，它有几个天生的问题。

第一个是查询与文档之间的语义鸿沟。用户提问的方式和知识库中文档的表达方式经常不一致。比如用户问“哪些客户投诉最多”，但文档里写的可能是“高频工单用户分析”，语义相近但表达完全不同，单靠向量相似度不一定能检索到。传统RAG只能把问题原样丢给Top K检索，一旦召回结果不理想，后续生成就是“巧妇难为无米之炊”。

第二个问题是固定K值的盲目性。有的问题三句话就能答，有的问题需要跨多个文档片段的证据链。传统RAG不管你问什么，永远检索Top 5或Top 10。问简单问题时浪费上下文窗口，问复杂问题时答案残缺不全。

第三个问题最致命：没有验证机制。传统RAG生成的答案只要模型觉得“听起来流畅”就输出，LLM本来就有幻觉倾向，再加上检索到的片段中如果有过时、矛盾的信息，模型根本不会主动去判断哪些可信、哪些需要进一步核实。我在实际项目里见过太多系统把两个年份的数据混在一起生成答案，用户不仔细看真的发现不了。

传统RAG本质上是一个静态管道——查询进去，答案出来，中间没有反馈、没有循环、没有决策。Agentic RAG要做的，就是给这个管道装上“大脑”。

2.2 Agentic RAG的三层架构：规划、执行、反思

我理解Agentic RAG，通常把它拆成三个核心层次。

第一层是规划层（Planning）。Agent接收用户问题后，不是立即调用检索工具，而是先做两个判断：这个问题是简单的还是复杂的？我需要哪些信息才能回答？如果是一个简单问题（比如“某个部门的负责人是谁”），直接一轮检索就够；如果是一个复杂问题（比如“哪些产品线的退款率环比上升且用户集中在哪个渠道”），Agent会拆解成子任务，比如“先查各产品线退款率”、“再查退款用户渠道分布”、“最后做用户分层分析”。这一层是关键分水岭，传统RAG永远不会有“拆解问题”这个动作。

第二层是执行层（Execution）。规划有了，Agent接下来按计划调用不同的工具。这里的“工具”远不止向量检索，可以包括SQL查询、Web搜索、时间序列数据查询、CRM API接口等。尤其值得注意的是，Agent不仅会调用这些工具，还会评估每次调用的结果——这次检索到的内容质量够不够？信息有没有冲突？我需不需要换个检索词再试一次？这就把传统RAG里的“一次性检索”变成了“多轮协同”。

第三层是反思层（Reflection）。生成答案之前，Agent会对已收集到的信息做一次自我审视：证据链完整吗？有没有回答不了的子问题？答案中是否存在矛盾？如果发现问题，Agent可以再次回到工具调用阶段，继续检索或调整检索策略。这种“生成-评估-再检索”的循环，在传统的单轮RAG中是完全不存在的概念。

我常说一句话：传统RAG是“拿了就跑”，Agentic RAG是“想好了再做，做完还要检查”。

2.3 单Agent还是多Agent：架构选型的现实考量

聊到Agentic RAG，必然涉及一个选择题：用一个大Agent把所有事情干完，还是拆成多个专用Agent协作？两种方案在实际项目中都有落地场景。

单Agent方案的特点是灵活性和上下文一致性。它把多轮检索、工具调用、推理判断都放在一个Agent循环里，状态管理简单，开发和调试成本低。对于大多数企业知识库问答场景，单Agent已经能覆盖80%的需求。我见过比较好的单Agent设计，是在系统提示词中明确给Agent定义“什么时候该检索”、“检索不到时怎么办”、“什么时候可以停止检索”等边界规则，这样它在多轮循环中会比较稳定。

多Agent方案的优势在于职责解耦和并行处理。比如一个Router Agent负责理解用户意图和分派任务，一个Retriever Agent专门做文档检索和初筛，一个Reasoner Agent负责信息综合和答案生成。每个Agent的提示词都更精简，任务更专注，适合问答类型非常复杂、来源系统多的场景。缺点也很明显：Agent之间的消息传递会增加延迟，调试难度成倍上升，模型成本高不少。

关于选型，我个人建议遵循一个原则：能用单Agent解决的就不要上多Agent。多Agent不是银弹，它更适合那种“一个流程涉及多个领域、需要不同工具链协同、且每个环节的规则都相对独立”的场景。比如我需要同时查企业内部的文档库、财务系统的销售数据、以及外部行业的基准报告，三个数据源的数据结构差异巨大，这时候多Agent的并行检索和协作价值就体现出来了。如果只是单数据源问答，单Agent的循环检索能力完全够用。

3. Agentic RAG的落地实现：从零搭建一个可运行的智能检索系统

3.1 技术选型：框架、模型和向量库怎么配

这几年Agent开发框架越来越多，我基于实际体验和社区反馈，以LangGraph为主线来演示（偏好其他框架的朋友可以关注对应的相同思路）。选这个框架主要是看中它对“循环控制”和“状态持久化”的原生支持——Agent往往需要通过循环检索和状态积累来判断信息是否真正充分，普通链式框架很难优雅地表达这种动态逻辑。

大模型这一层，首选函数调用能力强的模型。Agent能不能稳定调用工具，取决于模型对工具描述的遵从度。实操中我建议用带温度参数的模型（比如通用对话模型或者指令优化的模型），温度保持在0到0.2之间，避免生成路径跑偏。不是说参数小的一定差，关键是推理类任务禁不起“随机”太高的采样。

向量库的选择要考虑部署复杂度、检索延迟、索引更新频率。常用的有Chroma、Milvus、Weaviate等，中小型项目Chroma起步就很方便，生产规模再换到Milvus或者云上的向量数据库服务也不难。重要的是提前考虑是否支持metadata过滤。Agentic RAG中我们经常要按部门、日期、文档类型等条件缩小检索范围，如果向量库不支持metadata过滤，很多策略实现起来会特别别扭。

3.2 核心代码骨架：一个带反思循环的Agent

下面这段代码是可以直接运行的核心骨架（基于LangGraph的思路、用语言模型做推理核心），展示了Agentic RAG最本质的循环结构：规划 -> 调用工具 -> 评估结果 -> 决定是否继续。

from langchain_core.tools import tool from langchain_core.messages import HumanMessage, AIMessage, ToolMessage from typing import List, Dict, Any # 定义Agent状态 class AgentState(Dict[str, Any]): messages: List # 对话历史与工具调用记录 retrieved_docs: List # 已检索到的文档片段 missing_info: List # 记录缺失的信息点 # 工具1: 向量检索 @tool def vector_search(query: str, top_k: int = 5, filters: dict = None) -> str: """从知识库中检索与query相关的文档片段""" # 实际项目中这里接入向量库的similarity_search # 先走metadata过滤，再做相似度检索 results = vector_store.similarity_search( query, k=top_k, filter=filters ) return "\n".join([f"[{i+1}] {doc.page_content}" for i, doc in enumerate(results)]) # 工具2: 结构化查询（查SQL库） @tool def sql_query(sql: str) -> str: """执行只读SQL查询，返回结果集""" # 实际项目中这里接入数据库 results = db.execute(sql) return str(results.fetchall()) # 工具3: 判断信息是否充分的反射机制 @tool def check_sufficiency(question: str, collected_info: str) -> str: """评估已收集信息能否回答问题，返回sufficient或不足原因""" # 这里可以用一个轻量的LLM调用做评估 # 也可以用明确的规则判断，比如关键实体是否出现、字段是否齐全 return llm_evaluate(question, collected_info) def agentic_rag_loop(user_question: str, max_iterations: int = 5): state = { "messages": [HumanMessage(content=user_question)], "retrieved_docs": [], "missing_info": [] } for i in range(max_iterations): # 推理核心: 让LLM决定下一步动作 response = llm_with_tools.invoke(state["messages"]) state["messages"].append(AIMessage(content=response)) # 如果模型判断可以直接回答，则结束循环 if response.tool_calls is None or len(response.tool_calls) == 0: break # 执行工具调用 for tool_call in response.tool_calls: tool_name = tool_call["name"] tool_args = tool_call["args"] print(f"[迭代{i+1}] 调用工具: {tool_name}, 参数: {tool_args}") if tool_name == "vector_search": result = vector_search.invoke(tool_args) state["retrieved_docs"].append(result) elif tool_name == "sql_query": result = sql_query.invoke(tool_args) elif tool_name == "check_sufficiency": result = check_sufficiency.invoke({ "question": user_question, "collected_info": "\n".join(state["retrieved_docs"]) }) # 把工具结果追加到消息历史中 state["messages"].append( ToolMessage(content=result, tool_call_id=tool_call["id"]) ) # 最终生成答案 final_answer = llm.invoke( [ SystemMessage(content="基于已检索到的信息，给出最终答案，并标注信息可信度。"), HumanMessage(content=user_question), *[m for m in state["messages"] if isinstance(m, (AIMessage, ToolMessage))] ] ) return final_answer.content

这段代码把Agentic RAG的核心循环表达得很清楚。模型每一步都可以选择调用工具或直接作答，工具返回结果后模型再接着推理。比较关键的细节是check_sufficiency这一步，它把“反思”显式建模出来了——信息够了就收，不够就继续查。这比硬性规定“必须检索N轮”要灵活得多，也符合真实业务对准确性的要求。

3.3 规划模块与工具定义的实操细节

规划模块设计得好不好，直接决定Agent的工作效率。实操中有一个容易被忽略的点：不要把规划的任务全压给LLM的“临场发挥”，而是在系统提示词里给Agent“可用的工具清单”和“常见规划模板”。

比如说提示词中这样写：如果问题是“某指标的变化及原因分析”，可先查该指标的历史数据，再查相关事件文档，最后综合两者生成归因分析。我看到过效果比较好的Agent系统，本质上就是把领域专家平时问问题的思路沉淀成了一系列规划模板。有了这些模板，Agent面对复杂问题时的第一步就不会跑偏。

工具定义也有讲究。工具描述写得好不好，直接决定大模型能不能正确调用工具。很多人在工具描述里写得很简陋，比如就写“查询数据库”，大模型根本不知道什么时候该用它。我的建议是每个工具的description里写清楚“适用场景、输入参数含义、输出格式示例”，最好带上一个具体例子。比如：

@tool def get_product_refund_rate(product_line: str, start_date: str, end_date: str) -> str: """获取指定产品线在给定时间范围内的退款率数据。 适用场景: 用户询问退款率、退货比例、售后占比等指标。 示例: get_product_refund_rate(product_line="智能家居", start_date="2024-01-01", end_date="2024-03-31") 返回: 产品线: 智能家居, 退款率: 2.3% """

这个示例能让模型准确理解工具用途。因为问“退款率”的用户可能在表达时用的是“退货百分比”、“售后问题占比”等不同说法，模型看到工具示例后就能把这些表达对应到正确的工具调用上。

3.4 工具的组成与One-Hop思维扩展

再往深说一层，我习惯把一个Agent能调用的工具箱分为三类。

第一类是语义检索类工具。这类工具依托向量检索，但可以加多个变体：按部门过滤的检索器、按时间过滤的检索器、按文档类型过滤的检索器等。把这些变体封装成不同工具，Agent就能更有针对性地获取信息。

第二类是结构化查询类工具。企业中大量数据存在SQL库或数仓里，比如销售金额、退款率、用户数、工单量。Agent需要能写SQL或调用预定义的SQL模板。实操中直接让Agent写SQL风险不小，我的折中做法是准备一批常用的SQL模板，Agent根据用户问题选模板并填参数。如果Agent发现没有匹配的模板，它会先检索文档，看有没有其他数据定义可以参考。

第三类是外部信息工具。比如天气API、地图API、外部行业报告等。在企业问答场景中不经常用，但在一些公共服务或开放域问答中很关键。

有一个概念值得单独强调：如果你希望Agent把信息链路打通，就不要把工具限制在“检索文档”上。举个例子，用户问“我们哪个区域的产品退货率最高，退货原因集中在哪里”。传统RAG需要先有人把这两个数据人工汇总成一篇文档，再切块入库，Agent才能检索到。而Agentic RAG的做法是：Agent先调用SQL工具查各区域退货率，拿到最高的区域后，再调用语义检索工具在那个区域的退货原因分析报告里查找具体原因。这个过程本身就是“One-Hop”的思维扩展——先拿到一个结果，再基于这个结果继续下一步推理。这是Agentic RAG最核心的能力加分项，也是它和传统RAG差异最明显的场景。

4. Agentic RAG落地之路：从文档嵌入到循环检索的完整链路

4.1 第一步：环境准备与依赖安装

实操之前先把环境跑通。我用的是Python 3.10以上的环境，推荐用虚拟环境隔离项目依赖，避免各种包版本冲突。

# 创建虚拟环境 python -m venv venv_agentic_rag source venv_agentic_rag/bin/activate # 安装核心依赖 pip install langchain langgraph chromadb openai tiktoken pip install pandas sqlalchemy # 结构化数据相关 pip install fastapi uvicorn # 最终部署API用

这里列的都是基础依赖。实际项目中你可能会用到其他向量库的SDK、特定数据库的驱动等，按需安装就好。装完之后验证一下版本能不能正常导入：

import langchain, langgraph, chromadb print(langchain.__version__, "OK")

4.2 第二步：文档加载、切块和向量化

检索质量的根基在文档处理。这一步如果偷懒，后面Agent再怎么智能都白搭。

先说加载。典型的输入包括PDF、Word、Markdown、HTML等格式，LangChain各格式对应的加载器是现成的，直接用就好。我自己遇到过的坑：PDF里的表格经常加载成乱码或错位文本，切块的时候需要注意表格区域是否被完整保留——如果表格被拦腰截断，检索阶段就很容易漏掉关键数据。

切块策略上，工程界的共识是不要用固定的字符数硬切。更好的做法是“按文档结构切块”：Markdown按标题切，PDF按章节和段落切，HTML按标签结构切。每个Chunk的大小控制在512到1024个token比较合适。太大检索起来不够精准，太小则上下文信息不完整。

向量化的选择比较灵活，BGE系列、OpenAI Embeddings等都可以。要注意的是，中文场景下选一个对中文理解好的Embedding模型，效果好不少。另外，重要的事说三遍：切块时一定要把metadata（来源、章节、时间、作者等）一并存储。Agentic RAG中Agent经常要根据metadata做过滤，这直接决定检索的精准度。

4.3 第三步：构建工具层和状态管理

工具层在3.2的代码里已经展示了基本思路，这里补充状态管理的设计。

Agentic RAG中需要管理的核心状态包括：已经检索到的文档片段、已经执行的工具调用记录、还有哪些信息缺口。我在项目里一般用一个字典类型的对象管理这些状态，在每次工具调用后更新。这套结构的好处是：即便Agent经历多次循环，我们仍能回溯它每一步的执行逻辑，对调试和复盘很有帮助。

状态管理还有一个隐形的作用：控制循环次数。Agent在理想情况下希望快速收敛，但有些复杂问题的确需要多轮检索。我通常把最大迭代次数设为5，超过就强制让Agent基于已有信息作答，避免无限循环。这个上限在线上环境特别重要，它直接限制了单次请求的响应时间和token消耗。

4.4 第四步：用FastAPI封装成可调用的API服务

项目最终总要暴露成服务给业务方调用。我用FastAPI封装一层：

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class QueryRequest(BaseModel): question: str user_id: str = "default" top_k: int = 5 class QueryResponse(BaseModel): answer: str trace: list # Agent执行轨迹，方便排查 @app.post("/agentic_rag/query", response_model=QueryResponse) async def query_endpoint(req: QueryRequest): # 带历史会话功能的话，可以根据user_id维护session状态 answer = agentic_rag_loop(req.question, top_k=req.top_k) return {"answer": answer, "trace": get_execution_trace()}

这个服务框架的好处是部署简单，直接扔到任意一台服务器上就能跑。响应字段里我特意保留了trace，Agent每步做了什么、调用了什么工具，都能返回给调用方。这在联调阶段排查问题非常有用。

5. 关键参数调优与性能优化经验

5.1 检索参数：Top K和相似度阈值的平衡

参数调优里最基础的是Top K和相似度阈值。

Top K决定了每次检索返回多少候选片段。经验值我一般取5到10之间。但这不是固定死的——Agent结合Top K找到所需信息后，可以自主决定是否需要扩大检索范围。我在系统提示词中明确告诉Agent：如果当前Top K结果不足以支撑回答，可以再次调用检索工具，但可以换一种表达方式或换一组过滤条件。这样既保留初始Top K的快速收敛特征，又给了Agent弹性空间。

相似度阈值的作用是过滤掉低相关的噪声片段。命令实践上，阈值太严会导致召回不足，太松又会把毫不相关的内容塞给模型。实操中建议在测试集上调出该数据集的合理阈值：收集一段时间的真实用户问题，逐一测试在0.6、0.7、0.8阈值下的回答准确率，取平衡点。不要盲目套用别人的阈值。

5.2 模型参数：温度、迭代次数和系统提示词

大模型推理温度建议设0到0.2。Agentic RAG的核心是决策和检索，不是创意写作，温度过高会让模型在“工具选择”这个关键环节摇摆不定。如果同时跑多个并发的数据，温度太高还会出现Agent之间行为不一致的问题，复盘难度会大幅上升。

迭代次数上限的设置要平衡服务质量与用户体验。我在多个项目中观察下来的结果：大多数普通问答在2到3次迭代内就能收敛，复杂分析类的问题可能需要5到6次。线上默认设5是合理的。如果超过5次还在循环，大概率是工具定义有问题，不分清问题类型就疯狂检索。这时候与其堆迭代次数，不如回去优化提示词。

系统提示词是Agentic RAG中最值得花时间打磨的部分。好的提示词应该明确给出决策规则：什么时候直接回答、什么时候要检索、检索不到怎么办、信息冲突怎么处理。我把提示词称为Agent的“工作手册”。有一个项目让我印象很深：仅仅重写了一版结构化的系统提示词，把决策规则逐条列清，整个系统的准确率提升了十几个百分点，而且Agent的工具调用次数明显下降——因为Agent不再盲目检索了。

5.3 推理与评测：怎么知道系统到底有没有变好

Agentic RAG项目的评测比传统RAG复杂。传统RAG看召回率和生成答案的BLEU/ROUGE分数就够了，Agentic RAG还要评估“决策质量”。

我实际使用的评测维度包括：工具调用是否准确（应该查销售库时有没有调错成文档检索）；路径是否最简，能不能用更少的检索次数得到答案；最终答案完整性；在Agent故意把多个数据源对比任务串起来的场景下的成功率。

评测集如何选取？我会准备几十道涵盖简单问答、多跳检索、对比分析、时序趋势四类题目的问题集，标记出标准答案和预期工具调用链。每次改完参数，整套跑一遍，对比工具调用链和答案质量。用上一段时间你就能明显感觉到：哪些改动是真正对系统有效的，哪些只是看起来像在变好但地图炮一个都没打通。

6. 常见问题与避坑实录

6.1 工具调用不可靠的排查思路

很多人在Agentic RAG上遇到的头号问题是：Agent经常不调工具，或者调错工具。我排查看第一位的是模型对工具描述的理解。如果工具描述里写的参数示例不够明确，模型就像拿到了模糊的API文档，用不对很正常。先把工具描述改写得更贴近实际使用场景，给出清晰的示例，往往能解决大部分调用不准的问题。

第二个常见原因是工具之间的描述相似度过高。两个工具的用途区分不够清晰时，模型会随机选一个调用。解决方法是给每个工具起一个能体现职责差异的名字，并且名称不要过于泛化。比如search_sales_orders和search_return_records，比query_database_1和query_database_2清晰得多。

第三是上下文太长导致模型“忘”了可用工具。当Agent多轮迭代后消息列表很长，某些模型对最早的工具描述关注度下降。这种情况可以适当压缩之前的中间步骤，只保留关键的已检索信息和决策依据在上下文里。

6.2 检索结果冲突与幻觉问题的治理

Agent在多次检索后，可能拿到互相矛盾的信息。比如一份文档说退款率2.3%，另一份说3.1%。如果不加处理，Agent可能会根据相关性随意选了其中一个数字，或者两边信息都保留，生成一段自相矛盾的答案。

我建议在系统提示词中明确规定：当信息出现冲突时，Agent必须列出冲突内容并让信息提供者“对话”——进一步检索更多证据，或根据metadata中的时间戳判断哪个数据更新。如果仍然无法裁决，最终答案中必须明确指出存在数据口径差异，并提供参考依据。不要为了让答案漂亮而掩盖矛盾，这是保障系统可信度的一条底线。

幻觉问题在Agentic RAG中比传统RAG好控制一些，因为Agent可以通过多步检索补充证据。但若Agent检索内容不足时强行作答，幻觉仍然可能出现。关键机制就是3.2中的check_sufficiency：当信息不足时，Agent应继续扩大检索范围，而不是马上生成。在提示词中我还会加一句约束：宁可如实回答“目前查到的信息不足以给出完整结论”，也不要编造。

6.3 性能优化与成本控制

Agentic RAG比传统RAG慢，本质上是因为多轮循环意味着多次LLM调用和多次检索。如果对延迟要求很高，有几个优化手段相对有效。

第一个是并行工具调用。当Agent判断需要同时查多个数据源且没有依赖关系时，可以一次发起多个工具调用，而不是串行执行。LangGraph内部对并行工具调用有原生支持，用起来很方便。

第二个是缓存策略。在Agent系统里，检索结果和中间推理结果都可以做缓存。同一类问题在短期内往往会重复出现，命中缓存后延迟会降到接近零，成本也会大幅下降。我见过最好的实现是把“工具名+参数”作为缓存key，这样即使在不同的会话中发起了相同的检索，也能复用结果。

第三个是轻量模型与强模型协作。让轻量且便宜的模型做主规划和高频简单问答，决策核心或复杂推理时再调用能力更强的模型。这有点像团队里“初筛-复核”的分工，成本能显著下降，体验几乎不受影响。

7. 现在的限制与我认为值得关注的演进方向

Agentic RAG远没有到“完全成熟”的阶段，它还有一些明显限制需要正视。

第一个是信任边界问题。Agent自主决策越强，用户越难以判断它这么做的依据是否可靠。在多步检索、多工具调用的链路中，如果缺少可靠的过程追溯和可信度标记，用户凭什么相信最终答案？我现在的做法是：在答案中尽可能标注信息来源和检索路径，让“结论可追溯”。但这里只是工程上的缓解，而非根本性解法。

第二个是成本问题。多轮迭代带来的token消耗是传统RAG的数倍。企业如果用量大，每月的模型成本可能会变成一笔不小的开销。降本的方向包括：能单轮解决的尽量不触发多轮；会话内信息复用；轻量模型承担简单任务。这个方向未来会有更多优化空间，现在仍需要人工干预。

第三个是评测标准化问题。目前Agentic RAG缺少像传统RAG那样成熟的自动化评测体系。不同团队各搞一套评测标准，效果很难横向比较，行业发展速度也因此受限。我期待出现更被广泛接受的Agent行为评测基准。

面对这些限制，我个人的判断是：Agentic RAG仍然是非常值得投入的方向。虽然成本和复杂性更高一些，但它确实解决了传统RAG在复杂问题上的核心短板。现在动手积累经验、沉淀最佳实践，比等技术完全成熟后再跟上要高效得多。我见过太多团队在传统RAG上修修补补很久，最终效果仍然不理想，然后转头把同样的文档处理工作又做了一遍，只是换成了Agentic RAG架构。

最后分享一个我在实际项目中反复验证有效的经验：不要一开始就把系统设计得过于复杂。先把一个最简单的问题类型跑通——比如单工具、两步检索——让整条链路稳定，再逐步增加工具种类和Agent的决策自由度。渐进式扩展在Agent类项目中相当重要，因为你更容易定位是哪一层出了问题，也能更快建立起对这个系统的掌控感。Agentic RAG的潜力很大，但它的能力边界，是用工程细节一块一块垒出来的。