先从结论说起如果你现在想入行或者正在做 AI 应用开发别再纠结“我到底该先学 LangChain 还是先学 LlamaIndex”这种问题了先把 RAG 和 Agent 这两条主线的核心模块吃透比什么都管用。我见过太多人一上来就追着最新框架跑结果连最基本的检索链路都说不清楚面试的时候一问一个准直接被问穿。这篇文章我不跟你扯 roadmap 大而全的东西就聚焦一个事儿从 RAG 到 Agent真正的 AI 应用开发到底是由哪些核心模块组成的每个模块解决什么问题以及你自己动手做的时候要注意哪些坑。先说下这篇文章适合谁。如果你是刚接触 RAG 和 Agent 的初学者这篇文章能帮你建立一张完整的地图知道该往哪个方向使劲如果你已经在做 Rag 项目或者 Agent 项目那这篇文章里的架构拆分、模块边界、踩坑记录能帮你把脑子里那些“模糊的感觉”变成可复用的方法论。如果你正准备面试那就更好了文末我会聊几个高频面试题你对照着自查一遍能少走很多弯路。我自己做这块业务的感受是市面上 90% 的教程都在给你讲“怎么调用 API”但很少讲“为什么这个模块要这么设计”以及“串联起来之后数据是怎么流动的”。而这些恰恰是 AI 应用开发面试、实际项目中最重要的部分。所以下面我按自己的理解把整个链路拆成了几个层次一层一层剥给你看。1. 内容整体设计与思路拆解1.1 先搞清楚 RAG 和 Agent 不是并列关系是递进关系很多初学者会把 RAG 和 Agent 当成两个独立的方向去学今天刷两个 RAG 项目明天刷两个 Agent 项目结果越学越乱。我自己也是从这条弯路走过来的后来才慢慢意识到一个关键点RAG 解决的是“让模型拥有你不知道的知识”Agent 解决的是“让模型能帮你干活”。两者解决的问题完全不同。用一个生活化的类比来解释RAG 就像是给一个刚入职的新员工配了一套完整的公司档案库他不懂的问题可以去档案库查资料查完再回答你所以他的回答永远是“有依据的”。而 Agent 更像是给这个员工配了手、脚和大脑的决策系统他不仅能查资料还能根据你的指令制定计划、调用工具、执行操作比如帮你发邮件、查天气、订机票。你可以把 Agent 理解为“能行动起来的 RAG”而 Agentic RAG 则是把两者的能力揉在一起让 Agent 在行动的过程中随时通过 RAG 获取所需的知识支撑。所以学习路径上我的建议是先打通 RAG 的完整链路再去看 Agent。原因很简单RAG 是 Agent 感知世界的重要途径之一如果你连检索质量都做不好那 Agent 后续的决策和行动就是建立在沙子上一碰就碎。1.2 从需求出发反向推导模块划分我们再换个角度从需求出发看看一条完整的 AI 应用开发链路里一定会出现哪些模块。不管你用什么框架最终都绕不开下面这几件事。第一你需要一个地方存放知识这就是知识库的构建涉及文档解析、切块、向量化、索引存储。第二用户提问后你需要从知识库里找到最相关的内容这就是检索模块涉及向量检索、关键词检索、混合检索、重排序。第三模型需要基于检索到的内容生成回答这就是生成模块涉及 Prompt 模板设计、上下文管理、大模型调用。第四如果这个应用不只是一个问答机器人而是要完成一系列任务那你需要任务规划与工具调用模块这实际上就是 Agent 的核心能力包括推理、规划、工具选择、多步执行。第五不管是 RAG 还是 Agent都需要有记忆模块来缓存历史对话或长期偏好。第六最后还需要一套评测与可观测性体系不然你根本不知道系统改得好不好。你会发现这套模块划分和具体选哪个框架是没有关系的它是整个 AI 应用开发的通解。基于这套思路接下来我逐一拆解每个模块的核心细节和实践要点。2. 核心细节解析与实操要点2.1 RAG 的命中率决定项目生死切块与检索很多人在 RAG 项目实战里最容易犯的错就是把精力全放在调 Prompt 上结果发现效果怎么也上不去。我跟你讲大概率问题出在检索这一层而且是切块这一步就已经埋下了雷。先说切块。切块这事看着简单实际上非常讲究。比如有个常见问题**你们切块到底用固定长度还是用语义切块chunk_size 和 overlap 怎么设**这里面的门道不少。固定长度切块最简单token 数设个 500 或者 1000overlap 设个 50 到 100就能跑起来但缺点也很明显容易把语义完整的段落拦腰截断。语义切块会更合理按标题、段落、句子边界去切但计算成本高而且遇到排版混乱的 PDF 也会出错。我个人的经验是在项目初期用固定长度切块快速跑通链路等发现问题后再针对特定文档类型优化切块策略。比如对于结构化的技术文档可以用 Markdown 标题级别来切保留层级信息对于 FAQ 类问答对可以参考 Ontology RAG 的思路一个问一个答就当成一个 chunk对于长表格你可能需要单独设计解析逻辑不能简单按行切。再说索引。索引存储这一层你可以选择向量数据库比如 Milvus、Qdrant、pgvector也可以用传统数据库加向量插件最关键的参数是 Embedding 模型的选择。Embedding 模型决定了“语义相似”这件事在你业务场景里准不准常见的开源选择有 BGE 系列、M3E、text-embedding-ada-002。我在实测里的结论是中文场景下 BGE 系列模型的效果通常比英文原版模型好因为中文分词和语义表示本身就不同你用训练英文数据为主的模型来跑中文检索会明显感觉 top-k 结果不贴切。这块也可以做混合检索同时跑向量相似度检索和关键词检索比如 BM25再用 RRF 或者重排序模型把结果合并能有效提升召回率。2.2 混合检索与重排序从“能搜到”到“搜得准”搜索和检索是 RAG 项目里最值得砸时间优化的一环。因为大模型本身是不知道答案的你给它的检索结果如果是不相关内容你再怎么调 Prompt 它也只能一本正经地胡说八道。我在做 rag 实战的时候喜欢拆成两个阶段来看。第一阶段是召回目的是“宁可多召回不可漏掉关键信息”所以一般使用向量检索配合关键词检索来做多路召回。第二阶段是重排序目的是“把真正有用的信息顶到最前面”因为大模型上下文窗口有限你如果给 20 个 chunk 进去既浪费 token 又容易让答案失焦。具体做法是在召回得到 20 到 50 个候选片段后用一个轻量级重排序模型对片段逐一打分排序最后只要 Top 5 到 Top 8 进入提示模板。这个操作在我的项目里实测下来非常稳有时候相关度提升是跳跃性的不用换模型不用改 Embedding就一个重排序层就能让答案质量跨一个台阶。另外还值得注意的一点是RAG 多轮对话怎么设计这也是面试里高频出现的题目。很多人在多轮对话场景下做 RAG 时直接把整段历史都塞进检索 query 里结果检索出来的内容乱七八糟。更好的做法是拆两步第一步先做对话改写把“它多少钱”改写成“iPhone 15 Pro 的价格是多少”第二步再用改写后的独立问句去做检索或召回。改写可以用大模型来做也可以用规则处理具体看你的成本和时延要求。2.3 Agent 的五大核心模块逐个拆解讲完了 RAG下面进入 Agent。我在 agent 开发的过程中发现Agent 系统拆来拆去最终都会落到五个问题上模型、规划、记忆、工具、执行。每一个如果你没想清楚后面都要返工。先说模型。这个没什么好讲的作为 Agent 的大脑它需要具备较强的推理能力尤其是函数调用和结构化输出能力。如果模型本身不支持可靠的函数调用那工具调度环节就会出现诡异 bug你让模型输出一段 JSON它非要夹带文字那你不得不在解析层做一堆容错处理引号、换行、多余逗号整得跟考古一样。然后是规划。规划这块的热门方案包括思维链、ReAct 框架、Plan-and-Execute 等。通俗地说ReAct 是让模型边想边做每一步先推理再行动Plan-and-Execute 是先让模型生成一个完整计划再一步步执行。这两种我都在项目里试过经验是任务简单、步骤固定的场景用 ReAct 反而更灵活任务复杂、步骤明确的场景用 Plan-and-Execute 更可控。如果你用 Agent 框架这些编排逻辑框架已经帮你封装好了但你要理解底层在发生什么不然出了问题根本不知道怎么排查。接着是记忆。记忆分为短期工作记忆和长期记忆。短期工作记忆其实就是对话历史比较推荐用消息列表的形式保存长期记忆通常用向量库保存用户偏好、项目事实、历史决策等在关键时刻检索出来注入上下文。注意事项是记忆模块要设置淘汰策略或者压缩策略不然时间一长上下文爆掉只是时间问题token 成本也会蹭蹭往上涨。然后是工具。工具是 Agent 连接外部世界的桥梁你给 Agent 注册工具时描述一定要写得足够清晰因为模型决策调用哪个工具靠的就是工具名和描述。你写“get_weather”肯定比写“查询天气接口封装”要好得多前者模型一眼就知道用来干嘛后者它可能真的理解不了。另外工具的入参定义要严谨能用 enum 限定取值就用 enum能加描述就都加上描述这会大幅提升函数调用成功率。最后是执行。执行层本质上是 Agent 循环模型决策调用工具、代码执行工具、拿到结果再喂回模型、模型再推理下一步直到任务结束。这一块建议你从一开始就设计好最大迭代步数限制防止 Agent 进入死循环烧钱。2.4 Harness 与框架别被概念名词绕晕热搜词里我看到有人在问 Harness 和 Agent 的区别这确实是新手很容易被绕晕的地方。简单来说Agent 是这个智能体本身而 Harness 是承载和驱动 Agent 运行的那套运行时环境。你可以把 Agent 想成一个人Harness 是他身处的整套配套系统比如办公桌各种工牌、通讯工具、任务清单看板等等。没有 Harness 的 Agent 就像没穿宇航服的宇航员想法再多也出不了仓。所以现在做企业级应用的时候不能只关注模型能力还要关注 Harness 层的工程化能力包括沙箱环境、资源隔离、监控告警、审计日志等。类似的概念还有 Skill 与 Agent 的区别、Pi Agent 这类框架和传统框架的差异。我的建议是这些名词了解即可不要过度纠结关键是抓住本质Agent 是脑工具是手Harness 是生存环境Skill 是预制能力包。面试时能在三五句话里把这个概念讲清楚面试官通常会认为你是真懂而不是在背术语。3. 实操过程与核心环节实现3.1 从零搭建一个最小可用的 RAG 项目这个最小项目我建议按下面的链路来做文档加载、文本切块、向量化、写入向量库、检索、重排序、生成。为了让你有更具体的体感我直接给一个实战链路。第一步是加载文档我建议你直接从 Markdown 文件开始因为 Markdown 本身保留结构信息。第二步切块按 Markdown 标题切块内用固定长度兜底比如每个块不超过 800 个 token。第三步是用一个 Embedding 模型批量向量化这个步骤要注意批量大小别设太大否则容易内存溢出。第四步写入向量库你要额外保存元数据比如来源文档路径、标题层级等这能帮你后续做引用溯源。检索部分的代码逻辑可以按下面这个思路来实现先对用户输入问题做改写然后同时走向量检索和关键词检索两条路把结果合并后重排序。这里有个细节值得记录关键词检索不要用简单的分词拼接建议用 BM25 或者全文索引召回效果差别明显。最后生成阶段的 Prompt 模板我习惯这样写先设定系统角色说明只能基于上下文回答然后用清晰的分隔符把检索到的上下文内容包起来。千万注意一点所有检索到的上下文一定要带来源标识这样模型在幻觉的时候你能快速定位是哪一步出了问题到底是检索没召回还是生成的时候没按上下文走。3.2 把一个普通 RAG 升级成 Agentic RAG接下来是最有价值的部分怎么把一个只会问答的 RAG 升级成一个能执行任务的 Agentic RAG。这一步做得好你在中小自研公司的 AI 应用开发岗就能直接干活了而不是整天被人指挥着改提示词。第一步抽象任务类型。先列一下用户可能会让你做什么比如查资料、写摘要、对比分析、生成周报、调用内部接口查数据等。把任务类型列出来后你会自然意识到光靠“检索生成”是不够的必须让模型有“选择工具”和“多次执行”的能力。第二步设计工具层。你自己定义几个简单工具比如“检索企业知识库”“调用天气 API”“执行 SQL 查询”等。每个工具都用一个函数实现函数需要给模型描述清楚用途、参数、返回值格式。实测下来工具描述写不好Agent 的成功率会明显下降所以描述里除了功能说明最好带上一两个示例比如“get_employee_salary(employee_id)示例get_employee_salary(10086)”。第三步让模型自己做规划。把用户请求发给模型要求模型一步步推理先决定整体计划再决定每一步调哪个工具。在代码实现上可以给大模型附上工具列表和说明让它先输出 JSON 格式的计划然后你的系统根据计划依次调用工具每次调用后把结果追加到上下文里再让模型决定下一步直到输出最终结果。第四步接入重检索。这里的 Agentic RAG 和普通 RAG 的区别在于模型在推理过程中可能会发现“当前信息不足需要再查一次”。比如第一步查了“项目背景”第二步要写“项目风险”发现上下文里没有相关内容于是自动发起第二次检索。这个能力就是 Agentic RAG 的核心也是热搜里这个词热度极高的原因。实现这个逻辑的原理并不复杂本质就是给模型一个“检索工具”让它在推理循环里按需调用。3.3 多 Agent 协作与编排的落地方案当任务粒度越来越大时单个 Agent 会显得力不从心因为他既要会写代码又要懂业务知识还得分心去控制对话节奏。这时候需要做多 Agent 架构把任务拆成几个角色 Agent每个 Agent 聚焦一个子领域再用一个主控 Agent 或者编排层来调度。我常用的模式是“主管-工人”模式主管 Agent 接收用户请求拆解任务然后分发给工人 Agent比如“检索 Agent”“分析 Agent”“写作 Agent”。每个工人 Agent 完成自己的子任务并把结果返回给主管主管再汇总整理最终答案。这种架构好在哪里呢一是每个 Agent 的上下文窗口压力变小了二是每个 Agent 的 Prompt 和工具集可以专精优化三是出了问题好排查你可以看是哪个 Agent 掉链子。但它的缺点也很明显就是多轮调用会增加 token 消耗和时延。所以如果你面对的任务比较简单一个普通 RAG 就能解决就真的别硬上多 Agent 架构杀鸡用牛刀。另外在多 Agent 编排时很多人会问那选什么框架。这个我可以给一个中肯的建议如果你偏向轻量级灵活控制LangGraph 这类偏底层的编排框架会比较顺手如果你想要开箱即用、少写胶水代码那就用成熟度较高的 Agent 框架。你甚至可以在生产环境里把不同框架混合使用底层流程自己控制上层用框架快速搭建。道理和炒菜一样锅和铲可以混着用关键是菜得熟。4. 常见问题与排查技巧实录4.1 检索效果差问题可能根本不在检索很多朋友在 rag 项目里遇到的现象是文档也拆了向量库也建了模型也换了结果问答效果还是不行。排查来排查去最后发现是源头数据是脏的。比如 PDF 里文字扫描件没做 OCR文档里大量乱码比如表格被拆成了碎片关键数字对不上了还比如文档版本混乱同一个产品有新旧两版说明书你也没做版本过滤。这些都是检索链条上游的问题你再怎么调下游都解决不了。所以我的排查顺序一般是这样先看召回结果如果召回出来的片段本身全是垃圾那就是数据源或切块的问题如果召回结果还不错但模型答得不好那才是生成环节的问题重点调 Prompt 模板和上下文组织方式。把这两类问题分开排查效率会高很多不至于乱成一锅粥。4.2 Agent 执行总是中断或者结果不符合预期怎么办热词里出现“Agent execution terminated due to error.”我猜不少人都遇到过这种报错Agent 跑着跑着突然终止执行。经验是这通常由三种原因导致。一是工具调用异常比如参数格式不对、入参缺失导致函数抛出异常Agent 循环被中断二是上下文超限步数多了或者单步结果太大直接超出模型上下文窗口三是模型输出不符合解析规则模型没按要求的 JSON 结构输出你的解析器直接报错退出。针对这三种情况我的处理办法分别是给每个工具调用包一层 try-catch捕获异常后把错误信息返回给模型让它自行调整重试设置全局最大步数和单步结果截断规则防止上下文膨胀解析模型输出时尽量宽容支持提取 JSON 片段而不是要求全量严格匹配。这些都是老鸟踩坑踩出来的经验你提前做好能省非常多调试时间。4.3 RAG 与 MCP 的关系到底怎么理解这个热点问题也是面试里近来出现频率较高的。说实话RAG 和 MCP 本来就不是同一层的东西硬要比就有点关公战秦琼了。MCP 的全称是 Model Context Protocol它是一个给模型提供上下文和工具访问的标准协议它的目标是标准化“模型如何连外部工具和数据源”。而 RAG 是一种检索增强生成的技术范式它管的是“怎么把外部知识检索出来辅助回答”。两者可以配合使用RAG 可以作为 MCP 的一个工具服务或者说 MCP 提供了工具接入的标准化能力而 RAG 是其中一个工具类型。理解到这个层面就够了面试时考官会认为你概念边界很清晰。4.4 面试前建议自测的五个核心问题我还整理了五个高频问题你上考场前可以拿它自测随便抽一个能说上三四分钟基本就稳了。你最常用的 RAG 链路是怎样的如果检索结果不够好你怎么排查你讲讲向量检索和关键词检索各自的优缺点什么时候用哪一个为什么Agent 和传统程序的区别是什么Agent 的规划、记忆、工具调用分别解决什么问题你在 Agent 项目里遇到过什么棘手 bug后来怎么解决的如果给你一个全新的业务场景你会怎么设计一套 AI 应用开发的 SOP从哪里入手上述每个问题都应该能用“场景背景、方案选择、绕过的坑、最终效果”来组织回答。这也是我从实际项目中提炼出来的答题套路比背一堆概念强十倍。4.5 中小自研公司到底缺不缺 AI 应用开发岗位热词里还有个很现实的问题中小自研公司的 AI 应用开发岗位多吗说实话多但和你想的不太一样。大厂的确在招很多算法工程师和研究型岗位但中小公司往往更缺的是“能把大模型能力落地成业务功能”的复合型工程师。他们不要求你发明新算法但要求你能做知识库、打通业务流、做内部工具、调 Prompt、保障系统稳定。说白了就是你要能做工程而不是只会聊论文。如果你面向这个市场去定位自己我的建议是重点积累全链路项目经验尤其是在某一个行业场景下的完整落地案例。比如“针对公司的售后知识库做一个带权限隔离的 RAG 问答系统”这比写十个玩具 Demo 更能体现你的价值。同时把 Agent 相关能力补上因为越来越多中小公司已经开始试点用 Agent 替代部分重复性人力工作供给缺口正在打开。5. 学习路径与踩坑经验总结5.1 建议的 AI 应用开发学习路线网上关于 AI 应用开发学习路线的文章铺天盖地但大多数越写越厚反而让人不知道怎么执行。我的建议是把它压缩成四步走。第一步掌握大模型基础调用逻辑包括补全、对话、函数调用、结构化输出。能用代码裸调一个大模型 API不走任何框架。这一步的终点是你会写一个简单的命令行问答工具。第二步完整做完一个 RAG 项目。从文档加载开始自己手动实现一遍切块、向量化、检索、重排序、生成不依赖任何高级框架把每一环都跑透再用框架快速重构一遍。这一步的终点是你能回答清楚“RAG 项目的每个环节为什么存在改了会怎么样”。第三步做一个带工具调用的 Agent 项目。从手动函数调用开始给模型定义三五个工具让它自主决定调用顺序。跑通之后再引入 Agent 框架观察框架帮你做了什么以及它有哪些隐藏限制。这一步的终点是你能设计并实现一个能完成多步任务的智能体。第四步做一个集成 RAG 能力的 Agentic RAG 项目。让 Agent 在规划时按需检索把检索结果作为观察输入再迭代执行。这一步是你从“应用开发”走向“智能应用开发”的关键一步。5.2 我在项目中踩过的五个坑最后我必须交底把我自己踩过的几个坑原原本本列出来免得你再走一遍。第一个坑是“过度设计”刚接触 Agent 的时候总想把所有功能做成自动化最后发现稳定性完全没法保障。后来学乖了所有 Agent 设计都从最简路径开始按“先规则再多步决策再自主规划”的梯度演进每一步稳定了再动下一步。第二个坑是“Embedding 模型选型走弯路”一开始图便宜用了非常小的 Embedding 模型结果检索相关性长期上不去后来换了 BGE 系列才明显改善。这个领域没有免费的午餐Embedding 模型的质量直接决定系统上限。第三个坑是“切块参数想当然”看到网上说 chunk_size 500 好就照抄忽略了你的文档长度、语义密度、问题粒度都有差异。现在做任何新项目的第一件事是先花半天时间对文档样本做切块与召回实验再定参数而这个实验往往能让你对最终效果更有底。第四个坑是“不设计可观测性”早期做 Agent 项目一旦出问题就只能在日志里捞非常痛苦。后来我在工具调用层统一加了耗时记录、入参出参记录、模型原始响应快照再配合可视化工具做链路追踪整体调试效率至少翻了一倍。第五个坑是“不考虑成本”没有限制最大迭代步数、没有设置重试策略、没有做结果缓存一个简单问题烧了很多 token月底一查账单才吓一跳。现在的做法是所有外部模型调用都加超时、重试上限和结果缓存层相当于给系统上了一道安全阀门。从 RAG 到 Agent这中间的跨越不仅是技术栈的扩展更是一种思维方式的转换。你得从“我给模型喂资料让它回答”的思维升级到“我给模型工具和目标让它自己找资料、自己干活”的思维。这个转变恰恰是从应用开发迈向智能应用开发的分水岭。我个人在实际操作中的体会是RAG 和 Agent 的技术点虽然多但真的没有哪个是理解不了的关键在于你能不能系统性地把它们串起来。如果你正在准备面试或者正在做一个相关项目建议你先从最小闭环做起哪怕用最朴素的方式不依赖任何框架手动实现一遍检索、重排序、工具调用把你的 AI 应用开发 SOP 文档沉淀下来再慢慢迭代优化。等你有一天能一边画架构图一边讲清楚每个模块的边界和风险点你就已经比大多数只会调包的人强出去一大截了。