AI应用开发学习路线：RAG、Agent、LangGraph与微调实战指南

如果你准备在 2026 年往 AI 应用开发工程师方向走，最需要先想清楚的，不是要不要学会某个新框架，而是 RAG、Agent、LangChain、LangGraph、模型微调这几块能力分别解决什么问题。很多人把大量时间花在追新上，最后写不出一个完整项目，原因不是笨，而是学习顺序乱了。这篇文章按我从实际项目里总结的能力结构拆一遍，重点讲清楚每一块什么时候学、怎么验证、容易在哪里踩坑。如果你已经能调 API 写提示词，但还没完整交付过 RAG 或 Agent 项目，这篇应该对你有用。

1. 先看懂 AI 应用开发的能力结构，而不是急着追新

很多刚开始学的人会陷入一个误区：看到 RAG、Agent、LangChain、LangGraph、模型微调这些词，就以为是一个进阶列表，先学 A 再学 B，学完就成专家。实际上不是。

这块领域更像是“按业务需求组合能力”。2026 年岗位名称可能还会变，但底层要处理的问题基本是固定的：让模型知道你的私有知识，让模型能调用外部工具，让多步骤流程稳定可控，让模型输出符合行业要求。下面先把这五块东西对齐到同一个坐标系里。

1.1 五块核心能力分别解决什么问题

RAG，检索增强生成，解决的是“模型不知道你的数据”。模型训练完之后，新文档、内部知识、最新资料它都不了解。RAG 的做法是先把文档切碎、转成向量，用户提问时先检索相关内容，再把检索结果和问题一起交给模型。简单说，就是给模型开卷考试。

Agent，解决的是“一个提示词搞不定的多步任务”。比如用户说“帮我查一下最近的订单物流，如果预计延迟就发一条提醒”，你需要先决定调用哪个接口、传什么参数、拿到结果后是否需要再调用另一个接口。Agent 的核心是模型自己决策操作顺序。

LangChain 和 LangGraph，解决的是“把上面这些组件更规范地串起来”。LangChain 给出一套链式抽象，LangGraph 则把流程建模成一张图，支持条件分支、循环、并行节点。它们不是模型，也不是业务本身，而是编排层。

模型微调，解决的是“通用模型的行为不符合你的预期”。比如你希望模型始终用固定格式输出、严格使用专业术语、不能跑题。微调不是补充知识，而是修改模型做事的习惯。

1.2 这几块能力不是并列关系，而是一条交付链路

可以把交付一个 AI 应用的过程拆成五个环节：

1. 理解需求，判断哪些用 RAG、哪些用 Agent、哪些必须微调。
2. 准备数据，把文档、表格、接口定义整理成模型能用的输入。
3. 选型编排方式，简单流程用 Chain，复杂状态机用 LangGraph。
4. 跑通最小闭环，先保证一条主流程能出结果。
5. 优化可靠性，加日志、超时、失败重试、质量检查。

我见过不少项目失败，不是模型不好，而是这五步中间断掉了。比如只做了向量检索，没有做结果校验；或者 Agent 循环没有设置最大次数，线上跑着跑着就卡住。学这些技术时，最好脑子里始终带着“这样改是为了哪一环更稳”。

1.3 不同技术背景的人，建议从不同位置切入

如果你是后端工程师，可以从接口和数据处理切入。先学 RAG 的文档加载、解析、切分，再学 Agent 的工具定义和日志链路，最后补 LangGraph 的状态管理。

如果你是算法工程师，可以从评估切入。你不需要从头写很多业务逻辑，但你要知道怎么判断 RAG 检索质量、Agent 决策是否正确、微调后是否产生遗忘。

如果你只会调用 API，也不用慌。2026 年做 AI 应用开发，更多是组合能力和边界判断能力，而不是从零写模型。你缺的通常是工程习惯，比如路径、日志、异常处理、参数配置。这些会在后面每一步中反复用到。

2. RAG：知识库问答是最容易跑通、也最容易做差的一环

