史上最全LangChain 学习教程

真正让大模型落地的从来不是那一句提示词。而是提示词之外那一大堆脏活累活。模型怎么接、消息怎么传、工具怎么调、知识库怎么检索、状态怎么保存、输出怎么约束、出了问题怎么追...这些都是我们要考虑的既是痛点也是难点。LangChain 的价值就在这里。它是啥它不是大模型。它也不是一个单纯的提示词库。它更像一层工程框架把大模型应用里最重复、最混乱、最容易失控的部分整理成一套可以复用、可以替换、可以扩展的构件。官方现在对它的定位也很直接它是一个开源框架提供预构建的 agent 架构以及面向不同模型和工具的集成用来更快地构建 LLM 应用和 agents。官方文档LangChain Docs很多人用过LangChain觉得它只是在链 prompt还能加快agent开发。这不算错但已经不够了。今天的 LangChain核心目标已经从“把几个步骤串起来”升级成了把 agent 应用工程化。官方文档里已经明确把重点放在 agent、工具调用、memory、middleware、observability以及和 LangGraph 的关系上。LangChain 负责更高层、更易上手的抽象LangGraph 负责更底层的编排能力比如长流程、有状态、可恢复、可中断的人机协同这些都是比较重要的。一、LangChain 是什么Lang Language指语言模型Chain Chains指把多个步骤串起来执行LangChain 官方文档直接写了“The name LangChain comes from ‘Language’ and ‘Chains’. ”更直白一点说不要只调用一次大模型而是把一连串步骤接起来。比如先检索资料再把资料塞进提示词再调用模型生成答案。LangChain 官方也把 chains 描述为一组预先设定好的计算步骤例如 RAG 里的先检索再生成。所以你可以把它理解成一句大白话LangChain 把语言模型接入一条工作链路的框架。最简单的定义是LangChain 是一套面向大模型应用的开发框架。它把模型调用、上下文组织、工具接入、知识检索、状态管理和调试追踪抽象成了统一的开发接口。这件事很重要为什么因为大模型开发真正的难点和痛点从来不是发一个请求给模型。真正难的是下面这些问题你今天用 OpenAI明天想换 Anthropic代码要不要全改。你想让模型能查天气、查数据库、发请求、执行函数怎么把工具安全地接进去。你做 RAG要怎么把文档加载、切分、向量化、检索、拼上下文这一整套接起来。你做多轮对话历史消息怎么管状态怎么存。你做 agent模型中途调用了三次工具到底哪一步错了怎么追。你上线后效果退化了是模型变了prompt 变了还是检索坏了。LangChain 不是替你解决业务问题更多的是重复性、复杂性高的基础工作。不过从设计哲学上看LangChain 的判断也很鲜明大模型本身很强但接入外部数据之后更强。未来应用会越来越 agent 化。但从原型走向生产并不容易真正难的是可靠性。它存在的目的就是让大模型跑的更稳。二、LangChain 的核心组成部分其实官方现在给出的口径很克制。在 LangChain 当前文档里Core components 只有 7 个这就说明 LangChain 想先教你的不是一个大而全的 AI 系统而是一个最小但完整的 agent 运行框架告诉你agent是怎么运行的。LangChain 官方对自己的定位也很直接它是一个开源框架提供预构建的 agent 架构以及面向任意模型和工具的集成用来快速搭建 LLM 应用。2.1 Agents如果说 LangChain 是一台机器Agent 就是这台机器的总控台。简单讲agent LLM prompt memory tools官方对 agent 的定义非常清楚“Agents combine language models with tools to create systems that can reason about tasks, decide which tools to use, and iteratively work towards solutions.”agent 把语言模型和工具结合起来让系统能够围绕任务进行推理决定该用什么工具并通过反复迭代逐步逼近答案。其实很简单LangChain 把 Agents 放在第一位不是因为它技术有多深而是因为它定义了整套系统的组织方式。你后面看到的模型、消息、工具、记忆、流式输出本质上都在服务这个循环。2.2 Models不要认为LangChain中模型只是一个调用的接口。在 LangChain 里模型不只是接口它是推理引擎。官方文档写到LLM 是强大的 AI 工具能够像人类一样解读和生成文本。他们足够多才多艺能够撰写内容、翻译语言、总结和回答问题而无需专门培训。很多现代模型除了文本生成还支持工具调用、结构化输出、多模态处理和多步推理。它开始承担判断、选择、规划和收敛的角色。比如什么时候该调用工具调用完之后怎么解释结果什么时候该停止循环给出最终答案这些都由模型来驱动。模型选得好不好决定了 agent 的底盘稳不稳。并且LangChain 的价值不是替你发一次请求而是把不同模型尽量放到统一接口下。这样你做应用时注意力可以更多放在系统设计上而不是陷在不同厂商 SDK 的细枝末节里。2.3 Messages如果说模型是推理引擎Messages 就是它看到的世界。官方把 messages 定义为模型上下文的基本单位包括角色、内容、元数据三部分。它们表示模型的输入和输出里面不仅有内容还有角色和元数据。一个 message 至少包含三层信息谁说的说了什么还带着哪些附加信息。LangChain 还提供了跨模型提供商统一的消息类型。简单来说message就是agent中传递的信息包包括类型本质用户问题message模型回答message工具调用请求message工具返回结果messagesystem promptmessage思考过程有些框架message一个最简单的message形态长这样{ role: user, content: 帮我写一个 Python 函数 }最简单的用途是创建消息对象并在调用时传递给模型。from langchain.chat_models import init_chat_model from langchain.messages import HumanMessage, AIMessage, SystemMessage model init_chat_model(gpt-5-nano) system_msg SystemMessage(You are a helpful assistant.) human_msg HumanMessage(Hello, how are you?) # Use with chat models messages [system_msg, human_msg] response model.invoke(messages) # Returns AIMessage四、Tools没有工具模型大多只能输入输出。有了工具模型才真正开始做。官方文档对 tools 的描述很直接工具让 agent 能获取实时数据、执行代码、查询外部数据库并对外部世界采取动作。在底层工具就是输入输出明确的可调用函数传给聊天模型之后由模型根据对话上下文决定是否调用以及传什么参数。这一层非常关键。它可以解释天气却拿不到此刻的天气。它可以写 SQL却不等于真的查了数据库。它可以规划一件事却不等于真的执行了动作。Tools 的诞生给了agent手臂。from pydantic import BaseModel, Field from typing import Literal class WeatherInput(BaseModel): Input for weather queries. location: str Field(descriptionCity name or coordinates) units: Literal[celsius, fahrenheit] Field( defaultcelsius, descriptionTemperature unit preference ) include_forecast: bool Field( defaultFalse, descriptionInclude 5-day forecast ) tool(args_schemaWeatherInput) def get_weather(location: str, units: str celsius, include_forecast: bool False) - str: Get current weather and optional forecast. temp 22 if units celsius else 72 result fCurrent weather in {location}: {temp} degrees {units[0].upper()} if include_forecast: result \nNext 5 days: Sunny return resultLangChain 为什么能从“聊天框架”走向“agent 框架”核心原因之一就在这里。它把外部能力标准化成模型可调用的工具。2.5 Short-term memory真正有用的系统不能每一轮都失忆。官方对 short-term memory 的定义是它让应用记住单个线程或单次会话里的历史交互。对 agent 来说记忆很关键因为它能帮助系统记住之前发生过什么从反馈中学习并逐步适应用户偏好。这里最值得注意的一点是LangChain 现在已经不把 memory 只看成把聊天记录再贴回去。在 agent 体系里短期记忆更像运行时状态。它记录对话历史也记录中间过程。它不只是为了聊天连贯更是为了让 agent 知道自己已经做到了哪一步。memory更像是agent的执行状态。没有状态就没有真正的多轮任务。没有状态所谓 agent 往往只是“会反复调用模型的脚本”。2.6 Streaming流式输出是否重要我觉得是它算是大模型使用体验的一个里程碑。其实它不仅是产品细节它也是体验分水岭。官方文档写得很明确LangChain 实现了一套 streaming 系统用来把 agent 运行过程中的实时更新暴露出来。这样应用不必等完整结果全部生成完用户可以提前看到进度从而明显改善响应体验。更重要的是它支持至少五类流 LangChain 文档 这意味着什么意味着 streaming 在 LangChain 里不只是显示层的小优化而是把系统内部运行过程显性化。你不仅能看到答案在生成还能看到 agent 走到了哪一步一旦你开始做稍复杂一点的 agent就会明白这件事有多重要。2.7 Structured 结构化 output大模型真正接入系统时最怕的一件事就是输出太像人话。人话适合阅读。系统需要的是可消费的数据。Structured output 应运而生官方文档它让 agent 直接返回可预测的结构化结果而不是让你再去解析自然语言。这些结果可以是 JSON、Pydantic model 或 dataclass。LangChain 的create_agent会自动处理这件事把模型生成的结构化数据捕获、校验并放进 agent state 里的structured_response。hh其实我感觉没那么重要自己解析其实也慢不到哪去。补充这里要先说明一下。下面这些不是“官方没提到”。更准确地说它们不在官方那 7 个 Core components 清单里但在官方其他栏目里都有明确位置。1. Middleware 中间件官方甚至单开一栏。官方把 middleware 放在 Core components 之外给了单独栏目。它的作用是在 agent 执行的每一步进行控制和定制包括日志、调试、改 prompt、改工具选择、加重试、加 fallback、提前终止、限流、加 guardrails 和 PII 检测。说白了Core components 决定 agent 能不能跑。Middleware 决定 agent 跑起来之后能不能被你真正管住。详细可以看官方文档。2. Retrieval 检索很多人一学 LangChain第一反应就是 RAG。但官方现在没有把 Retrieval 放进核心七件套而是放进 Advanced usage。这背后的意思很微妙。LangChain 想先让你理解 agent 的基本骨架。至于检索是在很多真实场景里常见且重要的一种扩展能力。官方检索文档也讲得很明白LLM 有上下文有限的天然约束所以 retrieval 的作用是在运行时为模型拿到相关上下文。你既可以自己构建知识库也可以直接连接已有数据库、CRM 或内部文档系统。3. 文档加载、切分、Embedding、Vector store这几个东西很多人学 LangChain 时会以为它们就是核心本体。其实从官方今天的组织方式看它们更像是 Retrieval 这条线里的基础积木。官方在 retrieval 页面明确列出了 retrieval pipeline 的几个 building blocks包括 document loaders、text splitters、embedding models 和 vector stores并且强调这些组件是可替换的。感觉这很像搭积木。加载数据是把知识搬进来。切分文本是把知识拆到能被召回的粒度。Embedding是把文本投到向量空间。Vector store是把这些向量存起来并搜索。4. Long-term memory长期记忆被很多人忽略了短期记忆解决的是单轮会话内的连续性。长期记忆解决的是跨会话的持续性。官方把 long-term memory 放在 Advanced usage 里。它允许 agent 在不同会话、不同线程之间存储和召回信息而不是只记住当前这一段对话。这类能力一旦进入生产环境就会非常重要。比如用户画像、偏好、历史行为、任务记录这些都不属于单次会话状态而属于更长期的系统记忆。messages 提供上下文models 做推理agents 决定流程tools 执行动作memory 保存状态structured output 规范结果middleware 控制整个运行过程。LangChain把这7个组件串联起来让大模型跑在想要的路上。三、LangChain 到底做了什么我觉得最重要的就是统一了度量衡。不同模型厂商有不同的 API、不同的消息格式、不同的参数命名工具、向量库和外部系统也各有各的接法。LangChain做的第一件事就是把这些差异收拢成一套相对统一的抽象让你可以更平滑地替换底层模型和工具而不必每换一家供应商就重写一遍业务代码。但是这样就片面了准确地说LangChain做的事情可以从四层来看统一接口、组织工作流、把 agent 工程化、补齐调试与评测。官方现在把它定义为一个带有预构建 agent 架构、并能连接任意模型和工具的开源框架它的 agent 又是构建在 LangGraph 之上的而调试、评测和部署则可以接到 LangSmith 上。四、如何学习 LangChain学 LangChain 最怕两件事。第一件事沉迷 API 名字。第二件事一上来就做多 agent 大项目。正确的学法不是背类图。而是顺着大模型应用的演化路径去学。1.先把大模型跑起来 (LangChain Docs)可以先做一个demo只包含三件事用户输入模型调用模型输出官方的 Quickstart 就是最好的教程从最小 agent 开始展示模型、工具和提示如何协同工作。安装入口也很直接LangChain 当前要求 Python 3.10 及以上。第一阶段只做三件事model 怎么初始化message 怎么传tool 是怎么被模型调用的可以先看看LangChain OverviewQuickstartModelsMessagesTools。2.补上检索和结构化输出 (LangChain Docs)学完大模型的基本调用就可以接触RAG了因为绝大多数真实场景都离不开外部知识。官方 Learn 区已经把 semantic search、RAG agent、SQL agent、voice agent 等典型路径整理好了。这一阶段建议做两个小项目第一个项目给一份 PDF 做语义检索。第二个项目在检索基础上加一个最小 RAG 问答。可以看看RetrievalBuild a semantic search engineBuild a RAG agentStructured output。这一阶段学完你会第一次真正理解 LangChain 的价值和作用。3.深入agent工作原理很多人一开始就学 agent最后只学会了几个 demo。更好的顺序是先把模型、工具、检索学明白再回来看 agent 为什么成立。这一阶段重点看AgentsShort-term memoryMiddlewareObservability重点关注它怎么决定下一步做什么。它怎么记住过程中的状态。你怎么拦截和控制它的执行。它出了问题你怎么定位。如果这四个问题你都能答清楚你对 LangChain 的理解就可以说你掌握LangChain了。4. LangGraph当你的流程开始变长开始有条件分支、循环、检查点、人工确认或者你希望 agent 可以中断后恢复就该进 LangGraph 了。官方建议也很明确入门先用 LangChain 的高层 agent。需要更深定制时再转 LangGraph。这个阶段重点在于LangGraph OverviewLangGraph QuickstartUse the Graph APIThinking in LangGraph看这些内容时多想想是怎么设计和实现的以及为什么而不是只会调包。5. LangSmith很多人把 tracing 当成上线前才需要的东西。其实从第一个 RAG demo 开始你就该接 LangSmith。官方 tracing quickstart 直接演示了如何把 retrieval 和 LLM 调用都记录进 trace然后在界面里看完整过程。没有可观测性你只是“觉得系统能跑”。有了可观测性你才开始真正“理解系统为什么这样跑”。总结如果你想要一条能落地的路线可以参考第一周只学 LangChain 基础组件。把 Quickstart 跑通理解 model、message、tool。第二周做一个最小 RAG。用自己的 PDF 或文档完成加载、切分、向量化、检索、回答。第三周加 structured output、memory 和 tracing。开始感受“从 demo 到应用”的区别。第四周进入 agent 和 LangGraph。做一个会调工具、能追踪、有简单状态管理的 agent。五、推荐的资料网课讲的都比较浅显而且是被动学习学起来慢不说还容易忘这边推荐直接看官方文档 LangChain 文档其他网站1.OpenAI 开发者2.Claude API Docs3.Google AI for Developers5.Hugging Face6.deeplearning.ai