大模型应用开发主线：提示词工程、RAG与Agent编排实践

大模型应用开发最难的从来不是某个具体工具而是没有一条主线。今天打开 B 站、掘金、CSDN搜索大模型能搜出成千上万份教程有讲提示词的有讲 LangChain 的有讲 RAG 的有讲 LangGraph 的还有讲微调的。大部分人都卡在同一类问题里——从一个教程跳到另一个教程学完提示词不知道下一步该干嘛跑通了一个 RAG demo 又不知道真实项目里怎么用LangChain 刚学完一半又冒出来一个 LangGraph直接懵了。这篇文章想把这条主线讲清楚。我会从零开始把大模型应用开发拆成三层递进的内容提示词工程、RAG、Agent 编排。其中 LangChain 和 LangGraph 不是竞争关系而是演进关系。读完这篇文章你不仅能理解每个技术到底解决什么问题还能拿到一组可以落地的实操代码以及一条有先后顺序、有阶段性验证目标的 2026 年学习路线。第一个要记住的判断是大模型应用开发的本质是把模型能力变成产品能力。所有框架和工具都只是这件事的脚手架。1. 大模型应用开发的三个层次与知识全景很多新手学大模型开发第一个误区是不知道自己要解决什么问题。看到提示词工程觉得重要看到 RAG 觉得重要看到智能体 Agent 也觉得重要最后什么都想学什么都没学透。实际上大模型应用开发可以清晰分成三个层次每一层的目标和所需技能完全不同。第一层是提示词工程Prompt Engineering解决的是“怎么让模型把话说对”的问题。你不需要写代码只需要调整输入就能显著改变模型输出质量。这是所有后续技术的基础因为它决定了模型对你指令的响应上限。很多人低估这一层觉得提示词不就是说话吗但真实项目里一个结构化的 System Prompt 和一个随手写的 Prompt产出的准确率能差 20% 到 40%。第二层是检索增强生成RAG解决的是“模型不知道的知识怎么办”的问题。大模型的知识截止时间是固定的也没有企业内部的私有数据。RAG 的核心思路不是重新训练模型而是先检索再生成从外部知识库找出相关内容拼进提示词里让模型根据这些资料回答。它解决的是知识时效性和私有知识接入问题也是目前企业落地大模型性价比最高的方式。第三层是 Agent 与流程编排解决的是“让模型动起来、多做几步”的问题。这里的代表工具就是 LangChain 和 LangGraph。提示词工程是单次交互的优化RAG 是单次问答的增强而 Agent 框架让模型可以自己决定调用什么工具、按什么顺序执行、什么时候结束。LangChain 是最流行的编排框架LangGraph 是它的升级版把流程从线性链条改成了有状态图。这三层对应三种开发难度提示词工程门槛最低产品经理都能学RAG 需要掌握向量数据库和检索逻辑适合后端开发者Agent 开发需要理解状态管理、编排逻辑和工具调用是进阶内容。下面按这个顺序展开最后给你一条完整的学习路线。2. 提示词工程不是聊天话术是人机接口契约提示词工程之所以被严重低估是因为它听起来太像日常说话了。但实际项目中提示词不是“话术”而是“接口契约”。你用固定的格式、字段和约束来定义模型的输入输出它会稳定地按你的要求执行你随便说它就随便答。开始学习提示词工程先掌握几组核心概念。System Prompt 是系统级指令用来设定角色、任务边界和输出格式User Prompt 是用户输入是每次对话变化的内容Few-shot 是给模型提供几个示例引导它按照示例的风格和结构输出。还有一个容易被忽视的东西叫温度参数Temperature它控制生成结果的随机性技术类任务建议调低到 0.1 到 0.3创意类任务可以调高到 0.7 以上。提示词工程真正值钱的地方是在真实任务中结构化约束。用一个场景来说明。假设你要做一个“文章摘要助手”随便写提示词是“帮我把这篇文章总结一下”模型输出什么取决于它当天的心情。但如果你写一个结构化提示词效果就完全不一样你是一个专业的技术文章摘要助手。请阅读用户提供的文章输出以下格式的摘要 【核心观点】3 句话以内概括文章主要观点 【关键技术】列出文章中提到的所有技术名词 【适用场景】说明这篇文章适合哪些读者 【一句话总结】用一句话说明文章价值 要求 1. 不要增加原文不存在的观点 2. 保持客观中立 3. 使用中文输出这个提示词做了什么它把“总结”这个模糊任务拆成了四个固定字段限制了输出范围还规定了不要做什么。这时候模型输出就是稳定可解析的结构化文本可以直接接入下游流程。这个思维模式才是提示词工程的核心先定义输入和输出的契约再让模型在这个契约内工作。在 2026 年的技术语境下提示词工程已经不再只是写几句话而是出现了提示词模板、自动优化和评测驱动的趋势。你写的每一条提示词都应该像代码一样可以版本管理、可以测试、可以评估效果。这个思维会在下一层 RAG 开发中被反复用到。3. RAG为什么大模型需要外挂一个知识库把提示词工程搞定之后你会遇到第二个坎模型不知道你企业的内部资料不知道 2026 年刚发生的新事件也会在专业领域一本正经地胡说八道。RAG 就是为这个场景而生的全称是 Retrieval-Augmented Generation检索增强生成。RAG 工作原理可以拆成三个阶段。第一个阶段是索引Indexing把文档切分成小块每一块用向量模型转成向量存进向量数据库。第二个阶段是检索Retrieval用户提问时先把问题转成向量然后去向量数据库里找出最相近的文档片段。第三个阶段是生成Generation把检索到的文档片段、用户问题和提示词模板拼在一起交给模型生成回答。说白了就是“先查资料再写答案”。为什么需要 RAG 而不是微调因为微调的代价高、周期长、更新麻烦。每改一次知识库就要重新训练一次模型而 RAG 只需要重新索引文档几分钟就能生效。拿一个客服系统举例公司产品手册更新了微调方案要准备训练数据、花钱训练、重新部署模型至少一周RAG 方案只需要把新手册切成片段存进向量库问答立刻就能用到。这也是为什么 RAG 被称为企业落地大模型性价比最高的方案。RAG 的完整技术栈比提示词工程复杂得多。它的核心组件包括嵌入式模型Embedding Model、向量数据库、切分策略、检索算法、重排序模型Reranker。其中检索质量是决定 RAG 效果上限的关键。有一个容易被忽略的点是切分策略直接决定检索质量切得太大会引入噪声切得太小会丢失上下文。一般先用固定大小加重叠窗口的方式切分再根据具体文档结构调整。这里建议你记住一句话RAG 的效果好不好80% 取决于索引和检索环节生成环节只是最后一步。4. RAG 最小链路代码实战从文本到问答理论讲完直接进入实战。这里搭建一个 RAG 最小链路选用 LangChain 生态中的开源组件和 FAISS 向量库目的是跑通“文档导入—向量化—检索—增强生成”的全过程。需要注意的是本文给出的代码结构是通用思路相关库的版本请以实际安装为准不要照抄版本号。先准备环境依赖pip install langchain langchain-community langchain-openai faiss-cpu python-dotenv国内开发者如果无法直接使用 OpenAI 接口可以把 base_url 换成任何兼容 OpenAI 协议的网关地址。关键是不管换哪个模型服务核心链路都不变。创建项目目录下的.env文件OPENAI_API_KEY你的密钥 OPENAI_BASE_URLhttps://你的网关地址/v1 EMBEDDING_MODELtext-embedding-3-small LLM_MODELgpt-4o-mini下面写一个最小 RAG 示例程序文件路径rag_demo.py。这个脚本做的事情是把一篇本地文档读取进来切分成小块转成向量存进 FAISS然后接收用户问题检索相关资料交给大模型生成答案。from dotenv import load_dotenv from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain_community.vectorstores import FAISS from langchain_core.prompts import ChatPromptTemplate load_dotenv() # 1. 加载文档 loader TextLoader(knowledge.txt, encodingutf-8) documents loader.load() # 2. 切分文档 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50, separators[\n\n, \n, 。, , , , ] ) chunks text_splitter.split_documents(documents) # 3. 向量化并存入 FAISS embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore FAISS.from_documents(chunks, embeddings) # 4. 创建检索器 retriever vectorstore.as_retriever(search_kwargs{k: 3}) # 5. 构建增强提示词模板 prompt ChatPromptTemplate.from_messages([ (system, 你是一个严谨的问答助手。请只根据下面提供的资料回答问题。 如果资料中没有答案请明确回答资料中未找到相关信息。\n\n 资料\n{context}), (human, 问题{question}) ]) # 6. 构建 RAG 链路 llm ChatOpenAI(modelgpt-4o-mini, temperature0.1) def rag_answer(question: str) - str: docs retriever.invoke(question) context \n\n.join([doc.page_content for doc in docs]) chain prompt | llm response chain.invoke({context: context, question: question}) return response.content if __name__ __main__: q 这份文档里提到的最重要技术点是什么 print(rag_answer(q))这段代码里需要注意三个细节。第一个是切分器的separators参数中文文档必须加上中文标点分隔符否则会把完整句子拦腰切断。第二个是k参数它决定每次检索返回多少文档片段一般 3 到 5 个足够太多反而会干扰模型判断。第三个是 System Prompt 中的约束“资料中没有答案就明确说没有”这是防止模型幻觉的第一道防线。运行方式很简单python rag_demo.py如果一切正常你会看到模型根据knowledge.txt内容输出的答案。如果输出乱答优先检查knowledge.txt的编码是否是 UTF-8如果检索结果为空打印一下chunks查看切分结果是否正常如果 API 报错检查.env文件和网关地址是否配置正确。跑通这个最小链路之后RAG 你就已经入门了。5. 向量检索与检索质量的关键细节RAG 跑通最小链路只是开始生产环境中真正的难点是检索质量。很多团队做完第一个 RAG demo 都很兴奋但一旦把真实业务文档灌进去效果立刻大打折扣答案牛头不对马嘴。问题几乎都出在检索环节而不是生成环节。第一个关键细节是文档切分策略。切分文档不是机械地按字符数切而是要尽量保留语义完整性。Markdown 文档应该按标题层级切代码文档应该按函数切PDF 论文应该按段落切。工业界最常用的方案是 RecursiveCharacterTextSplitter 配合自定义分隔符先用段落分隔段落太长再按句子分隔句子还太长最后才按字符硬切。切分长度也有讲究经验值在 300 到 800 个字符之间具体要看你的模型上下文长度和文档类型。第二个关键细节是向量检索的局限性。向量检索擅长找“语义相似”的内容但它对关键词匹配不敏感。假设用户搜索的是产品型号“A100-X”向量检索很可能返回一堆关于 GPU 的泛泛内容因为嵌入模型认为“A100-X”和“高性能计算”语义接近但用户要的是精确型号的规格文档。解决这个问题的方法是混合检索Hybrid Search同时用向量检索和关键词检索BM25再把两种结果合并去重。这是 2026 年 RAG 工程中最常见的优化手段。第三个关键细节是重排序Rerank。向量检索返回 Top 20 甚至 Top 50 片段里面包含很多不相关的内容。这时候不要直接把所有片段都扔给大模型而是用一个重排序模型对候选片段做精细打分选出最相关的 Top 3 到 Top 5。重排序模型虽然会引入额外延迟和成本但能显著提升最终答案的准确性。典型的开源方案有 BGE-Reranker 系列也可以使用云厂商的重排序 API。第四个关键细节是知识库更新。生产环境的文档每周都会变不可能每次更新都全量重建索引。常见方案是增量更新维护一个文档哈希表文档内容变了就删除旧向量、写入新向量。FAISS 本身不擅长删除操作生产环境更推荐使用支持过滤和更新的向量数据库如 Milvus、Qdrant、pgvector。这都是在真实项目中会踩到的坑早一点了解后面就少走很多弯路。6. LangChain大模型应用开发的积木工具箱现在进入第三层LangChain。很多初学者第一次接触 LangChain会被它的概念数量吓到模型封装、提示词模板、记忆模块、工具调用、Agent、Chain、回调系统……感觉像一座大山。其实 LangChain 的核心价值就一句话把大模型应用开发中重复出现的模式封装成可复用的积木。LangChain 最基础的概念是 Model I/O也就是模型输入输出封装。不管你是用 OpenAI、国产模型还是本地部署的模型LangChain 都提供统一的调用接口。这就是为什么前面那段 RAG 代码里换模型就只需要改一行配置。再往上走是 Retrieval前面已经实践过LangChain 把文档加载、切分、向量化、检索封装成了一套标准接口。然后是记忆模块解决多轮对话上下文的保存问题。对话系统如果每次调用都忘记前面说了什么体验会非常差。LangChain 提供了多种记忆实现BufferMemory 保存全部历史ConversationSummaryMemory 用摘要代替全文以节省 Token还有专门配合向量数据库长期记忆的方案。再往上是 Agent 和工具调用。LangChain Agent 让你可以给模型注册一组工具——查天气的 API、查数据库的函数、执行代码的沙箱——然后让模型自己决定什么时候调用哪个工具。这个能力打开了一个巨大的想象空间模型不再只是聊天它能干活了。LangChain 的编排模式是 Chain链用|管道符把组件串联起来前面的输出作为后面的输入。前面 RAG 示例里的prompt | llm就是最简单的一条链。但这种链式结构有个天然缺陷它是线性的、单向的。复杂业务场景里你可能需要根据模型的中间输出决定下一步走哪个分支可能需要在几个工具之间来回循环多次。线性链条做不到这一点。这个时候LangGraph 就出现了。7. LangGraph从线性链到有状态图LangGraph 是 LangChain 团队推出的下一代编排框架本质是一个有状态图执行引擎。如果说 LangChain 是积木那 LangGraph 就是把积木搭成一个复杂的机电系统能循环、能判断、能维护状态、能容错重试。它和 LangChain 不是二选一的关系而是演进和保护的关系你先用 LangChain 的组件模型、检索器、工具再用 LangGraph 编排它们。LangGraph 的几个核心概念需要先理解。State 是图执行过程中的共享状态所有节点都能读写它Node 是图中的一个处理步骤比如“调用大模型”“调用检索器”“执行工具”Edge 是节点间的连线分为普通边和条件边条件边是 LangGraph 最强大的地方它可以根据当前状态决定下一步走向哪个节点。用一个多轮 Agent 例子来说明 LangGraph 的价值。假设你要做一个自动排查问题的运维助手第一步让大模型判断问题属于网络故障还是服务故障第二步分别走不同的排查子流程第三步如果排查结果不明确还要回退到第一步继续追问。这个场景用 LangChain 线性链条非常难写要么写很多 if-else 分支要么写出一堆难以维护的回调。LangGraph 用图来表达就非常自然判断节点发散出两条条件边回退逻辑就是一条回到判断节点的循环边。这里用一个 LangGraph 基础示例来展示它在 Agent 开发中的形态。先安装依赖pip install langgraph下面的例子构造了一个简单的工作流模型先回答问题然后判断回答质量如果质量不达标重新回答一次。from typing import TypedDict, Literal from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI class AgentState(TypedDict): question: str answer: str quality: str llm ChatOpenAI(modelgpt-4o-mini, temperature0.3) def generate_answer(state: AgentState): response llm.invoke(f请回答这个问题{state[question]}) return {answer: response.content} def check_quality(state: AgentState): response llm.invoke( f请判断这个回答是否清晰完整。回答{state[answer]}。 f如果清晰完整只回复通过否则只回复重写。 ) return {quality: response.content.strip()} def rewrite_answer(state: AgentState): response llm.invoke( f你之前的回答不够清晰请重新回答这个问题{state[question]}。 f要求逻辑清晰步骤完整。 ) return {answer: response.content} def route_after_check(state: AgentState) - Literal[rewrite, END]: if state[quality] 重写: return rewrite return END graph StateGraph(AgentState) graph.add_node(generate, generate_answer) graph.add_node(check, check_quality) graph.add_node(rewrite, rewrite_answer) graph.set_entry_point(generate) graph.add_edge(generate, check) graph.add_conditional_edges(check, route_after_check) graph.add_edge(rewrite, check) app graph.compile() if __name__ __main__: result app.invoke({question: 什么是RAG请举一个实际落地场景。}) print(最终回答, result[answer])这个示例里模型先回答一次然后让另一个模型扮演评审角色判断回答是否合格不合格就重写重写后再次评审直到通过为止。这个循环结构用 LangGraph 表达得非常清晰。背后的状态对象AgentState在多个节点之间传递共享数据这就是它和 LangChain 线性链的核心差别。LangGraph 在 2026 年已经成为 Agent 开发的主流框架之一官方还推出了 LangGraph Studio 可视化调试工具可以看到图节点执行情况和状态变化。学习 LangGraph重点不是背 API而是理解状态机思维把业务流程拆成状态、节点、边、分支和循环。一旦建立这种思维你再看复杂的 Agent 系统就不会迷失在细节里。8. 2026 大模型开发学习路线从入门到项目实战讲完三个层次的技术最后给出一条可执行的学习路线。这条路线设计的核心原则是每学一个阶段都能做出一个可以展示的阶段性成果而不是学完才发现自己什么都做不出来。第一阶段是提示词工程建议两周时间。目标不是学多少技巧而是学会结构化思考。练习方式是找 10 个不同类型的文本任务——摘要、翻译、分类、抽取、改写——分别为它们设计结构化提示词并且用模型评估每次输出的好坏。这一阶段不需要写代码但一定要形成提示词也要评测和迭代的意识。学习资源可以看 OpenAI 官方 Prompt Engineering 指南以及各家大模型厂商的提示词最佳实践文档。第二阶段是 RAG 开发建议三到四周。先跑通前面第 4 节的 RAG 最小链路然后替换不同的文档类型和切分策略观察检索效果变化。接着引入混合检索和重排序搭建一个更完整的 RAG 系统。最后找一个自己熟悉的领域知识库比如课程笔记、产品文档、面试题合集做一个可用于日常问答的知识库助手上传到 GitHub。这个项目就是你求职或接私活时最有说服力的作品。第三阶段是 LangChain 与 LangGraph建议四到六周。先系统学 LangChain 的核心模块模型封装、提示词、检索、记忆和工具调用然后重点学 LangGraph 的状态管理和条件分支。练习方式是把第二阶段的知识库助手改造成一个 Agent 应用让它不仅能回答问题还能在信息不足时主动调用搜索工具或者调用一个计算工具完成推理。这个改造过程会迫使你把前面所有学过的知识融会贯通。第四阶段是工程化实践没有严格的时间限制但这个阶段决定了你能不能胜任真实岗位。重点学习模型评测、成本控制、安全防护、监控告警、部署上线。一个被很多人忽略的事实是大模型项目的核心难点不在模型而在工程。如何评测不同提示词方案的效果如何优化 Token 成本如何处理用户恶意输入如何监控模型输出质量这些才是企业最关心的问题。这个阶段可以参考 LangChain 官方模板仓库和主流云厂商的大模型应用最佳实践架构图。这套路线学下来大概需要三到四个月。不要贪多不要跳级每一阶段都完成一个可展示的实战项目再进入下一阶段。这才是 2026 年大模型开发最稳妥的入局方式。9. 大模型学习常见问题与避坑建议最后整理一份常见问题清单这些问题几乎每个初学者都会遇到提前知道可以省下大量时间。问题现象根本原因解决方案跟着教程写代码一直报错环境依赖版本不一致优先按教程的版本要求创建虚拟环境用 requirements.txt 锁定版本提示词改了效果还是差只改措辞没有结构化约束补充输出格式、限定条件、Few-shot 示例用评测数据驱动优化RAG 答非所问切分策略不合理或检索质量差打印检索结果检查相关性调整切分参数引入混合检索和重排序不确定该学 LangChain 还是 LangGraph混淆了两个框架的定位LangChain 学组件封装LangGraph 学流程编排两者配合使用API 调用成本太高没有做缓存和 Token 优化对高频问答做缓存压缩提示词用更小的模型处理简单任务本地部署大模型速度太慢硬件资源或量化策略不匹配优先用量化模型配合 Ollama 部署对实时性要求不高的场景用异步任务还有一个经常被忽略的学习建议一定要手动敲代码不要只用复制粘贴。复制粘贴的代码看起来跑通了但你没有理解报错时哪里出了问题。亲手敲一遍代码遇到报错看堆栈信息思考出错的位置这个从错误中学习的过程才真正建立了工程能力。安全边界也需要重视。在生产环境接入大模型时要注意提示词注入攻击限制模型可访问的工具和权限所有外部输入都要做校验。涉及用户隐私数据的知识库要做权限控制和脱敏处理。大模型不是万能钥匙安全意识是工程能力的一部分。10. 总结与下一步行动建议大模型应用开发的路径已经比较清晰提示词工程解决单次交互的质量问题RAG 解决模型知识不足的问题LangChain 解决组件复用的问题LangGraph 解决流程编排的问题。这四个技术不是孤立的而是逐层递进的。很多人学不下去是因为跳过了底层直接学上层结果遇到问题无法定位、无法debug。我的建议是先不要纠结学哪门课、看哪本书而是选定一个小项目从头到尾跑通一遍。把提示词优化好把知识库搭起来让模型能回答你准备的问题再让这个问答过程自动化、多样化。哪怕是一个简单的个人知识库助手跑通之后你对整个技术栈的理解都会发生质的变化。学习大模型开发最好的时机是现在。框架和工具还会持续迭代但底层的原理和工程思维不会过时。当你理解了大模型应用开发的核心链路再学新的框架不过是换一套接口表达同样的逻辑。下一篇文章我会继续深化 LangGraph Agent 的实战包括多工具调度、人机协同和状态持久化建议收藏关注。有任何问题欢迎在评论区交流。如果你正在实践本文中的代码示例可以把你遇到的问题直接贴出来一起讨论排错思路。