大模型应用开发主线：提示词工程、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_URL=https://你的网关地址/v1 EMBEDDING_MODEL=text-embedding-3-small LLM_MODEL=gpt-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", encoding="utf-8") documents = loader.load() # 2. 切分文档 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", " ", ""] ) chunks = text_splitter.split_documents(documents) # 3. 向量化并存入 FAISS embeddings = OpenAIEmbeddings(model="text-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(model="gpt-4o-mini", temperature=0.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(model="gpt-4o-mini", temperature=0.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. 大模型学习常见问题与避坑建议

最后整理一份常见问题清单，这些问题几乎每个初学者都会遇到，提前知道可以省下大量时间。

还有一个经常被忽略的学习建议：一定要手动敲代码，不要只用复制粘贴。复制粘贴的代码看起来跑通了，但你没有理解报错时哪里出了问题。亲手敲一遍代码，遇到报错，看堆栈信息，思考出错的位置，这个从错误中学习的过程才真正建立了工程能力。

安全边界也需要重视。在生产环境接入大模型时，要注意提示词注入攻击，限制模型可访问的工具和权限，所有外部输入都要做校验。涉及用户隐私数据的知识库，要做权限控制和脱敏处理。大模型不是万能钥匙，安全意识是工程能力的一部分。

10. 总结与下一步行动建议

大模型应用开发的路径已经比较清晰：提示词工程解决单次交互的质量问题，RAG 解决模型知识不足的问题，LangChain 解决组件复用的问题，LangGraph 解决流程编排的问题。这四个技术不是孤立的，而是逐层递进的。很多人学不下去，是因为跳过了底层直接学上层，结果遇到问题无法定位、无法debug。

我的建议是：先不要纠结学哪门课、看哪本书，而是选定一个小项目从头到尾跑通一遍。把提示词优化好，把知识库搭起来，让模型能回答你准备的问题，再让这个问答过程自动化、多样化。哪怕是一个简单的个人知识库助手，跑通之后你对整个技术栈的理解都会发生质的变化。

学习大模型开发最好的时机是现在。框架和工具还会持续迭代，但底层的原理和工程思维不会过时。当你理解了大模型应用开发的核心链路，再学新的框架，不过是换一套接口表达同样的逻辑。下一篇文章我会继续深化 LangGraph Agent 的实战，包括多工具调度、人机协同和状态持久化，建议收藏关注。

有任何问题欢迎在评论区交流。如果你正在实践本文中的代码示例，可以把你遇到的问题直接贴出来，一起讨论排错思路。