LangChain 1.0+ 入门：从”只会调 API”到”搭出 AI 应用”

摘要：单一大模型只能回答问题，做不了完整应用。LangChain 1.0+ 用标准化组件把模型、消息、工具、状态组织起来，本文从零讲清它的定位、核心组件，以及 Model 与 Message 两个最基础的组件。

引子：会调 API 不等于会做应用

你大概已经会这样调用大模型了：

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[{"role": "user", "content": "你好"}],
)

但真要做产品时，你会发现单靠这个远远不够：模型不知道最新消息、连不上数据库、记不住上一轮对话、更不会自己去查订单状态。“能调用模型”和”能做出一个可上线的 AI 应用”之间，隔着工具、记忆、流程控制一整套工程问题。

LangChain 就是来解决这层差距的。本文讲清它是什么、解决什么问题，并拆解它最基础的两个组件：Model（模型调用）和 Message（消息结构）。

一、LangChain 是什么

1. 从 Web 框架到 AI Agent 框架

Web 时代有 Spring Boot、Django；AI Agent 时代，LangChain 扮演类似角色：一个用于开发大语言模型（LLM）驱动应用的开源框架。它诞生于 2022 年 10 月，由哈佛大学的 Harrison Chase 创建，名字来自 “Language”（语言）与 “Chain”（链式连接）。

2. 为什么只调模型不够

单一大模型有三个天然局限：

局限	说明
知识截止	无法获取训练时点之后的信息
与世隔绝	不能直接访问数据库、外部 API
没有状态	记不住多轮对话的上下文

LangChain 的价值就是补上这三点，把模型能力组织成真正可运行、可维护、可上线的应用。

3. 核心组件一览

LangChain 1.0+ 提供一套标准化组件：

组件	作用
Models	统一对接 GPT、Claude、DeepSeek 等模型，可切换
Messages	用标准消息结构组织多轮对话
Prompts	提示词模板化、动态填充
Tools	把函数、API、数据库查询封装成工具
Agents	让模型自主”判断下一步 + 调工具 + 完成任务”
Middleware	执行过程中的控制逻辑（权限、日志、拦截）
State / Memory	管理多轮上下文和业务状态
LangGraph	复杂流程编排、持久化、人类介入
LangSmith	调试、追踪、评估、可观测

一句话：LangChain 1.0+ = 标准化组件 + Agent 架构，目标是让你像搭积木一样组合模型、工具、数据、记忆和流程。

二、1.0+ 和旧版有什么区别

2025 年 10 月 LangChain 发布 v1.0.0，学习主线变化很大：

变化点	0.3 旧版	1.0+
学习主线	`LLMChain`、`AgentExecutor`、`Memory`	`create_agent()`、`Middleware`、`LangGraph`
Agent 创建	多种分散写法	统一 `create_agent()`
控制机制	写在 prompt、hook、业务代码里	`Middleware`
记忆机制	`ConversationBufferMemory` 等	`messages`、`state`、`checkpointer`、`thread_id`

包结构也做了分层（不是混乱，是设计）：

包	职责
`langchain`	主包，高阶入口（`create_agent`）
`langchain-core`	基础抽象（消息、工具、模型）
`langchain-openai` / `langchain-deepseek`	各厂商模型集成
`langchain-classic`	旧版兼容包
`langgraph`	状态和流程编排

课程常见导入：

from langchain.agents import create_agent
from langchain_core.messages import HumanMessage, AIMessage, ToolMessage
from langchain.tools import tool
from langchain_deepseek import ChatDeepSeek
from langgraph.checkpoint.memory import InMemorySaver

三、Model：统一的大模型调用层

Model 是所有 LangChain 应用的起点。它要回答一个问题：原生 SDK 和 LangChain 调用模型，差别在哪？

1. 环境准备

1	pip install -U langchain langchain-openai langchain-deepseek langgraph python-dotenv pydantic

密钥放 .env，用 python-dotenv 加载，绝不写死在代码里：

from dotenv import load_dotenv
import os
load_dotenv()
api_key = os.getenv("DEEPSEEK_API_KEY")

2. 原生 SDK vs LangChain

原生 SDK 解决”能不能调用”——client、model、messages、生成参数、response 五个部分；LangChain 解决”如何接入 Prompt、Tool、Agent 组件体系”。

两者的分界：

层	工具	回答的问题
原生 SDK	`client.chat.completions.create()`	能不能调用模型
LangChain	`model.invoke()/stream()/batch()`	如何让模型进入组件体系

