如果你准备在 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 应用的过程拆成五个环节理解需求判断哪些用 RAG、哪些用 Agent、哪些必须微调。准备数据把文档、表格、接口定义整理成模型能用的输入。选型编排方式简单流程用 Chain复杂状态机用 LangGraph。跑通最小闭环先保证一条主流程能出结果。优化可靠性加日志、超时、失败重试、质量检查。我见过不少项目失败不是模型不好而是这五步中间断掉了。比如只做了向量检索没有做结果校验或者 Agent 循环没有设置最大次数线上跑着跑着就卡住。学这些技术时最好脑子里始终带着“这样改是为了哪一环更稳”。1.3 不同技术背景的人建议从不同位置切入如果你是后端工程师可以从接口和数据处理切入。先学 RAG 的文档加载、解析、切分再学 Agent 的工具定义和日志链路最后补 LangGraph 的状态管理。如果你是算法工程师可以从评估切入。你不需要从头写很多业务逻辑但你要知道怎么判断 RAG 检索质量、Agent 决策是否正确、微调后是否产生遗忘。如果你只会调用 API也不用慌。2026 年做 AI 应用开发更多是组合能力和边界判断能力而不是从零写模型。你缺的通常是工程习惯比如路径、日志、异常处理、参数配置。这些会在后面每一步中反复用到。2. RAG知识库问答是最容易跑通、也最容易做差的一环很多人学 AI 应用开发的第一个项目就是做一个 RAG 知识库问答系统。这个选择很合理因为它的链路清晰文档加载、切分、向量化、检索、生成。但也是因为这个链路太清晰很多人容易忽略每个环节里的细节最后做出一个“demo 能跑换数据就崩”的系统。2.1 最小闭环加载、切分、向量化、检索、生成一个标准 RAG 流程可以拆成五步文档加载读取 PDF、Markdown、Word、HTML、数据库记录。文档切分把长文本切成块。不能太长否则检索不精准不能太短否则语义不完整。向量化用 embedding 模型把文本块转成向量。检索用用户问题去向量库找最相似的 Top-K 文本块。生成把检索到的文本块和用户问题一起拼进 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接收用户输入。模型判断需要调用哪个工具。执行工具拿回结果。模型判断结果是否满足任务需求。不满足就继续下一步满足就输出最终答案。每一步都是一次模型推理。所以 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”的超时错误。不要一上来就怀疑模型能力有问题按下面的顺序排查先看日志卡在哪一步。是模型生成超时还是工具调用超时再看工具本身。工具是否真的能访问网络、数据库、文件系统权限够不够参数是否传对再看上下文长度。如果历史消息太长模型响应时间会明显变慢甚至触发超时。再看并发和排队。多个 Agent 同时跑时外部接口可能扛不住需要在代码层加重试和限流。最后看 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 和微调解决的是两类不同问题。用一张表来对比会更清楚。对比项RAG模型微调核心目标给模型补充外部知识改变模型的行为和输出习惯更新成本换文档、重新索引即可需要准备数据集、重新训练可追溯性答案可以回溯到原文很难说清某个行为来自哪条数据算力要求主要花在检索和推理训练前、训练中、推理都需要额外算力适合场景知识密集、内容经常更新输出格式固定、术语约束强、行为需要稳定如果一个问答系统答错是因为知识库里根本没有相关信息那优先补文档或优化检索。如果模型知道答案但输出总是缺字段、格式乱、术语不专业那才需要考虑微调。5.2 不微调模型也能拓展垂类应用的几种方式“有什么方法不微调模型也可以拓展垂类应用”是很多人会搜的问题。这确实值得先说清楚。第一种是 RAG。通过外部知识库让模型在回答时带上领域内容天然适合内容型业务。第二种是提示词工程。把业务规则、格式要求、判断标准写进系统提示词。简单有效缺点是提示词越长模型越容易忽略部分要求需要反复测试。第三种是工具调用和外部规则。比如模型自己不擅长计算那就让它调用计算函数模型不擅长查实时数据那就让它调用数据库接口。把复杂能力外包给外部系统模型只负责拆任务和组装结果。第四种是后处理校验。对模型输出做规则校验、格式解析、强制纠错不满足要求就重新生成。这类做法经常被忽略但非常实用。你可以把这几种方式组合起来。先用提示词定规则用 RAG 补知识用工具补能力最后做一层输出校验。大多数垂类应用到这一步就够了不一定要微调。5.3 真正需要微调的场景和前置条件如果你的业务有下面几种情况微调才变得必要。第一种输出格式极度固定。比如必须输出严格 JSON字段不能多也不能少。提示词可以压到一定准确率但要达到很高的稳定性微调可能更合适。第二种领域术语密集且使用方式特殊。比如法律条文、医疗诊断、工业维修手册。通用模型可能偶尔用错术语微调可以让模型形成稳定的表达习惯。第三种特定交互风格。比如客服助理必须语气克制、不能主动越权。如果你试了多次提示词仍不稳定微调可以作为补充。但微调的前置条件很高。首先需要一份质量不错的数据集每条输入、输出都要对齐业务标准。其次需要一个评估集用来判断微调前后是变好还是变坏。再次要有算力或至少能使用参数高效微调方案比如 LoRA。最后还要做灾难性遗忘检查防止模型学了新知识后把通用能力丢掉。不要一开始就追求在完整大模型上做全量微调。先选一个小一些的模型整理几百条高质量样例用 LoRA 方式试跑评估效果再决定是否扩大数据规模。5.4 微调项目的验收标准和常见翻车点微调项目不要只看“Loss 降了”就认为成功。真正的验收要看几个方向目标任务准确率有没有提升。通用能力有没有明显下降。格式稳定性是否达标。对用户输入的对抗性和边界情况是否应付得了。常见翻车点也很集中。数据标注不一致会导致模型行为混乱正例太多、负例太少会让模型只会答应不会拒绝训练集和评估集分布不一致会让人误判效果。还有一点微调之后模型在已知样例上很听话但换一批相似表达就失效。这说明数据集多样性不足不是模型问题。6. 2026 年的实践路线从一个端到端项目开始把前面五块能力拆开讲完最后落到实践。2026 年做 AI 应用开发真正拉开差距的往往不是谁更了解某个库而是谁能把一条链路完整地跑通并稳定交付。下面按我的建议给出一套顺序以及每一阶段的验收标准。6.1 一套可复用的学习顺序如果基础一般建议按下面的顺序推进先掌握模型调用的基本能力。能通过 API 或本地模型完成对话、JSON 输出、流式输出。再做一个最小 RAG 项目。必须包含文档加载、切分、向量化、检索、生成、引用展示。然后做一个受限 Agent。只提供两三个工具跑通工具调用循环加入最大步数和超时控制。接着把 Agent 流程迁移到 LangGraph。把判断、调用、结束抽成节点用条件路由控制。最后再评估是否需要微调。不要在前四步没跑通时提前进入微调。每个阶段都要有验证标准。RAG 阶段至少要回答三个问题并保证答案能追溯到原文。Agent 阶段至少要能连续完成一个多工具任务并保证单条失败不会拖垮整个流程。LangGraph 阶段至少要能做“条件分支 循环 中断恢复”其中的两项。6.2 三个项目练手知识库问答、客服 Agent、带记忆的复杂流程项目太多会让人迷失我建议重点做三个。第一个项目是领域知识库问答。不限领域选自己熟悉的比如内部 IT 运维手册、产品说明书。重点练文档解析、切块、引用溯源。这个项目做完你应该能说清楚同一个问题为什么换了切块策略答案就变了。第二个项目是客服 Agent。给它提供订单查询、物流查询、退款规则三个工具。重点练工具定义、上下文管理、超时重试。这个项目做完你应该能处理“Agent 走错分支”的问题而不是只会对着错误提示发呆。第三个项目是带记忆的复杂流程。增加长期记忆让 Agent 能记住用户偏好。再把流程拆成子图和并行分支。这个项目做完你对 LangGraph 的状态和路由就已经有实际体感了。这三个项目不需要都用生产级配置。先跑通再优化再考虑并发和接口化。6.3 通用排查顺序与上线前检查清单最后给一份排查顺序你会在很多问题里反复用到。先看现象。是报错、卡住、无输出、输出质量差还是速度慢。再看输入。文件路径是否正确、编码是否有问题、输入格式是否符合预期。再看环境。依赖版本是否兼容、权限是否足够、磁盘和内存是否够用。再看参数。并发数、批量大小、超时时间、模型路径、输出目录是否设置正确。最后看框架本身。版本差异、功能边界、已知限制。上线前检查清单也不要忽略有没有日志可以追踪每一步。有没有失败重试和超时控制。输出目录和命名是否唯一批量任务会不会互相覆盖。敏感信息有没有被打进日志或上下文。评估集是否可以反复用来比较版本效果。还能不能回到上一个可用版本数据和配置有没有版本管理。这些点看起来不如“让 Agent 更聪明”有趣但实际项目里最容易出问题的就是它们。把基础链路做稳比追一个高深的新概念更能提高交付质量。如果你只能记住一句话我建议是先把单条任务跑稳再谈批量、并发和微调。 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 应用的过程拆成五个环节理解需求判断哪些用 RAG、哪些用 Agent、哪些必须微调。准备数据把文档、表格、接口定义整理成模型能用的输入。选型编排方式简单流程用 Chain复杂状态机用 LangGraph。跑通最小闭环先保证一条主流程能出结果。优化可靠性加日志、超时、失败重试、质量检查。我见过不少项目失败不是模型不好而是这五步中间断掉了。比如只做了向量检索没有做结果校验或者 Agent 循环没有设置最大次数线上跑着跑着就卡住。学这些技术时最好脑子里始终带着“这样改是为了哪一环更稳”。1.3 不同技术背景的人建议从不同位置切入如果你是后端工程师可以从接口和数据处理切入。先学 RAG 的文档加载、解析、切分再学 Agent 的工具定义和日志链路最后补 LangGraph 的状态管理。如果你是算法工程师可以从评估切入。你不需要从头写很多业务逻辑但你要知道怎么判断 RAG 检索质量、Agent 决策是否正确、微调后是否产生遗忘。如果你只会调用 API也不用慌。2026 年做 AI 应用开发更多是组合能力和边界判断能力而不是从零写模型。你缺的通常是工程习惯比如路径、日志、异常处理、参数配置。这些会在后面每一步中反复用到。2. RAG知识库问答是最容易跑通、也最容易做差的一环很多人学 AI 应用开发的第一个项目就是做一个 RAG 知识库问答系统。这个选择很合理因为它的链路清晰文档加载、切分、向量化、检索、生成。但也是因为这个链路太清晰很多人容易忽略每个环节里的细节最后做出一个“demo 能跑换数据就崩”的系统。2.1 最小闭环加载、切分、向量化、检索、生成一个标准 RAG 流程可以拆成五步文档加载读取 PDF、Markdown、Word、HTML、数据库记录。文档切分把长文本切成块。不能太长否则检索不精准不能太短否则语义不完整。向量化用 embedding 模型把文本块转成向量。检索用用户问题去向量库找最相似的 Top-K 文本块。生成把检索到的文本块和用户问题一起拼进 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接收用户输入。模型判断需要调用哪个工具。执行工具拿回结果。模型判断结果是否满足任务需求。不满足就继续下一步满足就输出最终答案。每一步都是一次模型推理。所以 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”的超时错误。不要一上来就怀疑模型能力有问题按下面的顺序排查先看日志卡在哪一步。是模型生成超时还是工具调用超时再看工具本身。工具是否真的能访问网络、数据库、文件系统权限够不够参数是否传对再看上下文长度。如果历史消息太长模型响应时间会明显变慢甚至触发超时。再看并发和排队。多个 Agent 同时跑时外部接口可能扛不住需要在代码层加重试和限流。最后看 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 和微调解决的是两类不同问题。用一张表来对比会更清楚。对比项RAG模型微调核心目标给模型补充外部知识改变模型的行为和输出习惯更新成本换文档、重新索引即可需要准备数据集、重新训练可追溯性答案可以回溯到原文很难说清某个行为来自哪条数据算力要求主要花在检索和推理训练前、训练中、推理都需要额外算力适合场景知识密集、内容经常更新输出格式固定、术语约束强、行为需要稳定如果一个问答系统答错是因为知识库里根本没有相关信息那优先补文档或优化检索。如果模型知道答案但输出总是缺字段、格式乱、术语不专业那才需要考虑微调。5.2 不微调模型也能拓展垂类应用的几种方式“有什么方法不微调模型也可以拓展垂类应用”是很多人会搜的问题。这确实值得先说清楚。第一种是 RAG。通过外部知识库让模型在回答时带上领域内容天然适合内容型业务。第二种是提示词工程。把业务规则、格式要求、判断标准写进系统提示词。简单有效缺点是提示词越长模型越容易忽略部分要求需要反复测试。第三种是工具调用和外部规则。比如模型自己不擅长计算那就让它调用计算函数模型不擅长查实时数据那就让它调用数据库接口。把复杂能力外包给外部系统模型只负责拆任务和组装结果。第四种是后处理校验。对模型输出做规则校验、格式解析、强制纠错不满足要求就重新生成。这类做法经常被忽略但非常实用。你可以把这几种方式组合起来。先用提示词定规则用 RAG 补知识用工具补能力最后做一层输出校验。大多数垂类应用到这一步就够了不一定要微调。5.3 真正需要微调的场景和前置条件如果你的业务有下面几种情况微调才变得必要。第一种输出格式极度固定。比如必须输出严格 JSON字段不能多也不能少。提示词可以压到一定准确率但要达到很高的稳定性微调可能更合适。第二种领域术语密集且使用方式特殊。比如法律条文、医疗诊断、工业维修手册。通用模型可能偶尔用错术语微调可以让模型形成稳定的表达习惯。第三种特定交互风格。比如客服助理必须语气克制、不能主动越权。如果你试了多次提示词仍不稳定微调可以作为补充。但微调的前置条件很高。首先需要一份质量不错的数据集每条输入、输出都要对齐业务标准。其次需要一个评估集用来判断微调前后是变好还是变坏。再次要有算力或至少能使用参数高效微调方案比如 LoRA。最后还要做灾难性遗忘检查防止模型学了新知识后把通用能力丢掉。不要一开始就追求在完整大模型上做全量微调。先选一个小一些的模型整理几百条高质量样例用 LoRA 方式试跑评估效果再决定是否扩大数据规模。5.4 微调项目的验收标准和常见翻车点微调项目不要只看“Loss 降了”就认为成功。真正的验收要看几个方向目标任务准确率有没有提升。通用能力有没有明显下降。格式稳定性是否达标。对用户输入的对抗性和边界情况是否应付得了。常见翻车点也很集中。数据标注不一致会导致模型行为混乱正例太多、负例太少会让模型只会答应不会拒绝训练集和评估集分布不一致会让人误判效果。还有一点微调之后模型在已知样例上很听话但换一批相似表达就失效。这说明数据集多样性不足不是模型问题。6. 2026 年的实践路线从一个端到端项目开始把前面五块能力拆开讲完最后落到实践。2026 年做 AI 应用开发真正拉开差距的往往不是谁更了解某个库而是谁能把一条链路完整地跑通并稳定交付。下面按我的建议给出一套顺序以及每一阶段的验收标准。6.1 一套可复用的学习顺序如果基础一般建议按下面的顺序推进先掌握模型调用的基本能力。能通过 API 或本地模型完成对话、JSON 输出、流式输出。再做一个最小 RAG 项目。必须包含文档加载、切分、向量化、检索、生成、引用展示。然后做一个受限 Agent。只提供两三个工具跑通工具调用循环加入最大步数和超时控制。接着把 Agent 流程迁移到 LangGraph。把判断、调用、结束抽成节点用条件路由控制。最后再评估是否需要微调。不要在前四步没跑通时提前进入微调。每个阶段都要有验证标准。RAG 阶段至少要回答三个问题并保证答案能追溯到原文。Agent 阶段至少要能连续完成一个多工具任务并保证单条失败不会拖垮整个流程。LangGraph 阶段至少要能做“条件分支 循环 中断恢复”其中的两项。6.2 三个项目练手知识库问答、客服 Agent、带记忆的复杂流程项目太多会让人迷失我建议重点做三个。第一个项目是领域知识库问答。不限领域选自己熟悉的比如内部 IT 运维手册、产品说明书。重点练文档解析、切块、引用溯源。这个项目做完你应该能说清楚同一个问题为什么换了切块策略答案就变了。第二个项目是客服 Agent。给它提供订单查询、物流查询、退款规则三个工具。重点练工具定义、上下文管理、超时重试。这个项目做完你应该能处理“Agent 走错分支”的问题而不是只会对着错误提示发呆。第三个项目是带记忆的复杂流程。增加长期记忆让 Agent 能记住用户偏好。再把流程拆成子图和并行分支。这个项目做完你对 LangGraph 的状态和路由就已经有实际体感了。这三个项目不需要都用生产级配置。先跑通再优化再考虑并发和接口化。6.3 通用排查顺序与上线前检查清单最后给一份排查顺序你会在很多问题里反复用到。先看现象。是报错、卡住、无输出、输出质量差还是速度慢。再看输入。文件路径是否正确、编码是否有问题、输入格式是否符合预期。再看环境。依赖版本是否兼容、权限是否足够、磁盘和内存是否够用。再看参数。并发数、批量大小、超时时间、模型路径、输出目录是否设置正确。最后看框架本身。版本差异、功能边界、已知限制。上线前检查清单也不要忽略有没有日志可以追踪每一步。有没有失败重试和超时控制。输出目录和命名是否唯一批量任务会不会互相覆盖。敏感信息有没有被打进日志或上下文。评估集是否可以反复用来比较版本效果。还能不能回到上一个可用版本数据和配置有没有版本管理。这些点看起来不如“让 Agent 更聪明”有趣但实际项目里最容易出问题的就是它们。把基础链路做稳比追一个高深的新概念更能提高交付质量。如果你只能记住一句话我建议是先把单条任务跑稳再谈批量、并发和微调。