这两年做 LLM 应用，大家很容易一开始就陷入“调模型”“拼 Prompt”“堆工具”的局部优化里，代码能跑，但结构很快失控。LangChain 之所以流行，不是因为它替我们发明了新的模型能力，而是因为它把大模型应用开发里最常见的几个动作，整理成了一套可以组合、可以维护、可以扩展的工程抽象。

不过现在真正容易让人混淆的，已经不只是 LangChain，而是 LangChain、LangGraph、Agent、Workflow 这些概念经常被混着讲。于是很多人看完几篇文章后，会觉得名字都熟，但边界还是不清楚。

所以这一篇我先不急着上复杂 Agent，而是先把三件事讲清楚：

LangChain 和 LangGraph 到底有什么区别
项目里该怎么选型
当前官方稳定架构到底统一了什么

把这层打稳了，后面再去看 LangGraph 工作流和 Agent 实战，就不会觉得“明明都在讲 Agent，为什么又要单独学一套图框架”。

0. 先把三篇的关系讲清楚

这个系列现在可以按下面的方式理解：

上篇：先解决认知问题
搞清楚 LangChain、LangGraph、Agent、Workflow 的区别与选型，再讲 LangChain 基础能力。
中篇：专讲控制流问题
聚焦 LangGraph，理解工作流、状态机、条件边、回环、子图和多 Agent 编排。
下篇：专讲 Agent 落地问题
回到实际系统，讨论 L2、L3、L4、OpenClaw 这类不同层级的 Agent 形态。

所以这三篇不是并列重复，而是三层递进：

先分清概念
再掌握骨架
最后进入实战

1. LangChain 和 LangGraph 到底有什么区别

如果只用一句话来概括，我更倾向于这样说：

LangChain 是高层应用框架，偏“快速搭应用”
LangGraph 是底层编排框架，偏“把复杂系统跑稳”

更具体一点：

1.1 LangChain 是什么

根据官方 overview 的表述，LangChain 现在的核心定位是：

提供统一模型接口
提供工具集成
提供预置 Agent 架构
让你更快搭出 agent 和 autonomous application

也就是说，LangChain 更像一个高层开发层。

它擅长解决的问题是：

怎么快速接模型
怎么快速接工具
怎么快速把一个 agent 跑起来
怎么用统一方式适配不同 provider

1.2 LangGraph 是什么

官方对 LangGraph 的定位则很明确，它是一个 low-level orchestration framework and runtime。

翻成工程语言，大致就是：

它更低层
它更关注 orchestration，而不是 prompt 抽象
它更关注长流程、状态、持久化、回环和人工介入

LangGraph 主要解决的是：

长流程怎么编排
状态怎么在节点之间传
失败后怎么恢复
如何做 durable execution
如何插入 human-in-the-loop

1.3 两者不是替代关系，而是上下层关系

这点是最关键的。

当前官方文档已经把这个关系讲得很清楚：

LangChain 的 agents 是 built on top of LangGraph
LangGraph 可以单独使用，不依赖 LangChain
但 LangGraph 文档也明确说，通常会配合 LangChain 组件来接模型和工具

所以更合理的理解方式不是：

学 LangChain 还是学 LangGraph

而是：

你现在需要的是高层入口，还是底层控制力

2. 如何选型：什么时候用 LangChain，什么时候上 LangGraph

如果你只是想快速判断，我建议按下面这个逻辑来。

2.1 这些情况优先用 LangChain

你想快速起一个 agent demo
你需要统一接不同模型和工具
你还没有复杂状态流转需求
你更关心“先跑起来”，而不是“先做成可编排系统”

典型例子：

智能问答助手
调用几个工具的研究助理
简单 RAG 应用
单轮或短流程自动化

2.2 这些情况优先上 LangGraph

有明确的多步工作流
存在条件分支
任务需要回环
系统需要持久化状态
需要人工审批或人工纠偏
需要多 Agent 协作

典型例子：

