LangChain 1.0 入门心法：从环境搭建到多轮对话，一文打通大模型应用开发第一步

TDevilT

531人浏览 · 2026-07-21 17:45:00

TDevilT · 2026-07-21 17:45:00 发布

前言：
最近两年大模型应用爆火，很多人一上来就冲着「智能体」「RAG」去，结果连 LangChain 的核心定位、消息体系都没搞明白，写出来的代码全是零散的 API 调用，既不好维护也没法扩展。
更坑的是网上九成教程还停留在 0.x 版本，各种过时写法满天飞，新手跟着踩坑踩得怀疑人生。

这篇文章，我基于最新的 LangChain 1.0 体系，从底层认知、环境搭建到核心消息模型、可运行实战案例，一次性讲透。
没有废话，全是可落地的干货，跟着敲完，你就能写出第一个可控、可扩展的大模型对话应用。

一、先搞懂本质：LangChain 到底是什么？

很多人学了很久，都说不清 LangChain 和直接调大模型 API 有什么区别。
一句话总结：LangChain 是大模型与业务应用之间的中间层框架，它把模型调用、提示词管理、上下文记忆、工具调用、知识库检索这些通用能力做了标准化封装，让你不用从零造轮子，专注写业务逻辑。

1. 为什么我们需要 LangChain？

在智能体时代，软件已经从「命令驱动」走向「目标驱动」。传统应用是写死流程，而大模型应用需要感知上下文、自主推理、调用外部工具、记忆历史对话。
如果全靠自己手写：

换一个大模型，整套调用逻辑要重写；
做多轮对话，自己维护上下文、处理窗口溢出；
接工具、接数据库，所有协议都要自己封装。

LangChain 做的就是把这些通用能力抽象成统一组件，一套代码兼容几十种大模型，快速搭建从简单对话到复杂智能体的各类应用。

2. 全家桶辨析：别再搞混 LangChain / LangGraph / Deep Agent

很多新手一上来就被生态名词砸晕，我给你一句话分清楚：

组件	定位	适用场景
LangChain	核心基础框架	简单对话、Prompt 管理、单轮工具调用等线性 AI 功能
LangGraph	有向图编排引擎	复杂工作流、多步骤推理、状态流转可控的场景
Deep Agent	高层智能体模板	重型全自动任务、多智能体协作，底层自动调用前两者
LangSmith	可观测性平台	调试、监控、评估智能体运行链路，解决黑盒问题

大佬选型建议：
简单功能直接用 LangChain 足够，别上来就上 Deep Agent 徒增复杂度；
需要完全掌控流程、自定义流转规则，手写 LangGraph；
做复杂全自动任务，优先 Deep Agent 快速落地。

3. 为什么直接学 1.0？少走半年弯路

LangChain 1.0 是里程碑式的版本，和早年 0.x 相比是彻底的架构重构：

废弃大量冗余 API，统一了模型初始化接口，不再有五花八门的写法；
设计思想从「链式思维」转向「智能体优先」，LangGraph 下沉为底层能力；
新增中间件机制，为企业级可观测性、权限控制打下基础。

记住一句话：新手入门直接学 1.0 以后的写法，0.x 的内容了解就行，别花精力去背老 API。

二、环境搭建：一步到位，避开新手 90% 的坑

很多人第一步就栽在环境上，版本不兼容、依赖装不上、API 调不通。
跟着下面的步骤走，全程零报错。

1. 前置准备

Python 版本：优先 3.10 / 3.11，这是 LangChain 1.x 生态兼容性最好、踩坑最少的版本；3.12 可正常用，3.13 部分小众包适配延迟。
大模型 API：本文以 DeepSeek 为例，核心原因是它完美兼容 OpenAI 接口格式，只需改 base_url 和密钥就能无缝切换，学习成本最低。

2. 安装依赖

打开终端执行命令，国内用户建议直接加清华镜像，速度快十倍：

pip install langchain langchain-openai openai python-dotenv -i https://pypi.tuna.tsinghua.edu.cn/simple

四个包的作用：

langchain：核心框架
langchain-openai：OpenAI 兼容模型的官方集成
openai：原生 OpenAI SDK，底层依赖
python-dotenv：读取环境配置，管理 API 密钥

进阶优化：配置全局 pip 镜像源
Windows 在用户目录下新建 pip/pip.ini，写入以下内容，以后装包自动走国内源：
[global]
index-url = https://mirrors.aliyun.com/pypi/simple/
trusted-host = mirrors.aliyun.com

3. 规范配置：API 密钥永远不要硬编码

新手最容易犯的错：把 API Key 直接写在代码里，一不小心提交到 Git 仓库，密钥泄露直接扣费。

正确做法：项目根目录创建 .env 文件，统一管理配置：

