企业官网建设流程全解析

先统一回答一个经常被问到的问题：想入门大模型应用开发，但网上的资料太零散，提示词工程、LangChain、RAG、LangGraph 这些名词反复出现，到底先学哪个？学到什么程度才算入门？

这篇文章就围绕 2026 年大模型应用开发这条主线，把完整的学习路线、核心知识点和项目实战思路梳理清楚。内容会覆盖提示词工程、LangChain、RAG、LangGraph，以及从课程学习到独立完成项目的完整路径。无论你是刚接触大模型的在校学生，还是已经在做后端、算法、运维，想转到大模型应用方向的在职开发者，都可以按这套体系来安排学习节奏。

1. 大模型应用开发到底在做什么

1.1 应用开发不等于模型训练

很多初学者会把“大模型应用开发”和“大模型训练”“大模型微调”混为一谈。实际上，两者解决的问题完全不同。

模型训练和微调关注的是“让模型掌握更多知识或某种能力”，比如用领域数据继续训练，让模型更懂医疗、法律术语。这需要 GPU 资源、数据清洗流程和较深的算法基础。

大模型应用开发关注的则是“把现成的模型用好”，通过调用 API 或部署开源模型，结合提示词、外部知识库、工具调用和工作流编排，做出能解决实际业务问题的系统。比如：

• 基于企业文档的智能问答机器人。
• 能自动查询数据库并生成报表的对话助手。
• 能根据用户需求调用多个工具完成任务的 Agent。

这类工作不一定需要你从零训练模型，但要求你理解模型的能力边界、API 调用方式，以及如何通过工程手段弥补大模型的不足。这也是 2026 年大模型岗位中需求量最大、上手门槛相对友好的方向。

1.2 应用开发的核心问题

大模型本身有几个明显的短板，应用开发的核心工作就是围绕这些问题展开。

第一个问题是“知识陈旧”。模型的训练数据有截止时间，同时企业内部大量私有知识模型完全没见过。解决思路是把模型接上外部知识库，也就是后面要讲的 RAG（检索增强生成）。

第二个问题是“不会调用工具”。模型只能输出文本，无法主动查询天气、操作数据库、调用内部系统。解决思路是让模型具备工具调用能力，也就是 Agent 方向，LangGraph 主要解决这类问题。

第三个问题是“回答不稳定”。同样的提示词，换个说法结果可能就变了。解决思路是提示词工程，把问题定义、输出格式、约束条件写清楚，必要时引入可评测的 Prompt 版本管理。

可以说，提示词工程、RAG、LangChain、LangGraph 都是围绕“让大模型在真实业务中更可靠、更可控”展开的。

1.3 一套完整的技术栈全景

在大模型应用开发领域，常见的技术栈可以按层次拆解：

• 模型层：OpenAI 系列、Claude、国产开源模型（如 DeepSeek、Qwen）等，可以通过 API 调用，也可以通过 Ollama 等工具本地部署。
• 应用框架层：LangChain、LangGraph、LlamaIndex 等，负责把提示词、模型、检索、记忆、工具调用组织成完整应用。
• 知识库层：向量数据库（如 Chroma、Milvus、Weaviate）、文档解析、切片、Embedding 模型，支撑 RAG 系统。
• 工作流层：Dify、Coze 等低代码平台，以及 LangGraph 这类代码化工作流框架，适合不同场景。
• 评估与运维层：评测集构建、效果评估、日志追踪、成本监控。

建议先理解整体结构，再逐个击破。不要一上来就陷入某个框架的源码细节。

2. 2026 大模型应用开发学习路线

2.1 阶段一：大模型基础与 API 调用

这一阶段的目标是能用代码调用大模型 API，了解模型输入输出的基本规律。

需要掌握的内容包括：

• 什么是 Token，Token 与中文字数的关系。
• 上下文窗口是什么，为什么它会限制输入长度。
• Temperature、Top-p、Max Tokens 等采样参数对输出的影响。
• System Prompt、User Prompt、Assistant 角色的区别。
• 通过 OpenAI SDK 或其他兼容 SDK 完成一次多轮对话。