Planner + Researcher + Writer + Reviewer
长周期任务执行
带人工审批的自动化流程
可恢复、可回放的 agent system

2.3 最常见的正确路径：先 LangChain，后 LangGraph

大多数团队并不是一开始就应该直接上 LangGraph。

更实际的路径通常是：

先用 LangChain 验证需求
当流程开始复杂化时，引入 LangGraph
再把原来分散的逻辑收拢成显式状态图

这个路径的好处是：

认知成本更低
交付更快
不会过早为复杂度买单

3. 当前官方“统一架构”到底统一了什么

这里我先明确一句，避免概念误伤：

截至 2026-04-14，我查到的官方稳定主线仍然是 LangChain 1.0 和 LangGraph 1.x，并不是已经正式进入一个公开稳定的 2.0 架构时代。

所以如果你说“2.0 统一架构”，更贴切的理解应该是：

这一代官方稳定设计，到底把哪些层统一了
LangChain 和 LangGraph 的分工现在是怎么收敛的

从官方 release / overview 文档来看，我认为有四个非常关键的统一点。

3.1 高层统一入口：`create_agent`

LangChain v1 把 create_agent 变成了标准高层入口。

这件事的意义在于：

你不再需要一开始就从低层 prebuilt graph 思维入手
Agent 的高层创建方式被统一了
LangChain 更明确承担“易用入口层”的角色

官方也明确提到，它替代了过去从 LangGraph 侧暴露出来的 create_react_agent 这种更偏过渡时代的入口。

3.2 模型层统一接口：provider-neutral model API

LangChain 现在非常强调“统一模型接口”。

也就是：

OpenAI
Anthropic
Google
其他 provider

尽量都走一致的调用体验。

这意味着在应用层，你更容易做到：

provider 切换
模型 AB test
结构化输出复用
tool calling 行为复用

3.3 内容层统一格式：content blocks

官方 v1 里把 content_blocks 作为一个重要统一方向提出。

它解决的是另一个非常现实的问题：

不同模型对文本、工具调用、多模态内容的返回格式并不一致
如果没有统一中间层，应用代码会越来越 provider-specific

content blocks 的意义，就是把现代模型返回内容抽象到一个更一致的消费形式上。

3.4 执行层统一到底座：LangChain agents built on LangGraph

这是我认为最关键的一点。

今天官方的关系已经不是：

LangChain 一套 agent
LangGraph 另一套 agent

而是：

LangChain 负责高层 agent abstraction
LangGraph 负责底层 agent runtime / orchestration

这意味着 durable execution、persistence、human-in-the-loop、streaming 这类能力，不再是两套世界观，而是逐步落在同一套分层里。

3.5 包与命名空间更清晰

LangChain v1 还做了一个非常务实的收敛：

langchain 聚焦当前主线能力
历史遗留和经典接口迁到 langchain-classic

这个变化很像一次“架构清淤”。

它的价值不在于名字，而在于官方终于更明确地告诉开发者：

现在推荐走哪条路
哪些东西是主线
哪些属于兼容历史

4. 一张图看懂当前关系

如果把当前官方主线简化成三层，我会这样画：

应用入口层：LangChain
负责快速接模型、工具、agent abstraction、provider 统一接口。
编排运行层：LangGraph
负责状态图、循环、持久化、人工介入、长期执行。
观测与生产层：LangSmith
负责 tracing、evaluation、observability、debugging。

也就是说，今天更推荐的认知方式是：

LangChain 不是 LangGraph 的对手
LangGraph 不是 LangChain 的升级版替代品
它们是同一代架构里不同层级的东西

5. LangChain 到底在解决什么问题

如果我们只调用一次模型接口，其实直接写 OpenAI SDK、Anthropic SDK 或者任意 HTTP 请求就够了。问题在于，真实业务很少只是一句输入、一句输出。

一个稍微像样点的 LLM 应用，通常都要处理下面这些问题：

