从API调用到Agent开发：LangChain、RAG与LangGraph实战学习路线

1. 从“会用”到“会造”大模型应用开发的学习路径拆解我真正开始系统学习大模型应用开发是在把聊天窗口里那些“哇好神奇”的新鲜感消耗完之后。那时候我发现一个很尴尬的事实我能跟大模型聊得火热却没法把它变成一个能解决具体问题的产品。问它问题它答得头头是道但让它去查我本地的文档、调用我的接口、记住我上一轮说过的话它就立刻露馅。这个落差就是我从“大模型使用者”转向“大模型应用开发者”的起点。如果你也处在这个阶段——能调用API但不知道怎么把大模型串进一个完整的业务流里听说过LangChain、LangGraph、RAG这些词但不知道它们各自解决什么问题、什么时候该用哪个想做一个属于自己的知识库问答或者Agent项目却卡在环境配置和框架选型上——那这篇内容就是写给你的。我会把我自己踩过的路、绕过的弯、以及最后沉淀下来的学习顺序和实操方法完整地摊开来讲。核心关键词就几个大模型、Agent、LangChain、LangGraph、RAG但我会把它们放在真实的开发场景里讲而不是干巴巴地念概念。先说一个我自己的判断大模型应用开发这件事门槛不在“模型”本身而在“应用”这两个字。模型是别人训练好的你改不了底层参数除非做微调那是另一条路你能控制的是怎么给它喂上下文、怎么让它调用工具、怎么管理它的记忆、怎么把它的输出变成结构化数据。这四件事分别对应了RAG、Agent、LangGraph和输出解析。把这四块吃透你就能从“调API的人”变成“做应用的人”。我给自己定的学习路线是这样的先用LangChain把最基础的链式调用跑通理解Prompt、Model、OutputParser这三件套然后立刻上手RAG因为这是最容易看到效果、也最贴近实际需求的方向接着学Agent让模型学会自己决定调用什么工具最后用LangGraph把前面这些零散的能力编排成一个有状态、可循环、能处理复杂分支的完整工作流。这个顺序不是拍脑袋定的而是按照“依赖关系”来的——没有RAG和Agent的基础直接上LangGraph会非常痛苦因为你不知道每个节点里该放什么。提示不要一上来就追求“全栈大模型工程师”的标签。先把一条链路跑通哪怕只是“读取本地PDF→切分→向量化→检索→生成回答”这么简单的RAG跑通一遍胜过看十篇综述。2. 核心概念拆解LangChain、LangGraph、RAG、Agent到底怎么分工2.1 LangChain不是框架是“胶水层”很多人对LangChain的第一印象是“太重了”“抽象太多”。我一开始也这么觉得尤其是看官方文档的时候各种Chain、Runnable、Tool、Memory的概念扑面而来很容易劝退。但后来我想明白了一件事LangChain的本质不是让你写更少的代码而是给你一套统一的接口让你能把不同厂商的模型、不同的向量数据库、不同的工具用同一种方式串起来。举个例子你今天用OpenAI的模型明天想换成Ollama本地部署的模型如果没有LangChain你得把代码里所有调用模型的地方都改一遍。但用了LangChain之后你只需要换一个ChatOpenAI为ChatOllama其他代码基本不动。这就是“胶水层”的价值——它不生产能力它只是能力的搬运工。我学LangChain的方法是“用多少学多少”而不是从头到尾读文档。具体来说我先跑通一个最简单的链from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser prompt ChatPromptTemplate.from_template(用一句话解释{concept}) model ChatOpenAI(modelgpt-4o-mini) parser StrOutputParser() chain prompt | model | parser print(chain.invoke({concept: RAG}))这段代码虽然简单但它包含了LangChain最核心的表达式语言LCEL思想用管道符|把各个组件串起来。你理解了这一行就理解了LangChain一半的设计哲学。剩下的Memory、Tool、Retriever都是在这个基础上往外扩。2.2 RAG给大模型装上“外挂知识库”RAG是我认为最值得优先投入时间的方向因为它解决的是大模型最致命的两个问题知识过时和幻觉。你问大模型一个关于你公司内部文档的问题它要么不知道要么一本正经地胡说八道。RAG的思路很直接既然模型不知道那我就把相关资料找出来塞进Prompt里让它基于资料回答。RAG的完整链路包括文档加载→文本切分→向量化→存储→检索→重排→生成。每一步都有坑。比如文本切分你切得太碎语义不完整切得太大检索精度下降。我自己的经验是中文文档用RecursiveCharacterTextSplitterchunk_size设在500到800之间chunk_overlap设在50到100之间这个范围在大多数场景下比较稳。向量化模型的选择也很关键。如果你做的是中文RAG不要直接用OpenAI的text-embedding-ada-002它在中文上的表现只能说凑合。可以考虑BGE系列或者M3E这些在中文语义相似度任务上表现更好。如果你要本地部署Ollama里可以拉nomic-embed-text或者bge-m3配合Chroma或者FAISS做本地知识库整套流程可以完全离线跑。注意RAG不是“向量检索”的同义词。完整的RAG还包括检索后的重排Rerank和生成时的Prompt约束。只做向量检索不做重排召回的相关文档可能排在后面导致模型看不到关键信息。2.3 Agent让模型自己决定“下一步做什么”Agent和普通链式调用的区别我用一个类比来解释普通链就像流水线每一步都是你提前定好的第一步做完做第二步第二步做完做第三步。Agent则像一个有自主权的员工你给它一个目标它自己决定先做什么、再做什么、要不要调用工具、调用哪个工具。LangChain里的Agent核心是“工具调用”机制。你定义几个工具比如搜索、计算器、查数据库然后让模型根据用户的问题自己选择调用哪个。这个过程是循环的模型思考→选择工具→执行工具→观察结果→继续思考直到它认为可以给出最终答案。我踩过的一个坑是一开始给Agent定义了太多工具结果模型经常选错。后来我学乖了工具数量控制在5个以内每个工具的description写得非常明确说明“什么时候该用这个工具”而不是只写“这个工具是干什么的”。比如不要写“查询天气”而要写“当用户询问某个城市的实时天气、温度、降水概率时使用此工具”。2.4 LangGraph把Agent的“思考过程”画成图LangGraph是我认为最被低估的一个工具。很多人觉得LangChain已经够用了为什么还要学LangGraph我的回答是当你需要循环、分支、状态共享、人工介入的时候LangChain的链式结构就不够用了。LangGraph把工作流建模成一张图节点是函数边是流转条件。你可以定义条件边让流程根据当前状态决定下一步走哪个节点。这听起来很抽象但实际用起来非常自然。比如做一个客服Agent用户问题先分类如果是退款就走退款流程如果是咨询就走咨询流程如果分类置信度低就转人工。这种逻辑用LangGraph表达非常清晰。LangGraph和LangChain的关系我的理解是LangChain提供了组件模型、工具、检索器LangGraph提供了编排这些组件的方式。你可以把LangGraph看作LangChain的上层建筑它不替代LangChain而是让LangChain的组件在更复杂的场景下协同工作。维度LangChainLangGraph核心抽象Chain / RunnableStateGraph / Node / Edge流程控制线性为主支持简单分支支持循环、条件分支、并行状态管理通过Memory传递显式定义State全局共享适用场景简单链式调用、RAG复杂Agent、多轮决策、人工介入学习曲线较平缓需要理解图论基础概念3. 实操环境搭建从零把开发环境跑起来3.1 Python环境与依赖管理我强烈建议用Conda来管理大模型应用开发的Python环境不要用系统自带的Python。原因很简单大模型相关的库更新极快依赖冲突是家常便饭。Conda可以给每个项目建独立环境互不干扰。conda create -n llm-dev python3.11 conda activate llm-dev pip install langchain langchain-openai langchain-community pip install chromadb faiss-cpu pip install langgraph pip install streamlitPython版本选3.11而不是3.12是因为有些向量数据库的底层库对3.12的支持还不完善。这个坑我踩过装FAISS的时候编译报错换回3.11就顺利了。3.2 模型接入云端API与本地部署的取舍学习阶段我建议先用云端API因为便宜、稳定、不用折腾硬件。OpenAI的gpt-4o-mini性价比很高适合练手。但如果你对数据隐私有要求或者想完全离线运行那就需要本地部署。本地部署大模型目前最省心的方案是Ollama。它把模型下载、量化、推理服务都封装好了你只需要一行命令ollama pull qwen2.5:7b ollama pull nomic-embed-text然后LangChain里这样接from langchain_ollama import ChatOllama, OllamaEmbeddings model ChatOllama(modelqwen2.5:7b, temperature0) embeddings OllamaEmbeddings(modelnomic-embed-text)选哪个本地模型我的经验是7B参数级别的模型Qwen2.5在中文任务上表现很稳适合做RAG的生成模型。嵌入模型用nomic-embed-text或者bge-m3后者对中文更友好。如果你的显卡显存只有8GB7B模型用4-bit量化可以跑但速度会慢一些。显存12GB以上可以考虑14B模型效果明显更好。提示本地部署的模型在指令遵循能力上通常不如云端大模型。做Agent的时候如果发现模型不按格式输出工具调用先换云端模型验证逻辑再回来调本地模型的Prompt。3.3 向量数据库选型Chroma vs FAISS学习阶段我推荐Chroma因为它自带持久化、API简单、和LangChain集成度高。FAISS性能更好但它是纯索引库不负责文档存储你需要自己管理文档和元数据。from langchain_chroma import Chroma vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db ) retriever vectorstore.as_retriever(search_kwargs{k: 4})k4是我常用的检索数量。太小可能漏掉关键信息太大则噪音多、消耗Token。你可以根据文档的粒度调整如果chunk比较小可以设到6到8。4. RAG实战从文档到可问答的知识库4.1 文档加载与切分策略RAG的第一步是把你的资料变成模型能消化的文本块。LangChain提供了大量DocumentLoaderPDF用PyPDFLoaderWord用Docx2txtLoader网页用WebBaseLoader。但我要提醒一句PDF解析是RAG里最脏最累的活。扫描版PDF需要OCR表格多的PDF解析出来格式全乱这些都会直接影响后续检索质量。切分策略上我试过固定长度切分、按段落切分、按语义切分。最后发现最稳的还是RecursiveCharacterTextSplitter它按照分隔符优先级递归切分尽量保持语义完整。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size600, chunk_overlap80, separators[\n\n, \n, 。, , , , , , ] ) chunks splitter.split_documents(docs)注意separators里我把中文标点加进去了因为默认的分隔符只考虑英文标点对中文文档不友好。这个细节很多教程不会讲但实际做中文RAG的时候非常关键。4.2 检索优化混合检索与重排单纯的向量检索有个问题它对关键词匹配不敏感。比如用户问“RX6750GRE能跑大模型吗”向量检索可能返回一堆关于“显卡跑大模型”的通用文档但漏掉具体提到这个型号的文档。解决办法是混合检索向量检索加BM25关键词检索两路召回后合并去重。LangChain里可以用EnsembleRetriever来实现from langchain.retrievers import EnsembleRetriever, BM25Retriever bm25_retriever BM25Retriever.from_documents(chunks) bm25_retriever.k 4 vector_retriever vectorstore.as_retriever(search_kwargs{k: 4}) ensemble EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.4, 0.6] )权重分配上我一般让向量检索占6成BM25占4成。如果你的文档里专有名词多可以调高BM25的权重。检索之后如果还想再提精度可以加一个重排模型。重排模型Reranker会对召回的文档做精细打分把最相关的排到最前面。常用的有bge-reranker系列可以用FlagEmbedding或者sentence-transformers加载。这一步会增加延迟但对精度提升明显尤其是召回文档多的时候。4.3 Prompt模板与幻觉抑制RAG的生成环节Prompt写得好不好直接决定回答质量。我的模板是这样的RAG_PROMPT 你是一个严谨的问答助手。请仅根据以下参考资料回答用户问题。 如果参考资料中没有相关信息请直接说“根据现有资料无法回答”不要编造。 参考资料 {context} 用户问题{question} 回答要求 1. 只使用参考资料中的信息 2. 如果资料中有矛盾指出矛盾 3. 回答要简洁不要重复问题 这个模板里最关键的是“如果资料中没有相关信息请直接说无法回答”。不加这句话模型会倾向于用它的预训练知识来补全导致幻觉。加了之后虽然有时候会显得“笨”但可靠性大幅提升。5. Agent与LangGraph从单步调用到复杂工作流5.1 用LangChain构建第一个AgentAgent的核心是工具调用。我先定义一个简单的工具集from langchain_core.tools import tool tool def search_knowledge_base(query: str) - str: 当用户询问产品文档、技术手册相关问题时使用此工具。输入应该是完整的问题描述。 docs retriever.invoke(query) return \n\n.join([d.page_content for d in docs]) tool def calculate(expression: str) - str: 当用户需要进行数学计算时使用此工具。输入应该是合法的Python数学表达式。 return str(eval(expression))然后创建Agentfrom langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.prompts import ChatPromptTemplate prompt ChatPromptTemplate.from_messages([ (system, 你是一个乐于助人的助手可以调用工具来回答问题。), (human, {input}), (placeholder, {agent_scratchpad}) ]) agent create_tool_calling_agent(model, [search_knowledge_base, calculate], prompt) executor AgentExecutor(agentagent, tools[search_knowledge_base, calculate], verboseTrue)verboseTrue在学习阶段非常有用它会把Agent的思考过程和工具调用完整打印出来你能清楚看到模型为什么选这个工具、传了什么参数。5.2 LangGraph入门把流程画成图LangGraph的核心概念是StateGraph。你先定义状态的结构然后添加节点和边。from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated from langgraph.graph.message import add_messages class State(TypedDict): messages: Annotated[list, add_messages] route: str def classify(state: State): last_msg state[messages][-1].content if 退款 in last_msg: return {route: refund} return {route: consult} def handle_refund(state: State): return {messages: [(ai, 正在为您处理退款...)]} def handle_consult(state: State): return {messages: [(ai, 请描述您要咨询的问题...)]} graph StateGraph(State) graph.add_node(classify, classify) graph.add_node(refund, handle_refund) graph.add_node(consult, handle_consult) graph.set_entry_point(classify) graph.add_conditional_edges(classify, lambda s: s[route], { refund: refund, consult: consult }) graph.add_edge(refund, END) graph.add_edge(consult, END) app graph.compile()这段代码定义了一个最简单的路由图先分类再根据分类结果走不同分支。实际项目中你可以在每个节点里放更复杂的逻辑比如调用RAG、调用外部API、甚至嵌套另一个Agent。5.3 LangGraph的循环与人工介入LangGraph真正强大的地方是支持循环。比如一个“反思-改进”的写作Agent生成初稿→自我评审→如果评审不通过就修改→再评审直到通过或者达到最大轮数。def generate(state): return {draft: model.invoke(f写一段关于{state[topic]}的介绍)} def review(state): result model.invoke(f评审以下文字只回答通过或不通过{state[draft]}) return {review_result: result.content} def should_continue(state): if state[review_result] 通过 or state.get(round, 0) 3: return end return revise graph.add_node(generate, generate) graph.add_node(review, review) graph.add_node(revise, lambda s: {draft: model.invoke(f改进{s[draft]})}) graph.add_edge(generate, review) graph.add_conditional_edges(review, should_continue, {end: END, revise: revise}) graph.add_edge(revise, review)这种循环结构用LangChain的链是表达不出来的但用LangGraph就非常自然。人工介入也是类似你可以在某个节点前加一个interrupt让流程暂停等待人工确认。6. 常见问题与排查技巧实录6.1 环境与依赖类问题问题现象可能原因解决方法安装FAISS报编译错误Python版本过高或缺少C编译环境换Python 3.11或安装faiss-cpu预编译包Ollama连接超时服务未启动或端口被占用运行ollama serve检查11434端口LangChain导入报错版本不兼容固定版本如langchain0.3.0向量检索返回空嵌入模型与文档语言不匹配换用中文嵌入模型如bge-m36.2 模型输出类问题Agent不调用工具而是直接回答通常是因为工具的description不够明确或者模型的指令遵循能力不足。解决办法把工具描述写得更具体明确“什么时候用”在system prompt里强调“你必须使用工具来获取信息”换用工具调用能力更强的模型。RAG回答“根据现有资料无法回答”但资料里明明有答案大概率是检索没召回相关文档。排查步骤先打印检索到的文档内容确认是否包含答案如果没包含调整chunk_size和检索数量如果包含了但模型没看到检查Prompt模板里context是否正确填充。6.3 性能与成本类问题本地部署模型推理慢优先检查是否用了GPU。Ollama默认会用GPU但如果显存不够会回退到CPU。可以用ollama ps查看模型加载情况。另外量化等级也影响速度Q4比Q8快很多但精度会降。云端API成本高学习阶段用gpt-4o-mini或者国内的通义千问、智谱GLM价格都很低。做Agent的时候循环调用会消耗大量Token建议设置最大迭代次数避免无限循环。提示LangGraph的recursion_limit默认是25如果流程复杂容易触发。可以在app.invoke(input, config{recursion_limit: 50})里调高但不要设太大否则出问题的时候很难排查。7. 学习路线复盘我踩过的坑和给你的建议回头看我的学习过程最大的弯路是“贪多”。一开始同时看LangChain、LlamaIndex、AutoGen、CrewAI每个都浅尝辄止结果哪个都没学透。后来我强迫自己只用一个框架——LangChain加LangGraph——把RAG和Agent两条线做深反而进步最快。第二个坑是“只看不练”。大模型应用开发是实践性极强的领域你看十篇RAG教程不如自己拿一份PDF跑一遍完整流程。跑的过程中会遇到各种教程里没写的问题PDF解析乱码、中文切分不对、检索召回不准、Prompt不生效。这些问题才是真正让你成长的东西。第三个坑是“忽视评估”。我一开始做完RAG就觉得万事大吉直到用户问了一个稍微偏一点的问题回答完全不对。后来我建了一个简单的测试集把常见问题和预期答案列出来每次调整参数后跑一遍看准确率变化。这个习惯让我少走了很多弯路。如果你现在刚开始我的建议是第一周只做一件事用LangChain加Chroma做一个本地PDF问答跑通就行不求完美。第二周加BM25做混合检索感受一下召回率的变化。第三周学Agent让模型学会调用你的知识库工具。第四周学LangGraph把前面的东西串成一个有状态的工作流。一个月下来你对大模型应用开发的理解会超过绝大多数只看不练的人。最后分享一个我常用的调试技巧在LangGraph的每个节点里加日志把输入状态和输出状态都打印出来。这样当流程走错分支的时候你能立刻定位是哪个节点的判断出了问题。这个习惯在复杂工作流里能救命。