很多人学 AI 应用开发的第一个项目，就是做一个 RAG 知识库问答系统。这个选择很合理，因为它的链路清晰：文档加载、切分、向量化、检索、生成。但也是因为这个链路太清晰，很多人容易忽略每个环节里的细节，最后做出一个“demo 能跑，换数据就崩”的系统。

2.1 最小闭环：加载、切分、向量化、检索、生成

一个标准 RAG 流程可以拆成五步：

1. 文档加载：读取 PDF、Markdown、Word、HTML、数据库记录。
2. 文档切分：把长文本切成块。不能太长，否则检索不精准；不能太短，否则语义不完整。
3. 向量化：用 embedding 模型把文本块转成向量。
4. 检索：用用户问题去向量库找最相似的 Top-K 文本块。
5. 生成：把检索到的文本块和用户问题一起拼进 Prompt，交给大模型回答。

我在本地环境做测试时，会先用一个小文档跑通流程，确认每个步骤的输出格式。比如加载之后打印文本长度，切分之后打印块数，向量化之后检查向量维度，检索之后打印召回片段。这一步很多人图省事跳过，后面出了问题往往要花更长时间定位。

如果不想从零写，也可以用 Dify 这类平台把知识库流程串起来，适合先验证业务效果。但作为学习，我建议至少手动实现一次，否则你很难理解后面出问题是在哪一层。

2.2 切块策略不能拍脑袋，要按检索结果反推

切块是 RAG 里最影响效果、也最容易被低估的环节。固定长度切块很简单，比如每 500 个字符切一块、重叠 50 个字符，但遇到表格、代码、法律法规条文时效果往往不稳定。

常见切块策略有几种：

• 固定长度切块：实现简单，速度快，适合内容结构均匀的文本。
• 递归分割：先按段落、再按句子、最后按字符，尽量保留语义边界。
• 语义切块：根据句子相似度或主题变化自动决定断点，效果通常更好，但需要额外计算。
• 结构感知切块：针对 Markdown、PDF 标题、表格结构做特殊处理，适合文档类型固定的场景。

判断切块策略好不好，不能只看“能不能切”，要看检索结果对不对。我会用几个典型问题来回测：每个问题应该命中哪个段落，实际命中了什么。如果召回内容答非所问，优先怀疑切块大小和切分边界，而不是模型效果。

还有一个常见思路是做 GraphRAG 或 Ontology RAG。简单说，就是先用实体和关系把领域知识结构化，再在检索时沿着关系扩散。比如做医疗问答，直接向量检索可能忽略“某症状属于某科室”的关系，而结构化的知识约束可以让结果更可靠。这类方案实现成本更高，适合业务对准确性要求较高、且领域实体关系明确的场景。

2.3 引用溯源与 groundedness：答案是“生成出来的”还是“有依据的”

RAG 最容易出现的问题，是模型把检索到的内容和自己的幻觉混在一起，输出看起来很有道理，但实际没有来源。解决思路是给答案做“引用溯源”，也就是让模型在生成时标注每个结论来自哪个文档块。

工程上可以这样做：

• 检索时保留每个文本块的文档名、页码或块 ID。
• Prompt 里明确要求：只能依据检索内容回答；引用时标注来源编号。
• 输出结果中附带来源列表，前端可以展示。
• 单独做一层 groundedness 判断，检查答案是否过度发散。

我见过不少 RAG demo 没有做引用溯源，用户问完问题，得到一段流畅答案，但没人知道这段答案是不是可靠。一旦应用面向真实业务，这基本不可接受。你至少要有办法把答案回溯到原始文档。

2.4 本地低配环境怎么搭 RAG 示例

如果你的机器没有像样的大显存，也可以跑一个可以学习的 RAG 示例。常见组合是用 llama.cpp 跑一个较小的开源模型，比如 Qwen 2 7B，用 FastAPI 提供接口，再配一个本地 embedding 模型和向量数据库。

这类方案要注意几点：

