零基础入门 LangChain 与 LangGraph（三）：环境搭建、包安装与第一个 LangChain 程序

文章目录

- [零基础入门 LangChain 与 LangGraph（三）：环境搭建、包安装与第一个 LangChain 程序](#零基础入门 LangChain 与 LangGraph（三）：环境搭建、包安装与第一个 LangChain 程序)
- [一、不要一上来就装一堆包，先把 LangChain 的包体系看明白](#一、不要一上来就装一堆包，先把 LangChain 的包体系看明白)
- - [1.1 `langchain`：主入口包](#1.1 langchain：主入口包)
  - [1.2 `langchain-core`：真正的地基](#1.2 langchain-core：真正的地基)
  - [1.3 `langchain-openai`、`langchain-anthropic` 这类包：真正负责"接模型"](#1.3 langchain-openai、langchain-anthropic 这类包：真正负责“接模型”)
  - [1.4 `langchain-community`：社区集成仓库](#1.4 langchain-community：社区集成仓库)
  - [1.5 `langgraph` 和 `langsmith`：一个负责流程，一个负责观测](#1.5 langgraph 和 langsmith：一个负责流程，一个负责观测)
- 二、从零搭环境时，我更推荐"最小可用安装法"
- - [2.1 为什么我不建议一上来就全装](#2.1 为什么我不建议一上来就全装)
  - [2.2 Python 版本怎么选](#2.2 Python 版本怎么选)
  - [2.3 在 Windows 上创建项目目录和虚拟环境](#2.3 在 Windows 上创建项目目录和虚拟环境)
  - [2.4 先升级 pip，再安装最小依赖](#2.4 先升级 pip，再安装最小依赖)
- [三、API Key 不要写死在代码里，先放到环境变量](#三、API Key 不要写死在代码里，先放到环境变量)
- - [3.1 为什么环境变量是第一选择](#3.1 为什么环境变量是第一选择)
  - [3.2 Windows 下怎么配置](#3.2 Windows 下怎么配置)
- [四、第一段 LangChain 代码，先把"最小可运行链路"跑通](#四、第一段 LangChain 代码，先把“最小可运行链路”跑通)
- - [4.1 第一步：定义模型](#4.1 第一步：定义模型)
  - [4.2 第二步：定义消息列表](#4.2 第二步：定义消息列表)
  - [4.3 第三步：`invoke()` 调用模型](#4.3 第三步：invoke() 调用模型)
  - [4.4 第四步：用 `StrOutputParser` 只取字符串](#4.4 第四步：用 StrOutputParser 只取字符串)
  - [4.5 第五步：用 `|` 把组件串起来](#4.5 第五步：用 | 把组件串起来)
- 五、这段最小代码背后，真正要掌握的是三个核心概念
- - [5.1 Message：模型处理的不是"孤立字符串"，而是上下文单元](#5.1 Message：模型处理的不是“孤立字符串”，而是上下文单元)
  - [5.2 Runnable：LangChain 里最值得抓牢的统一抽象](#5.2 Runnable：LangChain 里最值得抓牢的统一抽象)
  - [5.3 LCEL：不是语法糖，而是 LangChain 的组合语言](#5.3 LCEL：不是语法糖，而是 LangChain 的组合语言)
- [六、除了 `ChatOpenAI`，还要认识一个更通用的入口：`init_chat_model`](#六、除了 ChatOpenAI，还要认识一个更通用的入口：init_chat_model)
- - [6.1 什么时候用 `ChatOpenAI`，什么时候用 `init_chat_model`？](#6.1 什么时候用 ChatOpenAI，什么时候用 init_chat_model？)
  - - [1. 入门阶段：先用 `ChatOpenAI`](#1. 入门阶段：先用 ChatOpenAI)
    - [2. 稍微进阶以后：开始了解 `init_chat_model`](#2. 稍微进阶以后：开始了解 init_chat_model)
    - [3. 建议：把"学习顺序"和"工程抽象"分开](#3. 建议：把“学习顺序”和“工程抽象”分开)
  - [6.2 关于"兼容 OpenAI 接口"的一个提醒](#6.2 关于“兼容 OpenAI 接口”的一个提醒)
  - - [1. 什么时候继续用 `ChatOpenAI + base_url`](#1. 什么时候继续用 ChatOpenAI + base_url)
    - [2. 什么时候我会尽量切到 provider 专用集成](#2. 什么时候我会尽量切到 provider 专用集成)
- 七、本篇总结

零基础入门 LangChain 与 LangGraph（三）：环境搭建、包安装与第一个 LangChain 程序

💬 开篇：前两篇先把"大模型是什么""为什么要学 LangChain 和 LangGraph"这两件事讲清楚了。到这一步，方向已经有了，接下来就不能再停留在概念层，必须真正开始动手。

👍 这篇要解决的问题：如果我现在是一个几乎没有 Python 基础、但有 C++ 和工程背景的开发者，第一次在 Windows 上搭 LangChain 环境，我到底该装哪些包、为什么这么装、第一段代码该怎么写、这段代码背后又该理解哪些核心概念？

🚀 这篇的目标：把 LangChain 从"听懂名词"推进到"真正跑起来"。写完这篇之后，至少要做到三件事：分清 LangChain 生态里的主要包；把本地环境搭好；写出并读懂第一个 LangChain 程序。

一、不要一上来就装一堆包，先把 LangChain 的包体系看明白

很多人第一次接触 LangChain，最容易犯的错误就是直接开装：

bash 复制代码

pip install 这个
pip install 那个
pip install 一大串

结果装完之后，包名记不住、分工分不清、依赖关系也一团乱。

真正更稳的做法其实正好相反：

先搞清楚各个包分别负责什么，再只安装当前阶段真正要用的最小依赖。

官方现在的安装思路也很明确：langchain 是主入口包，而不同模型和服务的集成能力，更多通过独立的 provider package 提供；langchain-core 负责底层抽象，langchain-community 负责大量社区集成，langgraph 和 langsmith 则分别覆盖状态化编排与应用观测。(LangChain 文档)

先给整个生态画一张图：
可与
也可与
langchain

主入口包
langchain-core

基础抽象
langchain-openai / langchain-anthropic / ...

模型与服务集成包
langchain-community

社区集成
langgraph

有状态工作流与图编排
langsmith

Tracing / Debug / Eval

这张图不用死记，但一定要建立一个直觉：
LangChain 不是一个"大而全的单包世界"，而是一个按抽象层和集成层拆开的生态。

1.1 `langchain`：主入口包

如果把整个生态比作一个工程项目，langchain 更像是开发者最先接触到的"正门"。

官方安装文档现在给出的最基础命令就是：

bash 复制代码

pip install -U langchain

并且明确说明：大量模型和工具集成并不都塞在主包里，而是放在独立的 provider package 里，按需安装。(LangChain 文档)

所以 langchain 的作用，不是"把所有东西一次性都装好"，而是：

提供高层入口
提供常用抽象的统一使用方式
把后续各种 provider 集成串进同一套开发体验里

对于初学者来说，可以先把它理解成：

进入 LangChain 生态的主入口。

1.2 `langchain-core`：真正的地基

如果说 langchain 是门面，

那 langchain-core 就是地基。

langchain-core 的官方定位很直接：它包含的是整个 LangChain 生态的基础抽象（base abstractions） ，这些抽象尽量保持模块化、简单，并且不绑定某个具体模型提供商。(PyPI)

也就是说，后面你会反复见到的这些东西：

Runnable
Message
BaseChatModel
各种统一输入输出协议

本质上都属于 core 这一层。

这也是为什么后面你会经常看到这样的导入路径：

python 复制代码

from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnableSequence

哪怕你平时更多是从 langchain 这个高层入口写代码，

真正支撑生态统一性的，还是 langchain-core。

对初学者最重要的认识只有一句：

以后你看到的很多"统一接口"，本质上都来自 core 这一层。

1.3 `langchain-openai`、`langchain-anthropic` 这类包：真正负责"接模型"

官方文档现在推荐的安装方式也很清楚：

先装主包，再按你要用的模型提供商单独安装对应的集成包，比如：

bash 复制代码

pip install -U langchain-openai
pip install -U langchain-anthropic

ChatOpenAI 这类类名，实际上就来自 langchain-openai 这样的独立集成包。(LangChain 文档)

这一层非常重要，因为它决定了你后面怎么接：

OpenAI
Anthropic
Google
Bedrock
Ollama
以及其他兼容或非兼容的服务

所以以后你只要看到一个包名长这样：

bash 复制代码

langchain-xxx

大概率就可以把它先理解成：

"把 LangChain 和某个具体服务或能力接起来的桥。"

1.4 `langchain-community`：社区集成仓库

langchain-community 的官方说明也很直白：它包含的是实现了 LangChain Core 基础接口的第三方集成，因此这些集成可以直接拿到 LangChain 应用里使用。(PyPI)

这个包你可以把它理解成：

很多社区维护的集成先放在这里
一些尚未彻底拆分成独立包的能力也会在这里
它更像一个"社区集成仓"

所以它很重要，但不意味着你现在就必须先装。

如果当前只做最小可运行示例，实际上先不装也完全没问题。

1.5 `langgraph` 和 `langsmith`：一个负责流程，一个负责观测

langgraph 官方安装文档写得很明确：它是一个单独安装的包，用来构建有状态、长时间运行的 agent 和工作流；并且官方特别强调，LangGraph 虽然由 LangChain 团队构建，但可以不依赖 LangChain 单独使用 。(LangChain 文档)

而 langsmith 则是另一条线。官方文档对它的定位是：它是一个 与框架无关（framework-agnostic） 的平台，可以用来做 tracing、调试、评估和监控；如果在 LangChain 应用里配置好环境变量，很多调用可以自动被记录。(LangChain 文档)

所以把这两个包放在一起看，会很清楚：

LangGraph：解决复杂流程怎么跑
LangSmith：解决流程跑起来之后怎么观察、怎么调试、怎么评估

这两个都很重要，但今天这篇里，我们先不急着全装上。

因为我们现在的目标还没走到"复杂工作流"和"完整观测"这一步。

二、从零搭环境时，我更推荐"最小可用安装法"

2.1 为什么我不建议一上来就全装

AI 生态变化很快，LangChain 生态变化也很快。

今天你装一堆包，也许暂时都没报错；但只要其中几个包版本关系稍微复杂一点，后面就很容易遇到：

依赖冲突
某些 API 版本不一致
某个集成包暂时不兼容
明明安装成功，运行时却报错

所以对于入门阶段，我更推荐一个原则：

先只安装当前马上要用到的最小依赖。

也就是说，这一篇我们的目标不是把整个生态一次性装齐，

而是先把下面这条链路跑通：

bash 复制代码

LangChain 主包 + OpenAI 集成包 + 第一个最小程序

等后面学到本地模型、工具调用、向量数据库、LangGraph，再一点点追加。

这不仅更稳，也更符合真正的工程习惯。

2.2 Python 版本怎么选

官方安装文档目前给出的最低要求是 Python 3.10+ 。LangChain 和 LangGraph 的安装页都明确写了这一点。(LangChain 文档)

但如果让我从零开始在 Windows 上搭一套开发环境，我不会盲目追最新版本，而是更倾向于：

Python 3.11
或者 Python 3.12

原因很简单：

越新的解释器，不代表在当前 AI 生态里越省心。很多包虽然理论上支持新版本，但真正到了不同 provider、不同向量库、不同文档处理组件一起混装时，稳定性往往还是"成熟版本"更舒服。

所以这篇我给的建议是：

如果你现在还没装 Python，优先选 3.11 或 3.12。

当然，如果你已经在用更高版本，也不是完全不能学；只是后面一旦遇到兼容问题，你要优先想到"是不是解释器版本太新了"。

2.3 在 Windows 上创建项目目录和虚拟环境

也可以使用专门的IDE，推荐Pycharm

先在一个干净目录下建项目：

bash 复制代码

mkdir LangChainDemo
cd LangChainDemo

然后创建虚拟环境：

bash 复制代码

python -m venv .venv

如果你用的是 PowerShell，激活方式是：

powershell 复制代码

.venv\Scripts\Activate.ps1

如果你用的是 CMD，激活方式是：

cmd 复制代码

.venv\Scripts\activate.bat

激活成功后，命令行前面一般会多出一个 (.venv)。

为什么一定要先建虚拟环境？

因为后面你会接触很多包：

langchain
langchain-openai
langgraph
langchain-community
文档处理包
向量库包
各种 provider 集成包

如果你不隔离环境，未来多个项目一混，很容易出现：

A 项目升级某个包，把 B 项目搞坏
今天这套代码能跑，明天换个项目又不行了
系统 Python 环境越来越乱

虚拟环境不是形式主义，它本质上是：

把每个项目自己的依赖边界隔离开。

2.4 先升级 pip，再安装最小依赖

先把 pip 升一下：

bash 复制代码

python -m pip install --upgrade pip

然后安装这一阶段最小依赖：

bash 复制代码

pip install -U langchain langchain-openai

这里我故意没有先装：

langchain-community
langgraph
langsmith
其他各种 provider 包

不是它们不重要，

而是今天先不需要。

官方安装文档现在也是这个思路：先装 langchain，如果要接 OpenAI，再单独装 langchain-openai；如果后面需要别的 provider，再追加对应集成包。(LangChain 文档)

这一步做完之后，我们就已经具备写第一个 LangChain 程序的基础了。

三、API Key 不要写死在代码里，先放到环境变量

3.1 为什么环境变量是第一选择

很多初学者最容易图省事，直接这样写：

python 复制代码

client = ChatOpenAI(api_key="你的密钥")

这样当然能跑，但从工程角度看，这不是一个好习惯。

原因很简单：

不安全

一旦代码发到仓库，密钥就暴露了。
不方便切换环境

你本地测试一套 key，服务器部署一套 key，如果都写死在代码里，后面维护会很麻烦。
不利于协作

代码应该是代码，密钥应该是配置。

这两件事最好分开。

官方 ChatOpenAI 文档现在也是直接推荐把 OPENAI_API_KEY 放进环境变量里；如果要启用 LangSmith tracing，也同样通过环境变量开启。(LangChain 文档)

所以我建议从第一天就形成这个习惯：

所有密钥类信息，都尽量走环境变量，不直接写进源码。

3.2 Windows 下怎么配置

如果你只是想临时在当前 PowerShell 会话里用一下，可以直接这样写：

powershell 复制代码

$env:OPENAI_API_KEY="你的 OpenAI API Key"

这种方式只对当前终端窗口生效。

关掉窗口之后，变量就没了。

如果你想写入用户环境变量，可以用：

powershell 复制代码

setx OPENAI_API_KEY "你的 OpenAI API Key"

执行完之后，重新打开一个新的终端 再生效。

如果后面你要接别的 provider，比如其他模型服务，也遵循同样的思路：

每个 provider 对应自己的 key，各自放在独立环境变量里。

四、第一段 LangChain 代码，先把"最小可运行链路"跑通

前面做了那么多准备，真正写代码的时候，其实反而非常短。

我先直接给出一版最小可运行代码，然后再逐段拆开讲。

python 复制代码

from langchain_openai import ChatOpenAI
from langchain.messages import HumanMessage, SystemMessage
from langchain_core.output_parsers import StrOutputParser

# 1. 定义聊天模型
model = ChatOpenAI(model="gpt-5-nano")

# 2. 定义消息列表
messages = [
    SystemMessage("Translate the following from English into Chinese."),
    HumanMessage("hi!")
]

# 3. 直接调用模型
result = model.invoke(messages)
print(result)
print(result.content)

# 4. 使用输出解析器
parser = StrOutputParser()
print(parser.invoke(result))

# 5. 用 LCEL 串成一条链
chain = model | parser
final_result = chain.invoke(messages)
print(final_result)

这段代码里，最核心的事情其实只有三件：

定义模型
准备输入
执行并拿结果

官方文档里，ChatOpenAI 的最基本用法也是这个思路：先安装 langchain-openai，配置 OPENAI_API_KEY，然后创建 ChatOpenAI 实例，再用 invoke() 发起调用。(LangChain 文档)

4.1 第一步：定义模型

最简单的写法就是：

python 复制代码

from langchain_openai import ChatOpenAI

model = ChatOpenAI(model="gpt-5-nano")

这里的 model 参数，就是你要调用的具体模型名。

如果你账户里可用的是其他型号，也可以换成对应名称。

在这一步里，先不要一上来就给自己加太多配置项。

比如：

温度
最大输出长度
超时
重试
organization
base_url

这些当然都重要，但对刚入门的人来说，先把一条链路跑通更关键。

等真跑通了，再逐个理解参数，节奏会稳得多。

4.2 第二步：定义消息列表

这一段是很多刚接触 LangChain 的人第一次会觉得"它和直接调 API 不太一样"的地方。

python 复制代码

from langchain.messages import HumanMessage, SystemMessage

messages = [
    SystemMessage("Translate the following from English into Chinese."),
    HumanMessage("hi!")
]

这里不是简单传一个字符串，而是传一组消息对象。

为什么要这样设计？

因为在 LangChain 里，消息（Messages）是模型上下文的基本单位。官方消息文档明确把它定义成模型输入输出的基本载体，并说明消息里不仅有内容，还有角色与元数据；同时 LangChain 提供了统一的消息表示方式，让不同 provider 之间的行为更一致。(LangChain 文档)

你可以先把这几种消息理解成：

SystemMessage：系统说明，告诉模型"你应该怎么工作"
HumanMessage：用户输入
AIMessage：模型返回的结果
ToolMessage：工具调用结果

今天先接触前两种就够了。

4.3 第三步：`invoke()` 调用模型

有了模型和消息之后，真正执行只需要一句：

python 复制代码

result = model.invoke(messages)

这时候你拿到的并不是纯字符串，

而是一个 AIMessage 对象。

也就是说，LangChain 返回给你的不只是：

回答内容

还会带上很多有用的信息，比如：

消息本体
使用量统计
模型名
一些响应元数据

对于初学阶段，我建议先重点盯住这两个：

python 复制代码

print(result)
print(result.content)

print(result)：看完整对象长什么样
print(result.content)：先拿最直观的文本结果

别小看这一步。

很多人学框架容易只顾着抄代码，不去看对象本身长什么样。

但如果你连返回值的数据结构都不熟，后面一到工具调用、结构化输出、多轮消息拼接，就很容易懵。

4.4 第四步：用 `StrOutputParser` 只取字符串

虽然 AIMessage 很完整，但很多场景里，我就是只想拿最后那段文本。

这时候就可以用输出解析器：

python 复制代码

from langchain_core.output_parsers import StrOutputParser

parser = StrOutputParser()
print(parser.invoke(result))

它做的事情其实很简单：

把模型返回的消息对象，解析成最普通的字符串。

这一步的意义不只是"省一步 .content"，

更重要的是它让你开始意识到：

LangChain 里，模型输出之后，还可以再经过一层标准化处理。

这就是后面"输出解析器"这个组件存在的意义。

4.5 第五步：用 `|` 把组件串起来

前面我先后调用了：

model.invoke(...)
parser.invoke(...)

其实已经隐含了一个完整流程：

bash 复制代码

消息输入 -> 模型处理 -> 消息输出 -> 解析器处理 -> 字符串输出

LangChain 不希望你每次都手动一段一段接，所以给了更自然的写法：

python 复制代码

chain = model | parser
final_result = chain.invoke(messages)
print(final_result)

这就是 LCEL 最直观的一种表现形式。

把模型和解析器用管道连起来，组成一条可以整体调用的处理链。

五、这段最小代码背后，真正要掌握的是三个核心概念

如果只是把上面的代码跑起来，那这篇最多只能算"安装成功"。

但如果想真正学会 LangChain，至少要先抓住下面三个概念。

5.1 Message：模型处理的不是"孤立字符串"，而是上下文单元

官方文档把 Message 定义得非常清楚：

它是 LangChain 模型上下文的基本单位，包含角色、内容和元数据。(LangChain 文档)

这件事非常重要，因为它决定了后面很多能力的表达方式：

多轮对话
系统提示
工具调用
工具返回
多模态内容
对话状态延续

如果你只把 LangChain 理解成"字符串进，字符串出"，

那后面看到一堆 HumanMessage、AIMessage、ToolMessage 会很容易乱。

所以从这一篇开始，我建议就把脑子切换过来：

LangChain 里的模型，更自然的输入不是纯文本，而是消息序列。

5.2 Runnable：LangChain 里最值得抓牢的统一抽象

这一层比 Message 更重要。

你会发现：

模型可以 invoke()
解析器也可以 invoke()
链组合之后依然可以 invoke()

这就说明，它们背后肯定遵循了某种统一接口。

这个接口就是 Runnable。

官方参考文档对 Runnable 的描述很关键：Runnable 可以被声明式地组合在一起，组合出来的链会自动拥有同步、异步、批处理和流式支持；而最常见的组合原语就是 RunnableSequence 和 RunnableParallel。(LangChain 参考文档)

总结一下就是：

只要一个组件实现了 Runnable 接口，它就能用统一方式被调用、被组合、被串联。

这件事是 LangChain 真正的"框架价值"之一。

因为它意味着：

你不用为不同组件记完全不同的使用方式
你可以像拼积木一样，把模型、解析器、检索器、工具等串起来
一旦串好，整个链本身也还是一个 Runnable

所以后面你越往下学，越会发现：

Runnable 不是一个普通类名，而是 LangChain 统一抽象能力的核心。

5.3 LCEL：不是语法糖，而是 LangChain 的组合语言

很多人第一次看到这个写法：

python 复制代码

chain = model | parser

会下意识觉得，它只是一个漂亮一点的语法糖。

但实际上，它背后对应的是 LCEL（LangChain Expression Language） 这套组合思路。

| 并不只是"好看"，

它表达的是：

前一个组件的输出
作为后一个组件的输入
共同组成新的可运行序列

官方文档把这种组合后的结果称为 RunnableSequence，并强调它同样具备 Runnable 的完整能力。(LangChain 参考文档)

所以这里最值得理解的，不是"运算符怎么写"，而是：

LangChain 鼓励你把任务拆成多个标准化组件，然后用一种统一语言把它们声明式拼起来。

等后面你学到：

Prompt 模板
Retriever
Tool
自定义函数
输出解析器
LangGraph 节点

你会越来越明白 LCEL 这套思路的重要性。

六、除了 `ChatOpenAI`，还要认识一个更通用的入口：`init_chat_model`

前面我一直用 ChatOpenAI，这是最适合刚入门的一种方式。

因为它简单、直观、好理解。

但如果只学这一种写法，后面很容易遇到一个问题：

一旦我要换模型提供商，是不是又要重新记一套初始化方式？

为了缓解这个问题，官方模型文档现在给出的建议是：

如果想更通用地初始化独立聊天模型，最简单的入口是 init_chat_model()。(LangChain 文档)

例如：

python 复制代码

from langchain.chat_models import init_chat_model

model = init_chat_model(
    "gpt-5-nano",
    model_provider="openai",
    temperature=0
)

response = model.invoke("用一句话解释什么是 LangChain")
print(response.content)

这个函数的意义在于，它把"不同 provider 的聊天模型初始化"统一到了一个更高层入口下。

所以你可以先这样理解两者关系：

ChatOpenAI：更具体，适合先从 OpenAI 这条线入门
init_chat_model：更通用，适合后面做 provider 切换和抽象化开发

6.1 什么时候用 `ChatOpenAI`，什么时候用 `init_chat_model`？

按照 LangChain 当前官方文档，init_chat_model() 确实是初始化独立聊天模型最通用、最统一的入口；而 ChatOpenAI 则是 langchain-openai 这个 OpenAI 专用集成包里的具体聊天模型类。换句话说，前者更像"统一工厂"，后者更像"具体实现类"。(LangChain 文档)

1. 入门阶段：先用 `ChatOpenAI`

如果我现在就是从零开始，就是先学 OpenAI 这一条线，那我会先用 ChatOpenAI。

原因很简单：它更直接。

当前 LangChain 的 OpenAI 集成文档里，入门方式就是先安装 langchain-openai，然后通过 from langchain_openai import ChatOpenAI 明确创建一个模型对象。对于刚入门的人来说，这种写法最容易建立"模型对象到底是什么、怎么来的、怎么调用"的直觉。官方在 Agent 文档里也明确提到：当你需要精确控制 temperature、max_tokens、timeout、base_url 这类 provider 相关参数时，直接初始化具体模型实例会更合适。(LangChain 文档)

python 复制代码

from langchain_openai import ChatOpenAI

model = ChatOpenAI(
    model="gpt-5-nano",
    temperature=0
)

response = model.invoke("用一句话解释什么是 LangChain")
print(response.content)

我为什么把它放在入门阶段？

因为这时候最需要搞明白的，其实不是"统一抽象层"，而是下面这些更基础的问题：

模型对象怎么定义
invoke() 到底怎么调用
输入到底是字符串，还是消息列表
返回值到底长什么样
参数到底加在什么地方

这些东西先用 ChatOpenAI 看，会更清楚。

2. 稍微进阶以后：开始了解 `init_chat_model`

等把"具体模型类"这层直觉建立起来以后，开始接触 init_chat_model()。

因为一旦学习继续往后走，我很快就会遇到这些需求：

我想换一个 provider 对比效果
我不想让上层代码和某一个 provider 耦合得太死
我希望模型初始化方式尽量统一
我希望以后能做配置化切换，而不是每换一家就改一套代码

init_chat_model() 的价值，就在这里。

LangChain 当前官方参考文档对它的定义非常直接：它是一个统一接口 ，可以从任意受支持的 provider 初始化聊天模型，并且有两个主要用法------一种是固定模型，另一种是把模型参数做成运行时可配置。官方模型文档里也把它写成"初始化 standalone model 最容易上手的入口"。(LangChain 参考文档)

python 复制代码

from langchain.chat_models import init_chat_model

model = init_chat_model(
    "openai:gpt-5-nano",
    temperature=0
)

response = model.invoke("用一句话解释什么是 LangChain")
print(response.content)

上面这段代码和前面的区别，关键不在"能不能跑"，而在"抽象层次"变了。

前面的 ChatOpenAI 是在说：

我现在明确要创建一个 OpenAI 的聊天模型对象。

而这里的 init_chat_model() 更像是在说：

你按统一规则帮我初始化一个聊天模型，至于它具体属于哪家 provider，可以通过模型标识或参数来决定。

LangChain 当前模型文档也明确写了，模型和 provider 可以一起写成类似 openai:o1 这样的字符串；在部分场景下，如果没显式传 model_provider，它还会尝试从模型名推断 provider。(LangChain 文档)

3. 建议：把"学习顺序"和"工程抽象"分开

从官方统一入口角度看 ：init_chat_model() 更通用
从零基础学习顺序看 ：我仍然更建议先用 ChatOpenAI 建立直觉

因为对于初学者来说，先见具体类，再理解统一工厂，更容易理解。

6.2 关于"兼容 OpenAI 接口"的一个提醒

现在很多模型服务都会提供"OpenAI 兼容接口"，也就是说，你改一下 base_url，很多基础聊天调用就能先跑起来。LangChain 官方的聊天模型集成页也明确提到：某些 provider 会暴露与 OpenAI Chat Completions API 兼容的端点，在这种情况下，可以通过 ChatOpenAI 配合自定义 base_url 来完成基础聊天功能。(LangChain 文档)

但是这里有一个很关键的限制：

ChatOpenAI 的目标是对接官方 OpenAI API 规格 。

如果你接的是第三方 OpenAI-compatible 服务，那么那些额外扩展出来的非标准字段 ，比如某些 reasoning 字段、provider 自定义元数据，LangChain 不保证会帮你完整提取和保留。官方文档对这一点写得很明确。(LangChain 文档)

这句话总结一下就是：

接口长得像，不代表能力就完全一样。

1. 什么时候继续用 `ChatOpenAI + base_url`

如果我现在只是做这些事情：

跑一个最小 demo
验证接口通不通
做基础对话测试
快速比较不同模型的回答风格

那我觉得用 ChatOpenAI + base_url 完全没问题。

只要能先跑起来，后面很多问题才谈得上。

2. 什么时候我会尽量切到 provider 专用集成

一旦开始在意下面这些东西，就不会再满足于"能通就行"了：

provider 扩展出来的额外字段
更完整的工具调用能力
更细的参数控制
更稳定的长期工程维护

LangChain 当前把各家 provider 都拆成了独立的 langchain-provider 包，官方说明这样做是为了更好的版本管理、依赖管理和测试；在 provider 总览页里，也已经能看到 langchain-openai、langchain-ollama、langchain-deepseek 等专用集成。也就是说，真要长期用哪一家，尽量还是往它对应的专用集成靠。(LangChain 文档)

七、本篇总结

ChatOpenAI 是具体实现类，适合把 OpenAI 这条线跑明白
init_chat_model() 是统一工厂入口，适合后面做更通用的抽象
OpenAI-compatible 接口可以用来快速验证，但不等于 provider 特性完全等价
真到工程阶段，尽量优先使用对应 provider 的专用 LangChain 集成

所以这一节真正要记住的，不是"哪个更高级"，而是：

先用具体类建立直觉，再用统一入口做抽象；先让代码跑通，再考虑把 provider 切换这件事设计漂亮。

💬 下一篇预告：下一篇开始进入聊天模型的进阶能力。我会把工具调用、结构化输出、流式传输和 LangSmith tracing 串成一篇完整博客。到那时，LangChain 才真正开始从"能调用模型"走向"能做应用"。

零基础入门 LangChain 与 LangGraph（三）：环境搭建、包安装与第一个 LangChain 程序

文章目录