DEEPSEEK_API_KEY=你的 DeepSeek API Key
DEEPSEEK_BASE_URL=https://api.deepseek.com

同时创建 .gitignore，把敏感文件和缓存排除：

.env
.venv/
__pycache__/
.idea/

4. 验证调用：两种写法对比

写法一：原生 OpenAI SDK 调用

先用原生 SDK 跑通，确认 API 密钥、网络一切正常：

import os
from dotenv import load_dotenv
from openai import OpenAI

# 加载环境变量
load_dotenv()

# 初始化客户端
client = OpenAI(
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    base_url=os.getenv("DEEPSEEK_BASE_URL"),
)

# 发起调用
response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[{"role": "user", "content": "请用一句话介绍 LangChain 是什么"}]
)

print(response.choices[0].message.content)

能正常输出说明环境没问题。但这种写法的问题是：和 OpenAI SDK 强绑定，后续要加记忆、Prompt 模板、工具调用，全都要自己手写。

写法二：LangChain 1.0 标准写法

这是官方推荐的 init_chat_model 统一初始化方式，也是后续所有案例的基础：

import os
from dotenv import load_dotenv
from langchain.chat_models import init_chat_model

load_dotenv()

# 一行初始化模型，后续换模型只需改配置
model = init_chat_model(
    model="deepseek-v4-flash",
    model_provider="openai",
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    base_url=os.getenv("DEEPSEEK_BASE_URL"),
    temperature=0.7
)

# 单次调用
response = model.invoke("什么是 Deep Agent？")
print(response.content)

# 流式输出
for chunk in model.stream("什么是 LangChain？"):
    print(chunk.content, end="")

重点提醒：
model_provider="openai" 不是说用 OpenAI 的模型，而是表示「按照 OpenAI 兼容接口格式调用」。
这就是 LangChain 的核心价值：以后你想换成硅基流动、CloseAI 甚至其他兼容接口的模型，业务代码一行都不用改，只换配置就行。

三、核心根基：消息结构，是所有大模型应用的起点

很多人学 LangChain 上来就研究 Chain、Agent，结果连最基础的消息结构都没搞懂。
可以说：理解了消息体系，就理解了大模型对话的 80%。

1. 为什么需要消息结构？

直接传字符串虽然简单，但只能做单轮问答。真实业务里，我们需要告诉模型：

你是什么角色，要遵守什么规则
之前和用户聊了什么
哪些是系统指令，哪些是用户输入

这就需要结构化的消息体系，LangChain 封装了三类核心消息对象：

消息类型	角色	作用
`SystemMessage`	系统	设定 AI 的身份、回答规则、输出格式、边界限制，全程生效
`HumanMessage`	用户	传递用户的提问、需求
`AIMessage`	助手	保存模型的回复，用于构建多轮上下文

导入方式：

from langchain_core.messages import SystemMessage, HumanMessage, AIMessage

2. SystemMessage：给 AI 定规矩的核心

System 消息是控制模型行为成本最低的方式，在对话最开头发送，优先级高于用户提问。
常见用途：

限定角色：你是一名电商客服、你是 Python 讲师
限定风格：回答简洁、语气礼貌、适合初学者
限定边界：不知道的问题不要瞎编、不回答无关话题
限定格式：输出 JSON、分点回答、不超过 100 字

经验之谈：新手别一上来写几十条规则，模型执行不稳定。核心规则 3-5 条足够，越清晰越容易生效。

3. 实战案例：角色化客服助手

我们用 System 消息定义一个快递客服角色：

import os
from dotenv import load_dotenv
from langchain.chat_models import init_chat_model
from langchain_core.messages import SystemMessage, HumanMessage

load_dotenv()

model = init_chat_model(
    model="deepseek-v4-flash",
    model_provider="openai",
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    base_url=os.getenv("DEEPSEEK_BASE_URL"),
    temperature=0.5,
)

# 构建消息列表：系统规则 + 用户提问
messages = [
    SystemMessage(content="""
        你是一名快递客服助手。
        回答要礼貌简洁，不超过100字。
        如果用户没有提供订单号，先提醒用户提供订单号再查询。
    """),
    HumanMessage(content="我的快递怎么还没到？"),
]

response = model.invoke(messages)
print(response.content)

运行后你会发现，模型会主动要求用户提供订单号，完全遵循我们设定的规则。

4. 关键参数调优：temperature 怎么用才对？

temperature 是大模型最核心的超参数，控制输出的随机性，取值范围 0~2。
我给你直接对应到场景，不用自己瞎试：

0 ~ 0.3：高度确定，几乎不胡编。适合：代码生成、知识库问答、数据提取、客服系统
0.3 ~ 0.7：平衡稳定与灵活。适合：日常聊天、内容总结、通用咨询
0.7 ~ 1.0：创造力强。适合：文案撰写、头脑风暴、创意写作
>1.0：随机性极高，容易逻辑混乱，极少使用