3. 三种调用写法

方式一：init_chat_model + 官方 provider（课程主线）

from langchain.chat_models import init_chat_model

model = init_chat_model(
    model="deepseek-v4-pro",
    model_provider="deepseek",
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    temperature=0.7,
)
response = model.invoke("你好，简单介绍下自己。")
print(response.content)

方式二：init_chat_model + OpenAI-compatible（兼容接口）

OpenAI-compatible 指”接口格式兼容 OpenAI”，不代表模型来自 OpenAI。换 api_key、base_url、model 三处即可接通义千问等：

model = init_chat_model(
    model="qwen-plus",
    model_provider="openai",
    api_key=os.getenv("DASHSCOPE_API_KEY"),
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)

方式三：手动实例化模型类（补充）

1
2
3

from langchain_deepseek import ChatDeepSeek

model = ChatDeepSeek(model="deepseek-v4-pro", api_key=os.getenv("DEEPSEEK_API_KEY"))

记忆口诀：model_provider 决定请求协议，base_url 决定请求地址，model 决定实际模型，api_key 决定访问凭证。

4. 三种访问方式：invoke / stream / batch

特性	invoke	stream	batch
输入	单个输入	单个输入	多个输入
输出	一个完整结果	多个增量片段	多个完整结果
返回时机	全部生成后	边生成边返回	一批任务完成
适用场景	脚本、测试、问答	聊天 UI、打字机效果	批量测试、离线任务

# stream：聊天界面打字机效果
for chunk in model.stream("你好"):
    print(chunk.content, end="", flush=True)

# batch：批量处理
responses = model.batch(["问题1", "问题2", "问题3"])

四、Message：对话的结构化上下文

Message 是对话模型的输入输出结构。关键认知：模型接收的不是一个字符串，而是一组带角色的消息。

1. 为什么围绕 messages 展开

对话模型必须知道每句话是谁说的。四种基础消息类型：

角色	Message 类	含义
system	`SystemMessage`	系统规则、角色设定
user	`HumanMessage`	用户输入
assistant	`AIMessage`	模型回复（可能含工具调用请求）
tool	`ToolMessage`	工具执行结果

为什么不用字符串拼接？因为角色信息在 API 里是结构化字段，不是让模型去猜的文本。工具调用时还要记录”调了哪个工具、传了什么参、结果对应哪次调用”，普通字符串维护不了。

2. 两种写法

# 字典写法（接近原生 API）
messages = [
    {"role": "system", "content": "你是一个乐于助人的 AI 助手。"},
    {"role": "user", "content": "你好，我叫 Yuan。"},
]
response = model.invoke(messages)

# Message 对象写法（LangChain 主线推荐）
from langchain_core.messages import SystemMessage, HumanMessage, AIMessage
messages = [
    SystemMessage(content="你是一个乐于助人的 AI 助手。"),
    HumanMessage(content="你好，我叫 Yuan。"),
]
response = model.invoke(messages)

3. 多轮对话：历史要应用自己维护

大模型 API 是无状态的——本次请求传什么它就看到什么。多轮对话靠应用把历史消息 append 回去：

messages = [SystemMessage(content="你是一个乐于助人的 AI 助手。")]
while True:
    user_input = input("你：")
    if user_input.lower() in {"exit", "quit"}:
        break
    messages.append(HumanMessage(content=user_input))
    response = model.invoke(messages)
    print("助手：", response.content)
    messages.append(response)

后续学到的 Memory、checkpointer、Agent state，本质都是解决”如何保存和管理 messages”。

4. 多模态仍是 Message

多模态场景下 Message 类型不变，变的是 content 结构——从字符串变成内容块列表：

message = HumanMessage(content=[
    {"type": "text", "text": "请描述这张图片。"},
    {"type": "image_url", "image_url": {"url": "https://example.com/image.jpg"}},
])

一句话：多模态不是另一套机制，只是 content 更丰富。是否支持取决于模型本身。

五、小结

学完这部分，你需要能回答六个问题：

对话模型输入为什么是 messages 而不是字符串？
四种 Message 类型分别代表什么？
如何用 messages 调用模型？
多轮对话为什么需要应用维护历史？
Agent 执行过程为什么也存进 messages？
多模态为什么仍属于 Message 体系？

Model 与 Message 是 LangChain 应用的地基。下一步（Part 3）将看 Agent 如何把这些组件组织成完整任务。