• 7B 模型对显存、内存和 CPU 的要求不低。纯 CPU 跑很慢，建议把模型量化版本调低。
• embedding 模型和生成模型分开，不要混用。
• 向量库在小项目里可以用 Chroma 或 FAISS，数据量不大时足够。
• 本地方案的用途是验证链路，不是追求生产级性能。

如果你只是学习 RAG，也可以先调用云端 API 做生成部分，本地只负责文档解析和向量检索。这样能把最难的部分留在本地练习，又不会被推理速度拖累。

3. Agent：工具调用与任务循环，先保证可控再谈自主

Agent 是 2026 年 AI 应用开发里讨论最多的方向之一。很多人把 Agent 想象得很新，其实核心机制并不神秘：模型根据用户任务，决定调用哪个工具、传什么参数、得到结果后继续下一步，直到任务完成或达到停止条件。

难点在于，这个循环一旦放开，不可控因素会变多。你可能遇到模型反复调用同一个工具、工具返回格式不符合预期、上下文越来越长、某个外部接口超时等问题。做 Agent 开发，第一目标是可控，其次才是智能。

3.1 从 Chain 到 Agent，多出来的其实是“决策循环”

在 LangChain 里，Chain 是预定好的调用顺序：先做 A，再做 B，最后输出。这种模式适合任务路径固定的场景，比如先检索后生成。Agent 不同，它会让模型自己选择下一步动作。

你可以把 Agent 理解成一个带工具和循环的 Chain：

1. 接收用户输入。
2. 模型判断需要调用哪个工具。
3. 执行工具，拿回结果。
4. 模型判断结果是否满足任务需求。
5. 不满足就继续下一步，满足就输出最终答案。

每一步都是一次模型推理。所以 Agent 的响应时间通常比普通 RAG 长，成本也更高。这不是 bug，是决策循环的代价。如果你发现某个任务路径其实是固定的，就不要硬上 Agent，用一个 Chain 更省钱、更稳定。

3.2 工具定义、上下文管理和日志是三个最容易出问题的地方

做 Agent 开发，我一般先盯三个点。

第一是工具定义。每个工具的说明、参数、返回结构要写清楚。模型是靠说明文字决定要不要调用工具的，工具说明含糊，决策质量就会下降。建议给工具加示例输入输出，甚至把失败返回值也写清楚。

第二是上下文管理。Agent 每执行一步，都要把新的工具结果追加到历史里。步数多了，上下文会越来越大，既增加成本，也可能超出模型的上下文窗口。常见的做法是只保留最近几轮消息，或把比较早的工具结果压缩成摘要。

第三是日志。不要只记“调用成功”或“调用失败”，要记下每一步的模型输出、工具参数、工具返回、耗时和 token 数。只有这样才能复现模型为什么走了一条错误路径。很多开源项目会强调自己的安装和执行环境，但在我看来，工程上区分 harness 和 agent 也值得理解：harness 更像承载 Agent 运行的壳，负责输入输出、工具执行、生命周期；Agent 本身是决策逻辑。理解这个区别，排查问题时思路会更清楚。

3.3 Agent 卡死或超时，先按这条顺序排查

实际开发中，很多人会遇到类似“the agent execution provider did not respond in time”的超时错误。不要一上来就怀疑模型能力有问题，按下面的顺序排查：

1. 先看日志，卡在哪一步。是模型生成超时，还是工具调用超时？
2. 再看工具本身。工具是否真的能访问网络、数据库、文件系统？权限够不够？参数是否传对？
3. 再看上下文长度。如果历史消息太长，模型响应时间会明显变慢，甚至触发超时。
4. 再看并发和排队。多个 Agent 同时跑时，外部接口可能扛不住，需要在代码层加重试和限流。
5. 最后看 Agent 配置。Agent 循环是否有最大步数、超时时间是否设得太短、失败重试策略是否合理。

我通常会把 Agent 的步数上限设小一点，比如先设 5 步，跑通了再逐步放开。不要一上来就开最大并发，先用一条样例确认输入、输出和日志都正常。