很多开源模型和云厂商都提供兼容 OpenAI 格式的 API，学会一种 SDK 写法，迁移成本很低。国内网络环境下，使用国产模型或本地部署模型是比较稳妥的选择。

这一阶段不建议直接学 LangChain，先把原生 API 调明白，理解底层请求和返回结构，后面看框架源码才不会懵。

2.2 阶段二：提示词工程

提示词工程（Prompt Engineering）是成本最低、见效最快的技能。所谓提示词工程，就是通过不断雕琢提示词，让大模型给出更理想答案的过程。

需要掌握：

• 角色设定、任务描述、输出格式约束。
• Few-shot（少样本示例）与 Zero-shot 的区别。
• CoT（思维链）提示词，让模型先推理再回答。
• 如何拆分复杂任务，避免一次性让模型完成过多要求。
• 提示词版本管理与效果评测。

这个阶段建议配合实际项目练习：拿一个真实问题，反复改写提示词，记录输出变化，建立对模型行为的感觉。

2.3 阶段三：LangChain 与编排思想

LangChain 是一个非常流行的应用编排框架，核心思想是“把模型、提示词、记忆、检索、工具这些组件用 Chain 串起来”。

需要掌握：

• 模型封装：ChatOpenAI、ChatOllama 等。
• 提示词模板：ChatPromptTemplate。
• 输出解析：让模型输出 JSON 并转为结构化数据。
• 记忆组件：简单对话记忆、窗口记忆。
• 简单的 Agent：让模型决定调用哪个工具。

学习 LangChain 时不要只抄官方示例，要多想“如果去掉框架，我用原生代码怎么写”。框架在快速迭代，但底层思想是通用的。

2.4 阶段四：RAG 检索增强生成

RAG 是目前企业落地最多的方向。它的核心思想是：不直接让大模型回答，而是先从知识库中检索相关内容，再让模型基于检索结果生成答案。

需要掌握：

• 文档加载与解析。
• 文本切片策略。
• Embedding 模型与向量化。
• 向量数据库的写入与检索。
• Dense Vector Search 的基本原理。
• 完整的 RAG 问答链路实现。
• RAG 的评测方法，包括检索质量、生成质量、忠实度。

这一阶段要动手构建一个完整项目，比如“企业规章制度问答机器人”，把文档、切片、向量库、问答链路、简易界面全部打通。

2.5 阶段五：LangGraph 与 Agent 工作流

当业务逻辑变复杂，比如需要多步推理、调用多个工具、根据中间结果决定下一步动作时，单纯的 Chain 不够灵活，可以考虑使用 LangGraph 这类图工作流框架。

需要掌握：

• State（状态）、Node（节点）、Edge（边）三个核心概念。
• 如何构建一个带条件跳转的工作流。
• Agent 循环：模型 -> 工具调用 -> 观察结果 -> 再次推理。
• 多 Agent 协作的基本思路。
• 工作流与 Chat 循环的差异。

这一阶段强调的是“用代码控制模型的行为路径”，而不是把所有控制逻辑塞进一个提示词里。

2.6 阶段六：项目实战与部署评估

最后一个阶段是真正拉开差距的地方。建议完成至少两个完整项目：

• 一个个人知识库问答项目。
• 一个带 Agent 能力的业务系统原型。

之后还需要了解：

• 通过 Ollama 或其他方案本地部署模型，降低 API 依赖。
• 模型微调的基本概念和适用边界。
• Dify 等平台与代码方案的选型对比。
• 大模型应用测试：投毒测试、注入测试、敏感信息泄露测试。
• 上线后的监控与评估闭环。

学习路线不要求每天固定几个小时，但建议“重项目、轻刷课”。每学一个概念，都要用代码验证一遍。

3. 提示词工程核心拆解

3.1 提示词工程的本质

提示词的调整过程，本质上是“通过语言约束模型的输出分布”。模型的训练目标决定了它会根据上文生成最可能的后续内容，提示词就是它唯一能看到的上文约束。

