LangChain实战入门：从核心概念到带记忆对话应用

过去两年里，大模型应用开发从一个"听起来很前沿"的技术话题，迅速变成了很多团队真正开工落地的事情。我也算是最早一批用 LangChain 做实际项目的开发者，从最初的简单封装，到后来的多智能体协作、知识库问答，一路下来踩坑不少，但收获更多。坦白说，LangChain 并不是一个"不学不行"的框架，但如果你想用大模型做正经的业务系统，而不是停留在调接口、玩 Demo 的阶段，那它会帮你省掉大量重复劳动。这篇文章是 LangChain 系列的第一篇，我会先把框架解决的核心问题、核心概念和最小 Demo 讲清楚，然后带你手写一个带记忆的对话应用，最后把新手最容易翻车的几个地方整理出来。适合刚接触大模型开发、或者已经会调 API 但想系统搭建应用层的人阅读。

1. 为什么大模型应用开发需要 LangChain 这类框架

先说一下我的经历。最早接触大模型应用时，我做的第一件事就是直接拿 HTTP 请求去调大模型服务的接口，把用户问题拼进 Prompt，再把返回内容处理后丢给前端。前两个接口写起来很爽，但等到需求变复杂，事情就不对了。

1.1 只靠裸调 API，代码会越来越不可控

裸掉 API 的问题，不在"调通"这一步，而在"维护"这一步。

第一，多轮对话的状态管理非常麻烦。每次都要手动把历史消息拼好，再一起发给模型。用户多问两句，消息记录越来越长，拼接逻辑要处理转义、截断、去重，代码越写越脏。

第二，Prompt 复用困难。不同场景要用不同的系统提示词，我最初的做法是写一堆字符串拼接函数，有的地方用 join，有的地方用 f-string，改一个词就要全局搜索。等到提示词版本多起来，根本分不清哪段逻辑对应哪个版本的 pPrompt，调试效率极低。

第三，换模型服务商等于重构。模型服务商各有各的接口风格。最开始我用了 A 家，后来因为成本和效果转向 B 家的兼容接口，结果不只是把 URL 换掉那么简单：响应结构不同、消息格式不同、流式输出的字段不同，几乎所有解析逻辑都要重写。

还有更复杂的场景，比如让大模型自己决定下一步调哪个工具。只靠裸调的话，你得自己实现一套"推理-行动-观察"循环，自己解析模型的输出，自己维护工具列表。这套东西写一次可以，但每个项目都从头写一遍，显然是在重复造轮子。

1.2 LangChain 的核心设计理念：一切皆组件

LangChain 想解决的就是上面这些"与应用层强相关、但每个项目都要重写一遍"的重复劳动。

它的核心思路可以概括为四个字：抽象与编排。

抽象指的是把大模型调用、提示词管理、输出解析、记忆存储、工具调用这些动作，都封装成有标准接口的组件。你在代码里不再关心"这个厂商的消息格式长什么样"，只需要操作统一的输入输出结构。

编排指的是把这些组件像流水线一样串起来，形成一条条链。比如一个典型的问答流程是：接收用户输入 → 组装 Prompt → 调模型 → 解析结果 → 存记忆。在 LangChain 里，这几步可以非常清楚地串成一条可读性很强的链，后续要增加一个"先检索资料再回答"的环节，也只是往链里多插一个组件。

很多人批评 LangChain 太抽象、太重，这点我不否认。但对刚上手的人来说，抽象反而是一张地图：你先理解它把整个大模型应用拆成了哪几个零件，再回头去看要做的事，心里就有数了。框架的具体 API 会变，但"模型、提示词、链、记忆、代理"这套拆解思路是稳定的，这也是我想在这个系列先讲清楚概念的根本原因。

2. 核心概念拆解：先打地基，再谈实现

LangChain 官方把框架分成若干个模块，但对新手来说，真正要理解的就五个：Model、Prompt、Chain、Memory、Agent。后面的所有高级功能，基本都是从这五个词演化出来的。