3.4 开源 Agent 项目很多，别只看安装方式

目前开源社区有大量 Agent 项目。有的偏个人助理，有的偏 API 编排，有的偏终端交互。命名也各不相同，比如常见的一类叫 agent，也有的用 assistant、harness、pi 这类名字。面对这些项目，不要只看安装是否方便，要重点看三件事：支持的模型接口有哪些、工具定义方式是否适合你的业务、有没有内置失败重试和超时机制。

如果你只是想理解 Agent 原理，自己写一个最简循环可能更有效。工具列表可以只有一个“当前时间”函数，模型判断要不要调用。这个过程跑了之后，你会对“模型决策 + 工具执行 + 结果回填”的组合有更直接的感受。

4. LangChain 与 LangGraph：编排框架的正确使用姿势

LangChain 和 LangGraph 是这个生态里最常被问到的两个词。很多初学者把 LangChain 当成一个“必须熟练掌握的框架”，其实它更像一套工具包。LangGraph 则是后来出现、更偏图状态机的编排方案。两者不是替代关系，而是侧重点不同。

4.1 LangChain 入门时最该理解的三层东西：链、记忆、工具

LangChain 的入门知识可以压缩成三层：

• 链（Chain）：把多个步骤串起来。比如“检索外部知识 -> 组装 Prompt -> 调用模型 -> 输出答案”。
• 记忆（Memory）：保存对话历史，让模型能引用上一轮的信息。常见做法是把历史消息放进 Prompt。
• 工具（Tool）：把函数、API、数据库查询包装成模型可以调用的能力。

入门时不要背太多类名，先手动搭一个简单流程，理解每一层的数据结构。很多人学 LangChain 时被文档绕晕，是因为没想清楚自己只是要“调用一次模型”，还是要“构建一个有状态的多轮流程”。

文档方面，LangChain 官方文档会更新得比较快，学习时尽量认准当前版本，不要拿几个月前的旧代码硬跑。版本之间 API 调整挺常见，报错时先看一下版本兼容。

4.2 LangGraph 到底改了什么事：状态、条件路由、循环、子图、并行

LangGraph 的核心理念是把流程建模成有向图。每个步骤是一个节点，节点之间是边。和多数的 Chain 相比，LangGraph 最明显的变化是四个能力。

第一，状态管理。整个流程共享一个状态对象，每一步可以往状态里写入新内容，后续节点可以读取。

第二，条件路由。从一个节点出发后，根据条件决定走哪个分支。这非常适合设计“先判断是否需要检索，不需要就跳过检索直接生成”的流程。在 LangGraph 里常见的形式是条件边，约定哪个返回值走哪个分支。

第三，循环检测。Agent 本质上就是循环：模型决策 -> 调用工具 -> 再次决策。LangGraph 允许节点回到前面的节点，形成循环，同时可以设置最大循环次数，避免停不下来。

第四，子图和并行分支。子图可以把一段复用的流程抽离出来，比如“格式化输出”子流程。并行分支则适合处理“同时检索文档 A、文档 B、调用接口 C”这类任务。

学 LangGraph 时，我建议先不看太多高级特性，而是先画一张图：输入节点、判断节点、工具节点、输出节点。把图画出来，再对应到代码，理解会快很多。

4.3 什么时候用 LangGraph，什么时候不要用

LangGraph 不是所有项目都需要。如果你的业务流程是固定的三条直线路径，用普通代码或 Chain 完全够。引入一个图框架会增加理解和维护成本。

我一般用这样的判断标准：

• 需要条件路由：用。比如客服系统里，先判断用户类型，不同用户走不同处理流程。
• 需要循环：用。比如 Agent 多步工具调用。
• 需要并行分支：用。比如同时查库存、查订单、查物流。
• 只是按固定顺序调两三次模型：不用。普通 Python 函数串起来更清楚。