所以，提示词工程不是靠运气乱试，而是有明确方向：

• 减少歧义：任务描述越具体，输出越稳定。
• 提供边界：告诉模型哪些事情不能做。
• 规定格式：要求 JSON、Markdown、表格等结构化输出。
• 拆分步骤：复杂任务拆成一步一答，减少中间出错概率。

下面先看一个最简单的版本迭代示例。

3.2 常用提示词技巧

角色设定

你是一名拥有十年经验的数据库管理员，擅长排查慢查询问题。

角色设定的意义在于激活模型在对应领域的知识组织方式，并影响回答的语气和详略程度。

Few-shot 示例

将用户输入分类为【售后】【售前】【其他】，只输出类别。 输入：这个订单什么时候发货？ 输出：售后 输入：你们支持企业采购开票吗？ 输出：售前 输入：今天天气怎么样？ 输出：

通过一两个示例，模型能很快理解你需要的输出格式。

CoT（思维链）

题目：一个盒子有 12 个苹果，拿走了三分之一，又放进去 2 个，现在有多少个？ 请先一步步推理，最后给出答案。

“先一步步推理”能显著减少复杂计算和逻辑推理中的跳步错误。

3.3 一个可运行的提示词调优示例

# 文件路径：prompt_demo.py # 需要提前安装：pip install openai from openai import OpenAI client = OpenAI( api_key="your-api-key", base_url="https://your-model-endpoint", # 按你的模型服务地址调整 ) def generate_answer(question: str) -> str: prompt = f""" 你是一名严谨的技术面试官。请针对下面的问题，给出两段内容： 1. 核心答案，不超过 200 字。 2. 两个追问方向，方便面试官继续深入。 问题：{question} 格式如下： 【核心答案】 （内容） 【追问方向】 1. （第一个追问） 2. （第二个追问） """ resp = client.chat.completions.create( model="gpt-4o-mini", # 以你实际可用的模型为准 messages=[ {"role": "system", "content": "你是一个帮助面试官准备面试问题的助手。"}, {"role": "user", "content": prompt}, ], temperature=0.3, max_tokens=600, ) return resp.choices[0].message.content if __name__ == "__main__": q = "请解释一下 RAG 的检索和生成流程。" print(generate_answer(q))

这段代码体现了三个关键点：角色设定、格式约束、参数控制。Temperature 调低到 0.3 左右，可以让输出更稳定。

3.4 常见误区

第一个误区是“提示词越复杂越好”。提示词过长反而会稀释重点，建议把核心约束前置。第二个误区是“不验证就直接上线”。提示词在不同输入下表现差异很大，建议建立评测集，比如准备 20 到 50 条典型问题，每次修改提示词后批量跑一遍。第三个误区是“期望提示词解决所有问题”。当业务逻辑复杂时，需要用 LangGraph 等工作流框架控制流程，而不是塞进一句话里。

4. LangChain 快速上手

4.1 LangChain 能解决什么问题

LangChain 流行是因为它把大模型应用开发中重复出现的“胶水代码”抽象成了标准组件。比如，每次都要组装 messages、调用模型、解析输出、处理历史记录，这些工作如果每个项目都重复写，维护成本会很高。

LangChain 的核心抽象包括：

• Chat Models：封装各类模型 API。
• Prompts：模板化地管理提示词。
• Output Parsers：把模型输出转成结构化对象。
• Retrievers：对接向量数据库完成检索。
• Memory：管理多轮对话历史。
• Agents：让模型决策调用哪些工具。

它解决的问题不是“让模型更聪明”，而是“让应用代码更规范、更可维护”。

4.2 环境准备与版本说明

本文示例使用 Python 3.10 以上环境，LangChain 相关包的版本迭代很快，不同版本 API 可能有差异。建议以你安装时的官方文档为准，下面代码主要演示核心思路。

安装依赖：

pip install langchain langchain-openai

如果你的模型服务兼容 OpenAI 格式，可以通过ChatOpenAI指定base_url来接入；如果使用 Ollama 本地模型，可以额外安装langchain-ollama。