2.1 Model 层：把各家模型接口"统一"起来

Model 层解决的是"怎么跟大模型对话"的问题。LangChain 把模型接口统一成了三种类型：

• LLM：纯文本进、纯文本出，适合早期那种填空式模型。
• ChatModel：按对话消息处理，输入是消息列表，输出也带角色信息。现在主流模型基本都是这种。
• EmbeddingModel：把文本转成向量，用于检索和相似度计算，在知识库问答里是主角。

这里面最实用的设计是：不管底层是哪家服务商，ChatModel 的调用方式几乎一样。你只需要在初始化时指定模型名、API Key、接口地址，后面的 invoke 方法、消息对象、输出解析方式都是统一的。

这个"统一接口"的价值，是真正做过项目的人才能体会到的。我实际维护过一个问答系统，因为模型厂商接口调整，需要整体切换服务。在裸调方案里这是个大工程，但切到 LangChain 之后，改动的只有初始化那一两行配置，业务代码几乎没动。

2.2 Prompt 模板：提示词也要工程化

Prompt 是决定大模型输出质量的关键，但它太容易被写成"魔法字符串"了。

LangChain 里的 PromptTemplate 就是给提示词做工程化管理的工具。你可以把提示词里会变的部分抽成变量，固定部分写成模板。比如：

from langchain.prompts import PromptTemplate template = """ 你是一位{role}。 请用简洁、准确的语言回答用户的问题。 用户问题：{question} """ prompt = PromptTemplate.from_template(template)

之后要生成不同角色的回答，不用再复制粘贴一堆字符串，只要调用prompt.format(role="Python工程师", question="如何理解装饰器")就行。

PromptTemplate 还有几个实用的子类，比如聊天消息模板 ChatPromptTemplate，可以把系统消息、用户消息分别组合起来。我以前觉得这玩意儿可有可无，直到有一次系统提示词加了 200 行，才发现没有模板管理根本没法维护。提示词的版本、变量、默认值、检验逻辑，都应该有明确归属。

2.3 Chain 链：让单次调用变成业务流程

Chain 是 LangChain 最标志性的概念，也是"组合"思想的直接体现。

一条链就是把多个组件串成一个完整流程。最简单的链是 LLMChain，它的内部逻辑就是：接收输入 → 格式化 Prompt → 传给模型 → 返回结果。但真正强大的是顺序链和路由链。

顺序链适合"前一步输出是后一步输入"的场景。举个例子，你要写一个"产品文案生成器"：第一步让大模型生成产品卖点，第二步再让大模型把卖点扩写成推广文案。用顺序链可以很直观地描述这个两步流程，中间不需要你手动搬运数据。

路由链则适合"根据问题类型选择不同处理路径"的场景。比如用户输入一句"今天天气怎么样"，系统可以直接查到对应知识库返回；如果用户输入的是闲聊，则走通用对话链路。LangChain 里可以用路由链对输入先做一次判断，再决定后续走哪条分支。

我个人的建议是：链条别设计得太长。一次流程超过五六个节点，排查问题的难度会指数级上升。先保证每个节点可靠，再去拼接更复杂的链。

2.4 Memory：对话上下文不能只靠变量硬塞

用过 ChatGPT 的人都知道，多轮对话很依赖上下文。但大模型接口本身是无状态的，它不记得你上一轮说了什么。每个请求都是独立的，要让对话"有记忆"，就得自己把历史消息传给模型。

LangChain 的 Memory 模块就是干这个的。最基础的是 ConversationBufferMemory，它会缓存整段对话历史，在每次请求时拼进 Prompt。此外还有滑动窗口记忆、摘要记忆、向量记忆等几种形式。

用记忆组件最大的好处是：你不用自己写"历史消息拼接器"。它会把历史包装成标准消息格式，配合链的使用，几行代码就能实现一个多轮对话机器人。