Prompt 模板如何复用
模型调用如何替换
结构化输出如何约束
多步处理如何串联
外部知识如何接入
工具调用如何组织
状态、记忆、日志和调试如何管理

LangChain 的价值，本质上就在于把这些问题拆成标准组件，然后让我们通过“拼装”的方式完成应用开发，而不是从零开始手搓一套流程引擎。

可以把它理解成一句话：

LangChain 不是模型本身，而是围绕 LLM 应用开发的一层工程框架。

2. LangChain 生态怎么理解

现在的 LangChain 生态已经不像早期那样只是一个包，而是逐渐拆成了几层：

langchain-core
负责最核心的抽象，比如 Runnable、Prompt、Output Parser、Message 等。
langchain
提供常见链路封装和更高层的组合能力。
langchain-community
放各种社区集成，比如不同向量数据库、文档加载器、工具连接器。
langchain-openai
把 OpenAI 模型适配到 LangChain 的统一接口里。
langgraph
更适合做复杂 Agent、状态图、多节点工作流和带回环的执行流程。
langsmith
用于链路追踪、调试、评估和观测。

如果只做入门项目，通常你至少会接触到：

langchain
langchain-openai
langchain-community

如果要做生产级 Agent，基本就绕不开 langgraph 和 langsmith。

3. LangChain 最核心的几个概念

3.1 Model

Model 是最基础的一层，也就是你真正调用的大模型。

在 LangChain 里，常见的模型分两类：

ChatModel
面向对话消息输入输出，比如 GPT、Claude、Gemini 这类聊天模型。
LLM
更偏传统“纯文本输入输出”形式，现在实际项目里大多数场景都更常用 ChatModel。

一个最简单的例子如下：

from langchain_openai import ChatOpenAI

model = ChatOpenAI(
    model="gpt-4o-mini",
    temperature=0
)

resp = model.invoke("请用三句话介绍 LangChain")
print(resp.content)

这里的重点不是这几行代码，而是从这一步开始，模型就被包装进 LangChain 的统一调用接口里了，后面它就可以和 Prompt、Parser、Retriever、Tool 无缝串起来。

3.2 Prompt Template

Prompt 如果全都写死在字符串里，维护成本会非常高。LangChain 提供了模板化 Prompt 的能力。

from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_messages([
    ("system", "你是一名专业的 AI 工程讲师"),
    ("human", "请用通俗方式解释 {topic}，并给出一个简单例子")
])

这样做有两个好处：

Prompt 参数化了，便于复用
system / human / tool 等角色消息被显式建模，更接近真实对话接口

3.3 Output Parser

很多时候我们不希望模型只输出一段自然语言，而是希望它输出结构化数据，例如 JSON、列表、字段对象。

这时就需要 Output Parser。

1
2
3

from langchain_core.output_parsers import StrOutputParser

parser = StrOutputParser()

如果项目要进入自动化执行，结构化输出非常重要，因为“好看”不等于“可消费”。一个面向程序的 LLM 应用，最终一定要把输出转成程序真正能接住的数据结构。

3.4 Chain

所谓 Chain，可以理解成“把多个步骤串起来”。

早期 LangChain 强调各种 LLMChain、SequentialChain，现在更推荐的方式是 LCEL，也就是 LangChain Expression Language。

一个最简单的链写法如下：

from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI

prompt = ChatPromptTemplate.from_template("请用三点介绍 {topic}")
model = ChatOpenAI(model="gpt-4o-mini", temperature=0)
parser = StrOutputParser()

chain = prompt | model | parser

result = chain.invoke({"topic": "LangChain 的作用"})
print(result)

这行 prompt | model | parser 就是 LCEL 的核心味道。它的好处是：

组合关系直观
每个节点都可以单独替换
后期扩展成更复杂工作流时更自然

3.5 Runnable

Runnable 是现在 LangChain 很核心的底层抽象。你可以把它理解成：

任何“能接收输入并产出输出的组件”，都可以被当成 Runnable 来组合。

