LangGraph 初识：Agent 为什么要采用 Graph 工作流？

天气查询这类简单任务，通常只需让模型调用一次工具即可完成；但旅游规划等复杂需求往往包含搜索、预算检查、方案修改和用户确认等多个环节。随着执行路径不断变化，单一 Agent 的上下文和决策压力也会增加，这正是 LangGraph 用图结构管理状态与流程所要解决的问题。

核心问题：

为什么已经有 LangChain Agent 了，还需要 LangGraph？

---

1. Agent 为什么越来越复杂？

先回顾普通 Agent：

用户输入

↓

LLM 思考

↓

调用 Tool

↓

返回结果

简单任务没问题。

例如：

查询天气

流程：

用户
 ↓
天气 Tool
 ↓
结果

---

但是实际 Agent：

比如：

帮我完成一次旅游规划

可能需要：

理解需求

↓

搜索资料

↓

制定计划

↓

检查预算

↓

修改方案

↓

等待用户确认

↓

执行

这已经不是一次 Tool 调用了。

它变成：

一个不断变化的工作流。

---

2. LangChain Agent 的问题

LangChain 传统 Agent 更像：

LLM
 |
决定下一步
 |
Tool
 |
结果
 |
继续思考

所有逻辑都交给一个 Agent。

问题：

2.1 上下文越来越大

单 Agent：

System Prompt

+
所有 Tool 描述

+
所有规则

+
所有技能

例如：

一个 Agent 有：

• 搜索
• 数据库查询
• 邮件发送
• 文件处理

但用户只是问：

查订单

结果：

数据库查询相关的信息只有一点。

但是：

所有 Tool 描述都塞进去。

问题：

• token 增加
• 无关信息干扰
• 决策质量下降

---

3. 多 Agent 为什么出现？

拆分：

              主 Agent

                  |

      ----------------------

      |          |          |

  搜索Agent   数据Agent   邮件Agent

每个 Agent：

只负责自己的领域。

例如：

搜索 Agent：

搜索相关 Prompt
搜索 Tool
搜索规则

数据库 Agent：

SQL
Schema
查询规则

优点：

• 上下文更小
• 推理更准确
• 更容易维护

---

4. LangGraph 的核心思想

LangGraph 不关注：

让一个 Agent 无限思考。

它关注：

如何组织 Agent 的执行流程。

把流程变成 Graph：

START

 ↓

Router

 ↓

 ┌────────┐
 ↓        ↓

Search   Database

 ↓        ↓

   Result

      ↓

     END

这里：

节点：

Node

负责执行任务。

连接：

Edge

负责控制流程。

数据：

State

负责保存中间结果。

---

5. Graph 是什么？

Graph：

就是：

节点 + 边

例如：

A -----> B -----> C

在 LangGraph：

A/B/C：

就是 Node。

箭头：

就是 Edge。

---

6. State 是什么？

所有节点共享的数据。

例如：

旅游规划：

{
 destination:"",
 budget:"",
 plan:[]
}

流程：

第一个节点：

return {
 destination:"东京"
}

第二个节点：

读取：

state.destination

继续生成方案。

所以：

State 是 Agent 工作流中的共享上下文。

---

7. LangGraph 第一印象

最终：

             State

               ↓

Node → Edge → Node → Edge → Node


               ↓

          最终结果

LangGraph 提供：

• 状态管理
• 流程编排
• 条件分支
• 循环
• 暂停恢复

让 Agent 从：

一个会思考的函数

变成：

一个可控制的工作流系统

---

总结

一句话：

LangGraph 是一个基于 Graph 结构编排 Agent 工作流的框架，它通过 State 保存上下文，通过 Node 执行业务逻辑，通过 Edge 控制执行路径，让复杂 Agent 支持分支、循环、记忆和人工介入。