这几年做AI应用开发我发现自己跟人聊得最多的一个词就是RAG。从最开始尝鲜式地搭一个本地知识库问答到后来发现单纯的“检索生成”在复杂任务面前经常不够用再到把Agent的能力嵌进去这几乎是每个做LLM应用的人都会走过的路径。很多人一上来就追着问“Agentic RAG到底是什么”“跟普通RAG有什么区别”但如果没有亲手做过一版笨拙的RAG没有在失败的检索结果里翻过车你很难真正理解为什么需要“让Agent来指挥检索”。这篇文章我想一次性把RAG、AI智能体、Agentic RAG这三层关系讲透。不堆概念从原理到代码实现到踩坑经验按我自己的实践路径来写。你可以把它当成一份从入门到进阶的学习地图也可以当作一份实战参考手册。无论你是刚开始接触RAG的新手还是已经做过几版RAG应用、正想往Agent方向升级的进阶开发者这篇文章都能给你一些不一样的角度。1. RAG到底是什么以及我为什么没选微调1.1 RAG的核心动机让模型“先查再答”RAG的全称是Retrieval-Augmented Generation检索增强生成。它的思路非常朴素大模型不是不知道你的私有知识吗不是会一本正经地编造吗那我先从一个知识库里把跟问题最相关的资料找出来然后把这份资料和用户的原始问题一起丢给大模型让模型基于资料来回答。就这么一个简单的思路同时解决了好几个让人头疼的问题。第一个是幻觉问题。模型在不知道答案的时候往往会自信地编造。但如果你把相关资料塞给它它就有了依据胡说八道的概率会大幅下降。虽然不能说完全消除幻觉但实测下来在知识密集的场景里RAG能明显减少一本正经的胡说八道。第二个是知识时效性问题。大模型的训练数据是有截止日期的但业务知识是实时变化的。你不可能为了一个新政策就去重新训练一次模型但你可以把新政策文档丢进向量数据库RAG系统自然就能回答相关问题。第三个是私有知识问题。企业内部的资料、个人笔记、产品手册这些永远不会出现在公网训练数据里。这些私有知识恰恰是最需要问答能力的场景而RAG是让模型接触私有知识最直接的方式。我在自己的项目里做过一个对比实验同一个领域问题直接问大模型它给出一个泛泛而谈甚至充满臆测的回答而用RAG之后它能引用我提供的技术手册中的具体条款来回答。这个差别是质的飞跃。注意RAG不是让模型“记住”知识而是让模型“看见”知识。它把知识库的查询能力外包给了一个外置的检索系统模型只负责“阅读理解”和“总结输出”。理解这一点你就知道RAG的天花板在哪里——检索质量决定了生成质量。1.2 RAG的完整流程拆解从文档到答案的六步走一个标准的RAG系统从准备到回答要经过六个环节。第一步是文档加载。把PDF、Word、Markdown、网页等各种格式的资料收集起来。这里有很多细节比如PDF可能是扫描件需要OCRWord可能含图片需要单独提取网页需要爬虫抓取并清洗。实际操作中这个步骤通常占了项目工作量的四成以上远比想象中耗时。第二步是文本切分。文档加载进来之后是一大段连续文字而Embedding模型对输入长度是有限制的向量检索也要求被检索的单元小而精。所以我们要把文档切成一个个片段专业术语叫Chunk。切分不是简单地按字符数硬切要考虑语义边界。常用的策略是按标题层级切分、按段落切分、按句子切分或者用递归字符分割器。切分粒度是个反复调试的过程。切的块太大检索出来的内容往往包含大量无关信息稀释了答案的精准度切的块太小又可能丢失上下文模型看不到完整的逻辑链。我自己的经验是一般的技术文档用300到500个字符的块大小比较合适但如果有表格或代码片段需要特殊处理。第三步是向量化。把每一个Chunk用Embedding模型转换成向量。这个过程相当于给每段文字打了一个“语义坐标”。语义相近的文字在向量空间里距离也相近。这样做的意义在于检索的时候不是靠关键词匹配而是靠语义相似度匹配。第四步是建立索引并存储。所有向量和对应的文本块会存进向量数据库比如常用的向量库。索引结构需要专门优化常见的有HNSW、IVF等算法目的是在百万级甚至亿级向量里快速找到相似的向量。第五步是检索。用户输入一个问题先把问题本身也转换成向量然后在向量数据库里做相似度搜索找出最相近的K个文本块。这个K值很关键K太小答案不全K太大噪音太多。第六步是生成。把检索到的文本块和用户的原始问题一起组装成Prompt交给大模型生成最终答案。这里面的技巧在于Prompt的结构设计——你要明确告诉模型“请基于以下资料回答问题不要自行发挥”否则模型还是会忍不住编造。1.3 为什么我不建议一上来就微调很多人接触RAG之前第一反应是“那我用微调不就行了吗”。这个想法很自然我自己也动过这个念头但实际对比下来微调在很多场景里是不划算的。微调的本质是修改模型的权重让模型从统计规律层面“学会”新知识或者新风格。这就带来几个问题。成本方面无论是全量微调还是LoRA这类参数高效微调都需要准备高质量的标注数据需要GPU训练资源需要调试训练参数。一个完整微调流程走下来对个人开发者来说是不小的开销。时效性方面你今天微调了模型明天业务知识更新了你要不要重新微调一遍这种频繁的训练循环在快速迭代的业务场景里根本不现实。可解释性方面微调之后你很难说清楚模型为什么在某些问题上有不同的表现。而RAG的整个链路是透明的——什么东西被检索到了模型引用了哪段资料出了问题可以回溯、可以排查。那微调适合什么场景呢我理解是改变模型的“行为风格”和“输出格式”比如让模型更严谨、更简短、更善于用某种固定格式输出。这是微调的舒适区。而注入新的知识、解决幻觉问题这是RAG的舒适区。两者不是互斥的但在大多数应用场景里RAG是性价比更高的起点。2. 从RAG到AI智能体为什么第一步是学会拆问题2.1 标准RAG的边界在哪里标准RAG看起来已经能解决很多问题了但只要你把它放到真实业务里很快就会发现它的边界。我做了一个模拟项目X的技术支持问答系统。一开始就是最标准的RAG架构文档切分、向量化、检索、拼接、生成。在演示环境里效果很好但放到真实使用中问题很快就暴露了。第一个问题是用户提问太复杂。“这个功能在A版本里怎么用如果数据量超过一万条会不会卡顿和B方案比有什么优劣”这类问题包含多个维度单次检索根本无法找到能覆盖所有维度的文档片段。标准RAG只能拆成一句话去检索召回回来的内容往往只覆盖了问题的一个侧面。第二个问题是灵活调用工具的缺失。用户问“帮我查一下最近一周的日志中出现了多少次登录失败”这根本不是检索文档能解决的问题。但一个智能体可以调用日志查询接口、写代码分析、汇总结果这是RAG之外的能力。第三个问题是多轮对话中的记忆碎片化。标准RAG对每轮问题都是独立处理的上一轮提到的信息不会延续到下一轮的检索中。当用户说“刚才那个方案再详细说说”的时候系统根本不知道“那个方案”指什么。这些边界的本质是因为标准RAG是一个“单步”过程一次检索、一次生成、给出答案。而真实世界的复杂问题往往需要“检索—思考—再检索—再思考”的循环。2.2 AI智能体的核心能力拆解AI智能体Agent之所以能打破RAG的天花板是因为它拥有三个标准RAG不具备的能力。规划能力。当用户抛出一个复杂问题的时候Agent不是急着去检索而是先把问题拆解成子任务。比如刚才那个多维度问题它可以规划成三步先检索A版本的操作文档再检索性能相关的说明最后搜索B方案的对比资料。这种分解-执行-汇总的模式是标准RAG做不到的。工具调用能力。Agent可以调用外部工具——搜索引擎、数据库接口、代码解释器、API服务等等。这让它的能力边界从“读文档”扩展到了“操作世界”。实际上RAG本身就可以被看作是一种特殊的工具调用你把“检索知识库”封装成一个工具Agent在需要的时候主动调用它。记忆能力。Agent可以在执行过程中维护一个会话记忆。用户在前几轮对话里提到的偏好、术语、约束条件都可以沉淀到记忆里指导后续的检索和生成。这解决了标准RAG在多轮对话中的信息断裂问题。2.3 为什么我觉得“Agent化”是RAG的必然方向如果把RAG和Agent放在一起看会发现一个有意思的事实RAG其实是Agent的一个子集。Agent的“工具调用”天然可以包含“检索”“问答”“生成”而RAG只是其中一种工具化能力的实现形式。从我的实践经验看架构演进的路线很清晰。先做一个标准RAG观察它的失败案例。然后给系统加一个“判断器”让它能判断当前检索到的资料是否足够回答用户问题不够就重写查询再检索一次。接着再加一个“路由”让它能识别问题类型是知识问答、是数据分析、还是需要多轮检索的复杂问题每种类型走不同的处理流程。最后你会发现你已经不知不觉地在往Agent的方向走了。这其实就是Agentic RAG的最朴素形态让Agent来编排和控制检索增强生成的全流程。3. Agentic RAG的本质与几种主流范式3.1 重新定义Agentic RAG从“工具”到“编排”Agentic RAG说透了就是把RAG从“一个流程”变成“Agent手中的一把工具”同时引入一个能思考、能规划的编排者。传统的RAG是一个固定的流程输入问题检索生成结束。Agentic RAG则是一个自适应的系统Agent在理解用户意图之后做出自己的决策——需不需要检索检索什么用哪把工具去检索如果检索结果不够好要不要换个姿势再检索一次最终怎么利用检索结果来回答我更喜欢用项目经理来类比。传统RAG像一个只会照本宣科的资料员你问他问题他翻一页资料给你念一遍。而Agentic RAG是一个项目经理接到任务后会自己判断需要哪些资料、去什么渠道找、找到后怎么评估质量、抽取出来的信息怎么组织成一份合格的报告。在工程实现上Agentic RAG和传统RAG的最明显区别是引入了控制流——条件判断、循环、路由、工具选择。架构不再是一条直线而是一棵树甚至一张图。3.2 范式一基于路由的RAG最简单的Agentic RAG范式是在检索之前加一个路由层。这个路由层本身可以是一个LLM调用也可以是一个轻量级的分类模型。它判断用户问题属于什么类型然后决定走哪条处理管线。常见的有这几类路由一种是知识库问答路由。问题涉及具体业务知识走标准RAG管线。一种是通用对话路由。问题是闲聊或者简单咨询不需要检索直接让模型泛化回答即可。一种是计算类路由。问题需要做数据分析或数学运算走代码解释器工具。一种是搜索类路由。问题涉及实时信息走Web搜索API。我在项目里用LLM做路由判断效果比关键词规则好很多。LLM在理解用户意图方面有天然优势即使问题表述模糊也能做出相对合理的路由选择。路由的价值在于分流它保证不同类型的请求不互相干扰同时为后续的扩展留下空间。新加一类工具只需要增加一个路由分支。3.3 范式二带自我反思的检索循环这一层比路由更进了一步。系统不是“检索一次就结束”而是在检索之后增加一个评估环节判断检索到的内容是否真的足够回答问题。我自己实践过的一种模式是这样的第一步执行一次标准检索。第二步让一个“评估者”LLM判断召回文档是否与用户问题相关是否包含了足够的信息。如果判断结果是否定的进入第三步。第三步根据当前情况重写用户的原始查询比如增加关键词、明确限定条件、补充同义表述然后重新去检索。第四步重复评估如果还不行再重写、再检索。最多循环N次防止死循环。第五步把多次检索的结果合并去重一起交给生成器。这个模式看起来简单但它很好地解决了标准RAG最头疼的一个问题用户问法跟文档表述不一致的时候一次检索往往召不到正确内容。通过自我反思和查询重写相当于让系统自己调整搜索策略。这种范式在学术界有个对应的概念叫Self-RAG它更进一步让模型在生成阶段逐段判断哪些检索片段跟当前生成内容相关并动态决定是否检索。工程上实现起来要复杂一些但核心思路是一致的把决策权交给系统自身在动态中优化。3.4 范式三多智能体协作模式当你面对的检索需求更复杂比如既要从内部知识库查资料又要查实时数据还要做交叉比对单一Agent就会显得吃力。这时候可以拆成多个Agent每个负责一块职能。在模拟项目X的升级版里我用过一个三Agent架构检索Agent负责在向量库里查询相关文档分析Agent负责对检索结果做深度分析和对比验证Agent负责检查分析结果是否有依据、是否自洽。用户的问题先由主Agent规划拆解分发给各个子Agent最后收集结果统一输出。这个架构的优点是每个Agent的职责单一Prompt可以写得非常精确系统行为也更可控。缺点是实现复杂度高Agent之间的通信、结果合并、冲突消解都需要额外设计。对我个人来说多Agent更适合团队协作和企业级应用个人项目从单Agent起步会更务实。3.5 三种范式的选型思路我遇到过很多人在选型时纠结不知道怎么选。根据我的经验可以按以下思路来判断。项目刚起步验证阶段先用标准RAG就够了。当标准RAG出现明显的失败案例比如多类问题混在一起答不对的时候加上路由层。当用户提问措辞多样、召回率偏低的时候引入自我反思循环。当任务真的需要多类工具交叉配合、结果需要多方验证的时候再考虑多Agent架构。选型的基本原则是架构的复杂度应该跟问题的复杂度匹配不要为了Agent而Agent。很多项目在路由加反思这个层级就已经能覆盖绝大部分真实需求了。4. 三小时落地一个Agentic RAG实战4.1 技术栈选型与工作流设计理论讲再多不动手始终隔着一层。我基于上面的反思循环模式做了一个完整的Agentic RAG Demo总体感受是“原理听起来不难但每一步都有细节坑”。技术栈选型如下语言用Python理由是AI生态最完善调试方便。向量数据库用轻量级的本地方案方便演示数据量大了可以无缝切换到服务端版本。Embedding模型用一个开源的中文向量模型对中文支持友好。LLM主模型可以用通用模型也可以用本地部署的开源模型。工具类方面用LangGraph用来编排Agent工作流它天然支持图结构流程特别适合描述带条件分支的Agent行为。我选择LangGraph还有个重要原因它能把“检索—判断—重写—再检索”这个循环结构清晰地表达出来。每一轮循环都是一个节点每条判断都变成一条边整个流程的每一步都是可见、可控、可调试的。4.2 第一步把“知识库”先跑起来知识库部分没有什么特殊之处就是标准的向量化流程。我整理了模拟项目X的十几份技术文档总共一百多个页面包括用户手册、API参考、部署指南、常见故障排查表。文档处理的核心是切分。我用了标题感知的切分器先按层级标题把文档切成大块再对超过长度上限的块做二次切分。这样既能保证每个Chunk在语义上是完整的又能控制块大小。为了验证切分的效果我记录了一个小实验。用一套包含50个问题的验证集去测试不同切分策略的召回效果。纯字符切分的方式召回准确率大概在六成标题感知切分方式召回率能提升到接近八成。这说明切分策略对检索质量的影响非常直接。向量化完成之后知识库部分就绪。这一步如果只是搭一个标准RAG到这里就可以直接接LLM生成答案了。但在Agentic架构下知识库只是Agent可调用的一个工具——我给它起名叫“知识库查询工具”Agent可以在任何阶段按需调用它。4.3 第二步用LangGraph搭出“反思-重写-再检索”循环这个循环是整个Demo的核心。我用LangGraph定义了四条主要的执行路径。第一条路径初始检索路径。收到用户问题后先用原始问题执行一次检索把检索结果交给评估节点。第二条路径评估判断路径。评估节点用LLM判断召回的文档是否真正覆盖了问题答案。如果覆盖直接走“生成答案”路径如果没覆盖走“查询重写”路径。第三条路径查询重写路径。重写节点根据评估结果对用户的原始问题进行改写。改写有两个方向一是补充细节让问题更具体二是抽象泛化扩大匹配范围。改写完成后重新走回初始检索路径。第四条路径生成答案路径。当评估节点判定检索结果合格或者循环次数达到上限时把所有召回文档汇总交给生成节点产出最终答案。我设定了最大循环次数为3次。第一个实际教训就是没有循环上限的Agent会在检索不到内容时无限循环而且LLM调用是有成本的每多循环一次都是一笔真实的花费。下面是核心的流程代码忽略具体工具封装聚焦逻辑骨架from langgraph.graph import StateGraph, END from typing import TypedDict, List class AgentState(TypedDict): question: str rewritten_question: str documents: List[str] loop_count: int answer: str def retrieve(state: AgentState): # 用当前问题原始或重写后的查询向量库 query state.get(rewritten_question) or state[question] docs vector_db.search(query, top_k5) return {documents: docs, loop_count: state[loop_count] 1} def evaluate(state: AgentState): # 评估器LLM判断文档是否足够回答用户问题 prompt build_eval_prompt(state[question], state[documents]) verdict llm.invoke(prompt) # 返回 SUFFICIENT 或 INSUFFICIENT return {route: verdict} def rewrite_query(state: AgentState): # 查询重写器LLM根据失败原因重写问题 prompt build_rewrite_prompt(state[question], state[documents], state[loop_count]) new_query llm.invoke(prompt) return {rewritten_question: new_query} def generate_answer(state: AgentState): prompt build_answer_prompt(state[question], state[documents]) answer llm.invoke(prompt) return {answer: answer} # 构建状态图 workflow StateGraph(AgentState) workflow.add_node(retrieve, retrieve) workflow.add_node(evaluate, evaluate) workflow.add_node(rewrite, rewrite_query) workflow.add_node(generate, generate_answer) workflow.set_entry_point(retrieve) workflow.add_edge(retrieve, evaluate) workflow.add_conditional_edges( evaluate, lambda state: state[route], { SUFFICIENT: generate, INSUFFICIENT: rewrite } ) workflow.add_edge(rewrite, retrieve) workflow.add_edge(generate, END)这段代码的精髓在条件边。LLM评估器返回一个路由信号这个信号决定系统是继续检索、还是改写后重试、还是直接生成答案。这种“动态路由”就是Agentic RAG与普通RAG在流程控制层面的分水岭。4.4 第三步写评估器和查询重写器的PromptAgentic RAG里最容易被低估的是Prompt工程。评估器的Prompt尤其重要因为它决定整个循环是否有效也直接关系响应延迟。我实验出来的评估Prompt结构是这样的先给系统角色设定告诉它是“一个严谨的文档质量评估员”然后给出用户原始问题和召回文档最后让模型用JSON格式输出判断结果包含一个布尔字段和一个解释字段。实际踩坑提醒如果你只让模型输出“是”或“否”模型的准确率会非常不稳定。加了“解释理由”的要求之后评估准确性明显提升。原因是要求模型解释理由会触发它更仔细地审视证据也就是我们常说的“思维链”效应。查询重写器的Prompt同样关键。重写方向取决于失败原因必须把评估器给出的失败原因告诉重写器。比如原因是因为问题太泛、关键词太少重写器就应该往“增加限定词”方向改写如果原因是因为文档用词与问题不匹配重写器就应该尝试近义词和更宽泛的表达。这两个Prompt加起来不需要太长各两百字左右但一定要把“用户意图”放在核心位置。模型一旦理解用户到底想找什么改写出来的查询质量会完全不同。4.5 实测表现从小翻车到稳定输出Demo搭建完成后我拿之前准备的50个验证问题跑了一轮测试。说直白一点第一次全量测试的结果并不理想准确率只比普通RAG高了一点点。排查之后发现主要问题出在评估器过于苛刻。评估器频繁判定文档“不足”导致大量问题走上了重写循环而重写后的查询往往扩大了范围召回了更多无关文档反而降低了答案准确率。解决方法是调整评估器Prompt的判断标准把“必须包含完整答案”改成“是否包含回答该问题所需的相关信息”。这两个标准看起来差不多实际效果差异巨大。前者要求太高几乎每个检索结果都会被判定不合格后者更贴近人类的信息获取习惯允许部分信息缺失只要大方向对就行。调整之后准确率明显提升。我统计了一下在五十个问题里一次性通过评估的占比六成多走了一次重写后成功的占比两成多重写两次以上才成功的占一成左右。这个分布很健康说明循环机制确实在发挥作用而不是摆设。给一个不完全严谨但很直观的性能参考值未命中一次检索单轮响应时间大概1到2秒走一次重写和二次检索耗时大约翻倍到3到4秒再走一次重写会到5秒以上。这个延迟在演示环境还可以接受但如果做生产系统要特别注意在不同轮次给用户提供“正在思考”的交互反馈不要让用户觉得卡死。5. 我踩过的那些细节坑与排查技巧5.1 召回质量差的常见原因排查表无论是标准RAG还是Agentic RAG最终的上限都取决于检索质量。以下是我在多个项目里反复踩过的高频问题整理成表格方便对照排查。现象可能原因排查思路解决方案检索结果与问题完全无关切分粒度过大语义被稀释查看召回文档原文缩小切分大小按段落语义边界切分相关文档明明存在但没被召回用户用词与文档用词不一致检查Embedding在相似词上的表现增加查询重写机制引入同义扩写多个文档内容重复、互相干扰文档间存在大量重叠内容检查来源文档结构建立索引时做去重检索时引入MMR最大边际相关性召回结果单薄、支撑力不足K值太小统计单个问题命中的有效片段数适当增大K值并增加重排环节代码类问题问答质量差代码切分破坏了语法结构查看切分后的代码块对代码文件单独设置切分规则按函数/类边界切分多轮对话中上下文丢失没有做会话记忆管理查看传给LLM的完整Prompt增加对话摘要机制提取关键约束加入检索查询MMR这个技巧值得单独说一下。普通相似度检索容易返回一堆内容高度相似但信息冗余的文档MMR在相关性基础上引入了多样性惩罚会让检索结果在“相关”和“多样”之间取得平衡。当你发现多个召回文档总是在重复同一段内容时考虑加MMR。5.2 循环机制失控的防护和成本控制Agentic RAG引入循环之后最大的风险就是成本失控。我见过不止一次“Agent陷入无效检索循环”导致账单飙升的情况这个必须从设计层面做防护。循环次数上限是底线把上限压在三次以内比较合理。三轮回溯还找不到内容说明要么知识库根本没有答案要么问题本身与知识库偏差太远继续循环只是浪费。超时熔断机制也很必要。给整个Agent工作流设置一个总超时时间例如15秒超过就直接返回部分结果或友好提示。真实世界的LLM响应时间波动较大不能假设每次调用都能在预期时间内返回。成本监控要从项目一开始就建立。记录每次检索和每次LLM调用的token消耗按会话维度汇总。我自己的习惯是在每个会话结束的时候打印一份本次调用统计检索次数、LLM调用次数、总耗时。这样做的价值在项目后期非常明显你能定位到某个问题类型为什么格外耗钱。5.3 Embedding模型与LLM的搭配心得很多人忽视Embedding模型和LLM之间的“匹配度”问题。实际操作中发现召回逻辑和生成逻辑对同一种表达方式有不同的偏好。Embedding模型擅长理解语义接近但字面不同的表达但它对“提问意图”和“陈述句答案”之间的匹配并不总是可靠。比如用户问“怎么解决卡顿”文档里写的是“性能优化方法”语义上是同一回事向量距离却不近。这时查询重写就该发挥作用把“怎么解决卡顿”改写成“性能优化 卡顿 处理方案”匹配概率就大得多。LLM对上下文非常敏感即使召回的文档高度相关如果Prompt结构混乱模型也可能抓不住重点。我的经验是把检索到的文档放在Prompt的中后部用户原始问题放在最后用分隔符明显区分让模型先读资料再回答问题生成质量会稳定很多。5.4 从Demo到生产环境还差多少很多人会在Demo验证成功之后开始规划生产化我在这个阶段也吃过亏。首当其冲的是文档的增量更新。Demo里知识库是静态的一次性构建索引就完事了。真实业务里文档是持续更新的今天改了一版手册明天加了一份新产品的资料系统都需要及时感知。工程上需要建立文档更新管道包括监控源文件变更、触发增量向量化、更新索引版本。如果更新不及时用户会不断问“为什么我昨天上传的资料系统不认识”。然后是权限控制。真实企业场景里不是所有用户都有权限查看所有文档。知识库问答如果需要做权限过滤必须在检索阶段就考虑权限约束而不是生成阶段再做过滤。比如某类机密文档只能在用户身份被验证之后才允许进入检索范围。这个设计要尽早做等上线后再补改动成本非常大。最后是可观测性和效果评估。生产环境需要一套完整的指标监控体系至少要覆盖以下指标检索命中率指检索出的文档包含有效答案的比例、端到端答案准确率、平均响应时间、不通过评估的循环率、单会话成本。搭建一套好用的评测集是Agentic RAG项目从“能跑”走向“好用”的第关键一步。我习惯每周跑一遍评测集任何Prompt调整或参数变更都先在评测集上验证效果而不是拿线上用户当小白鼠。6. 关于未来方向的一点个人看法写到这里整条从RAG到Agentic RAG的路径已经梳理完了。按照我个人目前的实践体会最后再分享三个方向上非常值得深入的内容也算是给自己后续工作留一个备忘。第一个方向是评估体系的自动化。Agentic RAG系统结构复杂、状态空间大传统的离线评测方式已经不太够用了。我认为“基于LLM的自动评测器”会是这个领域的刚需——它能根据一段标准答案自动评判模型输出质量可以大规模跑评测集。我后续想把它整合进CI流程每次改完Prompt或架构自动跑评测并出报告效果会非常直观。第二个方向是ReWOO模式的引入。ReWOO的意思是“Reasoning WithOut Observation”核心思路是把Agent的推理过程与外部工具调用过程解耦。决策路径先由规划器一次性生成然后并行执行工具调用最后汇总结果。相比当前的“每走一步就调用一次LLM”的模式ReWOO能显著降低调用次数进而减少延迟和成本同时保持强大的问题解决能力。第三个方向是训练专门的检索评判模型。目前评估环节用的是通用LLM调用成本高、速度慢。如果能用开源模型做一个专门做检索质量评估的轻量模型部署成本会大幅下降评估响应速度也会从数秒降到数十毫秒。这个方向对小规模个人项目尤其有意义。RAG、AI智能体和Agentic RAG本质上都是在解决同一个问题怎么让大模型在真实世界里更可靠、更有用。从一条直线到一张网络从单次检索到动态循环这个演进过程本身就是应用AI的思维方式在升级。希望这篇文章能帮你少踩一些我踩过的坑更快地走到属于自己的Agentic应用面前。