Prompt 是 Runnable，Model 是 Runnable，Parser 也是 Runnable。正因为它们都遵守统一协议，所以链路可以拼起来。

这是 LangChain 从“工具箱”走向“组合框架”的关键。

3.6 Retriever

如果模型不知道你的私有知识，就需要先检索再生成。Retriever 就是 RAG 流程里的“查资料”组件。

经典链路是：

用户提问
向量检索召回相关文档
把召回结果拼进 Prompt
模型基于上下文回答

Retriever 本身不负责生成答案，它只负责把合适的上下文捞出来。

3.7 Tool

Tool 是 Agent 场景的关键。它让模型不只是“说”，还可以“做”。

常见 Tool 包括：

搜索网页
查数据库
调用内部 API
运行 Python
读写文件
发消息、发邮件、调日历

只要 Tool 定义清楚输入、输出和用途，模型就可以在推理过程中决定是否调用它。

3.8 Memory

早期 LangChain 很强调 Memory，但现在大家会更谨慎地看待它。

因为所谓“记忆”在工程上其实分很多层：

会话上下文
短期任务状态
用户画像
长期知识沉淀

所以今天更好的理解方式不是“有没有 Memory”，而是：

你的系统希望记住什么，记多久，存在哪里，谁能读到，什么时候该被清除。

在简单对话里，Memory 可能只是消息历史；在复杂 Agent 里，它更像状态管理加长期存储。

4. LangChain 最推荐的思维方式：先链，后 Agent

很多人一上来就想做 Agent，但经验上看，真正稳定的 LLM 应用往往不是先做 Agent，而是先把确定性流程搭出来。

建议顺序通常是：

单次模型调用
Prompt + 输出解析
多步链式处理
检索增强
工具调用
Agent 化

原因很简单：

链更稳定
链更容易调试
链更适合明确业务流程
不是所有问题都值得上 Agent

如果一个任务的步骤本来就清楚，硬上 Agent 往往只会增加不确定性和调试成本。

5. LangChain 怎么安装和起步

一个最小可用环境通常如下：

1	pip install -U langchain langchain-openai langchain-community

配置环境变量：

1	export OPENAI_API_KEY="your_api_key"

最小可运行示例：

from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

model = ChatOpenAI(model="gpt-4o-mini", temperature=0)

prompt = ChatPromptTemplate.from_template(
    "你是一名 AI 助手，请用简洁语言回答：{question}"
)

chain = prompt | model | StrOutputParser()

print(chain.invoke({"question": "LangChain 和直接调用 OpenAI API 有什么区别？"}))

这已经是一个非常标准的 LangChain 入门骨架了。

6. 一个稍微完整点的基础案例

下面做一个“文章摘要器”，让模型输出结构化摘要。

from typing import TypedDict

from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI


class Summary(TypedDict):
    title: str
    highlights: list[str]
    conclusion: str


model = ChatOpenAI(model="gpt-4o-mini", temperature=0)
structured_model = model.with_structured_output(Summary)

prompt = ChatPromptTemplate.from_template(
    """
    你是一名技术编辑，请阅读下面内容并提炼结构化摘要。

    内容：
    {article}
    """
)

chain = prompt | structured_model

result = chain.invoke({
    "article": "LangChain 是一个围绕大模型应用开发的工程框架，强调组件化、可组合与可维护性。"
})

print(result)

这个例子比纯文本输出更接近工程实战，因为它已经开始体现两个非常重要的思想：

Prompt 负责表达任务
结构化输出负责保证程序可消费

7. LangChain 与 RAG 的关系

很多人会把 LangChain 和 RAG 画等号，其实不完全对。

RAG 是一种应用模式，LangChain 是实现这种模式的工程框架之一。

一个典型 RAG 流程可以拆成：

文档加载
文本切分
向量化
建索引
检索召回
拼接上下文
模型生成答案

LangChain 在这些环节里都提供了相应抽象，所以做 RAG 会非常顺手。

