写这篇东西的起因是我最近面试了不少做 AI 应用开发的候选人也帮几个朋友内推过简历。一个很明显的现象是简历上十个有八个写着“熟悉 RAG 流程”但问到“你的切块策略怎么定的”“召回低于 70 你怎么办”“多轮对话里怎么区分 query 改写和历史记忆”很多人就开始含糊了。再往深一点问你 RAG 和 Agent 到底是什么关系、你的 RAG 流程怎么暴露成工具给 Agent 用基本就聊不下去了。这不是个别现象。RAG 和 Agent 是现在 AI 应用开发里最热的两个词但热词之下大家对这个领域的核心模块其实缺少一个全局认识。很多人是今天看一篇“RAG 实战”明天抄一段“Agent 框架 demo”最后发现换个场景全都跑不通。这篇就把我从 RAG 到 Agent 这一路做下来踩过的坑、总结出的核心模块、以及我理解的学习路线完整梳理一遍。内容会有点长但每一点都是能在实际项目里落地的东西。服务端、客户端、算法、全栈不管你现在是什么岗位只要你想真正上手 AI 应用开发这篇文章应该能帮你把脑子里那团浆糊理成一张地图。1. 先把手摸透RAG 不是“文档丢进去就能答”很多人的 RAG 入门是从“装一个 LangChain读一个 PDF问两句”开始的。跑通了就觉得掌握了 RAG。但实际上那只是把路打通了你的车能不能跑、跑得快不快、会不会半路抛锚一个都还不知道。RAG 的全称是 Retrieval-Augmented Generation检索增强生成。核心思路很简单大模型不是数据库它不知道你内部的最新数据那我就先把相关资料检索出来拼进 Prompt 里再让模型基于这些资料回答。听起来不复杂但这里面藏着四个关键环节文档解析与切块、向量化入库、检索召回、重排与生成。每一步都有讲究。1.1 文档解析与切块最不被重视、最容易翻车的环节我见过太多 RAG 项目死在第一步。最常见的情况是把 PDF 直接丢进框架解析出来全是乱码或者排版错乱。尤其是扫描版 PDF、带复杂表格的金融文档、工程图纸标注这类内容不做事先清洗后面做得再好都是白搭。现实里比较稳妥的做法是这样先按文件类型分流处理。文本型 PDF用 PyMuPDF 或 pdfplumber 提取优先保留段落结构和标题层级扫描版 PDF先走 OCR比如 PaddleOCR 或 Tesseract识别质量直接影响后续所有环节Word/Excel/PPT用 python-docx、openpyxl 这些库直接读别从 PDF 中转一道信息容易丢HTML/网页用 BeautifulSoup 或 Readability 提取正文去掉导航和广告。紧接着就是切块策略。这块的经典误区是“固定切 512 个字”。当然很多教程就是教你这么做但它只是“能跑”不是“跑得好”。实际项目里面我建议按结构优先的策略来切尽量让一个 chunk 保持语义完整。比如你先按标题切一级、二级标题如果某个标题下的内容太长再按段落切段落还长就按句子边界或固定窗口切同时设置一个 overlap通常是 50 到 100 个字符来保留上下文粘连。为什么 overlap 这么重要我举个实际例子你切出来的 chunk 1 末尾是“该项目的核心收益包括”chunk 2 开头是“成本降低 30%效率提升 50%”如果没有 overlap用户问“收益有哪些”检索很可能只召回 chunk 2 甚至只召回 chunk 1答案就残缺了。还有一个我强烈建议做的操作写一个好的 page_metadata 或者标题上下文注入。也就是把“这个 chunk 来自哪个文档、哪个章节、是什么文档类型”直接拼进 chunk 内容里这样不仅检索命中率高后面做引用溯源也就是给用户展示“答案来自哪一段”也方便很多。1.2 向量化与检索Embedding 模型怎么选是门手艺RAG 的第二个核心环节是把文本转成向量再用向量相似度做召回。这里的关键就是 Embedding 模型的选择。有些人会觉得选大的通用 Embedding 就一定好这真不一定。中文场景下常见的选择有 OpenAI 的 text-embedding-3-small、智源的 BGE、阿里的 text-embedding-v3还有开源的 bge-m3 等等。我个人的做法是先用一两个主流的本地可部署模型跑通流程之后再拿自己领域的数据做召回效果评测再决定要不要换。这里有个非常实用的经验如果预算和环境允许优先选支持 8K 甚至更长文本的 Embedding 模型比如 bge-m3这样你的 chunk 可以适度调大减少切片带来的信息碎片化问题。另外向量维度不需要盲目贪高512 维在大部分场景下已经足够1024 维以上收益不明显但计算和存储开销显著增加。检索环节最容易被忽略的是“相似度选择”。常见的向量检索库有 FAISS、Milvus、Chroma、pgvector每种都有自己适合的场景。FAISS 轻量适合单机Milvus 有分布式能力适合生产pgvector 的好处是能和结构化数据共用 PostgreSQL维护成本低。我自己在中小型项目里很喜欢 pgvector一条 SQL 就把向量检索和业务字段过滤全做了尤其是“只能查我自己上传的项目资料”这种业务权限过滤用 pgvector 写起来极其舒服。召回排序上一般用余弦相似度就够了。但如果你发现检索结果和用户问的语义不太对齐优先考虑混合检索——也就是向量检索加上 BM25/全文检索再通过 RRFReciprocal Rank Fusion把所有结果合并排序。很多开源框架把混合检索做成了标配我实际用过之后感觉召回率提升通常在 10 到 20 个百分点非常值得。1.3 重排与生成决定输出质量的那 20%如果说向量检索是海选那重排就是终审。常规向量检索返回 Top 20、Top 50 的候选里面可能参杂很多“看起来像、其实不对”的结果。这时候你用重排模型Reranker对候选按相关性重新打分只取 Top 三到五条拼进 Prompt输出的质量会大幅提升。重排模型和 Embedding 模型的原理不太一样。Embedding 是双塔模型把文本和 query 分别编码成向量计算快但精度有限重排模型通常是 cross-encoder把 query 和文档拼在一起一起编码计算重但精度高。所以实践上一定分两步先双塔粗召回再 cross-encoder 精重排。中文场景可以看看 bge-reranker效果不错。重排之后的生成环节反而被很多人忽视。我看到不少团队在 RAG 里就是简单把检索结果塞进 Prompt没有任何约束。结果经常是模型东拼西揍、自由发挥更夸张的是你问“根据检索内容回答”模型却开始用训练记忆里的常识来答。我的做法是在 System Prompt 里写明三条铁律。第一只能基于检索到的上下文回答检索不到就明确说不知道不许编造第二回答里需要引用具体来源时标明 chunk 编号或者原文片段第三避免把无关检索片段组合成错误结论。三句话就能明显减少幻觉。你还可以在生成层增加一个“相关性校验”计算检索结果与问题的相似度如果最高分都低于某个阈值直接让模型回答“未找到相关资料”这样体验反而比强行给答案好。2. RAG 不是终点Agent 才是 AI 应用的分水岭RAG 解决了“让模型拥有私有知识”的问题但它有一个明显的天花板一切都在单轮检索生成的框架里。用户说“帮我查一下上个月华南区的销售数据然后写一封分析邮件发给王总”RAG 的流程就要命了因为这是一个多步骤任务需要查数据表、编写内容、甚至触发发送动作单次检索生成根本做不完。这时候 Agent 就登场了。Agent 的核心价值不是“能聊天”而是“能行动”。它把一个复杂任务拆解成多个子步骤规划执行路径调用工具获取信息并根据每次执行的结果调整下一步动作。你可以把 RAG 理解为“给模型配了个图书馆”而 Agent 是“给模型配了手和脚”。2.1 工具调用Agent 的外接能力层Agent 的看家本领就是调用工具。一个简单的天气查询 Agent其实就有几个标准动作识别意图——发现用户要查天气提取地点实体——比如“北京”然后调用天气 API再把返回结果回填成自然语言。这套机制就是 Function Calling函数调用。具体到实现上你需要先把每个能力封装成函数再给每个函数写一份 JSON Schema 描述这个函数是干嘛的、参数有哪些、每个参数的类型和约束是什么。然后把这些 Schema 传给大模型模型在生成回复时如果判断需要调用工具就会输出一个结构化的调用请求函数名和参数 JSON你再拿这个请求去执行真实代码。这里有两个常见坑。第一个是函数描述写得不够细模型不知道该在什么时候调用它结果就是该调不调、不该调瞎调。第二个是参数设计不严密比如你让模型提取“时间”参数结果它填了个“最近三天”你的 API 根本解析不了。解决方法是描述里给足约束最好连示例参数都写进去。现在工具调用还有两个进阶方向值得关注。一个是 MCPModel Context Protocol这类标准化协议。之前每个 Agent 框架都搞自己的一套插件格式换个框架就得重写工具接入代码。MCP 想解决的就是这个“接口统一”问题用一套标准协议让模型服务器与各种工具服务对接。我看到的趋势是未来你写的工具如果支持 MCP 协议几乎可以被任何 Agent 框架直接复用。所以现在做工具开发优先考虑设计成符合 MCP 的格式长远来看回报很高。很多人问“RAG 和 MCP 有什么区别”其实就是RAG 是知识供给方式MCP 是工具连接协议二者解决的不是同一个问题。另一个是把 RAG 封装成一个工具给 Agent 调用。这一点非常关键也是我们常说的 Agentic RAG。你不再是一开始就做检索而是让 Agent 自己判断“这个问题需不需要检索、检索哪些范围、检索之后要不要追问”。这意味着你的 RAG 组件变成 Agent 工具箱里的其中一个工具它能被按需触发。2.2 记忆系统让 Agent 从“失忆症”里走出来如果说工具调用是 Agent 的手脚记忆系统就是它的脑容量。目前 Agent 的记忆分为三层短期记忆、长期记忆、工作记忆。短期记忆其实就是对话上下文。实现上最常见的是把最近几轮对话拼进 Prompt。但这里有个开销问题拼得越多Token 费越高而且过长的上下文还容易让模型抓不住重点。实践中的做法是给历史对话设一个滑动窗口一般保留最近 10 到 20 轮同时加一个摘要记忆——每隔 N 轮让模型把之前对话压缩成一个摘要存起来。这样既保住了长期语义又控制了 Token 成本。长期记忆则要复杂得多一般分两条路一条是把用户偏好、关键事实写进向量数据库或键值存储下次交互时按需检索出来注入上下文另一条是用一个轻量的记忆模型把原始对话抽取成结构化事实。我自己做过一个客服 Agent把“用户上次反馈了什么问题”“当前账户状态是什么”这类信息存在长期记忆里体验提升非常明显用户能明显感觉 Agent“记得我之前说过的事”。工作记忆是当前任务执行过程中的临时状态比如“已经把文件上传临时目录了”“正在等待审批接口返回”。这个一般直接放在 Agent 的上下文状态里但要注意序列化保存——因为一旦进程崩溃或超时任务状态不能丢否则整个编排流程就断了。2.3 规划与编排Agent 的大脑核心Agent 不是简单地“模型调用工具”它还需要规划能力。最经典的范式是 ReActReasoning Acting模型先“思考”下一步要做什么然后“行动”调用工具观察工具返回结果再继续思考下一步直到任务完成。这个循环可以理解为“想一步、做一步、看结果、再想下一步”每一步都是动态决策而不是预先把步骤定死。很多 Agent 框架里最常见的一个循环就是这么运作的。更复杂的任务可以用 Plan-and-Execute先让模型产出整体计划然后逐个子步骤执行执行完再整体校验是否需要修正计划。还有个思路叫反思Reflection就是让模型给自己的输出打分、找漏洞、再改。我在做客服 Agent 的时候就加了一个“自查”环节模型回答完先让另一个模型或者同一个模型用不同 Prompt检查一遍回答里有没有事实错误、有没有承诺做不到的事有就重写。虽然多了一次模型调用但输出质量提升很明显。编排框架这块LangGraph 是目前比较主流的选择。它的设计更像状态机把 Agent 的每一步节点和状态流转边显式地画出来方便调试也方便控制。如果你的场景比较复杂比如多角色协作、条件分支、人工介入审批那 LangGraph 这类框架会是更好的选择。一般单步工具调用用 LangChain 就够了但一旦你要做循环控制、状态管理最好直接上 LangGraph想清楚再动。需要提醒的是不要为了用 Agent 而用 Agent。很多人一听 Agent 就觉得高端恨不得所有需求都上 Agent。但实际上很多单轮问答场景用 RAG 就够了硬上 Agent 反而增加延迟、增加调用成本、增加故障点。我自己总结的一个判断标准是如果任务可以拆成固定规则流程就用普通 RAG 加规则如果任务里存在未知分支、需要动态决策或探索才上 Agent。这个取舍很关键。3. 技术栈选型与其纠结框架不如把基本功打扎实聊完理论和模块很多人肯定想问那我到底该学哪个框架LangChainLangGraphLlamaIndexAutoGen还是直接撸底层 API我的建议可能会让一些人意外先别急着上框架先从没有框架的方式跑一遍核心链路。比如你用 OpenAI 的函数调用 API自己实现一个简单的“意图识别 → 工具执行 → 结果回填”循环几十行代码就能跑通。这一步让你把底层机制吃透后面再用任何框架就都不慌了因为你只是把框架当工具而不是当魔法。框架封装度高反而容易让你迷失在抽象层里出了问日不知道去哪里排查。3.1 主流框架怎么选一张表讲明白现在主流的框架思路差异挺大我按自己的使用体感做个简单的分类框架定位适合场景学习成本我的建议LangChain组件超市快速组装 RAG 链路、工具调用中适合入门但生产里你会想替换它的鸡肋封装LangGraph图结构编排复杂 Agent 流程、分支、循环、状态机中高生产级 Agent 编排优先考虑LlamaIndex数据框架围绕数据接入、索引、检索的 RAG 深度定制中如果你的核心就是复杂 RAG值得深耕AutoGen / MetaGPT多 Agent 对话协作多个 Agent 互相讨论、分工完成复杂任务高多角色场景才用单 Agent 场景没必要原生 API 调用最底层学习原理、极致控制、轻量场景低强烈建议所有初学者先写一遍我个人给新人的路线是零基础先用原生 API 写一个带工具调用的极简 Agent理解 ReAct 循环然后用 LlamaIndex 或 LangChain 搭建完整的 RAG 链路体会切块、检索、重排每一步最后再用 LangGraph 做一个需要多步决策的真实项目比如“合同审查 Agent”或者“客服工单处理 Agent”。这三步走完你对 AI 应用开发这个领域的整体理解会比绝大多数只会看教程的人扎实得多。3.2 别忽略了工程化可观测性、评估与成本控制技术栈选型里最容易遗漏的是工程化模块。我见过不少团队模型选型、框架选型都做得漂漂亮亮但上线一周后就开始痛苦——因为他们的 Agent 完全是个黑盒不知道它调用了哪个工具不知道它为什么崩溃不知道用户问了什么问题它答错了更不知道怎么评估它到底做得好不好。这里有两个模块是必须学的第一个是可观测性。Agent 应用和传统应用完全不一样每一步都是模型决策出错了很难复现。所以从开发第一天开始就要把“每次调用的模型名、Prompt 全文、工具调用列表及参数、模型返回内容、延迟、Token 消耗”全部记录成日志最好有 trace 级联跟踪方便你回放整个决策过程。现在 LangSmith 和 Langfuse 这类工具就是干这件事的可以省下大量排查时间。第二个是评估体系。AI 项目的传统测试用例方式并不好用——你没法给一个 Agent 写一套固定的断言。更好的做法是建一个评测集里面包含 100 到 200 个真实问题每类问题标注好“正确答案的要点”和“应当使用的工具”然后每次你对 Prompt 或链路做修改都跑一遍评测集计算正确率、调用成功率、未拒绝率等指标。这一步的核心是可复现、可对比用数据来驱动迭代而不是靠感觉。这也是“AI 应用开发 SOP 文档”里最关键的一部分——没有评估一切优化都是空中楼阁。至于成本控制常规手段包括优先用小模型处理简单意图复杂问题再升级到大模型大量使用前缀缓存避免重复计费全链路 Token 日志审计能用规则和检索解决的就不要每次都把大招模型拉出来。3.3 关于岗位与市场现状的一点实话热词里有一个“中小自研公司的 AI 应用开发岗位多吗”我也想顺手聊两句。就我观察AI 应用开发岗位的需求在明显增长但岗位定义非常多样化。有的公司其实是想找“Prompt 工程师 后端开发”有的公司想要“能独立搭建 RAG 平台的全栈”还有的在找“能设计 Agent 工作流的算法工程”差别很大。稀缺的其实不是大模型算法岗位而是能结合业务场景、把模型和工具真正用起来的人。很多中小公司并不需要自己去训练模型他们需要的是能快速理解业务、组装 RAG/Agent、并让系统稳定跑在生产环境的人。所以你学好这块的价值是非常真实的。但有一点要提醒面试的时候比起“你用过哪些框架”面试官更在意“你解决过什么问题”。比如你做过一个切块策略优化的项目和结果、你做过检索质量评测的方案、你处理过 Agent 循环失控的案例这些具体经历才是最有说服力的。4. 实战项目怎么做从问题定义开始而不是从框架开始学了一堆模块最怕的是眼高手低。我建议你自己动手做一个完整的项目来收口而选项目时有一个非常重要的原则不要做一个“教程里早就做烂的聊天机器人”要选一个你有领域背景、数据可获取、并且你愿意花时间去打磨的真实场景。我自己带人常用的一个入门项目是“公司内部文档问答助手”。听上去很普通但它的优势是数据是你自己构造或收集的你可以控制文档类型PDF、Word、Excel 都有你可以自己定义问题评测集比如 50 个高频问答你还可以加权限过滤需求一套坐下来RAG 的每一步都会亲手摸到。第二层进阶把它升级为“工单自动处理 Agent”用户提交一个工单描述Agent 先调用分类工具判断工单类型再检索相似历史工单根据检索结果生成回复初稿然后调用审批接口或人工复核接口完成闭环。这个项目里就真正用到了 Agent 的规划、工具调用、记忆和编排。4.1 实操流程一个 RAG 项目从零到一的关键节点我把一个真实 RAG 项目的完整流程列出来你可以直接当 checklist 用问题定义与数据盘点明确用户要问什么、数据在哪、数据质量如何、更新频率多高。这一步做不好,后面全都是白搭。搭建基线 RAG不做任何优化用最简单的方式跑通“文档 → 切块 → 向量化 → 检索 → 生成”全链路先拿到一个能跑的结果。构建评测集整理 50 到 100 个用户真实可能问的问题人工标注答案要点和期望引用的来源段落。这是你后续优化的指挥棒。检索质量优化用评测集跑召回指标看看是切块导致的语义割裂还是 embedding 不匹配导致的语义鸿沟或者是候选召回量太少逐项优化。生成质量优化调整 Prompt 约束、加入重排、控制引用格式用评测集对比修改前后的输出质量。工程化封装把链路封装成 API 服务加上访问鉴权、日志、监控、限流。维护迭代数据更新后要能增量更新向量索引用户反馈“答得不对”的问题要回流到评测集里形成闭环。每一步都有一个关键词评测。我见过太多项目调 Prompt 全靠感觉改一下切块策略也不做对比测试上线以后效果越来越飘。如果你能养成“每次改动用评测集打一次分”的习惯这个项目的质量就稳了大半。4.2 多轮对话与 Agent 记忆的设计实践很多人在多轮对话上栽跟头我单独讲一下。RAG 场景里的多轮对话最大的问题是用户第二句话经常省略上下文。比如用户先问“华东区这个月业绩怎么样”Agent 回答后用户又说“那同比呢”——此时如果直接把 “那同比呢” 拿去检索必然失败。两种常见解法一种是 query 改写让大模型先结合前文把问题补全为“华东区这个月业绩与去年同期相比怎么样”再拿去检索另一种是直接把上一轮检索到的上下文追加到当前轮次的检索条件中再综合检索。我自己实践下来query 改写加一点“历史关键实体”注入效果最好成本也不高。在 Agent 场景里记忆的设计则要更小心。有些 Agent 框架默认把全部历史对话塞进上下文很快就超过上下文窗口然后就开始胡言乱语。我的经验是维护一个“任务记忆池”把用户目标、已完成步骤、当前待办、关键约束分别抽取出来存成结构化 JSON每次只把最相关的那部分注入上下文。比如客服 Agent每次只需要注入“用户当前诉求、账户状态、最近一次沟通摘要”而不是把过去 30 条消息原样全塞进去。这样既稳当又便宜远比无脑堆历史对话靠谱。4.3 避坑清单这些坑我踩过你们别踩了我整理一份高频踩坑清单每一个都是真实项目里遇到过的只按固定字符数切块导致语义割裂和跨块信息分散不做格式清洗PDF 引号、换行符、编码问题直接污染向量直接把大模型训练知识当答案来源检索结果反而成了摆设召回 Top 5 就直接拼进 Prompt没做重排低相关片段干扰输出向量数据库选了不支持过滤的导致业务权限控制无法实现Agent 工具函数描述写得像 API 文档模型在真实对话里不知道怎么调用不加循环上限Agent 卡在闭环里不断调用工具Token 烧完才开始报错没有日志追踪线上 Agent 犯错之后根本没法复现没有评测集每次改 Prompt 都像是在赌运气。这九条你随便命中几条项目体验都会很难受。其中我觉得最隐蔽的是“工具函数描述”这条。因为你语义上觉得写得很清楚但模型理解方式和人不一样你得站在模型的角度去想我给的这些参数模型能从用户的话里提取出吗真实用户不会说“帮我调用 search_engine(query绩效考核方案, top_k10)”他们只会说“你帮我找找绩效考核相关的东西”。所以你的函数描述必须写成“用户想找某个文档时调用”并且把实体提取的规则写明白。5. 从学习到落地给你一条看得见的路说了这么多最后给一个可以直接照着走的学习路线。我更建议你把它当成一个 6 到 8 周的副线任务每天投入一到两小时而不是突击式地看一堆视频。第一周搞懂基础假装自己有手。认真读一遍 OpenAI Function Calling 或 Claude Tool Use 的文档然后用原生 API 写一个“能查询天气并回答”的极简 Agent。这不难但足够让你理解“工具调用”到底是怎么发生的。同时把 RAG 的四个环节用文字形式画一遍不需要画复杂的图就想清楚数据从哪来、存到哪、怎么取、怎么答。第二到三周完整搭建一个本地 RAG 项目。选一批你自己的文档用 Python 写一个不依赖重型框架的 RAG 服务文档解析用 PDF 库、向量化用开源模型、检索用 FAISS 或 SQLite 向量、生成用任意大模型 API。整个链路都自己写能写多简单写多简单关键是每一行都要知道它在干嘛。然后构建你的评测集记录基线成绩。第四到五周从 RAG 升级到 Agent。把之前写的 RAG 封装成一个工具函数然后用“意图识别 → 工具调用循环”的方式做一个客服工单 Agent。重点练习工具描述怎么写、状态怎么管理、loop 怎么终止。如果中途发现框架能帮你解决很多重复劳动再去引入 LangGraph。第六到八周做工程化和评估。给你的 Agent 加上日志追踪、评测集跑分、失败案例回流机制再对照我前面说的避坑清单逐项排查。最后写一份你自己的“项目复盘文档”记录遇到的问题和解决过程。这份复盘就是你面试时最有价值的东西。最后再分享一个个人经验。我在做 AI 应用开发时特别受用的一句话是“模型是下限链路是上限”。同一个模型有人做出来的 RAG 召回率 90%有人只能做到 60%差的往往不是 API 调用姿势而是切块、检索、重排、评测这些链路细节。Agent 更是如此同样的模型能力编排得好就是高效自动化编排得烂就是连环翻车事故。先把链路吃透再追模型热点方向就不会错。希望这篇长文能帮你把这整条链路看得更清楚也欢迎在评论区聊聊你自己做 RAG 和 Agent 时踩过的坑。