引言：为什么 ReAct 在复杂任务里开始“不够用”？

前面我们已经深入学习了 ReAct Agent：

Thought → Action → Observation

它最大的特点是：

一边思考，一边行动。

这种模式在：

• 天气查询
• 简单搜索
• Tool 调用
• 小型自动化

里表现非常优秀。

但当任务开始变复杂时，问题就出现了。

例如：

帮我做一份 AI Agent 行业调研报告：
1. 搜索最新行业趋势
2. 分析主要公司
3. 对比产品能力
4. 生成总结报告

如果让 ReAct 直接开始：

边想边做

它经常会出现：

• 做着做着跑偏
• 遗漏步骤
• 顺序混乱
• 重复调用 Tool
• 上下文越来越乱

原因很简单：

ReAct 擅长“即时决策”，但不擅长“整体规划”。

于是，Planning Agent 开始出现。

---

一、什么是 Planning Agent？

一句话理解：

Planning Agent 会先制定计划，再执行任务。

核心思想：

先想清楚“怎么做”
再一步步执行

而不是：

边做边想

---

二、Planning Agent 为什么重要？

因为现实世界的大多数任务：

不是一步完成的

例如：

---

1. 数据分析

查询数据
→ 清洗数据
→ 统计分析
→ 生成图表
→ 输出报告

---

2. 自动化办公

读取邮件
→ 提取任务
→ 查询数据库
→ 生成日报
→ 发送邮件

---

3. 软件开发 Agent

分析需求
→ 拆解模块
→ 编写代码
→ 运行测试
→ 修复 Bug

---

三、ReAct 的核心问题（为什么需要 Planning）

ReAct 最大的问题不是“不聪明”。

而是：

缺少全局视角

它每一轮只考虑：

下一步该做什么？

但不会提前思考：

整个任务应该如何拆解？

---

四、典型问题：ReAct 为什么容易跑偏？

例如：

帮我调研 DeepSeek 和 OpenAI 的 Agent 平台差异。

ReAct 可能：

1. 搜索 DeepSeek
2. 搜索 OpenAI
3. 又搜索 DeepSeek
4. 开始介绍 GPT 历史
5. 忘记做对比

因为：

它没有“整体任务结构”

---

五、Planning Agent 的核心思想

Planning Agent 会先做：

Task Decomposition（任务分解）

例如：

任务：调研 Agent 平台

Plan：
1. 搜索 DeepSeek Agent 能力
2. 搜索 OpenAI Agent 能力
3. 提取核心功能
4. 对比价格与模型
5. 输出总结

然后：

按计划逐步执行

---

六、Plan-and-Execute 模式（核心）

Planning Agent 最经典模式：

Plan-and-Execute

流程：

用户问题
↓
Planner（生成计划）
↓
Executor（逐步执行）
↓
汇总结果

---

七、Plan-and-Execute 的核心结构

它通常由两个 Agent 组成：

角色	职责
Planner	负责拆解任务
Executor	负责执行步骤

---

Planner 示例

输入：

帮我做 AI Agent 行业分析

输出：

1. 搜索行业趋势
2. 搜索主要厂商
3. 分析产品能力
4. 总结市场方向

---

Executor 示例

执行：

Step1 → 搜索
Step2 → 搜索
Step3 → 分析
Step4 → 总结

---

八、ReAct vs Plan-and-Execute（核心对比）

这是最重要的一部分。

---

维度	ReAct	Plan-and-Execute
核心思想	边想边做	先规划再执行
任务结构	动态	结构化
适合任务	简单 / 即时	复杂 / 多步骤
Tool 调用	即时决定	按计划执行
灵活性	高	中
稳定性	中	高
Token 消耗	较低	较高

---

九、用一句话理解差异（非常重要）

ReAct：下一步做什么？
Planning：整个任务怎么完成？

---

十、Planning 为什么更稳定？

因为它：

先拆任务
再执行

这样会减少：

• 漏步骤
• 重复调用
• 跑偏
• 无限循环

---

十一、Planning 的代价（必须知道）

Planning 并不是“全面优于 ReAct”。

它也有缺点。

---

1. Token 成本更高

因为多了一次：

生成 Plan

---

2. 延迟更高

流程变成：

Plan → Execute

而不是直接执行。

---

3. Plan 可能错误

如果 Planner 拆错：

后面全部跟着错

---

4. 灵活性降低

ReAct：

边执行边调整

Planning：

按计划执行

---

十二、2026 年为什么 Planning Agent 越来越重要？

因为 Agent 正在从：

聊天助手

升级为：

任务执行系统

例如：

• AI 员工
• AI 研究员
• AI 编程 Agent
• AI 自动化系统

这些任务通常：

步骤复杂 + 时长较长

所以：

必须具备 Planning 能力。

---

十三、现实中的 Planning Agent 示例

1. AI 编程 Agent

例如：

• 需求分析
• 文件规划
• 编码
• 测试
• 修复

---

2. AI 研究 Agent

例如：

• 搜索论文
• 提取摘要
• 对比实验
• 生成报告

---

3. AI 办公自动化

例如：

• 读取邮件
• 提取任务
• 调用 API
• 更新数据库

---

十四、Planning Agent 与 LangGraph（重要）

为什么 LangGraph 特别适合 Planning？

因为：

Planning 本质是：
复杂状态 + 多步骤执行

而 LangGraph 天生支持：

• State
• 多 Node
• Conditional Edge
• 长流程控制

所以：

LangGraph 非常适合构建 Planning Agent。

---

十五、Planning Agent 的典型结构

后面几篇我们会逐步实现：

START
 ↓
Planner Node
 ↓
生成任务列表
 ↓
Executor Node
 ↓
执行步骤
 ↓
更新状态
 ↓
是否完成？
 ↓
END

---

十六、一个非常重要的认知升级

很多人觉得：

Agent = Tool Calling

其实这只是第一阶段。

真正高级的 Agent：

不是“会调用工具”

而是：

会拆解复杂任务
会组织执行流程

这才是 Planning Agent 的意义。

---

十七、什么时候应该用 Planning？

适合：

✔ 多步骤任务
✔ 长任务
✔ 有明确阶段
✔ 容易遗漏步骤
✔ 需要结构化输出

不适合：

✘ 简单问答
✘ 单次 Tool 调用
✘ 即时查询

---

结语

一句话总结：

ReAct 擅长“即时行动”，Planning 擅长“整体组织”。

这一篇你已经理解了：

• 为什么需要 Planning
• ReAct 的局限
• Plan-and-Execute 核心思想
• Planner / Executor 架构
• Planning Agent 的应用场景

接下来，我们会真正开始：

用 LangGraph 构建 Planning Agent