写这篇的时候我刚从一个大半年的Agent落地项目里抽身出来。最近经常有人问我RAG是不是快过时了大家都在搞Agent是不是直接学Agent就行这个问题本身就带着一个误判。我做了这么多项目后反而越来越确信一件事——RAG没有过时它只是被Agent吸收进去了。更直白地说你看到的大多数所谓Agent架构一半的复杂度都藏在RAG背后。这一篇我想把“从RAG到Agent”这条演进路径掰开揉碎讲清楚。重点不是让你再背一遍RAG流程而是搞清楚两件事第一检索增强和行动决策是怎么融合的第二融合之后边界到底在哪里。这两点搞明白了你才算真正迈过Agent架构师这道门槛。1. 从RAG谈起检索增强到底解决了什么问题1.1 大模型的“知识僵局”与RAG的破局思路先把时间拨回RAG刚火的那阵子。大模型参数越训越大能力越来越强但有一个问题始终绕不开它的知识被锁死在训练数据里。你问它今年公司的内部报销流程怎么走它不知道你问它某款产品的最新规格参数它的回答可能停留在两年前的版本。更麻烦的是它还能一本正经地编出看似合理的答案这就是幻觉。RAG解决的就是这件事。它的思路说起来很简单模型不知道的知识你去外部知识库里查查到以后把相关内容塞进Prompt里让模型看着资料回答。这就像你让实习生写行业分析报告不指望他脑子里什么都有而是给他一摞最新的参考资料让他照着写。但我想强调一个很多人忽略的点RAG本质上是个“只读系统”。它把知识检索出来交给模型做阅读理解最终输出一段话。它从头到尾没有改变环境里任何东西——不提交订单、不发送邮件、不修改配置。它是一个优秀的“知识外挂”但它不是一个“行动者”。1.2 索引、检索、生成RAG链路里三个关键环节RAG的标准链路业内通常切成三段索引构建、检索召回、生成回答。每一段都有讲究我一个个说。索引构建阶段核心是文档切分和向量化。文档切多碎直接决定检索粒度——切太粗一块内容几千字向量化后语义被稀释召回结果不精准切太细语义可能被打散上下文不连贯。我在项目里常用的经验是结构化文档按章节或段落切非结构化文本按300到500字切同时保留20%的窗口重叠避免关键信息刚好被拦腰截断。向量化这一步中文场景下我踩过不少坑直接用开源Embedding模型跑中文效果参差不齐需要针对业务语料做微调否则检索质量很难上去。检索召回阶段最朴素的做法是算向量相似度取Top-K。但后来大家发现光靠向量不够关键词匹配、BM25这类稀疏检索能补足精确名词匹配的短板于是有了混合检索。再后来重排模型出场——先粗召回上百条候选再用交叉编码器精排取最相关的几条进上下文。这里有一个容易被忽略的指标命中率也就是相关文档是否成功出现在召回列表里。很多项目上线后效果差第一件事就该查这个数而不是抱怨大模型理解能力不行。生成阶段核心是上下文组织和Prompt约束。检索回来的内容不能一股脑全塞进去要在Token预算内做取舍还要防Prompt注入——恶意文档内容可能在检索后被模型当成指令执行这个问题在Agent场景会被进一步放大后面会细讲。1.3 RAG的边界能答得准不代表能做得到把RAG做到极致你会得到一个什么样的系统一个检索精准、回答流畅的企业知识问答机器人。你问它“销售合同里甲方逾期付款的违约金比例是多少”它能把条款原文翻出来精确到小数点后两位。但如果你问它“帮我给违约的客户发一封催款函并在系统里把这笔订单标记为逾期”它就傻了。为什么因为第二个问题需要的不是检索而是行动——要调合同数据、要生成函件、要操作业务系统、要在执行前确认权限和风险。这些动作RAG一个都做不了。这就是我理解的第一个边界RAG负责“知道”不负责“做到”。知道和做到之间隔着一整个Agent层。2. Agent的登场从“知道”到“做到”2.1 ReAct循环推理、行动、观察的交替Agent和普通聊天机器人的本质区别在于它具备行动闭环。我接触过的Agent框架底层核心几乎都绕不开ReAct模式——Reasoning和Acting交替进行。模型先分析当前状态决定要调用什么工具然后执行工具拿到结果后再次推理直到完成目标。这个过程可以用你做菜来类比。你不会一口气把菜谱背完再动手而是边做边看——锅里冒烟了你判断要关小火盐放少了你补一勺尝一口熟了你装盘出锅。每一步都是推理、行动、观察的循环。Agent干的就是这件事只不过它观察的对象不是锅里的菜而是工具调用返回的数据。2.2 Agent的五大核心组件规划、记忆、工具、行动、反思从业者视角看Agent架构我习惯把它拆成五个组件缺一个都不完整规划能力负责把大目标拆解成子任务。比如“帮我订一张去北京的高铁票”规划层要拆成查询车次、比较时间、选择车票、提交订单、确认结果五个步骤。记忆系统又分短期和长期。短期记忆是当前任务上下文长期记忆则负责跨对话沉淀用户偏好和业务知识。这一块后面会专门讲因为它和RAG的关系最深。工具层是Agent的手脚。一个Agent能干什么事取决于它接了哪些工具。搜索、数据库查询、订单提交、邮件发送每接一个工具就多一分能力也多一分风险。行动执行是规划落地的过程。框架负责调用工具API解析返回结果处理异常。这里面有大量工程细节比如超时重试、错误恢复、并发控制。反思机制让Agent在行动失败或结果不理想时能自我修正。我在项目里最常用的策略是给Agent配一个回顾步骤“上一次尝试结果如何是否需要调整策略”。这个机制对复杂任务尤其重要否则Agent会在同样的问题上反复撞墙。2.3 Agent是系统工程不是模型能力有一个误解必须澄清很多人一提到Agent就以为选个聪明的大模型就够了。实际上Agent的效果上限由模型决定但效果下限由工程决定。同样是GPT级别的模型有人搭出来的Agent像自动驾驶有人搭出来的像遥控玩具差距几乎全在架构上。工具选型、记忆管理、上下文窗口裁剪、错误处理、安全护栏、评测机制每一项都是实打实的工程活。我甚至见过同一个模型在A团队手里任务成功率80%在B团队手里只有30%就是因为B团队跳过了反思机制也没有做工具调用的异常兜底。所以Agent架构师这个角色本质是系统工程架构师不是模型调参师。3. RAG与Agent的四种融合模式3.1 模式一RAG工具化——把知识库封装成Agent的SkillRAG与Agent最直观的融合方式就是把RAG链路封装成一个工具交给Agent调度。Agent接到用户问题后先判断“这个问题需不需要外部知识”如果需要就调用知识检索工具拿到相关资料后再结合工具返回内容继续推理。这种融合模式里RAG是Agent的一个能力单元。在多Agent系统里这个知识检索能力可以单独抽成一个子Agent负责“知识问答域”。其他业务Agent需要资料时直接问它要。这就像公司里配了一个情报分析员业务部门有疑问就发工单给他他查完资料把结论返回。我见过一个在线教育项目这么落地课程推荐Agent主攻用户意图分析和推荐策略课程知识库Agent负责检索课程大纲、教师背景、学员评价。用户问“零基础能不能学Python数据分析”推荐Agent先找知识库Agent拿课程详情再结合用户画像做推荐。两个Agent各管一摊职责清晰效果比单Agent硬扛好得多。3.2 模式二Agentic RAG——让检索本身具备决策能力传统RAG有一个明显的机械感不管什么类型的问题检索策略一模一样。但真实场景里有的问题需要精准匹配条款原文有的问题需要对比多份文档有的问题明面上问的是A实际上要查的是B。这时候固定流水线式的RAG就不够用了于是有了Agentic RAG。Agentic RAG的核心理念是把检索链路改造成一个可决策的过程。系统先判断问题类型决定用向量检索、关键词检索还是混合检索如果第一次召回结果不理想自动重写查询词再召回一次如果问题涉及多个方面主动拆成多个子查询分别检索后汇总。整个过程由Agent逻辑编排而不是写死的代码流水线。我做一个法律问答项目时感受特别深。用户问“年终奖争议的仲裁时效是多久”常规RAG只搜“仲裁时效”结果返回一堆不相关内容。Agentic RAG会先识别出“年终奖”“劳动仲裁”“时效”三个子主题分组检索再汇总回答质量立刻上了一个台阶。3.3 模式三记忆即检索——用RAG实现Agent的长期记忆Agent的长期记忆怎么存一直是个难题。直接把对话历史全存下来很快塞爆上下文窗口只存摘要又丢失了细节。我见过不少团队用RAG的思路解决记忆问题效果不错。具体做法是每个对话轮次或业务交互结束后把关键信息抽出来向量化存进记忆库。新会话开始时Agent先把当前用户的问题向量化在记忆库中召回相关历史记忆再开始推理。这样Agent能记住“用户上次说预算不超过五千”“上个月合同编号是CT-2024-0817”这类细节越用越像了解你的助理。这里要特别提一下记忆安全。社区里有个概念叫A-MemGuard专门做LLM Agent记忆的主动防御。原理很简单但很管用写入记忆库之前先过一遍敏感信息检测和内容审计防止隐私数据、错误结论、甚至恶意注入的脏数据被长期固化。我接手过一个客户项目Agent记忆库里存了一条用户被诱导输入的恶意指令导致后续每次对话都被带偏排查了很久才定位到根因。从那以后我再也没跳过记忆安全审计这一步。3.4 模式四从GraphRAG到Ontology RAG——知识结构决定决策质量向量检索是语义层面的模糊匹配擅长处理“意思相近”的内容但处理不了“关系复杂”的内容。比如“这个产品的所有下游依赖组件清单”向量检索很难给出准确答案因为答案藏在知识图谱的结构里。GraphRAG的思路是把实体和关系抽取出来构建知识图谱检索时沿着图结构做遍历和推理。到了Ontology RAG再进一步——不只建图谱还定义领域本体明确实体类型、属性、关系约束让机器真正理解知识的结构化含义。这一层融合对Agent的意义非常大。Agent做决策时需要的往往不只是“一段相关文本”而是“一套结构化的业务规则与关系链”。我在工业制造项目里做过一个案例设备故障诊断Agent接上了Ontology RAG故障现象、零部件、维修方案之间的关联关系全都结构化存好。Agent拿到故障描述后能在知识图里快速定位可能相关的零部件和历史上的维修记录诊断效率和准确度都远非传统RAG可比。4. 融合的边界谁负责读谁负责做4.1 一张表看懂RAG系统与Agent系统的架构差异很多新手容易把二者的边界模糊化。我画过一张对比表每次分享都先给大家看这个对比维度RAG系统Agent系统核心目标提供有依据的答案完成复杂的任务闭环系统闭环读知识、答问题感知、决策、行动、观察对外影响只读环境不改状态可调用工具改变系统状态上下文来源检索到的外部文档记忆、工具返回、环境状态失败模式答不准、检不到行动中断、决策错误、误操作评测重点命中率、准确性、忠实度任务成功率、效率、安全合规看这张表就明白了RAG系统再复杂它还在“读”的范畴里Agent系统一旦接了工具、能改状态就进入了“做”的范畴。“做”和“读”的风险等级完全不同。4.2 Skill、Harness、Agent三个容易混淆的层级边界社区里经常有人问skill和agent的区别、harness和agent的区别。我在实际架构中是这样划分的Skill是能力的最小单元。一个“查询订单状态”的函数是Skill一个“生成催款函”的流程也是Skill。它本身没有自主决策能力但它是Agent唯一能干活的途径。没有SkillAgent就是光说不练的嘴炮。Harness是Agent的运行时环境我习惯叫它“执行鞍具层”。它负责工具调用调度、上下文管理、错误恢复、跟踪记录、权限校验。你可以把Harness理解成舞台Agent是台上的演员Skill是演员手中的道具。再好的演员舞台搭得烂也演不出好戏。Agent则是决策主体。它定义目标、制定计划、使用Skill、响应观察结果。多个Agent协作时还会涉及通信协议和任务分配。这三层边界很实用每次方案评审我先问清楚你改的是Skill、Harness还是Agent逻辑层次一分明架构就不会乱。4.3 架构决策清单什么场景用RAG什么场景上Agent这是我的核心方法论也是最想让你带走的部分。接到一个需求先不要急着上Agent按这个清单过一遍。问题只要求“准确回答”吗如果是纯RAG就够了。比如“员工手册里年假怎么算”检索增强问答完全可以胜任强行加Agent反而引入不必要的不确定性。问题必须“操作业务系统”吗需要改状态、调接口、发消息那就要上Agent因为Agent才有行动层。问题依赖多步推理和工具组合吗比如“对比三个供应商报价并给出推荐还要把推荐理由写成邮件草稿”——纯RAG做不到需要Agent拆解任务、多次调用外部工具。问题依赖长期用户记忆吗跨会话记住用户偏好那就必须在Agent架构里设计记忆层记忆的存取大量用到RAG检索能力。场景对失败容忍度有多高金融交易、医疗诊断、自动化发单这类高风险场景无论技术多先进都要人工审核兜底。宁慢勿错。每次我评审别人的架构方案都会拿这份清单过一遍。很多项目失败的原因不是技术选型不对而是根本没想清楚当前需求到底处在“读”的层次还是“做”的层次。4.4 边界模糊时的典型信号还有一类场景需求本身既包含读也包含做边界模糊。这时候有几个信号可以帮你判断该往哪边偏。第一个信号是检索命中率漂移。知识库内容更新后命中率不升反降说明固定切分策略不再适配新文档结构这时候需要Agentic RAG的主动适配能力而不是继续死磕向量化参数。第二个信号是工具幻觉。Agent在决策时调用了根本不存在的工具参数或者生成了和业务规则矛盾的指令。这是典型的Agent行动层问题不是RAG知识层问题。排查方向要转向工具定义规范和调用约束而不是去扩充知识库。第三个信号是执行中断。Agent运行时报错终止最常见的一句话是agent execution terminated due to error。我会在下一章详细说这个问题的排查路径。5. 工程落地中的常见问题与排查实录5.1 “Agent execution terminated due to error”的定位三板斧这是我被问得最多的问题也是最让人抓狂的问题。Agent跑着跑着突然中止错误信息不足以定位根因项目群里一片哀嚎。我的排查三板斧是第一板斧查日志分层。Agent执行链路有规划日志、工具调用日志、上下文日志三个层次先确认是哪一层报错。规划层报错通常是模型收到了非法格式输入工具层报错是API超时、参数校验失败或权限不足上下文层报错一般是上下文窗口溢出。分层定位后至少能甩掉三分之二的干扰项。第二板斧看状态清理。很多所谓“终止”不是真实系统错误而是上一轮运行留下的脏状态——全局变量残留、缓存数据过期、跨Agent消息积压。我在一个多Agent协同项目里就遇到过这种情况两个Agent的会话上下文被复用串联了后一个Agent读到前一个Agent的中间结果逻辑瞬间混乱直接中断。每次任务开始前做状态隔离和清理这个习惯能省很多半夜抓头发的时间。第三板斧抓完整原始输出。很多Agent框架默认只记录最终结果中间过程全部丢弃。这是排查的致命伤。正确做法是在开发和预发环境里把每次规划推理的完整输出、工具入参和出参全部持久化。不管排查什么问题完整轨迹一拉根因基本无处遁形。5.2 评测指标组合Hit Rate只是起点如果从零搭一个RAG或Agent项目我建议第一天就把评测体系搭起来不要等开发得差不多了再补。很多团队陷入无休止调参就是因为没有量化的反馈全靠肉眼感觉。对RAG层至少要看三个数据命中率核心文档是否被成功召回忠实度大模型有没有忠实基于检索内容回答而不是自由发挥上下文利用率召回的段落里有多少真正被最终答案用到。我的经验是上下文利用率低往往比命中率低更危险说明检索召回了大量垃圾内容模型只能硬着头皮从噪声里挑答案。对Agent层只看检索指标远远不够还要看任务成功率、工具调用准确率、平均完成步数、异常中断率、人工干预率。我做的项目里最看重的是人工干预率——系统自动跑不动、需要人介入处理的任务占比。如果一个Agent系统的人工干预率超过30%它还没到放心交出去的状态。5.3 一个本地ERP产品检索的落地实例前面讲了不少抽象架构这里给一个具体的落地案例。某制造企业想把产品检索做成智能问答接上本地ERP系统。技术栈选了.NET生态框架用了Semantic Kernel。落地路径是这样的先把ERP里的产品主数据、库存状态、定价规则抽出来构建本地知识库按产品线切分索引。RAG检索部分封装成Semantic Kernel的Plugin暴露给Agent调用。Agent负责解析用户问法比如用户说“A型电机还有多少库存价格最近有变动吗”Agent先调库存查询Plugin、再调价格历史Plugin最后汇总成回答。这个过程中我发现一个重要的教训ERP字段含义和业务口径必须沉淀进知识库否则Agent看不懂系统返回的字段。比如ERP里库存有一条“IN_TRANSIT”状态字段业务上它意味着采购在途、已锁定预留给某订单。你不把这个口径写进知识库Agent可能直接把在途库存当成可用库存报给用户后果就是订单超卖。所以本地ERP加RAG加LLM的项目同步梳理业务口径字典优先级和主链路开发一样高。5.4 Agent架构师学习路线与面试高频考点最后聊一下能力成长。现在很多人问Agent架构师的学习路线我的建议是先夯实RAG基础再上Agent架构顺序不能乱RAG是Agent的知识底座。单纯背Agent概念、抄一套框架Demo上手做项目基本一击即溃。我乐意推荐的路径是第一步吃透RAG全链路能做到自己搭一套可靠的企业知识问答系统第二步掌握Agent核心组件用主流框架完整跑通一个工具调用项目第三步深入研究记忆系统和检索决策把Agentic RAG吃透第四步开始设计多Agent协作架构理解Skill、Harness、Agent的分层边界第五步研究安全与评测建立自己的工程方法论和避坑清单。面试方面的高频考点我总结过一份问题和考点大概是这样RAG检索质量差怎么优化考混合检索和重排的理解Agent怎么让模型不跑偏考系统提示词和上下文管理Agent记忆是怎么设计的考长期记忆与短期记忆的架构能力多Agent之间怎么协作考通信协议和任务编排Agent上线后误操作怎么防考权限收敛和人工审核机制RAG命中率低怎么排查考拆解定位能力。最后说点个人体会。这个系列写到这里我最大的感触是RAG和Agent不是替代关系是演进关系。RAG把大模型从“闭卷考试”变成“开卷考试”Agent又把开卷考试变成了“项目执行”。前者解决知道的问题后者解决做到的问题。一个稳定的Agent架构永远是你中有我——知识层用RAG的力量决策层用Agent的框架中间靠一套清晰的边界把两者缝合。踩过几次坑之后你会明白真正难的不是技术本身而是守住边界。该读的地方读扎实该做的地方做果断不越界不欠位Agent系统就不会差到哪里去。
写这篇的时候我刚从一个大半年的Agent落地项目里抽身出来。最近经常有人问我RAG是不是快过时了大家都在搞Agent是不是直接学Agent就行这个问题本身就带着一个误判。我做了这么多项目后反而越来越确信一件事——RAG没有过时它只是被Agent吸收进去了。更直白地说你看到的大多数所谓Agent架构一半的复杂度都藏在RAG背后。这一篇我想把“从RAG到Agent”这条演进路径掰开揉碎讲清楚。重点不是让你再背一遍RAG流程而是搞清楚两件事第一检索增强和行动决策是怎么融合的第二融合之后边界到底在哪里。这两点搞明白了你才算真正迈过Agent架构师这道门槛。1. 从RAG谈起检索增强到底解决了什么问题1.1 大模型的“知识僵局”与RAG的破局思路先把时间拨回RAG刚火的那阵子。大模型参数越训越大能力越来越强但有一个问题始终绕不开它的知识被锁死在训练数据里。你问它今年公司的内部报销流程怎么走它不知道你问它某款产品的最新规格参数它的回答可能停留在两年前的版本。更麻烦的是它还能一本正经地编出看似合理的答案这就是幻觉。RAG解决的就是这件事。它的思路说起来很简单模型不知道的知识你去外部知识库里查查到以后把相关内容塞进Prompt里让模型看着资料回答。这就像你让实习生写行业分析报告不指望他脑子里什么都有而是给他一摞最新的参考资料让他照着写。但我想强调一个很多人忽略的点RAG本质上是个“只读系统”。它把知识检索出来交给模型做阅读理解最终输出一段话。它从头到尾没有改变环境里任何东西——不提交订单、不发送邮件、不修改配置。它是一个优秀的“知识外挂”但它不是一个“行动者”。1.2 索引、检索、生成RAG链路里三个关键环节RAG的标准链路业内通常切成三段索引构建、检索召回、生成回答。每一段都有讲究我一个个说。索引构建阶段核心是文档切分和向量化。文档切多碎直接决定检索粒度——切太粗一块内容几千字向量化后语义被稀释召回结果不精准切太细语义可能被打散上下文不连贯。我在项目里常用的经验是结构化文档按章节或段落切非结构化文本按300到500字切同时保留20%的窗口重叠避免关键信息刚好被拦腰截断。向量化这一步中文场景下我踩过不少坑直接用开源Embedding模型跑中文效果参差不齐需要针对业务语料做微调否则检索质量很难上去。检索召回阶段最朴素的做法是算向量相似度取Top-K。但后来大家发现光靠向量不够关键词匹配、BM25这类稀疏检索能补足精确名词匹配的短板于是有了混合检索。再后来重排模型出场——先粗召回上百条候选再用交叉编码器精排取最相关的几条进上下文。这里有一个容易被忽略的指标命中率也就是相关文档是否成功出现在召回列表里。很多项目上线后效果差第一件事就该查这个数而不是抱怨大模型理解能力不行。生成阶段核心是上下文组织和Prompt约束。检索回来的内容不能一股脑全塞进去要在Token预算内做取舍还要防Prompt注入——恶意文档内容可能在检索后被模型当成指令执行这个问题在Agent场景会被进一步放大后面会细讲。1.3 RAG的边界能答得准不代表能做得到把RAG做到极致你会得到一个什么样的系统一个检索精准、回答流畅的企业知识问答机器人。你问它“销售合同里甲方逾期付款的违约金比例是多少”它能把条款原文翻出来精确到小数点后两位。但如果你问它“帮我给违约的客户发一封催款函并在系统里把这笔订单标记为逾期”它就傻了。为什么因为第二个问题需要的不是检索而是行动——要调合同数据、要生成函件、要操作业务系统、要在执行前确认权限和风险。这些动作RAG一个都做不了。这就是我理解的第一个边界RAG负责“知道”不负责“做到”。知道和做到之间隔着一整个Agent层。2. Agent的登场从“知道”到“做到”2.1 ReAct循环推理、行动、观察的交替Agent和普通聊天机器人的本质区别在于它具备行动闭环。我接触过的Agent框架底层核心几乎都绕不开ReAct模式——Reasoning和Acting交替进行。模型先分析当前状态决定要调用什么工具然后执行工具拿到结果后再次推理直到完成目标。这个过程可以用你做菜来类比。你不会一口气把菜谱背完再动手而是边做边看——锅里冒烟了你判断要关小火盐放少了你补一勺尝一口熟了你装盘出锅。每一步都是推理、行动、观察的循环。Agent干的就是这件事只不过它观察的对象不是锅里的菜而是工具调用返回的数据。2.2 Agent的五大核心组件规划、记忆、工具、行动、反思从业者视角看Agent架构我习惯把它拆成五个组件缺一个都不完整规划能力负责把大目标拆解成子任务。比如“帮我订一张去北京的高铁票”规划层要拆成查询车次、比较时间、选择车票、提交订单、确认结果五个步骤。记忆系统又分短期和长期。短期记忆是当前任务上下文长期记忆则负责跨对话沉淀用户偏好和业务知识。这一块后面会专门讲因为它和RAG的关系最深。工具层是Agent的手脚。一个Agent能干什么事取决于它接了哪些工具。搜索、数据库查询、订单提交、邮件发送每接一个工具就多一分能力也多一分风险。行动执行是规划落地的过程。框架负责调用工具API解析返回结果处理异常。这里面有大量工程细节比如超时重试、错误恢复、并发控制。反思机制让Agent在行动失败或结果不理想时能自我修正。我在项目里最常用的策略是给Agent配一个回顾步骤“上一次尝试结果如何是否需要调整策略”。这个机制对复杂任务尤其重要否则Agent会在同样的问题上反复撞墙。2.3 Agent是系统工程不是模型能力有一个误解必须澄清很多人一提到Agent就以为选个聪明的大模型就够了。实际上Agent的效果上限由模型决定但效果下限由工程决定。同样是GPT级别的模型有人搭出来的Agent像自动驾驶有人搭出来的像遥控玩具差距几乎全在架构上。工具选型、记忆管理、上下文窗口裁剪、错误处理、安全护栏、评测机制每一项都是实打实的工程活。我甚至见过同一个模型在A团队手里任务成功率80%在B团队手里只有30%就是因为B团队跳过了反思机制也没有做工具调用的异常兜底。所以Agent架构师这个角色本质是系统工程架构师不是模型调参师。3. RAG与Agent的四种融合模式3.1 模式一RAG工具化——把知识库封装成Agent的SkillRAG与Agent最直观的融合方式就是把RAG链路封装成一个工具交给Agent调度。Agent接到用户问题后先判断“这个问题需不需要外部知识”如果需要就调用知识检索工具拿到相关资料后再结合工具返回内容继续推理。这种融合模式里RAG是Agent的一个能力单元。在多Agent系统里这个知识检索能力可以单独抽成一个子Agent负责“知识问答域”。其他业务Agent需要资料时直接问它要。这就像公司里配了一个情报分析员业务部门有疑问就发工单给他他查完资料把结论返回。我见过一个在线教育项目这么落地课程推荐Agent主攻用户意图分析和推荐策略课程知识库Agent负责检索课程大纲、教师背景、学员评价。用户问“零基础能不能学Python数据分析”推荐Agent先找知识库Agent拿课程详情再结合用户画像做推荐。两个Agent各管一摊职责清晰效果比单Agent硬扛好得多。3.2 模式二Agentic RAG——让检索本身具备决策能力传统RAG有一个明显的机械感不管什么类型的问题检索策略一模一样。但真实场景里有的问题需要精准匹配条款原文有的问题需要对比多份文档有的问题明面上问的是A实际上要查的是B。这时候固定流水线式的RAG就不够用了于是有了Agentic RAG。Agentic RAG的核心理念是把检索链路改造成一个可决策的过程。系统先判断问题类型决定用向量检索、关键词检索还是混合检索如果第一次召回结果不理想自动重写查询词再召回一次如果问题涉及多个方面主动拆成多个子查询分别检索后汇总。整个过程由Agent逻辑编排而不是写死的代码流水线。我做一个法律问答项目时感受特别深。用户问“年终奖争议的仲裁时效是多久”常规RAG只搜“仲裁时效”结果返回一堆不相关内容。Agentic RAG会先识别出“年终奖”“劳动仲裁”“时效”三个子主题分组检索再汇总回答质量立刻上了一个台阶。3.3 模式三记忆即检索——用RAG实现Agent的长期记忆Agent的长期记忆怎么存一直是个难题。直接把对话历史全存下来很快塞爆上下文窗口只存摘要又丢失了细节。我见过不少团队用RAG的思路解决记忆问题效果不错。具体做法是每个对话轮次或业务交互结束后把关键信息抽出来向量化存进记忆库。新会话开始时Agent先把当前用户的问题向量化在记忆库中召回相关历史记忆再开始推理。这样Agent能记住“用户上次说预算不超过五千”“上个月合同编号是CT-2024-0817”这类细节越用越像了解你的助理。这里要特别提一下记忆安全。社区里有个概念叫A-MemGuard专门做LLM Agent记忆的主动防御。原理很简单但很管用写入记忆库之前先过一遍敏感信息检测和内容审计防止隐私数据、错误结论、甚至恶意注入的脏数据被长期固化。我接手过一个客户项目Agent记忆库里存了一条用户被诱导输入的恶意指令导致后续每次对话都被带偏排查了很久才定位到根因。从那以后我再也没跳过记忆安全审计这一步。3.4 模式四从GraphRAG到Ontology RAG——知识结构决定决策质量向量检索是语义层面的模糊匹配擅长处理“意思相近”的内容但处理不了“关系复杂”的内容。比如“这个产品的所有下游依赖组件清单”向量检索很难给出准确答案因为答案藏在知识图谱的结构里。GraphRAG的思路是把实体和关系抽取出来构建知识图谱检索时沿着图结构做遍历和推理。到了Ontology RAG再进一步——不只建图谱还定义领域本体明确实体类型、属性、关系约束让机器真正理解知识的结构化含义。这一层融合对Agent的意义非常大。Agent做决策时需要的往往不只是“一段相关文本”而是“一套结构化的业务规则与关系链”。我在工业制造项目里做过一个案例设备故障诊断Agent接上了Ontology RAG故障现象、零部件、维修方案之间的关联关系全都结构化存好。Agent拿到故障描述后能在知识图里快速定位可能相关的零部件和历史上的维修记录诊断效率和准确度都远非传统RAG可比。4. 融合的边界谁负责读谁负责做4.1 一张表看懂RAG系统与Agent系统的架构差异很多新手容易把二者的边界模糊化。我画过一张对比表每次分享都先给大家看这个对比维度RAG系统Agent系统核心目标提供有依据的答案完成复杂的任务闭环系统闭环读知识、答问题感知、决策、行动、观察对外影响只读环境不改状态可调用工具改变系统状态上下文来源检索到的外部文档记忆、工具返回、环境状态失败模式答不准、检不到行动中断、决策错误、误操作评测重点命中率、准确性、忠实度任务成功率、效率、安全合规看这张表就明白了RAG系统再复杂它还在“读”的范畴里Agent系统一旦接了工具、能改状态就进入了“做”的范畴。“做”和“读”的风险等级完全不同。4.2 Skill、Harness、Agent三个容易混淆的层级边界社区里经常有人问skill和agent的区别、harness和agent的区别。我在实际架构中是这样划分的Skill是能力的最小单元。一个“查询订单状态”的函数是Skill一个“生成催款函”的流程也是Skill。它本身没有自主决策能力但它是Agent唯一能干活的途径。没有SkillAgent就是光说不练的嘴炮。Harness是Agent的运行时环境我习惯叫它“执行鞍具层”。它负责工具调用调度、上下文管理、错误恢复、跟踪记录、权限校验。你可以把Harness理解成舞台Agent是台上的演员Skill是演员手中的道具。再好的演员舞台搭得烂也演不出好戏。Agent则是决策主体。它定义目标、制定计划、使用Skill、响应观察结果。多个Agent协作时还会涉及通信协议和任务分配。这三层边界很实用每次方案评审我先问清楚你改的是Skill、Harness还是Agent逻辑层次一分明架构就不会乱。4.3 架构决策清单什么场景用RAG什么场景上Agent这是我的核心方法论也是最想让你带走的部分。接到一个需求先不要急着上Agent按这个清单过一遍。问题只要求“准确回答”吗如果是纯RAG就够了。比如“员工手册里年假怎么算”检索增强问答完全可以胜任强行加Agent反而引入不必要的不确定性。问题必须“操作业务系统”吗需要改状态、调接口、发消息那就要上Agent因为Agent才有行动层。问题依赖多步推理和工具组合吗比如“对比三个供应商报价并给出推荐还要把推荐理由写成邮件草稿”——纯RAG做不到需要Agent拆解任务、多次调用外部工具。问题依赖长期用户记忆吗跨会话记住用户偏好那就必须在Agent架构里设计记忆层记忆的存取大量用到RAG检索能力。场景对失败容忍度有多高金融交易、医疗诊断、自动化发单这类高风险场景无论技术多先进都要人工审核兜底。宁慢勿错。每次我评审别人的架构方案都会拿这份清单过一遍。很多项目失败的原因不是技术选型不对而是根本没想清楚当前需求到底处在“读”的层次还是“做”的层次。4.4 边界模糊时的典型信号还有一类场景需求本身既包含读也包含做边界模糊。这时候有几个信号可以帮你判断该往哪边偏。第一个信号是检索命中率漂移。知识库内容更新后命中率不升反降说明固定切分策略不再适配新文档结构这时候需要Agentic RAG的主动适配能力而不是继续死磕向量化参数。第二个信号是工具幻觉。Agent在决策时调用了根本不存在的工具参数或者生成了和业务规则矛盾的指令。这是典型的Agent行动层问题不是RAG知识层问题。排查方向要转向工具定义规范和调用约束而不是去扩充知识库。第三个信号是执行中断。Agent运行时报错终止最常见的一句话是agent execution terminated due to error。我会在下一章详细说这个问题的排查路径。5. 工程落地中的常见问题与排查实录5.1 “Agent execution terminated due to error”的定位三板斧这是我被问得最多的问题也是最让人抓狂的问题。Agent跑着跑着突然中止错误信息不足以定位根因项目群里一片哀嚎。我的排查三板斧是第一板斧查日志分层。Agent执行链路有规划日志、工具调用日志、上下文日志三个层次先确认是哪一层报错。规划层报错通常是模型收到了非法格式输入工具层报错是API超时、参数校验失败或权限不足上下文层报错一般是上下文窗口溢出。分层定位后至少能甩掉三分之二的干扰项。第二板斧看状态清理。很多所谓“终止”不是真实系统错误而是上一轮运行留下的脏状态——全局变量残留、缓存数据过期、跨Agent消息积压。我在一个多Agent协同项目里就遇到过这种情况两个Agent的会话上下文被复用串联了后一个Agent读到前一个Agent的中间结果逻辑瞬间混乱直接中断。每次任务开始前做状态隔离和清理这个习惯能省很多半夜抓头发的时间。第三板斧抓完整原始输出。很多Agent框架默认只记录最终结果中间过程全部丢弃。这是排查的致命伤。正确做法是在开发和预发环境里把每次规划推理的完整输出、工具入参和出参全部持久化。不管排查什么问题完整轨迹一拉根因基本无处遁形。5.2 评测指标组合Hit Rate只是起点如果从零搭一个RAG或Agent项目我建议第一天就把评测体系搭起来不要等开发得差不多了再补。很多团队陷入无休止调参就是因为没有量化的反馈全靠肉眼感觉。对RAG层至少要看三个数据命中率核心文档是否被成功召回忠实度大模型有没有忠实基于检索内容回答而不是自由发挥上下文利用率召回的段落里有多少真正被最终答案用到。我的经验是上下文利用率低往往比命中率低更危险说明检索召回了大量垃圾内容模型只能硬着头皮从噪声里挑答案。对Agent层只看检索指标远远不够还要看任务成功率、工具调用准确率、平均完成步数、异常中断率、人工干预率。我做的项目里最看重的是人工干预率——系统自动跑不动、需要人介入处理的任务占比。如果一个Agent系统的人工干预率超过30%它还没到放心交出去的状态。5.3 一个本地ERP产品检索的落地实例前面讲了不少抽象架构这里给一个具体的落地案例。某制造企业想把产品检索做成智能问答接上本地ERP系统。技术栈选了.NET生态框架用了Semantic Kernel。落地路径是这样的先把ERP里的产品主数据、库存状态、定价规则抽出来构建本地知识库按产品线切分索引。RAG检索部分封装成Semantic Kernel的Plugin暴露给Agent调用。Agent负责解析用户问法比如用户说“A型电机还有多少库存价格最近有变动吗”Agent先调库存查询Plugin、再调价格历史Plugin最后汇总成回答。这个过程中我发现一个重要的教训ERP字段含义和业务口径必须沉淀进知识库否则Agent看不懂系统返回的字段。比如ERP里库存有一条“IN_TRANSIT”状态字段业务上它意味着采购在途、已锁定预留给某订单。你不把这个口径写进知识库Agent可能直接把在途库存当成可用库存报给用户后果就是订单超卖。所以本地ERP加RAG加LLM的项目同步梳理业务口径字典优先级和主链路开发一样高。5.4 Agent架构师学习路线与面试高频考点最后聊一下能力成长。现在很多人问Agent架构师的学习路线我的建议是先夯实RAG基础再上Agent架构顺序不能乱RAG是Agent的知识底座。单纯背Agent概念、抄一套框架Demo上手做项目基本一击即溃。我乐意推荐的路径是第一步吃透RAG全链路能做到自己搭一套可靠的企业知识问答系统第二步掌握Agent核心组件用主流框架完整跑通一个工具调用项目第三步深入研究记忆系统和检索决策把Agentic RAG吃透第四步开始设计多Agent协作架构理解Skill、Harness、Agent的分层边界第五步研究安全与评测建立自己的工程方法论和避坑清单。面试方面的高频考点我总结过一份问题和考点大概是这样RAG检索质量差怎么优化考混合检索和重排的理解Agent怎么让模型不跑偏考系统提示词和上下文管理Agent记忆是怎么设计的考长期记忆与短期记忆的架构能力多Agent之间怎么协作考通信协议和任务编排Agent上线后误操作怎么防考权限收敛和人工审核机制RAG命中率低怎么排查考拆解定位能力。最后说点个人体会。这个系列写到这里我最大的感触是RAG和Agent不是替代关系是演进关系。RAG把大模型从“闭卷考试”变成“开卷考试”Agent又把开卷考试变成了“项目执行”。前者解决知道的问题后者解决做到的问题。一个稳定的Agent架构永远是你中有我——知识层用RAG的力量决策层用Agent的框架中间靠一套清晰的边界把两者缝合。踩过几次坑之后你会明白真正难的不是技术本身而是守住边界。该读的地方读扎实该做的地方做果断不越界不欠位Agent系统就不会差到哪里去。
