从 LangChain 到 LangGraph的新手入门指南
目录
六、总结：LangChain 与 LangGraph 的定位
随着大语言模型（LLM）的快速发展，AI 应用已经从简单的问答机器人，逐渐演变为能够自主规划、调用工具、执行任务的智能 Agent。
但是，当 Agent 的能力越来越复杂时，一个新的问题出现了：
如何管理一个复杂 Agent 的执行流程？
例如，一个智能客服 Agent，可能需要：
-
判断用户意图；
-
查询知识库；
-
调用外部工具；
-
分配给不同专业 Agent；
-
判断回答质量；
-
失败后自动重试；
-
保留多轮对话上下文。
如果这些逻辑全部依靠传统代码实现，很快就会陷入大量 if-else 和状态管理中。
而 LangGraph，就是为了解决这个问题而诞生的。
一、LangChain 与 LangGraph 的区别
很多初学者容易混淆 LangChain 和 LangGraph。
简单来说：
LangChain 负责提供构建大模型应用的基础能力，而 LangGraph 负责管理复杂 Agent 的执行流程。
LangChain：大模型应用开发工具库
LangChain 更像一个大模型应用开发框架，它提供了大量基础组件，例如：
-
LLM 模型调用；
-
Prompt 模板管理；
-
Tool 工具调用；
-
Memory 记忆管理；
-
RAG 检索增强；
-
Agent 基础能力。
它解决的问题是：
如何方便地调用大模型，并组合各种 AI 能力。
例如：
用户输入
↓
Prompt模板
↓
调用LLM
↓
返回结果
这种简单流程，LangChain 完全可以满足。
LangGraph：Agent 工作流编排框架
但是，当 Agent 变复杂以后，简单 Chain 模式就会出现问题。
例如：
一个智能客服：
用户输入
↓
判断问题类型
↓
查询知识库
↓
生成答案
↓
检查答案质量
↓
返回结果
看起来很简单。
但是实际业务中可能出现：
-
用户需要多轮交流才能确定需求；
-
技术问题交给技术 Agent；
-
售后问题交给售后 Agent；
-
回答质量低需要重新生成；
-
检索失败需要重新搜索；
-
不同条件进入不同执行路径。
这时候流程可能变成：
技术问题
↓
用户输入 → 意图判断
↓
售后问题
回答质量不足？
↓
重新检索
↓
重新生成
传统代码通常会变成：
if 用户问题属于技术问题:
调用技术Agent
elif 用户问题属于售后问题:
调出售后Agent
if Agent回答质量低:
重新检索知识库
再次生成答案
if 用户继续提问:
保存上下文
本质上，我们其实是在：
手动编写一个状态机。
随着业务扩大，这种方式会越来越难维护。
二、LangGraph 的核心思想：用图管理 Agent
LangGraph 的核心思想非常简单：
把复杂 Agent 流程抽象成一个 Graph（图）。
一个 Graph 由三个核心部分组成：
-
State（状态）
-
Node（节点）
-
Edge（边）
整体结构：
Node
↓
Edge → Node → Edge
↑
State
三、LangGraph 三个核心组件
1. State：整个 Agent 的共享状态
State 是 LangGraph 最核心的数据结构。
可以理解为：
整个 Agent 工作流运行过程中的共享上下文。
例如：
{
"user_input": "如何退款？",
"user_type": "会员用户",
"intent": "售后问题",
"history_messages": [],
"search_result": "",
"answer": "",
"confidence": 0.8
}
整个流程中的所有 Node，都可以读取和修改 State。
例如：
用户输入：
我的订单为什么还没有发货？
进入意图识别节点：
读取：
state["user_input"]
分析得到：
intent = "物流咨询"
然后更新 State：
{
"intent":"物流咨询"
}
之后物流 Agent 就可以根据这个状态继续执行。
传统代码：
functionA(data):
functionB(data)
每个函数之间手动传递参数。
而 LangGraph：
Node A
↓
修改 State
↓
Node B读取 State
所有节点围绕同一个状态协作。
State 也是 Agent 的记忆
除了保存当前流程信息，State 还承担了上下文记忆功能。
例如：
第一轮：
用户：
我的订单什么时候到？
State：
{
"order_id":123
}
第二轮：
用户：
如果明天不到怎么办？
Agent 可以通过 State 知道：
-
当前讨论的是订单 123；
-
当前主题是物流问题。
因此能够理解上下文。
2. Node：执行具体任务的节点
Node 可以理解为：
一个完成特定功能的函数。
例如：
-
意图识别 Node；
-
RAG 检索 Node；
-
工具调用 Node；
-
数据库查询 Node；
-
Agent 推理 Node；
-
回复生成 Node。
例如：
def search_node(state):
result = search_database(
state["question"]
)
state["search_result"] = result
return state
这个 Node 做三件事情：
-
从 State 获取用户问题；
-
调用数据库查询；
-
将结果写回 State。
多个 Node 组合：
用户输入
↓
意图识别 Node
↓
知识库检索 Node
↓
答案生成 Node
↓
质量检查 Node
每个节点职责单一。
这样：
-
容易维护；
-
容易复用；
-
容易扩展。
3. Edge：控制流程流转
Edge 表示：
当前节点执行完成后，下一步应该去哪里。
LangGraph 中主要有两种 Edge。
普通边（Normal Edge）
表示固定流程。
例如：
用户输入
↓
问题分类
↓
知识库搜索
↓
生成答案
执行路径固定。
条件边（Conditional Edge）
表示根据状态动态选择下一步。
例如：
技术问题
↓
用户分类 Node
↓
售后问题
代码：
def router(state):
if state["intent"]=="技术问题":
return "tech_agent"
elif state["intent"]=="售后问题":
return "service_agent"
LangGraph 会根据返回结果选择对应 Node。
这也是 LangGraph 相比普通 Chain 最大的区别：
LangChain 更像：
A → B → C → D
固定流水线。
而 LangGraph 可以表达：
B
↗
A → 判断
↘
C
↓
D
↑
|
重试
它可以描述：
-
分支；
-
循环；
-
回退；
-
多 Agent 协作。
四、如何理解 LangGraph 的本质？
我认为 LangGraph 可以理解为：
一个专门用于管理 LLM Agent 执行流程的状态机框架。
传统程序：
代码控制流程
+
变量保存状态
LangGraph：
Graph控制流程
+
State保存状态
+
LLM负责智能决策
它并不是替代代码。
而是：
把复杂 Agent 中最难维护的流程控制部分抽象出来。
五、一个真实 Agent 示例
例如智能客服 Agent：
用户输入
↓
意图识别 Node
↓
┌───────────┴───────────┐
↓ ↓
技术 Agent 售后 Agent
↓ ↓
└───────────┬───────────┘
↓
质量检查 Node
↓
置信度判断
↓ ↓
是 否
↓ ↓
重新检索 返回答案
这个系统包含：
-
状态共享；
-
条件分支；
-
循环执行；
-
多 Agent 协作；
-
错误恢复。
这正是 LangGraph 最擅长解决的问题。
六、总结：LangChain 与 LangGraph 的定位
一句话总结：
LangChain 解决的是“大模型能力如何调用”的问题。
例如：
-
怎么调用 GPT；
-
怎么设计 Prompt；
-
怎么连接工具；
-
怎么做 RAG。
而：
LangGraph 解决的是“多个大模型能力如何组织协作，并控制复杂执行流程”的问题。
如果你的应用只是：
用户问题
↓
LLM回答
那么 LangChain 足够。
但如果你的应用变成：
用户
↓
判断任务
↓
多个Agent协作
↓
调用工具
↓
检查结果
↓
失败重试
↓
持续对话
那么 LangGraph 才是真正适合的方案。
未来的 AI 应用，大概率不会只是简单调用一个大模型，而会变成多个 Agent、工具和流程共同协作的复杂系统。
而 LangGraph，就是帮助开发者构建这些复杂 Agent 系统的重要基础设施。
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
0
0- 0
已为社区贡献3条内容
所有评论(0)