但记忆也是"双刃剑"，记忆内容越长，单次请求消耗的 token 就越多，响应速度也会变慢。我自己经常遇到的情况是：对话到十几轮之后，模型开始"忘记"前面的关键设定。这时候光靠大记忆并不能解决根本问题，你得考虑滑动窗口、摘要压缩，甚至引入外部数据库做长期记忆。这个话题后面我会专门写一篇。

2.5 Agent：让大模型学会使用工具

Agent 是大模型应用里最有想象力的部分。普通链是"固定流程，模型只是执行者"；Agent 则是"模型自己决定下一步做什么"。

最常见的 Agent 工作模式是 ReAct。模型先观察当前环境，然后思考"要不要调用某个工具，比如搜索、计算器、数据库查询"，接着产生行动，系统把工具返回的结果再交给模型，如此循环，直到得到最终答案。

比如用户问"北京和上海之间的距离大概多少？"，模型可以决定调用地图工具拿数据，再结合计算结果回答。整个过程看起来就像是模型自己在"使用工具"。

LangChain 里做 Agent 需要三样东西：一个负责决策的模型，一组工具，一个执行器。工具可以是自定义函数，也可以是框架内置的网络搜索、文档读取、代码解释器等。在项目里，最常见的做法是把公司内部 API 封装成工具，让 Agent 根据用户意图去调用。

但我要提醒一句：Agent 不是越多越好。模型自己决策的环节越多，出错概率越高。如果你的业务场景是固定流程，用 Chain 就够了；只有当你实在无法预判用户会触发哪条路径时，再考虑 Agent。

3. 环境准备与第一个最小 Demo

概念讲完，接下来动手。你先不用关心特别复杂的工程结构，先把环境搭好，跑通最简单的链路。

3.1 安装与工程结构

LangChain 的安装比前几年复杂了，因为它把很多模型服务商的适配拆成了独立包。以我常用的 Python 环境为例，通常要装这么几个：

pip install langchain pip install langchain-openai pip install langchain-community

如果要做文档加载、向量库、网页搜索之类的功能，后面还会加别的包。第一次接触的话，别一口气全装，用到一个装一个。因为版本之间依赖关系比较敏感，装多了容易出现包冲突。

工程结构上，我建议哪怕是 Demo 也按个小项目来组织，方便后面扩展。我的一个习惯是：

my_langchain_demo/ .env main.py chains/ prompts/ utils/

.env文件存放 API Key 和接口地址，main.py放入口逻辑，chains放自定义链，prompts放提示词模板，utils放公共方法。别小看这个习惯，系列后面的文章会在这个基础上持续扩展。

3.2 跑通第一个最小链路

这里我以"最常见的兼容大模型接口"为例。你用哪家服务商都可以，只要初始化时把模型名、API Key、接口地址换成你自己的就行。

from langchain.prompts import PromptTemplate from langchain_openai import ChatOpenAI # 第一步：定义提示词模板 prompt = PromptTemplate.from_template( "你是一位{role}。\n请回答用户问题：{question}" ) # 第二步：初始化模型 model = ChatOpenAI( model="实际的模型名称", # 换成你在用的模型 api_key="你的API Key", base_url="你的接口地址", # 用默认服务可以省略 temperature=0.7 ) # 第三步：用管道符把模板和模型串成一条链 chain = prompt | model # 第四步：执行 response = chain.invoke({ "role": "Python进阶开发者", "question": "请解释什么是闭包" }) print(response.content)

如果你安装的版本正常、密钥配置正确，运行后就会看到模型输出的回答。这段代码只有十几行，但已经完整覆盖了"组装提示词 → 调用大模型 → 拿结果"的过程。

3.3 核心代码背后的设计思路说明

代码里最值得注意的，是prompt | model这个管道符写法。这是 LangChain 较新版本的主推写法，官方叫 LangChain Expression Language，简称 LCEL。

