先从结论说起：如果你现在想入行或者正在做 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 或者 1000，overlap 设个 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 文档沉淀下来，再慢慢迭代优化。等你有一天能一边画架构图一边讲清楚每个模块的边界和风险点，你就已经比大多数只会调包的人强出去一大截了。
