RAG、Agent、AI 应用开发——这三个词最近一年在技术讨论、招聘面试和公司内部立项里的出现频率高得让人没法忽视。我从两年前开始做知识库问答系统到现在带团队做多 Agent 协作应用被问得最多的一个问题不是哪个模型更强而是一个人想系统学会 AI 应用开发到底该先把精力花在哪些模块上这篇内容就是把从 RAG 到 Agent 这条路上的核心模块按实际项目中的推进顺序拆开讲清楚结合我自己踩过的坑和验证过的做法给出一份可以直接照着走的参考清单。适合三类人看准备转岗 AI 应用开发的工程师、正在准备 AI 应用开发面试的同学、以及已经在做但觉得知识体系比较零散、想补齐短板的人。1. RAG 是 AI 应用开发的第一块敲门砖1.1 先搞清楚 RAG 到底在解决什么问题很多人一上来就学 Agent我反而觉得 RAG 才是 AI 应用开发最该先啃下来的部分。原因很简单RAG 是大部分真实业务场景里大模型能力落地的最短路径而且它解决的问题足够具体、足够高频。大模型本身有两个天生的短板一是知识有截止时间二是会产生幻觉也就是一本正经地胡说八道。你把私有文档、产品手册、历史工单丢给通用大模型它根本没见过这些内容再强的推理能力也白搭。RAG 的核心思路用大白话说就是开卷考试模型不再凭记忆硬答而是先从外部知识库里检索出与问题相关的片段把检索结果塞进上下文再让模型基于这些材料生成答案。这个思路听起来简单但它同时解决了可控性和溯源两大问题——回答有依据错了也能知道错在哪一步。一个完整的 RAG 系统拆开来看永远是三大件索引把文档切块、向量化、存进向量库、检索把用户问题转成向量去库里找相关内容、生成把检索结果交给大模型组织答案。很多新手一开始就纠结向量库选型、Embedding 模型选哪个结果切块策略没设计好整个系统检索质量一塌糊涂。这个顺序问题我后面会详细讲。1.2 RAG 实战中的核心工程细节切块、向量化与检索先说切块。这是整个 RAG 项目里最容易偷懒、也最容易翻车的环节。切块的目标不是把文档切成等长碎片而是让每个块保持语义完整同时块之间要有合理的上下文衔接。我实测下来固定长度切块配合 10% 到 15% 的 overlap 是性价比最高的起步方案比如按 500 到 800 个字符切重叠 50 到 100 个字符。原因很直接如果块太小语义被切碎检索回来的是残片如果块太大向量表征被稀释相关性反而下降而且会浪费宝贵的上下文窗口。进阶一点的方案是父子切块先把文档按章节或段落切成父块再把父块细分成子块做检索命中子块后把整个父块交给模型。这样既保证了检索精度又给模型提供了完整上下文。我在做产品手册问答时就用的这个策略召回准确率明显高于单纯固定长度切块。还有一个实战小技巧切块前一定要做文档清洗把页眉页脚、目录、重复的表格说明清理掉否则这些噪声会被一起向量化检索时经常返回一堆无关内容。向量化和检索是下一个重点。Embedding 模型的选择直接影响检索效果的上限我通常建议先跑通再优化不要一上来就追求超大模型。中文场景下先用通用中文 Embedding 模型跑出基线再根据效果决定要不要换成领域微调的版本。向量维度、距离度量这些参数默认的余弦相似度在大多数场景就够了没必要一开始就折腾。真正容易被忽视的是混合检索纯向量检索对专有名词、型号编码这类关键词召回很差因为向量相似度捕捉的是语义而不是精确匹配。我在实际项目里都会加一路 BM25 关键词检索两路结果合并后再过一遍 Rerank 模型重排。这一步对最终回答质量的影响比换一个大模型还明显。这里想特别提一个热词里反复出现的思路历史用例检索与实例化适配。我们把历史问答对、处理过的工单作为案例存进知识库检索时先找出与当前问题最相似的历史用例把它们作为参考示例注入提示词再让模型针对当前实例做适配。这个做法本质上是用历史成功案例给模型做 few-shot 引导尤其适合客服、运维、售后这类有大量历史记录的场景。我做过一个设备故障排查助手就是靠这个办法把首次解答准确率提高了不少。1.3 RAG 多轮对话设计与引用溯源问答系统的最后两块拼图单轮 RAG 问答跑通之后一旦要接多轮对话问题立刻变复杂。它指的是什么上面说的那个方案具体怎么操作——这类问题如果不做处理直接把对话历史一股脑塞给检索模块召回的基本都是噪声。我的做法是两条线并行第一做查询改写把用户当前的问题结合对话历史重写成一条可以独立检索的完整问题这一步可以用模型来做也可以用规则先兜底第二对对话历史做压缩管理控制进入上下文的 token 量。最初我以为多轮对话的重点在模型侧做久了才明白真正的难点在问题重构这一步重构做不好检索再先进也白搭。引用溯源这件事我建议从第一版就做不要等到客户投诉了再补。具体做法是在生成阶段要求模型每一条关键结论都带上知识库来源编号前端展示时把来源段落展开给用户看。这看起来是产品层面的小细节实际作用非常大它直接建立了用户对系统的信任更重要的是它能帮你快速定位问题——如果答案内容是对的但引错了源那是检索排序的问题如果引对了源但答案不对那是模型理解的问题。RAG 的评测也不能忽略。一定要在项目开始时就建一批测试问题和标注答案至少覆盖各文档类型和难度梯度。跑完基线之后再修改切块、重排、改写策略都用同一套测试集做回归对比。我见过太多团队凭感觉优化 RAG页面看起来在变好一问准确率反而下降了就是因为没有可量化的评测。2. 从 RAG 到 Agent能力边界的一次跃迁2.1 Agent 不是加强版 RAG而是换了引擎有些同学觉得 Agent 就是 RAG 加上几个函数调用我认为这是一个重要的认知误区。RAG 的核心是知识供给用户问系统查模型答整个过程是被动的、确定的。Agent 的核心是行动决策模型不仅要理解用户意图还要自己规划应该调用什么工具、按什么顺序调用、怎么根据中间结果调整方案。如果把 RAG 比作图书馆里的查询员你问他什么他查什么Agent 更像一个项目经理你给他一个目标他自己拆任务、调资源、处理意外最后把结果交付给你。最近常被问到 RAG 和 MCP 的区别我觉得这个对比能很好说明问题。MCP 是工具调用的标准化协议它解决的是大模型怎么和外部工具、数据源安全地连接这件事让 Agent 不用为每个工具写一套定制对接逻辑。RAG 解决的是模型不知道的知识从哪里来MCP 解决的是模型除了说话还能做什么动作。两者在架构上经常同时出现——Agent 通过 MCP 调用检索服务而这个检索服务内部就是一套 RAG 系统。把这两个概念分清面试时基本不会露怯。还有一个高频混淆点Skill 和 Agent 的区别。我习惯把 Skill 理解成预定义好的能力片段比如一个查天气的函数封装、一段固定的流程脚本Agent 则是具备自主决策逻辑的完整智能体它会根据用户目标自己决定用哪个 Skill、什么时候用。换句话说Skill 是工具箱里的工具Agent 是决定用什么工具干活的工人。2.2 Agent 的体内构造规划、记忆、工具与执行四要素一个能稳定干活的 Agent体内至少要有四个模块规划、记忆、工具调用、执行。规划层负责把用户目标拆解成可执行的步骤——ReAct 模式里就是思考→行动→观察的循环模型每走一步都基于上一步的观察结果重新调整策略更复杂的系统还会用 Plan-and-Execute先产出完整的计划再逐条执行。记忆层分短期和长期短期记忆就是会话上下文管理重点是控制 token 占用长期记忆要把历史交互里的关键信息存起来常见做法是存成向量后检索复用但要注意去重和过期处理否则记忆库会变成垃圾场。工具调用层依赖 Function Calling模型输出结构化参数系统去执行外部 API这一层的工程重点在我看来是参数 schema 的设计和错误兼容。执行层是很多人会忽视的部分。网上经常有人问Harness 和 Agent 的区别我给的答案一直是Agent 是决策大脑Harness 是承载大脑运转的整套执行环境包括工具注册、运行沙箱、状态管理、日志追踪这些外围支撑。你可以把 Agent 类比成一辆车上的自动驾驶算法Harness 则是配合算法运转的整个车辆底盘。没有好的执行环境Agent 再聪明也跑不稳。2.3 Agentic RAGRAG 到 Agent 的必经桥梁从纯 RAG 跨到全能 Agent 之前有一个中间形态非常值得投入精力就是 Agentic RAG。它跟普通 RAG 的区别在于普通 RAG 是一次检索一次生成Agentic RAG 是模型自主决定查不查、查哪个库、查几次、什么时候停。比如用户问对比一下 A 方案和 B 方案的维护成本普通 RAG 会把这句话拿去检索返回一堆文档让模型硬拼Agentic RAG 会让模型先规划分别查 A 方案的资料、查 B 方案的资料可能还要再查一份比较类文档然后综合生成答案。整个过程类似一个谨慎的调研员而不是信手拈来的答题机器。做 Agentic RAG 时一个很实用的实现方式是让模型先反思——对当前问题是否存疑、已有信息是否足够再决定调用检索工具。另一个思路是检索多路并行从不同知识库并行召回汇总去重后再生成。我最早做这个的时候踩过一个坑模型频繁触发多余检索回答速度慢而且成本高。后来加了触发条件约束比如规定只有当问题涉及知识库明确覆盖的实体时才触发检索现象才缓解。把 Agentic RAG 做好你会自然而然地理解 Agent 的规划编排逻辑——它其实就是把围绕一个目标做决策循环这件事从检索场景泛化到任意工具场景。3. Agent 开发必须掌握的核心模块与框架编排3.1 规划、记忆、工具的工程实现细节到了 Agent 阶段所有的模块都要从概念变成代码。先讲规划层。ReAct 循环落地时最关键的是给模型规定清晰的思考格式和行动格式模型先输出当前状态分析再输出下一步要调用的工具和参数系统解析执行后把结果作为新的观察回传。我发现工程上的难点不在格式解析而在于循环终止和异常恢复——模型可能陷入反复调用同一个工具的循环或者工具返回错误后不知道怎么收场。一定要设置最大迭代次数和退路机制比如超过上限就基于已有信息直接回答并在回答里说明哪些信息没查到。记忆层要处理的问题是存什么、取什么、什么时候清。长期记忆建议只存经过提炼的结构化信息比如用户偏好、关键事实、历史决策不要一股脑存原始对话。检索记忆时要结合当前会话的具体语境过滤不然容易把旧场景的信息当成当前事实。记忆写入的时机也很重要一般放在一轮任务完成之后做异步写入而不是每轮对话实时写入这样既省算力又避免中间状态污染记忆库。工具调用层有一个几乎所有项目都会遇到的问题模型生成的参数偶尔不符合 schema导致调用报错。这个报错就是我们经常在日志里看到的 Agent execution terminated due to error 一类情况。我的处理办法是三层兜底第一层工具调用前做参数校验不符合就自动修正比如枚举值做归一化第二层调用失败后把错误信息回传给模型让它自己调整参数重试通常一两次就能成功第三层连续失败超过 N 次就放弃该工具走降级方案。这套机制看起来简单却能让整体成功率从 80% 提升到 95% 以上。3.2 主流框架选型LangChain4j、AgentScope 和自研的边界在哪里Agent 开发要不要用框架这事我纠结过很久现在的结论是小步快跑阶段可以用框架但一定要弄清楚框架替你做了什么。目前在社区里热度比较高的方向一类是 LangChain 系的 LangGraph 和 Java 生态的 LangChain4j适合快速搭建 RAG 和基础 Agent 流程另一类是 AgentScope 这类偏研究向、强调Agent 即服务理念的框架它把 Agent 能力抽象成可独立部署的服务单元配合 RAG as Service、多智能体协作场景会比较顺。我个人的经验是先用框架跑通一个最小闭环然后逐步用自定义代码替换掉那些不理解但能用的黑盒部分最后保留下来的核心编排逻辑一定是自己的。判断框架好不好的一个标准是能不能看源码、能不能单步调试。Agent 应用中 80% 的问题都出在 Prompt 构造和工具调用链路上如果框架把这些东西包得太严实出了问题你连查都无从查起。我之前用过一个封装过度的框架Agent 偶发不调用工具翻代码翻了半天才发现是框架自带的系统提示词压过了业务提示词。从那以后我对任何框架的第一动作都是把它的 Prompt 组装逻辑读一遍。框架不是越多越好你的核心业务逻辑如果和框架深度绑死后面替换的成本会高到你宁可重写。还要强调一点不要盲目追社区里高频出现的开源 Agent 项目。我经常看到有人花大量时间研究各种开源 Agent 的安装和使用但连最基础的 ReAct 循环、Function Calling 参数约束都没自己写过一遍。工具类项目换个版本 API 就大变样学到的全是壳子。真正有价值的是理解它们的架构设计——记忆怎么存、工具怎么组织、失败怎么恢复这些底层的招式吃透了换什么框架都能快速上手。3.3 AI 应用开发的 SOP从想法到上线怎么走才不翻车AI 应用开发和传统软件开发的差异在于模型的行为有一定随机性所以必须有一套更严谨的 SOP 来兜住不确定性。我团队现在执行的标准动作是五步第一步定义场景和边界明确输入输出和失败兜底第二步准备数据和基线先把 RAG 或纯 Prompt 的基线做出来量化准确率第三步做 Agent 化改造把需要决策的节点替换成工具调用和规划循环第四步建立评测集和回归机制每一次改版都跑同一套测试第五步灰度上线并全程留痕记录所有 Agent 决策轨迹用于复盘。这套流程听起来不性感但能救你于水火之中。没用 SOP 的时候我经历过最惨痛的一次事故一个 Agent 应用在线上突然频繁调错工具排查了半天才发现是上游数据格式悄悄变了但 Agent 因为指令遵循的问题没有发现异常直接按旧格式解析参数越跑越偏。后来我们在所有工具调用入口加了格式校验和异常告警才止住这类问题。AI 应用的监控比传统应用多了一个维度——不仅要监控服务是否挂掉还要监控行为是否跑偏也就是所谓的 Agent evals 和决策轨迹分析。找问题的时候先看日志里的决策轨迹再对比模型输入输出往往几分钟就能定位根因。4. 学习路线、面试准备与职业现实4.1 我给新人的 RAG 到 Agent 学习路线图面对AI 应用开发学习路线这个问题我通常给五步走的建议每一步都要产出可演示的作品。第一步花一周理解大模型基础把 token、上下文窗口、提示词工程这些概念吃透能用提示词完成结构化输出。第二步用 Python 或 Java 做一个小型 RAG 知识库项目文档加载、切块、向量化、检索、生成全流程跑一遍这是理解 AI 应用开发的必经之路。第三步学习 Function Calling让模型调用真实 API 完成一个任务比如查天气、查库存、发消息体会工具调用的完整链路。第四步实现一个简单的 ReAct Agent给自己配一个线性模式规划、调用工具、观察结果、继续行动然后逐步加上记忆和错误恢复。第五步研究一个主流框架的源码理解它怎么组织 Agent 核心模块并用它重构自己之前的项目。这条路线每一阶段都在为下一阶段打基础。很多人想直接跳到第四步结果连切块对检索的影响都没感觉做出来的 Agent 即使规划再聪明检索回来的知识是垃圾产出同样不可用。我把这条路线在团队内部带过三批新人按这个顺序走的基本上六到八周就能独立承担一个 AI 应用模块的开发跳着学的反而经常卡壳。实操时有一点要提醒练习项目不要求大要求完整。宁可做一个只有三个工具、两条记忆规则的小型 Agent把日志、评测、错误恢复这些工程细节都补上也不要做一个调用十几个工具但一跑就崩的半成品项目。面试官想看到的是你对完整链路的掌控能力而不是工具数量。4.2 AI 应用开发岗位的现状与高频面试题热搜词里有个问题很真实中小自研公司的 AI 应用开发岗位多吗。我的观察是岗位数量在涨但要求越来越复合——不是会调大模型 API就行而是既懂业务、又会 Prompt、还能写工程代码、能做评测。纯 CRUD 背景的工程师转型 AI 应用开发最大的短板往往不是不会用框架而是缺乏对模型行为不确定性的工程化处理经验。中小公司尤其看重这一点因为他们的 AI 产品通常是直接对业务负责的可解释性和稳定性比炫酷更重要。我整理过一份高频面试题清单基本覆盖了网上热词的常见讨论RAG 和 MCP 的区别是什么切块策略怎么选为什么不能盲目定长RAG 多轮对话怎么设计引用和改写Agent 的记忆是怎么分层的长短期记忆分别存什么Harness 和 Agent 的区别是什么Skill 与 Agent 的区别是什么Agent 工具调用失败了怎么排查和处理Agent evals 怎么做这些题看似分散其实都在考察一个核心能力——你有没有真正把一个 AI 应用从零到一做完。我面试时最喜欢问的一句话是你做过最复杂的 AI 应用里最难解决的一个问题是什么。这道题刷掉过很多简历漂亮但实际没深入做过项目的候选人。准备面试的建议是不要背概念要把每个概念落到自己做过的一个具体问题上。比如谈到切块你要能说出我当时按 700 字符切overlap 100因为我们的文档是表格和段落混合太短会把表格拆散。这种具体到细节的表述远比复述一遍定义有说服力。4.3 新手避坑清单常见问题与排查实录最后整理一份我实战中反复遇到、网上讨论也很多的问题速查表覆盖了从 RAG 到 Agent 最常见的翻车点问题现象根因排查方向检索结果与问题无关切块不合理或者文档噪声太多先人工检查Top5召回结果调整切块和文档清洗向量召回对代码/型号匹配差只用了向量检索加BM25混合检索和Rerank回答正确但引用来源不对重排排序问题或模型没有按来源作答检查Rerank模型强化提示词中的引用约束多轮对话越来越乱查询改写失效或上下文膨胀检查改写策略压缩旧轮次信息Agent不调用工具系统提示词压制指令或工具描述不清检查提示词结构简化工具描述并给示例Agent循环调用同一工具缺少最大迭代限制和异常分支加循环检测和降级兜底工具调用报错终止参数不符合schema或上游数据变化加参数校验、错误回传重试机制改版后效果变差但说不清缺少评测集建立固定测试集做回归对比我还想单独强调一个经常被忽视的问题Embedding 模型的更新。很多团队上线后就不再关注向量化环节结果某天重新跑了一遍索引用了新版本的 Embedding 模型新旧向量维度或语义空间不一致导致检索效果明显波动。我的习惯是Embedding 和检索相关组件一旦定版就锁版本、锁参数任何改动都要走评测回归流程。另外新手做 Agent 项目时最容易忽略日志的重要性。一定要在每一轮思考、每一次工具调用前后都打结构化日志记录时间、输入、输出、token 消耗和耗时。这不是为了好看是为了后面排查问题时能像放电影一样回放 Agent 的每一个决策。我带队时有一个硬性要求任何 Agent 模块没有完整 trace 日志就不允许上测试环境。说回学习这件事本身。我自己走了不少弯路早期花了很多时间研究各种模型和提示词技巧后来才意识到 AI 应用开发的立身之本是把工程细节做到位——数据清洗、切块策略、检索重排、工具调用容错、评测回归这些听起来不那么AI的东西恰恰决定了项目能不能落地。从 RAG 到 Agent本质上不是两条独立路线而是一条连续的技能谱系RAG 让你学会驾驭知识Agent 让你学会驾驭行动两者都过关了才算真正入了 AI 应用开发的门。最后分享一个小技巧无论你做的是知识库还是智能体第一版上线前先花半天时间把所有检索结果和工具调用日志从头到尾翻一遍你会看到很多在测试集上发现不了的问题。