一句话原则：业务场景往低调，创意场景往高调；不确定的时候，0.5 是安全值。

四、进阶实战：实现带上下文的多轮对话

单轮对话只是基础，真实的客服、聊天机器人都需要记忆历史，这就是多轮对话。

1. 多轮对话的本质

大模型本身没有记忆，所谓的「上下文」，就是把之前的对话历史，连同新问题一起喂给模型。
每一次调用都是完整的上下文输入，模型自己从历史里理解对话脉络。

2. 实战：命令行连续对话客服

import os
from dotenv import load_dotenv
from langchain.chat_models import init_chat_model
from langchain_core.messages import SystemMessage, HumanMessage, AIMessage

load_dotenv()

model = init_chat_model(
    base_url=os.getenv("DEEPSEEK_BASE_URL"),
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    model="deepseek-v4-flash",
    temperature=0.5,
    model_provider="openai"
)

# 初始化消息列表，先放系统规则
messages = [
    SystemMessage(content="你是快递客服，回答礼貌简洁，用户未提供单号时请先索要快递单号")
]

# 循环对话
while True:
    question = input("用户: ")
    if question.lower() == "exit":
        break
    
    # 把用户问题加入历史
    messages.append(HumanMessage(content=question))
    # 调用模型
    response = model.invoke(messages)
    print("客服:", response.content)
    # 把模型回复也加入历史，下一轮就能带上
    messages.append(AIMessage(content=response.content))

运行后测试：

用户: 我要查物流
客服: 您好，请提供一下您的快递单号，我帮您查询物流信息。
用户: 单号是 A10086
客服: 好的，单号 A10086 的包裹正在运输途中，预计明天送达。
用户: 那我可以申请退款吗？
客服: 可以的，您可以在订单页面提交退款申请，有单号我们会尽快为您处理。

可以看到，模型能记住之前的单号和对话内容，实现了连贯的多轮交互。

3. 必踩的坑：历史消息不能无限增长

很多人写完上面的代码就以为完事了，这恰恰是新手最容易忽略的问题。
无限累加历史消息会带来三个致命问题：

成本飙升：每次调用都带上全部历史，token 消耗越来越高
速度变慢：上下文越长，模型推理越慢
窗口溢出：每个模型都有上下文长度限制，超了直接报错

4. 优化方案：截断历史，只保留最近轮次

最简单有效的方案：只保留最近 N 条消息，更早的对话直接丢弃。

import os
from dotenv import load_dotenv
from langchain.chat_models import init_chat_model
from langchain_core.messages import SystemMessage, HumanMessage, AIMessage

load_dotenv()

model = init_chat_model(
    base_url=os.getenv("DEEPSEEK_BASE_URL"),
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    model="deepseek-v4-flash",
    temperature=0.5,
    model_provider="openai"
)

system_prompt = SystemMessage(content="你是快递客服，回答礼貌简洁，用户未提供单号时请先索要快递单号")
# 单独维护历史消息列表
history = []

while True:
    question = input("用户: ")
    if question.lower() == "exit":
        break
    
    history.append(HumanMessage(content=question))
    # 核心：拼接系统提示 + 最近6条历史（约3轮对话）
    messages = [system_prompt] + history[-6:]
    
    response = model.invoke(messages)
    print("客服:", response.content)
    history.append(AIMessage(content=response.content))

history[-6:] 是 Python 列表切片语法，表示取最后 6 条消息。
一轮对话包含 1 条用户消息 + 1 条 AI 回复，6 条大约是最近 3 轮对话，既保证了上下文连贯，又不会让消息无限膨胀。

后续更高级的做法还有摘要记忆、向量检索记忆，但入门阶段，截断法是性价比最高的方案。

五、给新手的 5 条入门心法

最后分享几条我总结的经验，能帮你少走很多弯路：

不要上来就搞 Agent
基础不牢，地动山摇。先把模型调用、消息结构、Prompt 模板搞扎实，再去碰工具调用、智能体。很多人花了一周搞 Agent，连消息角色都分不清，最后全是复制粘贴的玩具代码。
统一用 init_chat_model 初始化模型
别再用各种零散的模型类了，这是 1.0 的官方标准写法，以后换模型、换平台，改配置就行，业务代码零改动。
密钥永远放环境变量
任何时候都不要把 API Key 写在代码里，.env + .gitignore 是标准操作，养成习惯。
业务场景 temperature 一律往低调
做客服、知识库、数据提取这类确定性场景，0.3 左右就够了。创造力是锦上添花，不胡说八道才是底线。
多轮对话一定要做长度控制
别等上线后用户聊了几十轮，接口报错才想起截断。从第一个版本就加上历史管理，是合格开发者的基本素养。