大模型应用开发学习路线：提示词工程、RAG、LangChain与LangGraph

大模型应用开发已经过了“能调接口就算会”的阶段。2026 年再聊这个方向大家更关心的是另一件事当需求从简单的单轮问答变成知识库问答、工具调用、Agent 任务拆解时开发者到底应该按什么顺序补技能才不会越学越乱。提示词工程、RAG、LangChain、LangGraph 这四个词基本把当前大模型应用开发的主干覆盖完了。这篇内容适合两类人一是刚准备入门、想建立一条清晰路线的初学者二是已经会写 Prompt、但不太确定 RAG 和 Graph 工作流到底该怎么集成的前端或后端工程师。下面按我自己的实测经验把学习路线、核心原理、项目练习和常见坑点完整拆一遍。1. 先想清楚你的学习目标到底是会调 API还是会做落地应用1.1 从“能写 Prompt”到“能交付应用”之间缺的是什么很多人在入门时有个误解以为大模型应用开发就是把 OpenAI 或者国产大模型的 API 包一层然后拼一个聊天框。这个阶段其实不叫应用开发叫接口调用。真正进入应用开发至少需要处理三件事模型输入输出不稳定时怎么通过 Prompt、参数和流程设计来兜底。模型不知道私有知识或最新信息时怎么用 RAG 把外部数据接进来。业务逻辑包含多步骤、多条件、多工具调用时怎么用一个可靠的工作流框架把它编排起来。这三件事正好对应提示词工程、RAG 和 LangChain/LangGraph。所以学习路线不是四个独立课程而是一条完整的技能链从模型交互到知识接入再到流程编排。1.2 五层学习路线与自测标准我建议把所有内容拆成五层每一层都有明确的出口标准而不是按视频时长来算学没学会。层级核心内容掌握标志L1基础 API 使用、上下文窗口、Token 概念、角色设定能独立完成一次结构化 Prompt 的调用并理解输出变化原因L2提示词工程指令设计、Few-shot、思维链、输出约束能针对同一个任务设计三套不同 Prompt并比较效果差异L3RAG 流程加载、切分、向量化、检索、增强、生成能自己做一个文档问答 Demo并解释哪个环节影响了答案质量L4LangChain 组件化编排模型、提示、检索器、工具、Agent能用 LangChain 把 RAG 和多工具调用串成一个 API 服务L5LangGraph 状态图开发节点、状态、条件分支、人工介入能处理带循环、多步判断和多 Agent 协作的复杂任务这个顺序不要跳。直接学 LangGraph 不是不行但你会发现报错之后很难定位是状态问题、模型问题还是 Prompt 问题。底层能力不稳上层框架只是把复杂度包装得更隐蔽。2. 提示词工程先从交互结构入手再往细节调优2.1 哪些场景必须做提示词工程提示词工程不是一个独立的“玩法”它出现在所有大模型应用的最外层。最常见的场景包括摘要生成需要控制输出长度、信息密度、是否保留专有名词。信息抽取需要从非结构化文本中提取字段并按固定格式返回。对话助手需要维护角色、语气、知识边界和拒绝策略。代码生成需要指定语言、依赖环境、输入输出格式和安全要求。在这些场景里Prompt 不是随便写一句话而是一份给模型的“任务说明书”。你自己的项目是什么语言、什么框架、什么数据格式都要写清楚。2.2 Prompt 调优时要盯的参数刚开始做提示词工程时不要只盯着提示词文字本身还要同时看模型参数。下面几个参数是影响结果最明显的temperature控制随机性。事实抽取类的任务建议调低比如 0 到 0.2创意写作可以调高但不要一上来就拉满输出会飘。top_p控制候选词的累积概率范围。和 temperature 功能上相关实际调的时候尽量只锁定其中一个不要两个同时大幅调。max_tokens控制最大生成长度。很多人漏掉它结果长文本生成到一半被截断误以为是模型能力问题。系统提示词定义整体边界比把规则全塞到用户 Prompt 里更稳定。系统提示词里适合写身份、目标、限制条件、输出格式用户 Prompt 里适合写具体任务和数据。我一般会先固定一组常规参数然后只改 Prompt 看效果当 Prompt 改到一定程度无法再提升时再回头调参数。不要两头同时改否则你根本不知道是哪个改动起了作用。2.3 提示词工程解决不了的三类问题这是踩坑后最该清楚的一条边界。模型本身不知道的知识靠提示词无法补全。比如私有文档里的信息、当天刚发生的事件这个问题需要 RAG 而不是更长的 Prompt。多步骤任务不能靠一段 Prompt 硬撑。让模型在一次调用里完成“理解文档→查数据库→写报告→发邮件”不仅容易遗漏步骤出错后也很难定位。这种情况需要流程编排。格式敏感、错误代价高的任务不能完全依赖自然语言输出。比如希望模型输出严格 JSON靠“请按照 JSON 格式返回”有时候有效但远不如用函数调用或结构化输出机制可靠。记住一点提示词工程解决的是“怎么让模型把能力发挥稳定”它不能替代外部知识也不能替代业务流程控制。3. RAG从检索增强生成的基础链路到进阶方案3.1 RAG 解决什么问题普通向量检索阶段怎么做RAG 全称 Retrieval-Augmented Generation检索增强生成。它的核心思路很直白在调用模型生成之前先从你自己的知识库里检索出相关内容把这些内容拼到 Prompt 里再让模型基于这些材料回答。这样做的好处是直接绕开了模型知识过期和私有数据缺失的问题。模型不需要“记住”你的文档只需要“阅读”你检索出来的那一小段内容。一个最小 RAG 系统由两条链路组成索引链路把原始文档切块做 Embedding 向量化存入向量数据库。查询链路把用户问题做 Embedding在向量库里做相似度检索拿到 TopK 片段拼入 Prompt让模型生成答案。3.2 配置最小 RAG 链路时七个环节不能少这里不限定具体工具按通用流程拆文档加载支持 PDF、Word、Markdown、HTML、TXT。不同类型解析效果差异很大PDF 有扫描版和文字版之分扫描版要做 OCR不然检索阶段会漏内容。文本切分按段落、固定 chunk 大小或语义边界切分。chunk 大小影响检索精度常见可以先按 300 到 800 token 去试。切分重叠相邻 chunk 之间保留 50 到 100 token 的重叠避免一句话被拦腰切断导致语义丢失。Embedding把文本转成向量。不同模型输出维度不同常见的有 768、1024、1536 等。关键在于上下文窗口和中文效果不要只看维度大小。向量数据库选择 Chroma、Qdrant、pgvector、Milvus 等。低配置学习阶段用 Chroma 或 Qdrant 的本地模式就够不要一上来就搭分布式集群。相似度检索常用余弦相似度或点积。返回 TopK 可以设为 3 到 5 个片段先看效果再调。生成把检索片段和用户问题一起放入 Prompt并明确告诉模型“只能依据以上材料回答”。注意不要一上来就追求大而全的 RAG 框架。先用最少的组件把链路跑通再去替换数据库、换嵌入模型、加重排序这样每一步的效果变化你都能感知。3.3 检索质量不好先检查三处RAG 最常见的失败不是模型生成能力差而是检索回来的内容根本不相关。遇到答案不对、答案空洞、答非所问时按这个顺序排查第一看切分。chunk 过大一个片段里混了多个主题检索分数高但内容不够聚焦chunk 过小则可能丢失上下文。第二看 Embedding 模型。通用领域和垂直领域用同一个模型效果会差很多。如果做法律、医疗、金融要优先选择在这些领域表现更好的嵌入模型。第三看检索逻辑。只做向量检索不一定够可以尝试“关键词匹配 向量检索”的混合检索再通过重排序模型对召回结果重新排序。我还建议你做一个简单评估预先准备 20 到 30 个问题每个问题标注对应的正确答案片段然后看系统能否把这些片段排在 Top1 或 Top3。这个动作叫 RAG 测评不需要一上来就做得多规范先有数据、有基线才能谈优化。3.4 从普通 RAG 到 Agentic RAG 和 Graph RAG当你把普通 RAG 跑通后网上会看到两个明显更进阶的方向Agentic RAG 和 Graph RAG。普通 RAG 的流程是固定的检索一次生成一次。Agentic RAG 则把检索过程交给 Agent 来控制。比如用户的问题比较模糊Agent 会决定先搜索一次发现信息不够再改写查询词继续检索或者发现需要多个知识库的数据就分别去查再合并答案。这种模式适合复杂查询和多轮交互但代价是延迟更高流程更不可控。Graph RAG 则是把实体和关系抽出来构建成图结构。普通 RAG 擅长回答“某篇文章里说了什么”Graph RAG 更适合回答“多个文档中实体之间的关系是什么”。它解决的是跨文档全局性问题但构建成本明显更高。如果只是做简单的文档问答普通 RAG 足够。不要为了追求技术热点一上来就上 Graph RAG。先把基础链路的数据质量做扎实再按需求升级。4. LangChain学它是在学组件化与标准化4.1 LangChain 在应用里的真实位置LangChain 不是一个“大模型”也不是一个“AI 平台”而是一个开发框架。它做的事情是把大模型应用开发中反复出现的组件统一抽象成标准接口然后把它们像搭积木一样串起来。它主要抽象了这些部件Models语言模型、聊天模型、嵌入模型。Prompts提示词模板和动态变量。Retrievers从向量库或外部系统获取相关资料。Tools模型可以调用的外部能力比如搜索、计算、API。Agents根据用户目标决定调用哪个工具、按什么顺序调用。很多初学者看 LangChain 的文档会觉得很乱因为类名太多。实际上你的学习重心不应该放在背类名而是理解它如何把一个 RAG 流程变成可维护的组件链。4.2 把 RAG 用组件的方式组装起来在 LangChain 里写一个简单 RAG代码逻辑大致是这样from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain.chains.combine_documents import create_stuff_documents_chain # 1. 加载文档 loader TextLoader(docs/example.txt) docs loader.load() # 2. 切分文档 splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) chunks splitter.split_documents(docs) # 3. 向量化并入库 # 这里需要你已配置 embedding 模型不同版本 API 存在差异 # embedder YourEmbeddingModel() # vectorstore Chroma.from_documents(chunks, embedder) # 4. 构造检索器 # retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 5. 构造问答 Prompt 并生成 prompt ChatPromptTemplate.from_template( 请仅根据以下资料回答问题\n\n{context}\n\n问题{question} ) # 6. 构建链 # chain {context: retriever, question: lambda x: x[question]} | prompt | model | StrOutputParser()以上是核心逻辑的骨架不是完整可运行代码。原因是 LangChain 不同版本的 import 路径和 API 变化很大直接复制会报错。你最重要的是理解这个流程加载器把文档变成 Document 对象切分器把长文变成 chunk向量库完成存储和检索Prompt 模板控制生成规则最后通过管道符或 chain 把步骤连接。我建议你去读当前安装版本的官方文档把自己手头的文档替换进去。版本不同不要硬套教程里的旧代码。4.3 LangChain 与 LangGraph编排逻辑完全不同这是新手最容易绕晕的地方。LangChain 是链式管线适合线性流程问题进来检索拼 Prompt调用模型输出结果。它也有 Agent 机制但处理复杂状态时不够自然。LangGraph 是基于状态图的工作流框架。它允许你定义多个节点节点之间用边连接整个流程有一个全局状态对象每个节点可以读取和更新状态。它天然支持分支、循环和人工介入。打个比方LangChain 像一条流水线零件按固定顺序往前传LangGraph 像一张流程图同一个任务可以走不同分支遇到条件不满足还可以跳回上一步重试。所以选择逻辑很清楚流程固定、步骤不多的任务用 LangChain。包含条件分支、循环、多角色协调、需要人工审批或重试的任务用 LangGraph。复杂项目里两者经常混用LangChain 负责封装单个能力模块LangGraph 负责整体流程编排。5. LangGraph用状态图承载真正的复杂流程5.1 什么时候该从 chain 换成 graph我自己判断要不要上 LangGraph只看三条流程是不是有多个决策分支。比如先判断问题需不需要查知识库不需要就直接回答需要就检索后再判断是否要再查一次。是否需要在多个节点之间共享中间结果。比如先总结文档再根据总结提取关键词再拿关键词去搜索每一步的结果下一步都要用。是否需要人工介入。比如 AI 生成答案后先进入审核节点审核通过才发送不通过就退回重新生成。如果你只是做一个“输入问题 → 检索→回答”的线性接口用 LangGraph 反而增加复杂度。不要为用而用。5.2 三个核心概念状态、节点、边LangGraph 的基础概念不难抓住三个就能理解State状态整个工作流共享的数据结构可以理解为一个字典或数据类。每个节点都能读取和更新它。比如question、documents、answer、retry_count都可以作为状态字段。Node节点一个处理单元接收状态返回更新后的状态。可以是模型调用、检索函数、人工确认逻辑等。Edge边节点之间的连接关系分为普通边和条件边。条件边根据状态值决定下一个进入哪个节点。一个非常简化的图解式描述用户输入 -- 判断节点 -- 知识库检索节点 -- 生成节点 -- 输出 | --- 直接回答节点 -- 输出在代码上LangGraph 的核心是构建一个状态图然后添加节点和边最后编译执行。不同版本 API 变化也很大但建模思路一致先把业务流程画成图再翻译成节点和边。5.3 从单 Agent 到多节点协作别急着拆角色很多人看完 LangGraph 教程后会把所有任务都拆成多个 Agent有 Planner、Researcher、Writer、Reviewer看起来分工明确结果实测时又慢又不稳定。我的建议是从单 Agent 单节点开始。先用一个模型节点处理主流程只有真的遇到“一个模型角色无法兼顾”的情况再拆节点、拆角色。举个例子先让模型判断问题是否需要实时信息。这个判断节点用一个小模型就能完成不需要上完整 Agent。如果判断结果为是再进入专门的工具调用节点。这样流程清晰也方便定位是判断错了还是工具调用出错了。多节点协作真正要注意的不是“怎么写得酷”而是每个节点的输入输出格式要稳定否则下游节点会收到预料之外的数据。状态字段要控制好不要把所有中间结果都堆在一个字段里后面会越改越乱。条件边必须覆盖所有分支否则可能出现图跑到一半没有下一个节点的情况。6. 串成项目三个可直接实操的方向和一套判断标准6.1 项目方向一文档知识库问答这是 RAG 最典型的落地场景。选一批你自己熟悉的文档比如项目方案、产品手册、论文或学习笔记做一个问答系统。建议不要直接用现成框架而是亲手完成加载、切分、向量化、检索、生成的完整链路。做完后给自己出几道难题比如跨章节的复合问题、含有表格内容的问题、需要对比多个片段的问题。这些才能真正暴露切分和检索的弱点。判断标准文档中直接有答案的问题回答准确率能达到 90% 以上。文档中没有答案的问题模型不能说谎要能回答“根据当前资料无法确认”。连续问 50 个问题不出现一次超出上下文窗口导致截断的报错。6.2 项目方向二带工具调用的 Agent 工作流做一个能调用外部工具的 Agent。比如一个“项目排查助手”它能根据用户的问题去查日志、调用计算工具、读取配置文件然后综合结果给出结论。这个项目重点不是把功能做得多复杂而是掌握工具注册、工具描述、模型选择工具、执行结果回填这一整条闭环。你会发现一个问题模型选错工具通常不是代码问题而是工具描述写得不够清楚。判断标准明确需要工具 A 的问题10 次里有 9 次调用的是工具 A。工具执行失败时Agent 能读取错误信息并尝试修复或换一个工具。递归调用次数有上限不会因为一个错误无限循环。6.3 项目方向三多步骤业务自动化选一个包含多个步骤的业务流程用 LangGraph 实现。比如“客户反馈处理流程”先解析反馈内容再判断类别需要查知识库就检索最后生成回复草稿并进入人工审核。这个项目能同时锻炼状态设计、分支条件和人工介入能力。建议从真实业务里找一个流程不要凭空捏造一个过于理想化的需求。判断标准流程中任何一步抛错状态不致丢失可以从断点重新执行。人工审核节点能拿到完整的中间过程而不只是最终结果。流程图可读别人拿到你的代码能反推出业务逻辑。6.4 配置、资源与成本判断学习阶段不需要高配服务器。大多数 Demo 在普通笔记本上就能跑。如果你的本机没有 GPU连接远程大模型 API 时要注意响应延迟主要来自网络和模型输出长度本机只负责编排和检索。向量数据库如果数据量在百万级以下本地模式完全够用。个人学习优先用小模型或性价比高的模型做流程验证跑通后再换更强的模型。官方文档写的是最新版本未必适配你本机的依赖环境安装前先确认 Python 版本和包版本。7. 学习路径里的典型坑和正确排查顺序7.1 API 变更和版本兼容是最大的隐形杀手LangChain 和 LangGraph 的版本迭代速度非常快网上教程默认的 class 名和 import 路径一升级就失效。看到报错 ModuleNotFoundError 先别怀疑自己先检查安装版本。排查顺序看报错信息里的 import 路径和 class 名。查看当前安装版本的官方文档对应页面。如果仓库代码里有 requirements.txt先按那个版本装不要直接用最新版。注意 Python 版本部分包在 Python 3.11 和 3.12 之间的依赖表现不同。7.2 数据问题比模型问题常见得多RAG 效果差十次里有七次是数据问题。文档格式混乱、切分不干净、Embedding 模型不匹配、检索阈值设置太高或太低都会导致答案错误。报错时先按这个链路查输入格式文件能否被正确解析表格和图片是否丢失。切分效果把一个原始段落打印出来看有没有被拦腰截断。检索结果把 TopK 片段直接打印出来看和你预期是否一致。Prompt 拼接看最终发到模型的内容是否包含多余字符或格式错乱。这一步非常关键。很多人一看到答案不对就去改 Prompt 和 temperature但真正问题在检索阶段根本没召回相关内容。改 Prompt 只是放大正确答案的概率前提是你得先把正确答案送到模型面前。7.3 不要一上来就开并发和批量任务很多课程演示只跑单条任务但实际落地时一定会遇到批量处理。比如一次性处理 200 篇文档、定期增量更新知识库。建议顺序是先跑一条文档确认输入、输出、日志都正常。再跑 10 条文档观察耗时和资源占用。最后才考虑并发、队列、失败重试和输出命名规则。批量任务里最容易出问题的不是模型调用而是文件路径、输出目录、编码格式和任务中断后的恢复逻辑。安排文件夹时就要用任务名加时间戳避免重跑时覆盖已有结果。8. 学习方式的最后一点提醒真正的进步不取决于看完多少节课程而在于你能否脱离教程独立完成一个小型闭环。我的判断标准很简单当你的项目报错时你不需要去群里发截图问别人而是能通过日志、文档、版本比对和直觉找到问题所在这个阶段才算真正入门了。学习大模型开发最低效的事情就是永远在收藏课程永远不落代码。每一层技能对应的不是你能说出多少概念而是你能用代码把一个具体问题解决到什么样的完成度。如果你现在正在规划自己的学习路线我的建议很直接挑一个你自己工作中的真实问题先用提示词工程硬写一个版本再上 RAG 补充知识最后再用 LangGraph 把多步骤流程固化下来。跑通一条完整链路比看二十个视频都有用。