4.3 核心组件与最小示例

# 文件路径：langchain_demo.py from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate # 1. 初始化模型 model = ChatOpenAI( model="your-model-name", api_key="your-api-key", base_url="https://your-model-endpoint", temperature=0.2, ) # 2. 定义提示词模板 prompt = ChatPromptTemplate.from_template( "你是一名数据报表专家，请用一句话解释下面的指标：{metric_name}" ) # 3. 使用管道符串联提示词和模型 chain = prompt | model # 4. 调用 response = chain.invoke({"metric_name": "DAU日均活跃用户"}) print(response.content)

这里用到了 LangChain 中非常经典的prompt | model管道语法，它把“格式化提示词”和“调用模型”两步组合成了一个可复用的链。当你需要增加输出解析时，只要在管道后面再接一个 parser：

from langchain_core.output_parsers import StrOutputParser chain = prompt | model | StrOutputParser() result = chain.invoke({"metric_name": "DAU日均活跃用户"}) print(result) # 此时 result 直接是字符串

4.4 LangChain 的局限性

LangChain 在低复杂度场景下很高效，但一旦涉及复杂条件分支、循环、多人协作流程，Chain 模式会变得笨重。这也是为什么 LangGraph 出现后很快受到关注。LangGraph 允许你把应用流程描述成一张有向图，节点是处理步骤，边是状态流转条件，比线性 Chain 更贴近真实业务逻辑。

所以我的建议是：用 LangChain 快速构建原型，用 LangGraph 处理复杂工作流，两者不是替代关系，而是互补关系。

5. RAG 检索增强生成实战

5.1 RAG 的原理与价值

RAG 是解决大模型知识不足、信息过时问题的通用方案。

它的工作流程可以拆成两条链路：

• 离线索引阶段：加载文档，做切片，调用 Embedding 模型将切片转成向量，写入向量数据库。
• 在线问答阶段：把用户问题向量化，在向量库中做相似度检索，取回 Top-K 文本片段，拼进提示词，交给大模型生成回答。

RAG 的核心价值在于：企业知识可以随时更新，不需要重新训练模型；同时大模型的回答有原文依据，可以显著降低“一本正经地胡说八道”的概率。

5.2 构建一个最小可运行的 RAG 系统

下面用一个简化版示例演示核心链路。实际项目中你还需要加入文档解析、切片优化、重排序、引用来源展示等逻辑。

# 文件路径：rag_demo.py # 依赖：pip install langchain langchain-openai chromadb from langchain_openai import OpenAIEmbeddings, ChatOpenAI from langchain_community.vectorstores import Chroma from langchain_core.prompts import ChatPromptTemplate from langchain_text_splitters import CharacterTextSplitter # 1. 准备知识文档 # 实际项目中通常从 PDF、Word、Markdown 中解析得到 docs = [ "公司的年假规则：入职满一年可享受 5 天年假，满三年可享受 10 天年假。", "报销流程：员工先提交发票，部门负责人审批，财务在 5 个工作日内打款。", "远程办公申请：需提前一天在 OA 系统提交，经直属 leader 审批。", ] # 2. 文本切片 splitter = CharacterTextSplitter(chunk_size=100, chunk_overlap=20) chunks = splitter.create_documents(docs) # 3. 向量化并存储 embeddings = OpenAIEmbeddings( model="your-embedding-model", api_key="your-api-key", base_url="https://your-model-endpoint", ) vectorstore = Chroma.from_documents(chunks, embeddings) # 4. 构建检索器 retriever = vectorstore.as_retriever(search_kwargs={"k": 2}) # 5. 定义 RAG 提示词 prompt = ChatPromptTemplate.from_template( """请基于下面的知识片段回答用户问题。 如果知识片段中没有相关内容，请直接回复“知识库中没有找到相关信息”，不要编造。 知识片段： {context} 用户问题：{question} """ ) # 6. 定义问答函数 def rag_answer(question: str) -> str: related_docs = retriever.invoke(question) context = "\n\n".join([doc.page_content for doc in related_docs]) model = ChatOpenAI( model="your-model-name", api_key="your-api-key", base_url="https://your-model-endpoint", temperature=0, ) chain = prompt | model resp = chain.invoke({"context": context, "question": question}) return resp.content if __name__ == "__main__": while True: q = input("请输入问题（输入 exit 退出）：") if q.lower() == "exit": break print("回答：", rag_answer(q)) print("-" * 50)

