很多人从视频课程开始学习大模型应用开发时最先遇到的问题不是某个算法看不懂而是被一串名词卡住提示词工程、RAG、LangChain、LangGraph。它们经常出现在同一张学习路线图里但各自解决的问题并不一样。有人学完提示词工程就直接问“是不是该学微调”有人刚弄懂 RAG 又被 LangGraph 的状态图劝退。真正的问题不是资料太少而是缺少一条清晰的开发主线。本文会围绕一条可执行的大模型应用开发学习路线展开先理解四个名词分别处在什么技术层级再准备本地模型环境然后依次完成提示词工程、RAG、LangChain、LangGraph 四个最小项目。每步都会给代码、参数解释、验证方法和常见坑。学完之后你不仅能跑通示例还能在真实项目里判断“这一步到底该用提示词、检索、链编排还是图编排”。1. 先理清四个名词它们不是并列关系而是不同层级的技术栈很多初学者把提示词工程、RAG、LangChain、LangGraph 当作四个“并列的大模型技术”。但实际开发中它们处于不同层级需要组合使用。理清这个关系比提前记某一行 API 更值钱。1.1 一句话定位每个概念提示词工程Prompt Engineering研究的是“如何与模型对话才能稳定得到想要的结果”。它不依赖任何框架是使用大模型的最底层能力。RAGRetrieval-Augmented Generation解决的是“模型不知道的知识怎么办”。它先把外部知识切成片段并向量化再在回答问题时检索相关片段拼进提示词里让模型基于资料回答。RAG 不是框架是一种系统架构。LangChain 是一套面向大模型应用开发的工具库。它把模型调用、提示词模板、输出解析、向量数据库、记忆组件、工具调用等能力统一封装让开发者可以用“链Chain”的方式拼接业务逻辑。LangGraph 是建立在 LangChain 生态之上的图编排框架。它不再把流程当一条直线链而是当成一张有状态、有分支、有循环的图。那些需要多轮判断、条件跳转、状态保存的 Agent 类应用用 LangGraph 组织会更清晰。1.2 四个概念的分层关系与学习顺序推荐的学习顺序不是“谁有名先学谁”而是按依赖关系来先学提示词工程因为无论后面用什么框架最终都要靠提示词和模型沟通。再学 RAG因为知识库问答是大模型应用最常见的落地场景。然后学 LangChain因为 RAG 各个环节要用 LangChain 组件串联效率更高。最后学 LangGraph用于解决 LangChain 的“线性链”表达不了分支和循环的问题。下面用一张表说明它们的分工概念解决什么问题核心产物典型使用场景提示词工程控制模型输出质量系统提示词、模板、Few-shot 示例文本分类、抽取、改写、格式化输出RAG引入外部知识、降低幻觉检索器、拼接后的增强提示词企业知识库问答、文档助手、客服系统LangChain封装 LLM 应用的通用组件模型对象、Chain、Tool、Memory把模型调用和业务逻辑组合成可复用模块LangGraph编排多步骤、有状态的工作流StateGraph、Node、Edge、State多步 Agent、条件分支、人工审批流程1.3 新手最容易误解的几点第一不是所有项目都需要 LangGraph。如果业务是“提问 - 检索 - 回答”的直线流程用 LangChain 的一条链就够了。LangGraph 的价值体现在分支、循环和状态恢复上提前引入只会增加理解成本。第二提示词工程不是“把话写长一点”。它的核心是让输入输出的约束模式稳定怎么做少样本示例、怎么定义输出格式、怎么处理异常输出、怎么在不泄露系统提示词的前提下完成任务。这些都需要单独测试。第三RAG 不等于“把资料全部塞进提示词”。不检索、直接拼原文会让上下文爆炸模型也会被无关内容干扰。RAG 系统里检索这一步的设计质量往往比生成时的提示词更影响最终效果。2. 环境准备先让大模型能对话再谈上层框架学习环境不要一上来就上云 API。建议先在本地部署一个开源模型跑通“模型能用”这一步再让 LangChain、LangGraph 和它对话。这样能够避免 API 费用、网络波动和 Key 泄漏等问题也方便看完整调用链路。2.1 模型服务的三种方式怎么选本地开发时模型服务有三种常见来源方案优点缺点适合场景云端托管 API响应快、模型大、免运维需要网络可达、有费用、需要密钥管理产品原型、商用系统本地私有化部署数据不出内网、可控、无按量费用需要 GPU 或大内存性能受本机限制隐私敏感、离线开发、教学实验兼容接口的本地服务本地模型也能使用 OpenAI 风格 API 语法接口兼容层可能有差异想用统一客户端代码切换后端模型实际学习中建议优先选本地部署。如果本机没有足够显存也可以选择内网中已有的模型服务地址不一定要自己装大模型。2.2 用 Ollama 本地跑通一个对话模型Ollama 是目前最常用的本地模型管理工具之一它会帮你管理模型下载、启停和端口。不同操作系统的安装方式以官方文档为准Linux 和 macOS 常见安装命令如下curl -fsSL https://ollama.com/install.sh | sh安装完成后启动服务并拉取一个适合学习的中文对话模型。如果没有特别原因可以先从 7B 级别模型开始ollama serve再开一个终端拉取并运行模型ollama pull qwen2.5:7b ollama run qwen2.5:7b如果屏幕出现一个可以聊天的交互界面说明模型已经跑起来了。按Ctrl D退出聊天后可以测试它提供的 HTTP 接口curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 用一句话介绍你自己, stream: false }返回 JSON 中的response字段就是模型输出。这个实验的意义在于确认本地模型服务监听地址、模型名、请求格式都没有问题。后面所有 LangChain、LangGraph 代码最终都会落到这个服务上。2.3 创建 Python 虚拟环境并安装依赖工程上不建议把依赖直接装到系统 Python 里。先创建虚拟环境python -m venv .venv source .venv/bin/activate pip install --upgrade pip然后安装本轮学习需要的依赖pip install langchain langchain-community langchain-ollama langchain-text-splitters langgraph chromadb说明一下这些包的用途langchain核心链、提示词模板、输出解析器。langchain-community社区集成组件如文档加载器、部分向量库封装。langchain-ollamaLangChain 与 Ollama 的对接封装提供ChatOllama模型客户端。langchain-text-splitters文档分块工具。langgraph状态图编排框架。chromadb本地向量数据库。大模型生态版本更新很快。不要照抄别人项目时忽略版本安装时最好把版本号写入requirements.txt固定下来例如pip freeze requirements.txt之后环境坏了可以随时恢复pip install -r requirements.txt2.4 用统一配置管理模型地址和模型名开发阶段不要把所有配置直接写在代码里。先创建一个.env文件OLLAMA_BASE_URLhttp://localhost:11434 LLM_MODELqwen2.5:7b EMBED_MODELnomic-embed-text在 Python 中读取时可以安装python-dotenv并这样加载pip install python-dotenvfrom dotenv import load_dotenv import os load_dotenv() OLLAMA_BASE_URL os.getenv(OLLAMA_BASE_URL, http://localhost:11434) LLM_MODEL os.getenv(LLM_MODEL, qwen2.5:7b) EMBED_MODEL os.getenv(EMBED_MODEL, nomic-embed-text)配置外置的好处是换模型服务、换模型名时不需要改业务代码只需改环境变量。后面进入生产环境时这套习惯也能顺利迁移到配置中心或容器环境变量。3. 第一步实践用提示词工程控制模型输出框架代码前先做一次“裸提示词”练习。目的不是练写作而是理解模型的输出是受提示词和生成参数共同影响的。3.1 提示词的基本结构一个完整提示词至少要包含三层信息角色与任务例如“你是一名客服助手”。输入内容例如用户的问题或文本。输出约束例如格式、长度、是否保留证据、是否允许推测。在实际开发中前两条系统提示词通常做成模板输入内容在运行时填充。先用 LangChain 的ChatPromptTemplate组织一个最简模板from langchain_core.prompts import ChatPromptTemplate from langchain_ollama import ChatOllama from langchain_core.output_parsers import StrOutputParser prompt ChatPromptTemplate.from_messages([ (system, 你是一个文本分类助手。只输出类别名称不要输出解释。), (human, 请对下面文本分类类别选项技术支持、账号问题、其他。\n文本{text}), ]) llm ChatOllama( base_urlOLLAMA_BASE_URL, modelLLM_MODEL, temperature0.2, num_predict256, ) chain prompt | llm | StrOutputParser() result chain.invoke({text: 我登录后一直提示验证码错误}) print(result)这里有一个很多初学者不理解的地方prompt | llm | StrOutputParser()这种写法是 LangChain 的 LCELLangChain Expression Language语法。竖线把“模板、模型、解析器”连接成一条链调用时数据按顺序流通。它的好处是每个组件都可以单独替换、单独测试。3.2 最小案例让模型输出结构化 JSON文本分类的下一步是让模型直接输出 JSON。项目里调用接口时往往需要把模型输出反序列化成对象。prompt_json ChatPromptTemplate.from_messages([ (system, 你是JSON转换助手。只输出JSON不要输出解释不要用Markdown代码块包裹。), (human, 抽取下面文本中的实体输出JSON格式如下\n{{\name\: \人名\, \company\: \公司名\}}\n文本{text}), ]) chain_json prompt_json | llm | StrOutputParser() raw chain_json.invoke({ text: 张伟在云枢科技担任前端工程师 }) print(raw)运行后理想输出是{name: 张伟, company: 云枢科技}如果模型输出了一段 Markdown 代码块字符串两侧会出现 json 标记。这种情况下不要直接json.loads()要先做清理import json def parse_json(text: str): text text.strip() if text.startswith(): text text.split(\n, 1)[1] if text.endswith(): text text[:-3].strip() return json.loads(text)这个清理逻辑虽然简单但在真实项目里能解决大量模型“画蛇添足”的问题。3.3 关键生成参数怎么调同一个模型不同参数组合可能得到完全不同的结果。下面的参数在 LangChain 的ChatOllama中使用参数含义常见设置调大影响调小影响temperature采样随机性0.2 到 0.8更随机、更有创意更稳定、更保守top_p核采样概率0.8 到 0.95候选词范围更大输出更集中num_predict生成最大 token 数256 到 2048可生成更长文本生成容易截断seed随机种子固定或忽略固定后结果更可复现每次输出变化更大需要区分两类场景。抽取、分类、格式化这类任务temperature建议设为 0.1 到 0.3。创意写作、头脑风暴、文案改写这类任务可以调到 0.7 以上。不要把temperature当成“让模型更聪明”的开关它只控制随机性不控制事实正确性。3.4 提示词工程里最常见的坑第一个坑是提示词越来越长规则之间相互矛盾。有人要求模型“必须保持专业”又要求“语气可爱”最后输出完全不可控。正确做法是把约束按优先级排列任务、输入、输出格式、语气。第二个坑是只调temperature不检查提示词。项目里遇到输出不稳定第一反应应该是看是不是提示词里给了模糊的指令而不是盲目降温。第三个坑是系统提示词被用户输入覆盖。有些模型对话接口中用户消息里写入的规则会覆盖早期系统消息。建议把不可变规则放系统消息把需要用户自由表述的内容放用户消息且不在用户消息里重复敏感指令。4. 第二步实践实现一个最小 RAG 知识库提示词工程能力足够后进入最常用的大模型应用方向RAG。RAG 并不是一个库而是一种流程。很多招聘要求里的“RAG 实战”考察的正是你对整个流程的理解和落地能力。4.1 RAG 解决什么问题大模型的知识存在训练时间截断也不了解企业私有文档。RAG 的思路是回答问题前先从外部知识库里检索相关内容再把“检索到的资料 用户问题”一起交给模型生成答案。这种方式有三个明显收益引入实时或私有知识不依赖模型内部记忆。降低模型编造信息的概率因为模型能引用给定资料。不需要针对每个知识片段重新训练模型成本远低于微调。4.2 最小 RAG 流程拆解一个完整 RAG 流程分为索引阶段和查询阶段。索引阶段加载文档。将长文档切分成小块。对每个块做向量化。把向量和文本存入向量数据库。查询阶段对用户问题做向量化。在向量库中查找最相似的几个块。把块内容拼入提示词。模型基于资料生成回答。理解这一点后再看代码就不会被各种抽象类吓到。4.3 用 LangChain Chroma 实现 RAG先准备一个名为knowledge.txt的文本文件内容可以是任何知识片段例如员工手册、产品说明、项目规范。下面代码演示完整流程。from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma # 加载文档 loader TextLoader(knowledge.txt, encodingutf-8) docs loader.load() # 切分块 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, ) chunks splitter.split_documents(docs) print(f切分后共 {len(chunks)} 个块) # 向量化 embedding OllamaEmbeddings( base_urlOLLAMA_BASE_URL, modelEMBED_MODEL, ) # 写入向量库 vectorstore Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./chroma_db, )这里有两个重点。chunk_size是每个块的最大字符数chunk_overlap是相邻块的重叠长度。重叠的目的是避免一个完整句子或完整概念恰好被切到两个块里。查询阶段代码from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser retriever vectorstore.as_retriever(search_kwargs{k: 3}) question 项目预算审批需要经过哪些步骤 results retriever.invoke(question) context \n\n.join([doc.page_content for doc in results]) rag_prompt ChatPromptTemplate.from_messages([ (system, 你是企业内部知识助手。请只根据给定资料回答资料中没有的信息不要编造。), (human, 资料\n{context}\n\n问题{question}), ]) rag_chain rag_prompt | llm | StrOutputParser() answer rag_chain.invoke({context: context, question: question}) print(检索到的片段数, len(results)) print(回答, answer)执行后可以先打印context人工确认检索到的片段是否真的与问题相关。这一步非常关键如果检索结果本身就不相关后面模型回答得再流畅也毫无意义。4.4 RAG 效果怎么验证RAG 的验证分两层检索质量和生成质量。检索质量可以用最朴素的方式验证对每一道测试题检查标准答案是否出现在召回结果中并看在返回的前 1、3、5 个结果里是否命中。这就是 RecallK 的思路。如果没有工程化的评测脚本至少要做到“人工看前几个召回片段确认没有跑偏”。生成质量验证时重点看三点模型是否完全照搬资料还是加入了自己的想象。资料中多个片段冲突时模型是否发现冲突。问题超出资料范围时模型是否老实回答“不知道”。4.5 RAG 落地中容易被忽视的坑第一个坑是分块参数一刀切。500 字符不一定适合所有场景。如果业务文档是合同条款可能要用 1000 以上并且做结构感知切分如果是客服问答对可能 200 就够。应该用小规模测试集比较不同chunk_size的结果而不是凭感觉定。第二个坑是同一个文档不关注章节结构。RecursiveCharacterTextSplitter会根据分隔符递归切分但它不理解标题层级。生产项目里最好先把 Markdown 标题、PDF 元数据等结构信息带入文本甚至保留page信息便于后续引用出处。第三个坑是忘记persist_directory每次启动都重建向量库。学习阶段问题不大但生产环境需要明确的索引更新策略哪些文档需要增量写入哪些需要替换哪些需要删除。5. 第三步实践用 LangChain 组织应用逻辑RAG 示例已经展示了 LangChain 的一部分能力。第三步要做的是把模型调用、提示词、输出解析、知识检索、记忆等能力组合成更完整、更可维护的应用。5.1 LangChain 在项目里到底负责什么不写 LangChain 也可以调用大模型。LangChain 的价值在于把高频动作抽象成组件并提供向前兼容的编排方式。当你需要“读取用户问题 - 检索知识库 - 判断是否需要追问”如果直接用原生代码也能写但每个模型供应商都要写一套 HTTP 调用。LangChain 统一了接口让代码更接近业务语义。5.2 再看 LCEL一条链就是一个可复用模块LCEL 的核心是用|把组件连接成管道。前面的 RAG 示例已经有了雏形。这里补一个同时带检索和输出的完整链from langchain_core.output_parsers import StrOutputParser from langchain_core.prompts import ChatPromptTemplate def build_rag_chain(retriever, llm): prompt ChatPromptTemplate.from_messages([ (system, 只能根据资料回答。), (human, 资料\n{context}\n\n问题{question}), ]) def format_docs(docs): return \n\n.join([doc.page_content for doc in docs]) chain ( { context: retriever | format_docs, question: lambda x: x[question], } | prompt | llm | StrOutputParser() ) return chain chain build_rag_chain(retriever, llm) print(chain.invoke({question: 报销标准是什么}))这段代码展示了 LCEL 的一个重要特点第一个字典并不是普通字典而是“运行时计算字段”。retriever | format_docs表示先执行检索再把检索结果用format_docs拼接成字符串。这比手动调用 retriever 再填充模板更简洁也让数据流更透明。5.3 多轮对话里的记忆怎么管理在客服机器人里用户可能会说“那什么时候到账”单看这一句系统不知道“那”指的是什么所以需要记忆。LangChain 中有多种 Memory 类。最简单实用的策略是把最近 N 轮消息保存到列表拼入提示词。注意不要无限放大上下文token 数量和延迟都会上涨。from langchain_core.messages import AIMessage, HumanMessage history [] def chat_with_history(question: str): messages [ (system, 你是客服助手回答简洁准确。), *history, (human, question), ] answer llm.invoke(messages).content history.append(HumanMessage(contentquestion)) history.append(AIMessage(contentanswer)) if len(history) 6: del history[:2] return answer这里del history[:2]是控制内存长度的简单实现。生产环境一般用 Redis 或数据库保存历史并按 session_id 隔离用户这里只演示思路。5.4 LangChain 版本变化带来的排错思路LangChain 生态接口曾经频繁变化。常见报错是ImportError: cannot import name XXX from langchain。遇到这种问题第一反应不是找“最新写法”而是检查当前环境版本pip show langchain langchain-community langchain-ollama然后去对应当前版本的官方文档查 API。千万不要直接抄一年前的博客代码。也可以写一段最小复现代码判断问题出在依赖版本还是业务逻辑。6. 第四步实践用 LangGraph 编排有状态的流程RAG 和 LangChain 解决的是“线性流程”但真实业务往往不是一条直线。例如客服机器人要判断“用户问题是否需要检索知识库”如果需要就查资料不需要就直接让模型回答。再比如多步 Agent 需要先查天气、再写文案、再调用审批接口。这种带分支和循环的流程应该交给 LangGraph。6.1 LangGraph 和 LangChain 的区别LangChain 的 Chain 是固定顺序的数据流。LangGraph 则把应用组织成一张有向图节点Node执行具体动作。边Edge决定节点的流转路径。条件边Conditional Edge根据当前状态决定走哪条路。图在运行过程中维护一个共享状态State。一句话概括LangChain解决“组件怎么组合”LangGraph解决“流程怎么流转”。6.2 核心概念State、Node、Edge、CheckpointerState 是贯穿整个图的数据结构。每个节点函数接收当前 State返回一个字典LangGraph 会把字典里的字段更新回 State。Node 就是一个普通 Python 函数。Edge 决定图结构。Checkpointer 用于持久化执行状态支持断点恢复。理解 State 的更新是 LangGraph 学习的关键。下面用 TypedDict 定义状态from typing import TypedDict, Literal class QAState(TypedDict): question: str docs: list[str] need_search: bool answer: str这里need_search是一个布尔值用来控制条件路由。6.3 最小 LangGraph 案例判断是否需要检索用图把三个节点串起来judge_node判断是否需要检索。search_node查询向量库。answer_node生成答案。代码from langgraph.graph import StateGraph, START, END def judge_node(state: QAState) - dict: prompt ChatPromptTemplate.from_messages([ (system, 判断用户问题是否需要查询内部资料。需要查询则输出yes否则输出no。), (human, state[question]), ]) decision (prompt | llm | StrOutputParser()).invoke({}) return {need_search: decision.strip().lower() yes} def search_node(state: QAState) - dict: docs retriever.invoke(state[question]) return {docs: [doc.page_content for doc in docs]} def answer_node(state: QAState) - dict: if state[docs]: context \n\n.join(state[docs]) prompt ChatPromptTemplate.from_messages([ (system, 只根据资料回答。), (human, 资料\n{context}\n\n问题{question}), ]) answer (prompt | llm | StrOutputParser()).invoke({ context: context, question: state[question], }) else: answer llm.invoke(state[question]).content return {answer: answer} def route_based_on_search(state: QAState) - Literal[search, answer]: return search if state[need_search] else answer graph StateGraph(QAState) graph.add_node(judge, judge_node) graph.add_node(search, search_node) graph.add_node(answer, answer_node) graph.add_edge(START, judge) graph.add_conditional_edges(judge, route_based_on_search, { search: search, answer: answer, }) graph.add_edge(search, answer) graph.add_edge(answer, END) app graph.compile() result app.invoke({ question: 年度调薪的申请流程是什么, docs: [], need_search: False, answer: , }) print(result[answer])注意add_conditional_edges的三个参数第一个是源节点名第二个是路由函数第三个是路由函数返回值和目标节点的映射。路由函数必须返回映射中定义的字符串否则运行时会出现 Key 错误。6.4 LangGraph 的调试方法LangGraph 项目里最常见的故障不是代码语法错误而是状态流没按预期走。调试时可以分三步打印invoke返回的最终 State确认每个字段是否符合预期。去掉answer节点只跑judge和search观察中间状态。增加日志或使用 LangGraph 内置的调试视图查看每个节点耗时和输入输出。如果你在judge之后发现need_search一直是 False先单独测试那个提示词不要直接怀疑框架。多数情况下问题出在模型理解或提示词表达而不是图本身。7. 常见问题排查从现象倒推原因四个最小项目跑完后下面这张排查表可以覆盖绝大多数学习阶段的问题。遇到故障时先从最基础的“服务是否可达、版本是否匹配”查起不要一上来就改业务代码。问题现象常见原因检查方式处理建议模型没有输出或超时Ollama 未启动、模型名错误、网络不通先 curl 模型服务接口重启ollama serve确认模型名返回 401 或鉴权失败API Key 错误、Base URL 配置错误检查.env中的地址和密钥用最小请求直接调模型服务验证输出中文乱码终端编码不对、模型分词异常把输出写入文件检查设置PYTHONIOENCODINGutf-8模型输出带 Markdown 代码块提示词没要求去除模型习惯性包裹打印原始返回字符串在提示词里强调“不输出代码块”并加清理函数检索结果与问题无关分块太大、embedding 模型弱、相似度阈值低打印召回片段文本调小 chunk_size换更好的 embedding 模型增加 rerankLangGraph state 未更新节点返回了未定义的 key打印每个节点返回字典检查 State 类型定义和节点返回值报 ImportErrorlangchain 版本过旧或过新执行pip show langchain锁定版本按当前官方文档修改导入路径本地推理速度慢模型过大、无 GPU、并发太高ollama ps查看加载模型换更小模型限制并发请求数量上面的表格是“现象表”。实际排错建议按下面的链路走确认模型服务本身可用。用命令行或 curl 直接请求一次模型服务排除代码问题。确认配置注入成功。打印OLLAMA_BASE_URL、LLM_MODEL、EMBED_MODEL看是否被错误路径覆盖。确认依赖版本。用pip freeze对比项目建议版本不要混用新旧 API。打印关键中间结果。RAG 项目打印召回片段LangGraph 项目打印每一步 State。用最小示例复现。把完整项目裁剪到“一个模型 一句话”如果最小例子没问题再逐步加回业务逻辑。最终才看日志和链路追踪。生产环境应该接入结构化日志和追踪系统否则问题排查会非常痛苦。8. 最佳实践与后续学习路线跑通四个最小项目只是开始。真正难的是把这些 demo 变成能够稳定运行在真实业务里的工程系统。8.1 学习环境与生产环境的差异维度学习环境生产环境模型服务本机 Ollama单机单用户托管模型服务或自建集群需要监控和负载均衡数据量一个 txt 文件多格式文档、海量片段、增量更新检索单路向量检索多路召回、重排、过滤、权限控制提示词写在代码里独立提示词版本管理、灰度发布配置.env本地文件配置中心或容器环境变量密钥加密日志print 输出结构化日志、链路追踪、指标监控错误处理直接抛异常超时重试、降级、兜底回答、告警评测人工看一两个结果自动化评测数据集持续回归8.2 项目落地前检查清单把下面这份清单当作上生产前的自检盘每项都打钩后再考虑发布模型服务是否具备可用性保障超时时间、重试次数、熔断策略是否配置。模型名称、Base URL、API Key 是否都来自配置文件而不是硬编码。向量库是否设置了持久化文档增量更新和删除逻辑是否确定。检索模块是否有评测集能够在不修改业务代码的情况下重跑评分。提示词模板是否有独立版本管理改动时是否会影响旧会话。是否限制单次上下文的 token 上限避免长文档导致显存和延迟飙升。是否记录每次调用的模型、参数、检索片段和生成结果便于事后追溯。是否对用户输入做必要的长度限制和内容过滤避免超大请求压垮系统。是否明确回答兜底规则没有检索到内容时模型应该拒绝回答还是给出通用提示。8.3 下一步可以扩展的方向学完提示词工程、RAG、LangChain、LangGraph 后有能力继续深入的方向包括Agent 开发给 LangGraph 接入工具调用让模型可以调用搜索、数据库、审批接口。RAG 性能优化引入 Rerank 模型重新排序召回结果提高检索精度。检索评测建立包含问题、标准答案、期望引用片段的数据集用自动化指标量化效果。模型微调把高频任务沉淀为训练数据用 LoRA 等低成本方式微调模型减少每次调提示词的负担。长文本处理研究 Contextual Retrieval、Agentic RAG 等更复杂的检索编排方式。真正的学习路径不是收集一堆工具名称而是不断用“最小可运行系统”去验证理解。每接触一个新概念都问一次它是要解决什么问题对比之前的方案多了什么把一个简单流程改成它值不值得。带着这个习惯你的大模型应用开发能力会比单纯追新版本提升得更快。
大模型应用开发实战：提示词工程、RAG、LangChain与LangGraph
很多人从视频课程开始学习大模型应用开发时最先遇到的问题不是某个算法看不懂而是被一串名词卡住提示词工程、RAG、LangChain、LangGraph。它们经常出现在同一张学习路线图里但各自解决的问题并不一样。有人学完提示词工程就直接问“是不是该学微调”有人刚弄懂 RAG 又被 LangGraph 的状态图劝退。真正的问题不是资料太少而是缺少一条清晰的开发主线。本文会围绕一条可执行的大模型应用开发学习路线展开先理解四个名词分别处在什么技术层级再准备本地模型环境然后依次完成提示词工程、RAG、LangChain、LangGraph 四个最小项目。每步都会给代码、参数解释、验证方法和常见坑。学完之后你不仅能跑通示例还能在真实项目里判断“这一步到底该用提示词、检索、链编排还是图编排”。1. 先理清四个名词它们不是并列关系而是不同层级的技术栈很多初学者把提示词工程、RAG、LangChain、LangGraph 当作四个“并列的大模型技术”。但实际开发中它们处于不同层级需要组合使用。理清这个关系比提前记某一行 API 更值钱。1.1 一句话定位每个概念提示词工程Prompt Engineering研究的是“如何与模型对话才能稳定得到想要的结果”。它不依赖任何框架是使用大模型的最底层能力。RAGRetrieval-Augmented Generation解决的是“模型不知道的知识怎么办”。它先把外部知识切成片段并向量化再在回答问题时检索相关片段拼进提示词里让模型基于资料回答。RAG 不是框架是一种系统架构。LangChain 是一套面向大模型应用开发的工具库。它把模型调用、提示词模板、输出解析、向量数据库、记忆组件、工具调用等能力统一封装让开发者可以用“链Chain”的方式拼接业务逻辑。LangGraph 是建立在 LangChain 生态之上的图编排框架。它不再把流程当一条直线链而是当成一张有状态、有分支、有循环的图。那些需要多轮判断、条件跳转、状态保存的 Agent 类应用用 LangGraph 组织会更清晰。1.2 四个概念的分层关系与学习顺序推荐的学习顺序不是“谁有名先学谁”而是按依赖关系来先学提示词工程因为无论后面用什么框架最终都要靠提示词和模型沟通。再学 RAG因为知识库问答是大模型应用最常见的落地场景。然后学 LangChain因为 RAG 各个环节要用 LangChain 组件串联效率更高。最后学 LangGraph用于解决 LangChain 的“线性链”表达不了分支和循环的问题。下面用一张表说明它们的分工概念解决什么问题核心产物典型使用场景提示词工程控制模型输出质量系统提示词、模板、Few-shot 示例文本分类、抽取、改写、格式化输出RAG引入外部知识、降低幻觉检索器、拼接后的增强提示词企业知识库问答、文档助手、客服系统LangChain封装 LLM 应用的通用组件模型对象、Chain、Tool、Memory把模型调用和业务逻辑组合成可复用模块LangGraph编排多步骤、有状态的工作流StateGraph、Node、Edge、State多步 Agent、条件分支、人工审批流程1.3 新手最容易误解的几点第一不是所有项目都需要 LangGraph。如果业务是“提问 - 检索 - 回答”的直线流程用 LangChain 的一条链就够了。LangGraph 的价值体现在分支、循环和状态恢复上提前引入只会增加理解成本。第二提示词工程不是“把话写长一点”。它的核心是让输入输出的约束模式稳定怎么做少样本示例、怎么定义输出格式、怎么处理异常输出、怎么在不泄露系统提示词的前提下完成任务。这些都需要单独测试。第三RAG 不等于“把资料全部塞进提示词”。不检索、直接拼原文会让上下文爆炸模型也会被无关内容干扰。RAG 系统里检索这一步的设计质量往往比生成时的提示词更影响最终效果。2. 环境准备先让大模型能对话再谈上层框架学习环境不要一上来就上云 API。建议先在本地部署一个开源模型跑通“模型能用”这一步再让 LangChain、LangGraph 和它对话。这样能够避免 API 费用、网络波动和 Key 泄漏等问题也方便看完整调用链路。2.1 模型服务的三种方式怎么选本地开发时模型服务有三种常见来源方案优点缺点适合场景云端托管 API响应快、模型大、免运维需要网络可达、有费用、需要密钥管理产品原型、商用系统本地私有化部署数据不出内网、可控、无按量费用需要 GPU 或大内存性能受本机限制隐私敏感、离线开发、教学实验兼容接口的本地服务本地模型也能使用 OpenAI 风格 API 语法接口兼容层可能有差异想用统一客户端代码切换后端模型实际学习中建议优先选本地部署。如果本机没有足够显存也可以选择内网中已有的模型服务地址不一定要自己装大模型。2.2 用 Ollama 本地跑通一个对话模型Ollama 是目前最常用的本地模型管理工具之一它会帮你管理模型下载、启停和端口。不同操作系统的安装方式以官方文档为准Linux 和 macOS 常见安装命令如下curl -fsSL https://ollama.com/install.sh | sh安装完成后启动服务并拉取一个适合学习的中文对话模型。如果没有特别原因可以先从 7B 级别模型开始ollama serve再开一个终端拉取并运行模型ollama pull qwen2.5:7b ollama run qwen2.5:7b如果屏幕出现一个可以聊天的交互界面说明模型已经跑起来了。按Ctrl D退出聊天后可以测试它提供的 HTTP 接口curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 用一句话介绍你自己, stream: false }返回 JSON 中的response字段就是模型输出。这个实验的意义在于确认本地模型服务监听地址、模型名、请求格式都没有问题。后面所有 LangChain、LangGraph 代码最终都会落到这个服务上。2.3 创建 Python 虚拟环境并安装依赖工程上不建议把依赖直接装到系统 Python 里。先创建虚拟环境python -m venv .venv source .venv/bin/activate pip install --upgrade pip然后安装本轮学习需要的依赖pip install langchain langchain-community langchain-ollama langchain-text-splitters langgraph chromadb说明一下这些包的用途langchain核心链、提示词模板、输出解析器。langchain-community社区集成组件如文档加载器、部分向量库封装。langchain-ollamaLangChain 与 Ollama 的对接封装提供ChatOllama模型客户端。langchain-text-splitters文档分块工具。langgraph状态图编排框架。chromadb本地向量数据库。大模型生态版本更新很快。不要照抄别人项目时忽略版本安装时最好把版本号写入requirements.txt固定下来例如pip freeze requirements.txt之后环境坏了可以随时恢复pip install -r requirements.txt2.4 用统一配置管理模型地址和模型名开发阶段不要把所有配置直接写在代码里。先创建一个.env文件OLLAMA_BASE_URLhttp://localhost:11434 LLM_MODELqwen2.5:7b EMBED_MODELnomic-embed-text在 Python 中读取时可以安装python-dotenv并这样加载pip install python-dotenvfrom dotenv import load_dotenv import os load_dotenv() OLLAMA_BASE_URL os.getenv(OLLAMA_BASE_URL, http://localhost:11434) LLM_MODEL os.getenv(LLM_MODEL, qwen2.5:7b) EMBED_MODEL os.getenv(EMBED_MODEL, nomic-embed-text)配置外置的好处是换模型服务、换模型名时不需要改业务代码只需改环境变量。后面进入生产环境时这套习惯也能顺利迁移到配置中心或容器环境变量。3. 第一步实践用提示词工程控制模型输出框架代码前先做一次“裸提示词”练习。目的不是练写作而是理解模型的输出是受提示词和生成参数共同影响的。3.1 提示词的基本结构一个完整提示词至少要包含三层信息角色与任务例如“你是一名客服助手”。输入内容例如用户的问题或文本。输出约束例如格式、长度、是否保留证据、是否允许推测。在实际开发中前两条系统提示词通常做成模板输入内容在运行时填充。先用 LangChain 的ChatPromptTemplate组织一个最简模板from langchain_core.prompts import ChatPromptTemplate from langchain_ollama import ChatOllama from langchain_core.output_parsers import StrOutputParser prompt ChatPromptTemplate.from_messages([ (system, 你是一个文本分类助手。只输出类别名称不要输出解释。), (human, 请对下面文本分类类别选项技术支持、账号问题、其他。\n文本{text}), ]) llm ChatOllama( base_urlOLLAMA_BASE_URL, modelLLM_MODEL, temperature0.2, num_predict256, ) chain prompt | llm | StrOutputParser() result chain.invoke({text: 我登录后一直提示验证码错误}) print(result)这里有一个很多初学者不理解的地方prompt | llm | StrOutputParser()这种写法是 LangChain 的 LCELLangChain Expression Language语法。竖线把“模板、模型、解析器”连接成一条链调用时数据按顺序流通。它的好处是每个组件都可以单独替换、单独测试。3.2 最小案例让模型输出结构化 JSON文本分类的下一步是让模型直接输出 JSON。项目里调用接口时往往需要把模型输出反序列化成对象。prompt_json ChatPromptTemplate.from_messages([ (system, 你是JSON转换助手。只输出JSON不要输出解释不要用Markdown代码块包裹。), (human, 抽取下面文本中的实体输出JSON格式如下\n{{\name\: \人名\, \company\: \公司名\}}\n文本{text}), ]) chain_json prompt_json | llm | StrOutputParser() raw chain_json.invoke({ text: 张伟在云枢科技担任前端工程师 }) print(raw)运行后理想输出是{name: 张伟, company: 云枢科技}如果模型输出了一段 Markdown 代码块字符串两侧会出现 json 标记。这种情况下不要直接json.loads()要先做清理import json def parse_json(text: str): text text.strip() if text.startswith(): text text.split(\n, 1)[1] if text.endswith(): text text[:-3].strip() return json.loads(text)这个清理逻辑虽然简单但在真实项目里能解决大量模型“画蛇添足”的问题。3.3 关键生成参数怎么调同一个模型不同参数组合可能得到完全不同的结果。下面的参数在 LangChain 的ChatOllama中使用参数含义常见设置调大影响调小影响temperature采样随机性0.2 到 0.8更随机、更有创意更稳定、更保守top_p核采样概率0.8 到 0.95候选词范围更大输出更集中num_predict生成最大 token 数256 到 2048可生成更长文本生成容易截断seed随机种子固定或忽略固定后结果更可复现每次输出变化更大需要区分两类场景。抽取、分类、格式化这类任务temperature建议设为 0.1 到 0.3。创意写作、头脑风暴、文案改写这类任务可以调到 0.7 以上。不要把temperature当成“让模型更聪明”的开关它只控制随机性不控制事实正确性。3.4 提示词工程里最常见的坑第一个坑是提示词越来越长规则之间相互矛盾。有人要求模型“必须保持专业”又要求“语气可爱”最后输出完全不可控。正确做法是把约束按优先级排列任务、输入、输出格式、语气。第二个坑是只调temperature不检查提示词。项目里遇到输出不稳定第一反应应该是看是不是提示词里给了模糊的指令而不是盲目降温。第三个坑是系统提示词被用户输入覆盖。有些模型对话接口中用户消息里写入的规则会覆盖早期系统消息。建议把不可变规则放系统消息把需要用户自由表述的内容放用户消息且不在用户消息里重复敏感指令。4. 第二步实践实现一个最小 RAG 知识库提示词工程能力足够后进入最常用的大模型应用方向RAG。RAG 并不是一个库而是一种流程。很多招聘要求里的“RAG 实战”考察的正是你对整个流程的理解和落地能力。4.1 RAG 解决什么问题大模型的知识存在训练时间截断也不了解企业私有文档。RAG 的思路是回答问题前先从外部知识库里检索相关内容再把“检索到的资料 用户问题”一起交给模型生成答案。这种方式有三个明显收益引入实时或私有知识不依赖模型内部记忆。降低模型编造信息的概率因为模型能引用给定资料。不需要针对每个知识片段重新训练模型成本远低于微调。4.2 最小 RAG 流程拆解一个完整 RAG 流程分为索引阶段和查询阶段。索引阶段加载文档。将长文档切分成小块。对每个块做向量化。把向量和文本存入向量数据库。查询阶段对用户问题做向量化。在向量库中查找最相似的几个块。把块内容拼入提示词。模型基于资料生成回答。理解这一点后再看代码就不会被各种抽象类吓到。4.3 用 LangChain Chroma 实现 RAG先准备一个名为knowledge.txt的文本文件内容可以是任何知识片段例如员工手册、产品说明、项目规范。下面代码演示完整流程。from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_community.vectorstores import Chroma # 加载文档 loader TextLoader(knowledge.txt, encodingutf-8) docs loader.load() # 切分块 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, ) chunks splitter.split_documents(docs) print(f切分后共 {len(chunks)} 个块) # 向量化 embedding OllamaEmbeddings( base_urlOLLAMA_BASE_URL, modelEMBED_MODEL, ) # 写入向量库 vectorstore Chroma.from_documents( documentschunks, embeddingembedding, persist_directory./chroma_db, )这里有两个重点。chunk_size是每个块的最大字符数chunk_overlap是相邻块的重叠长度。重叠的目的是避免一个完整句子或完整概念恰好被切到两个块里。查询阶段代码from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser retriever vectorstore.as_retriever(search_kwargs{k: 3}) question 项目预算审批需要经过哪些步骤 results retriever.invoke(question) context \n\n.join([doc.page_content for doc in results]) rag_prompt ChatPromptTemplate.from_messages([ (system, 你是企业内部知识助手。请只根据给定资料回答资料中没有的信息不要编造。), (human, 资料\n{context}\n\n问题{question}), ]) rag_chain rag_prompt | llm | StrOutputParser() answer rag_chain.invoke({context: context, question: question}) print(检索到的片段数, len(results)) print(回答, answer)执行后可以先打印context人工确认检索到的片段是否真的与问题相关。这一步非常关键如果检索结果本身就不相关后面模型回答得再流畅也毫无意义。4.4 RAG 效果怎么验证RAG 的验证分两层检索质量和生成质量。检索质量可以用最朴素的方式验证对每一道测试题检查标准答案是否出现在召回结果中并看在返回的前 1、3、5 个结果里是否命中。这就是 RecallK 的思路。如果没有工程化的评测脚本至少要做到“人工看前几个召回片段确认没有跑偏”。生成质量验证时重点看三点模型是否完全照搬资料还是加入了自己的想象。资料中多个片段冲突时模型是否发现冲突。问题超出资料范围时模型是否老实回答“不知道”。4.5 RAG 落地中容易被忽视的坑第一个坑是分块参数一刀切。500 字符不一定适合所有场景。如果业务文档是合同条款可能要用 1000 以上并且做结构感知切分如果是客服问答对可能 200 就够。应该用小规模测试集比较不同chunk_size的结果而不是凭感觉定。第二个坑是同一个文档不关注章节结构。RecursiveCharacterTextSplitter会根据分隔符递归切分但它不理解标题层级。生产项目里最好先把 Markdown 标题、PDF 元数据等结构信息带入文本甚至保留page信息便于后续引用出处。第三个坑是忘记persist_directory每次启动都重建向量库。学习阶段问题不大但生产环境需要明确的索引更新策略哪些文档需要增量写入哪些需要替换哪些需要删除。5. 第三步实践用 LangChain 组织应用逻辑RAG 示例已经展示了 LangChain 的一部分能力。第三步要做的是把模型调用、提示词、输出解析、知识检索、记忆等能力组合成更完整、更可维护的应用。5.1 LangChain 在项目里到底负责什么不写 LangChain 也可以调用大模型。LangChain 的价值在于把高频动作抽象成组件并提供向前兼容的编排方式。当你需要“读取用户问题 - 检索知识库 - 判断是否需要追问”如果直接用原生代码也能写但每个模型供应商都要写一套 HTTP 调用。LangChain 统一了接口让代码更接近业务语义。5.2 再看 LCEL一条链就是一个可复用模块LCEL 的核心是用|把组件连接成管道。前面的 RAG 示例已经有了雏形。这里补一个同时带检索和输出的完整链from langchain_core.output_parsers import StrOutputParser from langchain_core.prompts import ChatPromptTemplate def build_rag_chain(retriever, llm): prompt ChatPromptTemplate.from_messages([ (system, 只能根据资料回答。), (human, 资料\n{context}\n\n问题{question}), ]) def format_docs(docs): return \n\n.join([doc.page_content for doc in docs]) chain ( { context: retriever | format_docs, question: lambda x: x[question], } | prompt | llm | StrOutputParser() ) return chain chain build_rag_chain(retriever, llm) print(chain.invoke({question: 报销标准是什么}))这段代码展示了 LCEL 的一个重要特点第一个字典并不是普通字典而是“运行时计算字段”。retriever | format_docs表示先执行检索再把检索结果用format_docs拼接成字符串。这比手动调用 retriever 再填充模板更简洁也让数据流更透明。5.3 多轮对话里的记忆怎么管理在客服机器人里用户可能会说“那什么时候到账”单看这一句系统不知道“那”指的是什么所以需要记忆。LangChain 中有多种 Memory 类。最简单实用的策略是把最近 N 轮消息保存到列表拼入提示词。注意不要无限放大上下文token 数量和延迟都会上涨。from langchain_core.messages import AIMessage, HumanMessage history [] def chat_with_history(question: str): messages [ (system, 你是客服助手回答简洁准确。), *history, (human, question), ] answer llm.invoke(messages).content history.append(HumanMessage(contentquestion)) history.append(AIMessage(contentanswer)) if len(history) 6: del history[:2] return answer这里del history[:2]是控制内存长度的简单实现。生产环境一般用 Redis 或数据库保存历史并按 session_id 隔离用户这里只演示思路。5.4 LangChain 版本变化带来的排错思路LangChain 生态接口曾经频繁变化。常见报错是ImportError: cannot import name XXX from langchain。遇到这种问题第一反应不是找“最新写法”而是检查当前环境版本pip show langchain langchain-community langchain-ollama然后去对应当前版本的官方文档查 API。千万不要直接抄一年前的博客代码。也可以写一段最小复现代码判断问题出在依赖版本还是业务逻辑。6. 第四步实践用 LangGraph 编排有状态的流程RAG 和 LangChain 解决的是“线性流程”但真实业务往往不是一条直线。例如客服机器人要判断“用户问题是否需要检索知识库”如果需要就查资料不需要就直接让模型回答。再比如多步 Agent 需要先查天气、再写文案、再调用审批接口。这种带分支和循环的流程应该交给 LangGraph。6.1 LangGraph 和 LangChain 的区别LangChain 的 Chain 是固定顺序的数据流。LangGraph 则把应用组织成一张有向图节点Node执行具体动作。边Edge决定节点的流转路径。条件边Conditional Edge根据当前状态决定走哪条路。图在运行过程中维护一个共享状态State。一句话概括LangChain解决“组件怎么组合”LangGraph解决“流程怎么流转”。6.2 核心概念State、Node、Edge、CheckpointerState 是贯穿整个图的数据结构。每个节点函数接收当前 State返回一个字典LangGraph 会把字典里的字段更新回 State。Node 就是一个普通 Python 函数。Edge 决定图结构。Checkpointer 用于持久化执行状态支持断点恢复。理解 State 的更新是 LangGraph 学习的关键。下面用 TypedDict 定义状态from typing import TypedDict, Literal class QAState(TypedDict): question: str docs: list[str] need_search: bool answer: str这里need_search是一个布尔值用来控制条件路由。6.3 最小 LangGraph 案例判断是否需要检索用图把三个节点串起来judge_node判断是否需要检索。search_node查询向量库。answer_node生成答案。代码from langgraph.graph import StateGraph, START, END def judge_node(state: QAState) - dict: prompt ChatPromptTemplate.from_messages([ (system, 判断用户问题是否需要查询内部资料。需要查询则输出yes否则输出no。), (human, state[question]), ]) decision (prompt | llm | StrOutputParser()).invoke({}) return {need_search: decision.strip().lower() yes} def search_node(state: QAState) - dict: docs retriever.invoke(state[question]) return {docs: [doc.page_content for doc in docs]} def answer_node(state: QAState) - dict: if state[docs]: context \n\n.join(state[docs]) prompt ChatPromptTemplate.from_messages([ (system, 只根据资料回答。), (human, 资料\n{context}\n\n问题{question}), ]) answer (prompt | llm | StrOutputParser()).invoke({ context: context, question: state[question], }) else: answer llm.invoke(state[question]).content return {answer: answer} def route_based_on_search(state: QAState) - Literal[search, answer]: return search if state[need_search] else answer graph StateGraph(QAState) graph.add_node(judge, judge_node) graph.add_node(search, search_node) graph.add_node(answer, answer_node) graph.add_edge(START, judge) graph.add_conditional_edges(judge, route_based_on_search, { search: search, answer: answer, }) graph.add_edge(search, answer) graph.add_edge(answer, END) app graph.compile() result app.invoke({ question: 年度调薪的申请流程是什么, docs: [], need_search: False, answer: , }) print(result[answer])注意add_conditional_edges的三个参数第一个是源节点名第二个是路由函数第三个是路由函数返回值和目标节点的映射。路由函数必须返回映射中定义的字符串否则运行时会出现 Key 错误。6.4 LangGraph 的调试方法LangGraph 项目里最常见的故障不是代码语法错误而是状态流没按预期走。调试时可以分三步打印invoke返回的最终 State确认每个字段是否符合预期。去掉answer节点只跑judge和search观察中间状态。增加日志或使用 LangGraph 内置的调试视图查看每个节点耗时和输入输出。如果你在judge之后发现need_search一直是 False先单独测试那个提示词不要直接怀疑框架。多数情况下问题出在模型理解或提示词表达而不是图本身。7. 常见问题排查从现象倒推原因四个最小项目跑完后下面这张排查表可以覆盖绝大多数学习阶段的问题。遇到故障时先从最基础的“服务是否可达、版本是否匹配”查起不要一上来就改业务代码。问题现象常见原因检查方式处理建议模型没有输出或超时Ollama 未启动、模型名错误、网络不通先 curl 模型服务接口重启ollama serve确认模型名返回 401 或鉴权失败API Key 错误、Base URL 配置错误检查.env中的地址和密钥用最小请求直接调模型服务验证输出中文乱码终端编码不对、模型分词异常把输出写入文件检查设置PYTHONIOENCODINGutf-8模型输出带 Markdown 代码块提示词没要求去除模型习惯性包裹打印原始返回字符串在提示词里强调“不输出代码块”并加清理函数检索结果与问题无关分块太大、embedding 模型弱、相似度阈值低打印召回片段文本调小 chunk_size换更好的 embedding 模型增加 rerankLangGraph state 未更新节点返回了未定义的 key打印每个节点返回字典检查 State 类型定义和节点返回值报 ImportErrorlangchain 版本过旧或过新执行pip show langchain锁定版本按当前官方文档修改导入路径本地推理速度慢模型过大、无 GPU、并发太高ollama ps查看加载模型换更小模型限制并发请求数量上面的表格是“现象表”。实际排错建议按下面的链路走确认模型服务本身可用。用命令行或 curl 直接请求一次模型服务排除代码问题。确认配置注入成功。打印OLLAMA_BASE_URL、LLM_MODEL、EMBED_MODEL看是否被错误路径覆盖。确认依赖版本。用pip freeze对比项目建议版本不要混用新旧 API。打印关键中间结果。RAG 项目打印召回片段LangGraph 项目打印每一步 State。用最小示例复现。把完整项目裁剪到“一个模型 一句话”如果最小例子没问题再逐步加回业务逻辑。最终才看日志和链路追踪。生产环境应该接入结构化日志和追踪系统否则问题排查会非常痛苦。8. 最佳实践与后续学习路线跑通四个最小项目只是开始。真正难的是把这些 demo 变成能够稳定运行在真实业务里的工程系统。8.1 学习环境与生产环境的差异维度学习环境生产环境模型服务本机 Ollama单机单用户托管模型服务或自建集群需要监控和负载均衡数据量一个 txt 文件多格式文档、海量片段、增量更新检索单路向量检索多路召回、重排、过滤、权限控制提示词写在代码里独立提示词版本管理、灰度发布配置.env本地文件配置中心或容器环境变量密钥加密日志print 输出结构化日志、链路追踪、指标监控错误处理直接抛异常超时重试、降级、兜底回答、告警评测人工看一两个结果自动化评测数据集持续回归8.2 项目落地前检查清单把下面这份清单当作上生产前的自检盘每项都打钩后再考虑发布模型服务是否具备可用性保障超时时间、重试次数、熔断策略是否配置。模型名称、Base URL、API Key 是否都来自配置文件而不是硬编码。向量库是否设置了持久化文档增量更新和删除逻辑是否确定。检索模块是否有评测集能够在不修改业务代码的情况下重跑评分。提示词模板是否有独立版本管理改动时是否会影响旧会话。是否限制单次上下文的 token 上限避免长文档导致显存和延迟飙升。是否记录每次调用的模型、参数、检索片段和生成结果便于事后追溯。是否对用户输入做必要的长度限制和内容过滤避免超大请求压垮系统。是否明确回答兜底规则没有检索到内容时模型应该拒绝回答还是给出通用提示。8.3 下一步可以扩展的方向学完提示词工程、RAG、LangChain、LangGraph 后有能力继续深入的方向包括Agent 开发给 LangGraph 接入工具调用让模型可以调用搜索、数据库、审批接口。RAG 性能优化引入 Rerank 模型重新排序召回结果提高检索精度。检索评测建立包含问题、标准答案、期望引用片段的数据集用自动化指标量化效果。模型微调把高频任务沉淀为训练数据用 LoRA 等低成本方式微调模型减少每次调提示词的负担。长文本处理研究 Contextual Retrieval、Agentic RAG 等更复杂的检索编排方式。真正的学习路径不是收集一堆工具名称而是不断用“最小可运行系统”去验证理解。每接触一个新概念都问一次它是要解决什么问题对比之前的方案多了什么把一个简单流程改成它值不值得。带着这个习惯你的大模型应用开发能力会比单纯追新版本提升得更快。