还有一点值得说。有人问 LangGraph 有没有 Rust 版本，这类问题背后真正关心的，是编排层能否脱离 Python 生态。目前在常见开源生态里，LangChain 和 LangGraph 的 Python 和 TypeScript 版本最普及，Rust 方向更多是社区尝试。如果你对性能敏感，更合理的做法不是找一个 Rust 版编排框架，而是把耗时操作放到独立服务里，让编排层只管流程控制。

4.4 长期记忆和上下文管理怎么设计

多轮 Agent 项目绕不开记忆问题。LangGraph 的常见记忆方式有两类：短期记忆和长期记忆。

短期记忆可以放在状态里，保存当前任务中的对话轮次和工具执行结果。长期记忆则要看业务需求，可以持久化到数据库、向量库或普通缓存中。

设计记忆时要注意：不是所有历史都要留在上下文里。信息太多会影响模型判断速度，也会拉高成本。按我的习惯，会把“用户核心事实”和“最近几轮对话”保留，把太久的工具返回摘要化。长期记忆要设计成可以按用户维度或会话维度读取，并且要保证不同会话之间不会串数据。

5. 模型微调：不要为了“显得专业”去微调

模型微调是五个关键词里成本最高、风险也比较大的一块。很多人学到后期会产生一种冲动：我的应用效果不好，是不是微调一下就解决了？实际上，大多数情况下先要考虑的是 RAG 和提示词优化，微调的投入要放在更靠后的位置。

5.1 先想清楚：知识不足用 RAG，行为不对才考虑微调

RAG 和微调解决的是两类不同问题。

用一张表来对比会更清楚。

如果一个问答系统答错，是因为知识库里根本没有相关信息，那优先补文档或优化检索。如果模型知道答案，但输出总是缺字段、格式乱、术语不专业，那才需要考虑微调。

5.2 不微调模型也能拓展垂类应用的几种方式

“有什么方法不微调模型也可以拓展垂类应用”是很多人会搜的问题。这确实值得先说清楚。

第一种是 RAG。通过外部知识库，让模型在回答时带上领域内容，天然适合内容型业务。

第二种是提示词工程。把业务规则、格式要求、判断标准写进系统提示词。简单有效，缺点是提示词越长，模型越容易忽略部分要求，需要反复测试。

第三种是工具调用和外部规则。比如模型自己不擅长计算，那就让它调用计算函数；模型不擅长查实时数据，那就让它调用数据库接口。把复杂能力外包给外部系统，模型只负责拆任务和组装结果。

第四种是后处理校验。对模型输出做规则校验、格式解析、强制纠错，不满足要求就重新生成。这类做法经常被忽略，但非常实用。

你可以把这几种方式组合起来。先用提示词定规则，用 RAG 补知识，用工具补能力，最后做一层输出校验。大多数垂类应用到这一步就够了，不一定要微调。

5.3 真正需要微调的场景和前置条件

如果你的业务有下面几种情况，微调才变得必要。

第一种，输出格式极度固定。比如必须输出严格 JSON，字段不能多也不能少。提示词可以压到一定准确率，但要达到很高的稳定性，微调可能更合适。

第二种，领域术语密集且使用方式特殊。比如法律条文、医疗诊断、工业维修手册。通用模型可能偶尔用错术语，微调可以让模型形成稳定的表达习惯。

第三种，特定交互风格。比如客服助理必须语气克制、不能主动越权。如果你试了多次提示词仍不稳定，微调可以作为补充。

但微调的前置条件很高。首先需要一份质量不错的数据集，每条输入、输出都要对齐业务标准。其次需要一个评估集，用来判断微调前后是变好还是变坏。再次要有算力，或至少能使用参数高效微调方案，比如 LoRA。最后还要做灾难性遗忘检查，防止模型学了新知识后，把通用能力丢掉。

不要一开始就追求在完整大模型上做全量微调。先选一个小一些的模型，整理几百条高质量样例，用 LoRA 方式试跑，评估效果，再决定是否扩大数据规模。

5.4 微调项目的验收标准和常见翻车点

微调项目不要只看“Loss 降了”就认为成功。真正的验收要看几个方向：

