核心问题:
为什么已经有 LangChain Agent 了,还需要 LangGraph?
1. Agent 为什么越来越复杂?
先回顾普通 Agent:
用户输入
↓
LLM 思考
↓
调用 Tool
↓
返回结果
简单任务没问题。
例如:
查询天气
流程:
用户
↓
天气 Tool
↓
结果
但是实际 Agent:
比如:
帮我完成一次旅游规划
可能需要:
理解需求
↓
搜索资料
↓
制定计划
↓
检查预算
↓
修改方案
↓
等待用户确认
↓
执行
这已经不是一次 Tool 调用了。
它变成:
一个不断变化的工作流。
2. LangChain Agent 的问题
LangChain 传统 Agent 更像:
LLM
|
决定下一步
|
Tool
|
结果
|
继续思考
所有逻辑都交给一个 Agent。
问题:
2.1 上下文越来越大
单 Agent:
diff
System Prompt
+
所有 Tool 描述
+
所有规则
+
所有技能
例如:
一个 Agent 有:
- 搜索
- 数据库查询
- 邮件发送
- 文件处理
但用户只是问:
查订单
结果:
数据库查询相关的信息只有一点。
但是:
所有 Tool 描述都塞进去。
问题:
- token 增加
- 无关信息干扰
- 决策质量下降
3. 多 Agent 为什么出现?
拆分:
markdown
主 Agent
|
----------------------
| | |
搜索Agent 数据Agent 邮件Agent
每个 Agent:
只负责自己的领域。
例如:
搜索 Agent:
搜索相关 Prompt
搜索 Tool
搜索规则
数据库 Agent:
sql
SQL
Schema
查询规则
优点:
- 上下文更小
- 推理更准确
- 更容易维护
4. LangGraph 的核心思想
LangGraph 不关注:
让一个 Agent 无限思考。
它关注:
如何组织 Agent 的执行流程。
把流程变成 Graph:
sql
START
↓
Router
↓
┌────────┐
↓ ↓
Search Database
↓ ↓
Result
↓
END
这里:
节点:
Node
负责执行任务。
连接:
Edge
负责控制流程。
数据:
State
负责保存中间结果。
5. Graph 是什么?
Graph:
就是:
节点 + 边
例如:
css
A -----> B -----> C
在 LangGraph:
A/B/C:
就是 Node。
箭头:
就是 Edge。
6. State 是什么?
所有节点共享的数据。
例如:
旅游规划:
css
{
destination:"",
budget:"",
plan:[]
}
流程:
第一个节点:
kotlin
return {
destination:"东京"
}
第二个节点:
读取:
state.destination
继续生成方案。
所以:
State 是 Agent 工作流中的共享上下文。
7. LangGraph 第一印象
最终:
markdown
State
↓
Node → Edge → Node → Edge → Node
↓
最终结果
LangGraph 提供:
- 状态管理
- 流程编排
- 条件分支
- 循环
- 暂停恢复
让 Agent 从:
一个会思考的函数
变成:
一个可控制的工作流系统
总结
一句话:
LangGraph 是一个基于 Graph 结构编排 Agent 工作流的框架,它通过 State 保存上下文,通过 Node 执行业务逻辑,通过 Edge 控制执行路径,让复杂 Agent 支持分支、循环、记忆和人工介入。