运行后，输入“年假有几天”，系统会从向量库检索到相关片段，再交给模型生成答案，而不是让模型凭记忆猜测。

这个流程中最重要的两个参数是chunk_size和chunk_overlap。切片过大，检索粒度太粗；切片过小，单个片段语义不完整。实际项目中需要根据文档类型反复测试。

5.3 Dense Vector Search 与 RAG 进阶方向

上面的示例中，Chroma默认采用的就是稠密向量检索（Dense Vector Search），即把文本映射到高维向量空间，用向量距离衡量语义相似度。它适合处理“用户问题和文档用词不同但意思相近”的情况。

RAG 的进阶方向包括：

• 重排序（Rerank）：检索出 Top 50，再用重排序模型挑出最相关的 Top 5，提高精度。
• Agentic RAG：不只是一次检索，而是让模型判断是否需要多次检索、是否要改写问题，适合复杂问答。
• GraphRAG / Ontology RAG：结合知识图谱与本体关系，让模型能回答“实体之间关系”类问题。
• 混合检索：关键词检索（BM25）与向量检索结合，兼顾精确匹配和语义匹配。

这些方向可以放到掌握基础 RAG 后再深入。

5.4 RAG 怎么测评

RAG 系统的效果评测通常分成几个层面。

• 检索质量：看 Top-K 结果中是否包含能回答问题的文档片段，常用指标有 Recall@K、Precision@K 等。
• 生成质量：答案是否正确、是否忠实于检索片段。
• 拒绝能力：知识库没有答案时，模型是否不会强行编造。

最简单的做法是：准备一组合格问答对，批量跑完 RAG 链路后，人工对每条结果的“正确性”和“忠实度”打分。上线前至少保证核心场景的准确率达到业务可接受阈值。

6. LangGraph：从 Chain 到 Agent

6.1 LangGraph 与 LangChain 的区别

LangGraph 是一个用于构建有状态、可编排的 Agent 应用的工作流框架。它和 LangChain 的关系可以这样理解：LangChain 解决了“把组件串起来”，LangGraph 解决了“让流程可以分叉、循环、按条件跳转”。

比如一个客户支持机器人，需要根据用户问题走不同分支：售后问题转工单系统，售前问题查产品手册，闲聊直接回复。如果用 Chain 写，代码会非常僵硬；用 LangGraph 则可以把每个环节定义成节点，用条件边控制跳转。

另一个实际区别是状态管理。LangGraph 维护一个在节点之间传递的状态对象，每个节点可以读取和更新状态，后续节点能感知前面步骤的结果。这让多轮工具调用变得可控。

6.2 核心概念：State、Node、Edge

State（状态）定义了整个工作流的数据结构。Node（节点）是具体执行步骤，它接收 State，处理完后返回更新后的 State 片段。Edge（边）定义节点之间的流转关系，分为普通边和条件边。

一个典型的 Agent 工作流包含以下节点：

• 用户输入节点：接收并整理问题。
• 模型决策节点：让模型判断需要调用什么工具。
• 工具执行节点：执行查天气、查数据库、调内部 API 等操作。
• 结果汇总节点：把工具返回结果交给模型，生成最终回答。

6.3 一个简易 LangGraph 工作流示例