一个简单示意代码如下：

from langchain.chains import create_retrieval_chain
from langchain.chains.combine_documents import create_stuff_documents_chain
from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

prompt = ChatPromptTemplate.from_template(
    """
    请基于以下上下文回答问题。
    如果上下文无法支持答案，请明确说明。

    上下文：
    {context}

    问题：
    {input}
    """
)

doc_chain = create_stuff_documents_chain(llm, prompt)

# retriever 需要由向量库创建，这里省略
# chain = create_retrieval_chain(retriever, doc_chain)

你会发现，LangChain 的价值不是替你发明 RAG，而是帮你把 RAG 的每个节点标准化。

8. LangChain 和 LangGraph 是什么关系

这是现在非常容易混淆的一点。

我的理解是：

LangChain 更适合表达组件组合和基础链路
LangGraph 更适合表达有状态、可回环、可中断、可恢复的 Agent 工作流

如果你的应用只是：

Prompt 组合
检索增强
数据抽取
简单工具调用

那么 LangChain 就够用了。

如果你的应用开始出现下面这些特征：

多节点状态流转
条件分支
重试和回环
人类审批节点
多 Agent 协作

那 LangGraph 会比单纯 LangChain 更合适。

简单说：

LangChain 解决“怎么拼组件”，LangGraph 解决“怎么管理复杂状态流”。

9. 初学 LangChain 最容易踩的坑

9.1 一开始就做万能 Agent

这是最常见的问题。很多项目并不需要自主规划，只需要一条清晰的工作流。

9.2 只关注模型，不关注输出契约

应用系统最终是要给程序消费的，不是只给人读的。结构化输出、字段校验、异常兜底非常重要。

9.3 Prompt、检索、工具、状态混在一起

如果这些层没有拆开，后面几乎必然越来越难维护。

9.4 没有观测与日志

LLM 应用出问题时，最怕的是“不知道它为什么这么回答”。链路追踪、输入输出记录、工具调用日志都很重要。

9.5 把 Memory 当成魔法

记忆不是“越多越好”，而是“合适的信息在合适的时候出现”。

10. 我对 LangChain 的实践建议

如果你是第一次做 LangChain 项目，我建议按下面这个顺序来：

先写一个单轮问答链
再加 PromptTemplate
再加结构化输出
再加检索
最后再决定要不要加 Agent

一个成熟项目里，往往真正稳定可靠的部分，反而不是最“智能”的那部分，而是边界最清晰、输入输出最可控的那部分。

所以 LangChain 真正值得学的，不只是 API 怎么写，而是它背后的工程思想：

把步骤拆开
把职责分清
把状态显式化
把不确定性关进边界里

12. 小结

这一篇我们主要做了四件事：

解释 LangChain 为什么存在
说明 LangChain 生态的基本分层
梳理 Model、Prompt、Parser、Retriever、Tool、Memory、Chain 等核心概念
给出基础代码示例和学习路径

如果只记住一句话，我更希望是这句：

LangChain 不是“让模型更聪明”的框架，而是“让 LLM 应用更可工程化”的框架。

下一篇会先把 LangGraph 单独拆开讲透。因为一旦开始做复杂工作流、状态机、条件分支和多 Agent 协作，LangGraph 基本就是绕不过去的一层。等把这层讲清楚之后，第三篇再回到 Agent 实战，就会更容易理解 L2、L3、L4 以及 OpenClaw 这类 computer-use agent 的差异。

13. 参考资料

LangChain 官方 overview：https://docs.langchain.com/oss/python/langchain/overview
LangGraph 官方 overview：https://docs.langchain.com/oss/python/langgraph/overview
LangChain v1 更新说明：https://docs.langchain.com/oss/python/releases/langchain-v1
LangChain / LangGraph versioning：https://docs.langchain.com/oss/python/versioning

AIGC-Agent-LangChain开发（上）LangChain、LangGraph区别与基础入门