LCEL 的核心思想是：任何实现了 Runnable 接口的对象，都可以用|连接起来。prompt是一个 Runnable，model也是一个 Runnable，两者连接后生成的 chain 同样是一个 Runnable。所有 Runnable 都有统一的 invoke / stream / batch 方法，所以上层用法完全一致。

用 LCEL 而不是传统的 LLMChain，主要好处有三个：

• 代码自然流式输出。只要模型支持，chain 直接调用.stream()就能把结果一点一点吐给前端，而不是等全部生成完。这对聊天类应用几乎是刚需。
• 可以轻松做并行和批处理。chain.batch([...])一次处理多条输入，不需要自己写循环。
• 调试更直观。每条链的中间结果都可以通过回调或者.debug打印出来，定位"哪一步出问题"会清晰很多。

我第一次上手 LCEL 时有点不习惯，觉得管道符有点像函数式编程。但用过几个项目后就回不去了，它把"流程即代码"这件事表达得非常清楚。

4. 实操：构建一个带记忆的对话问答 Demo

现在我们把概念串起来，做一个真正能跑的多轮对话机器人。这是系列第一篇的收尾项目，也是后续所有复杂应用的地基：一个带记忆的对话链。

4.1 需求拆解与选型

需求很简单：用户提问，机器人回答，并且能记住前面聊了什么。比如用户先说"我要学 Python"，下一轮问"那我先学什么"，机器人应该能联想到前面的话题。

这个需求虽然看着简单，但拆解下来包含三个关键点：模型会话、历史记忆、对话链组装。

在选型上，Model 用 ChatModel，因为对话场景本身就是消息式的。Memory 我选择 ConversationBufferMemory，这是最基础、最好理解的记忆方式：不加修饰地记录全部历史。对话链用 LangChain 提供的 ConversationChain，它会自动把记忆内容注入到每次请求的 Prompt 里。

注意：记忆组件不是把历史存放在模型那边，而是在你的应用内存里维护一份记录，每次请求前拼装到 Prompt 里。应用重启，记忆就清空。如果需要持久化，得接数据库，这个后面再讲。

4.2 逐步实现：从模型到记忆再到对话链

先创建一个配置文件，把密钥和模型参数放进去。这里我直接读取环境变量，方便后续部署：

import os from dotenv import load_dotenv load_dotenv() model_name = os.getenv("MODEL_NAME") api_key = os.getenv("API_KEY") base_url = os.getenv("BASE_URL")

接下来实现主逻辑。先把模型和记忆初始化，再创建对话链：

from langchain_openai import ChatOpenAI from langchain.memory import ConversationBufferMemory from langchain.chains import ConversationChain # 初始化模型 llm = ChatOpenAI( model=model_name, api_key=api_key, base_url=base_url, temperature=0.7 ) # 初始化记忆，return_messages=True 表示按消息列表形式保存 memory = ConversationBufferMemory(return_messages=True) # 创建对话链 conversation = ConversationChain( llm=llm, memory=memory, verbose=True # 开启后会在控制台打印详细过程 ) # 命令行交互 while True: user_input = input("你：") if user_input in ("退出", "exit", "quit"): break response = conversation.run(user_input) print("AI：", response)

这里最核心的一行是ConversationChain(llm=llm, memory=memory)。它的内部逻辑是：每次run调用时，把memory里的历史记录取出来，和当前用户输入一起格式化到默认提示词模板里，然后把完整 Prompt 发给模型，拿到回答后再把"用户输入 + 模型输出"追加进记忆里。

这一切对使用者完全透明，你只需要关心业务逻辑。

return_messages=True这个参数，新手经常忽略。如果设为默认的 False，记忆会以纯文本拼接形式保存，在简单场景也能用，但遇到结构化的聊天消息或者后续要接更复杂的链，就很容易出问题。我建议在一开始就养成用消息格式的好习惯。