# 文件路径：langgraph_demo.py # 依赖：pip install langgraph # 注意：LangGraph API 在不同版本有调整，请以官方文档为准 from typing import TypedDict from langgraph.graph import StateGraph, END class WorkflowState(TypedDict): question: str need_tool: bool tool_result: str final_answer: str def analyze_question(state: WorkflowState): # 模拟判断：当问题包含“天气”时，需要查工具 need_tool = "天气" in state["question"] return {"need_tool": need_tool} def call_tool(state: WorkflowState): # 实际项目中这里会调用真实天气 API 或其他工具 return {"tool_result": "今日多云，气温 22-28 摄氏度（演示数据）"} def generate_answer(state: WorkflowState): if state.get("tool_result"): final_answer = f"根据工具查询结果：{state['tool_result']}" else: final_answer = f"这是一个通用问题：{state['question']}" return {"final_answer": final_answer} # 构建图 graph = StateGraph(WorkflowState) graph.add_node("analyze", analyze_question) graph.add_node("tool", call_tool) graph.add_node("answer", generate_answer) graph.set_entry_point("analyze") # 条件边：如果 need_tool 为 True，则走 tool 节点，否则直接生成答案 graph.add_conditional_edges( "analyze", lambda state: "tool" if state["need_tool"] else "answer", ) graph.add_edge("tool", "answer") graph.add_edge("answer", END) app = graph.compile() result = app.invoke({"question": "今天北京天气怎么样？"}) print(result["final_answer"])

这个例子虽然简化了模型调用，但完整展示了 StateGraph 的核心写法：先定义 State 类型，再添加节点，最后用条件边决定分支走向。

真实项目中，analyze_question节点通常是让大模型判断意图并输出一个 JSON 结构，call_tool节点负责执行真实工具调用，generate_answer节点再结合工具结果生成回答。

6.4 LangGraph 适合的场景

LangGraph 更适合以下场景：

• 需要多轮工具调用，且调用顺序不固定。
• 需要根据中间结果决定下一步动作。
• 需要人工审批节点参与流程。
• 需要对工作流状态做日志追踪和可观测。

如果你的应用只是简单的“问题 -> 向量检索 -> 模型回答”，先用纯 RAG 链路就好，不一定要引入 LangGraph。技术选型的原则是：复杂度匹配业务需求，不要为了用框架而用框架。

7. 项目实战与选题思路

7.1 个人学习型项目

学习阶段建议做三个难度递增的项目。

第一个项目：个人知识库问答机器人。收集你的学习笔记、收藏文章、日常记录，搭建一个本地 RAG 问答系统。重点掌握文档解析、切片、向量检索、问答链路。

第二个项目：提示词评测工具。准备一组合格问题和答案，批量测试不同 Prompt、不同模型参数的效果，生成对比报告。这个项目能体现你对提示词工程的理解深度。

第三个项目：带 Agent 的工作流原型。比如做一个“信息整理助手”，能根据用户指令搜索本地文档、调用计算工具、生成周报。通过这个项目掌握 LangGraph 的条件分支和工具调用。

每个项目做完后，整理一份 README、架构图、运行截图和技术总结，这些材料可以直接用于简历和面试展示。

7.2 业务落地型项目

有企业环境的话，可以尝试以下方向。

企业内部知识库问答：把员工手册、规章制度、产品文档做成问答系统，这是 RAG 最高频的落地方案。比如，可以类似“政务 RAG 知识库”的思路，将公开的政策文件、办事指南结构化后构建问答系统，核心流程是文档解析、知识分类、检索问答、引用溯源。

行业知识助手：比如农业领域，可以利用大模型结合传感器采集的土壤、气象数据，实现智能灌溉建议或施肥指导。这类项目的关键不只是大模型，而是如何把结构化数据转成模型能理解的上下文，再通过 RAG 或流程编排输出建议。

开发辅助工具：利用开源模型接入 VS Code 等开发环境，做一个面向私有代码库的问答或代码审查助手。

业务项目比学习项目更看重三个点：数据从哪来、效果怎么评估、出错了怎么降级。建议优先选择你熟悉的业务场景，这样能更聚焦在技术链路，而不是花大量时间理解行业知识。

7.3 从课程学习到独立项目的路径

很多同学“看课都会，动手就废”，原因是课程里把数据和环境都准备好了，缺少独立排查的机会。建议按下面步骤过渡：

