LangChain 入门：定位与第一次调用

裸 SDK 是写大模型应用最顺手的起点：pip install openai，十几行代码就能跑通第一次对话。但应用一旦长大——提示词要复用、输出要解析成 JSON、模型要能换、多步逻辑要编排——重复劳动就开始在裸 SDK 之上堆积。LangChain（官方文档、GitHub 仓库）是目前生态最完整的框架层方案，2025 年 10 月它与 LangGraph 同时发布 1.0，完成了一次从“全家桶”到“代理工程平台”的转型，如今的学习成本与收益边界都已和 0.x 时代不同。

本系列《LangChain 从入门到实战》共 12 篇，默认你已经会用 OpenAI 或 Anthropic 任一官方 SDK 完成基本调用（本站的模型 SDK 系列文章覆盖了这部分），在此基础上专讲框架层。本文是第 1 篇，回答四个问题：LangChain 解决什么、1.x 的包边界在哪、什么时候不该用、第一次调用怎么跑，最后给出系列路线图。

1、LangChain 解决什么问题

裸 SDK 给你的是“能对话”，应用要的是“能交付”。两者的缺口可以拆成三类高频重复劳动，对照你写过的裸 SDK 代码，大概率每一类都手写过：

提示词模板：系统提示、用户变量、历史消息的拼接逻辑，每个功能重写一遍
输出解析：模型返回的是字符串，程序要的是对象，解析与校验反复造轮子
流程编排：多步调用、工具触发、失败重试，裸 SDK 里全是手写状态机

用一个真实场景感受这三件事的分量：你给客服系统写了个“对话摘要”功能，拼接系统提示与对话记录、要求模型返回 JSON、解析失败重试一次；两周后另一个项目要“邮件分类”，你把这三段逻辑又抄了一遍；再过一个月模型降价要换型号，两个项目的调用代码各改一轮。当同样的代码第三次出现时，就是该框架化的信号。

LangChain 的框架价值恰好压在这三件事上：用统一的消息与模型抽象抹平厂商差异，用现成组件覆盖模板与解析，用运行时承接编排。注意它并不让第一次调用变简单——单轮调用裸 SDK 反而更短——它省的是第十次、第一百次扩展时的重复地基。这也是本系列建议先掌握官方 SDK 再上框架的原因：框架解决的是规模问题，你得先见过原始问题长什么样。

顺带把“框架层”三个字说清楚：SDK 对接协议，框架组织代码。两者是叠加而非替代关系——LangChain 里的每一次模型调用，最终仍落到对应厂商的集成包上，框架管理的是调用之外的部分：消息的形状、组件的拼装、流程的运转。理解这个分层，后面每一篇的抽象都不会凭空出现。

2、从全家桶到代理工程平台

0.x 时代的 LangChain 是出了名的全家桶：chains、agents、memory、检索全部塞在一个包里，API 迭代飞快且版本间常不兼容，“为一个功能引入整个世界”是当时社区最常见的吐槽。这有历史原因——项目 2022 年底以“大模型应用的瑞士军刀”起家，2024 年 1 月的 0.1 才算第一个稳定版，彼时已背上七百多个集成，什么都想做导致什么都难做精。2025 年 10 月，LangChain 与 LangGraph 同时发布 1.0（见1.0 发布公告），官方把定位收敛为代理工程平台（agent engineering platform）：主包只保留构建 agent 的标准路径，编排下沉给 LangGraph，旧能力整体迁出。

转型后的包结构边界如下图所示。

flowchart TD L[LangChain 生态] --> C[core 基础抽象] L --> M[langchain 主包] L --> G[langgraph 运行时] L --> I[模型集成包] C --> C1[消息与接口] C --> C2[工具与解析] M --> M1[标准 agent 入口] M --> M2[统一模型入口] G --> G1[图编排与状态] G --> G2[持久化检查点] I --> I1[OpenAI 集成] I --> I2[Anthropic 集成]

图中四条分支各司其职：langchain-core 定义消息、模型、工具等基础抽象，是其余所有包的地基；langchain 主包放标准 agent 入口 create_agent 与统一模型入口 init_chat_model；langgraph 是底层编排运行时，负责图状态、循环与持久化，主包的 agent 就构建在它之上；各厂商模型拆成独立集成包，按需安装 langchain-openai 或 langchain-anthropic。长尾厂商与社区维护的集成另有 langchain-community 承接，不在本系列主线里。更多细节可查官方的 v1 更新说明。

0.x 的 langchain 0.3 在 1.0 后更名为 langchain-classic，网上大量教程仍基于它。辨认标志是 from langchain.chains import ... 这类导入——本系列全部基于 1.x 新 API。

版本口径（截至 2026 年 10 月，以 PyPI 主页为准）：Python 端 langchain 主包已迭代到 1.4.x，langchain-core 到 1.6.x，1.x 线已稳定运行一年。今天执行 pip install langchain 装到的就是新主包。

3、什么时候不该用它

框架不是免费的：多一层抽象，就多一层学习成本、多一类依赖、排障时多一个环节。要不要引入，可以收敛成一棵决策树。

flowchart TD A[要调用大模型] --> B{一次性脚本?} B -->|是| C[裸 SDK 直接写] B -->|否| D{多步编排或工具?} D -->|是| F[用 LangChain] D -->|否| E{常要换模型?} E -->|是| F E -->|否| G[裸 SDK 也够用]