4.3 运行效果与调优细节

项目跑起来后，你可以连续问几个关联性问题，比如：

你：我正在学 Python AI：很好！Python 是一门非常适合入门的语言，你想重点了解哪方面？ 你：那我应该先学基础语法还是先学爬虫？ AI：建议先学基础语法，因为爬虫会用到变量、循环、函数等知识……

最后一句回答能引用前面的话题，说明记忆已经生效。

但我用下来有几处细节值得注意。

第一，verbose=True开启后，控制台会打印出链内部完整执行的的情况。它会展示"拼进了哪些历史记忆、最终 Prompt 长什么样、模型返回了什么"，这对排查问题是利器。等调试完成，记得把它关掉，否则生产日志会变得很嘈杂。

第二，温度参数要按场景调。闲聊场景可以设高一点，比如 0.8，回答会更有创意。做客服或者知识问答，我一般降到 0.2 甚至 0。温度越低，输出越稳定，越不容易瞎编。

第三，对话默认是无限存储的。从上面的实现来看，聊了几个小时，历史列表就会变得非常长。每次请求都要把全部历史发给模型，有几轮后我明显感觉响应变慢了，token 消耗也在上升。处理办法有两个：一是改用滑动窗口记忆，只保留最近若干轮；二是用摘要记忆，让模型定期把历史压缩成摘要再喂回去。后者实现稍复杂，但效果更好。

5. 常见问题排查与避坑经验

这个主题放在第一篇，是因为我见到的初学者问题相当有共性。提前把这些坑说出来，你后面会省很多事。

5.1 问题排查速查表

这张表是浓缩版。多数问题，本质上都不是 LangChain 的问题，而是配置或环境问题。报错信息只要肯仔细读，基本都能定位。

5.2 我实测下来最容易忽略的三件事

第一件，版本意识。LangChain 迭代非常快，不同版本之间的 API 差别很大。网上教程往往写了旧版写法，照抄后在新版运行直接报错。我的经验是：看教程时注意发布时间，不确定就查官方文档对应版本；项目里锁定依赖版本，不要哪天升级环境后突然把代码跑挂。

第二件，别把密钥写进代码。见过太多人把 API Key 直接写在 Python 文件里，然后往 Git 仓库一推，密钥就泄露了。正确做法是用环境变量或者密钥管理服务。这一点我觉得怎么强调都不为过。

第三件，别盲目上 Agent。有些开发者一看到 Agent 觉得很酷，把简单的问答也做成代理模式，结果模型自己调用工具绕来绕去，既慢又不稳定。我的原则是：能用普通链解决的问题绝不升级到 Agent，能用一个模型调用的任务绝不用两个。

6. 后续系列内容预告

这篇文章是大模型应用开发系列的开篇。到这里为止，你已经把 LangChain 的概念、最小链路、对话记忆和常见的坑都过了一遍。

后面的系列里，我最想写的是这几个方向，也是实际项目里真正高频使用的部分：

首先是大模型知识库问答，也就是业界常说的检索增强生成。它解决的问题是：让模型基于你自己的文档回答问题，而不是靠它的"记忆"瞎编。里面会涉及文档加载、文本切分、向量化、向量存储、召回重排这些详细的技术环节。

其次是 Agent 的深度实战。我会用一到两个完整的项目，拆解让大模型自动调用工具的前因后果，以及如何做好工具失败时的兜底。

还有 LCEL 高级用法和可观测性。写出能上生产环境的链，日志、流式输出、错误重试、性能监控一个都不能少。

最后是记忆系统的完整方案。从短期滑动窗口，到长期向量记忆，再到用数据库存用户配置和偏好，这正好接上今天这篇末尾没讲完的部分。

按照我自己带项目的经验，把这一系列跟下来的读者，应该能独立完成一个中等复杂度的大模型应用，而不是只会跑通教程示例。今天这篇只是开始，真正的硬核内容还在后面。