第一步，复现课程代码。不要只看，要逐行敲一遍，理解每个依赖包的作用。

第二步，替换成自己的数据。把课程示例里的文档换成你感兴趣领域的资料，比如把你收藏的博客文章做成知识库。

第三步，改一个功能。比如给基础 RAG 加上引用来源展示，或者给 Agent 增加一个自定义工具。

第四步，从零搭建一个小系统。不参考任何现成代码，从需求分析、技术选型、接口设计到部署，完整走一遍。

完成第四步之后，你会发现面试和实际工作中的很多问题都能对号入座了。

8. 常见问题与排查思路

排错时可以把握一个原则：先定位问题出在哪一层。是模型层、提示词层、检索层、框架层还是代码逻辑层？不要在没确认原因的情况下反复随机试参数。

9. 最佳实践与工程建议

9.1 提示词层面的工程化

提示词也是代码资产，需要纳入版本管理。建议为每个业务场景维护独立的 Prompt 模板文件，记录修改时间、修改原因和评测结果。

每次修改 Prompt 之前，先跑一遍评测集，确认修改没有导致其他场景回归。生产环境中的 Prompt 变更建议走测试环境验证再发布，避免直接影响线上问答效果。

9.2 检索与数据层面

RAG 系统效果的上限取决于文档处理和索引质量，而不是模型本身。建议重视几个细节：

• 文档解析后先做清洗，去掉页眉页脚、乱码和无关水印。
• 切片时保留标题和层级信息，必要时手动补充摘要片段。
• 对高频问题建立“问答对”索引，让模型直接检索到标准答案。
• 定期重建索引，及时移除过期文档。
• 涉及敏感数据时，在写入向量库前进行脱敏处理，并对检索权限做隔离。

9.3 代码与部署层面

• API Key 使用环境变量或密钥管理服务，严禁硬编码进代码或前端。
• 对模型调用做超时控制和失败重试，但要注意重试可能带来重复扣费。
• 增加缓存层，对相同或相似的查询直接返回结果，降低成本和延迟。
• 记录关键日志，包括用户问题、检索片段、模型输出、耗时和 token 消耗，方便线上问题回溯。
• 模型输出属于非确定性结果，关键业务环节要增加人工确认或规则校验。

9.4 安全与合规

大模型应用涉及的安全问题需要格外重视。

• 提示词注入：用户可能在输入中试图覆盖系统指令，需要在应用层对输入做长度和内容限制，并对输出做敏感信息过滤。
• 敏感信息泄露：不要让模型输出训练数据中可能存在的隐私信息，生产环境建议增加脱敏和过滤环节。
• 权限控制：采用最小权限原则，模型和 Agent 只能访问完成任务所需的最少数据和工具。
• 测试验证：涉及数据库操作、文件删除、资金交易等高风险动作时，必须在测试环境验证，并且要有审批和回滚机制。

同时提醒一句：不要为了追求功能完整，让 Agent 自动执行所有操作。越重要的系统，越要设置人工闸口。

10. 最后的建议

大模型应用开发这个方向，知识更新确实快，但核心能力是稳定的：理解模型的行为规律、掌握检索与编排的工程手段、具备拆解业务需求的能力。这三件事，在任何框架和模型迭代周期内都不会过时。

学习过程中，不要追求把所有工具都学一遍。先把 API 调用、提示词、RAG、LangGraph 这条主线打通，再用项目经验去验证和补充细节。遇到版本变化、API 调整，不要慌，读官方文档、看源码报错、对比新旧示例，这是每个开发者都会经历的日常。

如果你当前的目标是快速上手，先把本文第 2 章的学习路线抄下来，给自己定一个两周的节奏：一周完成 API 调用和提示词工程，一周完成一个最小 RAG 项目。跑通之后再回来深入学习 LangGraph 和 Agent 工作流。技术文章看再多，都不如自己亲手跑通一条链路来得实在。

如果这篇文章对你有帮助，可以收藏备用，也欢迎在评论区讨论你在学习大模型应用开发时遇到的问题。