解读这棵树：单轮调用、模型固定、输出直接给人看，裸 SDK 就是最短路径，引入框架纯属负资产。负资产不是修辞，它有具体形态：安装时多拉几十个依赖，报错时调用栈多穿两层框架代码，升级时还要跟着框架的发版节奏走——0.x 时代“升级一次改一片”的教训，1.x 稳定了很多但依赖管理的账依然存在。一旦出现工具调用、多步流程、结构化输出、模型可替换任何一项，标准化的收益才开始超过成本。还有一条隐性判据是协作——多人维护的项目里，统一抽象比各写各的拼接逻辑更容易长期存活，新人接手时读的是同一套消息模型而不是三种私有封装。

4、环境准备与第一次调用

4.1、安装依赖

最小安装是主包加一个集成包，以 OpenAI 为例：

pip install -U langchain langchain-openai

装完设置环境变量 OPENAI_API_KEY 即可。用 Anthropic 模型就把集成包换成 langchain-anthropic，环境变量对应 ANTHROPIC_API_KEY，两家集成在 1.x 中都是一等公民。两个工程习惯建议从第一天保持：用虚拟环境隔离（uv venv 或 python -m venv 均可），以及记住集成包有自己的版本节奏——langchain-openai 已迭代到 1.7.x，与主包各自发版，锁定版本能避免“今天能跑明天升坏”。

4.2、第一次调用

1.x 的统一模型入口是 init_chat_model，用“厂商前缀冒号模型名”的字符串声明要什么模型，其余参数原样透传：

from langchain.chat_models import init_chat_model

# 前缀 openai 对应集成包 langchain-openai
model = init_chat_model("openai:gpt-6.1-terra", temperature=0)

resp = model.invoke("用一句话解释什么是框架")
print(resp.content)

这段代码四步走：导入、构造、调用、取值。init_chat_model 返回实现了 core 消息接口的模型对象，集成包在首次调用时才懒加载，所以忘装 langchain-openai 会在这里报错。给 invoke 传字符串等价于传一条用户消息，需要系统提示或多轮上下文时改传消息列表即可，SystemMessage、HumanMessage 这些类型由 langchain-core 统一定义，换厂商后原样可用。想换 Anthropic 只改字符串一处：

model = init_chat_model("anthropic:claude-sonnet-4-5", temperature=0)

后续 invoke 与 .content 的写法完全不变——对比一下：裸 SDK 换厂商要换整个客户端对象和响应结构，这里只动一个字符串前缀。这就是统一抽象最直观的收益。

5、八行代码的最小对比

同一需求——固定温度、单轮提问、打印回答——先看裸 SDK 写法。这边用的是官方 openai 库，构造客户端、组装 messages、再从 choices 里剥出正文，每一步都贴着 HTTP 语义：

from openai import OpenAI

client = OpenAI()  # 读取环境变量 OPENAI_API_KEY

resp = client.chat.completions.create(
    model="gpt-6.1-terra",
    temperature=0,
    messages=[{"role": "user", "content": "用一句话解释什么是框架"}],
)
print(resp.choices[0].message.content)

LangChain 侧就是上一节那段代码。两个维度的完整对照如下：

维度	裸 SDK 写法	LangChain 写法
核心行数	约 8 行	约 4 行
抽象层级	HTTP 客户端封装	消息与模型接口
换模型成本	改导入与调用链	改一个前缀字符串
返回值形态	各家私有结构	统一消息对象
适用边界	调用层	应用层

诚实地说，在单轮调用场景 LangChain 只是略整洁，行数差四行不构成使用它的理由——毕竟你还多装了一个包。表中真正有分量的是后三行：统一消息对象意味着流式输出、结果解析、工具调用在所有模型上写法一致，换模型不再触碰业务代码。当需求从“打印一句回答”演进到“把回答解析成结构化对象”时，两边代码量的差距才会真正拉开——那是从本系列第 2 篇开始逐步兑现的能力，也是框架层价值的第一现场。

6、系列路线图

后续 11 篇沿着“从调用到应用”的坡度展开，各主题对应解决的问题如下：

主题	解决的问题
提示模板	提示词复用与变量管理
结构化输出	让模型稳定返回可解析数据
工具调用	让模型操作外部世界
链与编排	把多步逻辑组装成可测单元
agent	工具选择与循环决策
记忆	跨轮次保存对话状态
RAG	检索增强与知识库问答
评测	给应用装上回归护栏
实战	串联全部能力完成真实项目

每一篇都会保持本文的写法：先讲清抽象解决哪类重复劳动，再给可运行的最小代码，最后说明它的适用边界与代价。建议的阅读节奏是跟着动手——每篇的示例都在十行上下，跑一遍再改一改参数，比连读十篇的收获大得多。

7、总结与练习

回顾全文：LangChain 1.x 定位代理工程平台，langchain-core 管抽象、langchain 主包管标准 agent 与统一入口、langgraph 管编排运行时、模型按厂商拆集成包；它不帮第一次调用减负，帮的是模板、解析、编排三类重复劳动；一次性脚本与固定单轮调用，裸 SDK 仍是更优解。对于准备长期迭代的应用，建议的学习路径是：先用 init_chat_model 单点切入跑通现有功能，再按第 6 节的坡度逐层引入模板与结构化能力，遇到旧教程先核对包版本再动手。

练习两道：

用 init_chat_model 分别以 openai: 与 anthropic: 前缀跑通同一个问题，确认 .content 取值写法一致
翻出一个自己写过的裸 SDK 脚本，对照第 3 节决策树判断是否值得迁移，并把理由写成三五行注释