• 目标任务准确率有没有提升。
• 通用能力有没有明显下降。
• 格式稳定性是否达标。
• 对用户输入的对抗性和边界情况是否应付得了。

常见翻车点也很集中。数据标注不一致会导致模型行为混乱；正例太多、负例太少会让模型只会答应不会拒绝；训练集和评估集分布不一致会让人误判效果。还有一点，微调之后模型在已知样例上很听话，但换一批相似表达就失效。这说明数据集多样性不足，不是模型问题。

6. 2026 年的实践路线：从一个端到端项目开始

把前面五块能力拆开讲完，最后落到实践。2026 年做 AI 应用开发，真正拉开差距的往往不是谁更了解某个库，而是谁能把一条链路完整地跑通并稳定交付。下面按我的建议给出一套顺序，以及每一阶段的验收标准。

6.1 一套可复用的学习顺序

如果基础一般，建议按下面的顺序推进：

1. 先掌握模型调用的基本能力。能通过 API 或本地模型完成对话、JSON 输出、流式输出。
2. 再做一个最小 RAG 项目。必须包含文档加载、切分、向量化、检索、生成、引用展示。
3. 然后做一个受限 Agent。只提供两三个工具，跑通工具调用循环，加入最大步数和超时控制。
4. 接着把 Agent 流程迁移到 LangGraph。把判断、调用、结束抽成节点，用条件路由控制。
5. 最后再评估是否需要微调。不要在前四步没跑通时提前进入微调。

每个阶段都要有验证标准。RAG 阶段至少要回答三个问题，并保证答案能追溯到原文。Agent 阶段至少要能连续完成一个多工具任务，并保证单条失败不会拖垮整个流程。LangGraph 阶段至少要能做“条件分支 + 循环 + 中断恢复”其中的两项。

6.2 三个项目练手：知识库问答、客服 Agent、带记忆的复杂流程

项目太多会让人迷失，我建议重点做三个。

第一个项目是领域知识库问答。不限领域，选自己熟悉的，比如内部 IT 运维手册、产品说明书。重点练文档解析、切块、引用溯源。这个项目做完，你应该能说清楚：同一个问题，为什么换了切块策略答案就变了。

第二个项目是客服 Agent。给它提供订单查询、物流查询、退款规则三个工具。重点练工具定义、上下文管理、超时重试。这个项目做完，你应该能处理“Agent 走错分支”的问题，而不是只会对着错误提示发呆。

第三个项目是带记忆的复杂流程。增加长期记忆，让 Agent 能记住用户偏好。再把流程拆成子图和并行分支。这个项目做完，你对 LangGraph 的状态和路由就已经有实际体感了。

这三个项目不需要都用生产级配置。先跑通，再优化，再考虑并发和接口化。

6.3 通用排查顺序与上线前检查清单

最后给一份排查顺序，你会在很多问题里反复用到。

1. 先看现象。是报错、卡住、无输出、输出质量差，还是速度慢。
2. 再看输入。文件路径是否正确、编码是否有问题、输入格式是否符合预期。
3. 再看环境。依赖版本是否兼容、权限是否足够、磁盘和内存是否够用。
4. 再看参数。并发数、批量大小、超时时间、模型路径、输出目录是否设置正确。
5. 最后看框架本身。版本差异、功能边界、已知限制。

上线前检查清单也不要忽略：

• 有没有日志可以追踪每一步。
• 有没有失败重试和超时控制。
• 输出目录和命名是否唯一，批量任务会不会互相覆盖。
• 敏感信息有没有被打进日志或上下文。
• 评估集是否可以反复用来比较版本效果。
• 还能不能回到上一个可用版本，数据和配置有没有版本管理。

这些点看起来不如“让 Agent 更聪明”有趣，但实际项目里最容易出问题的就是它们。把基础链路做稳，比追一个高深的新概念更能提高交付质量。如果你只能记住一句话，我建议是：先把单条任务跑稳，再谈批量、并发和微调。