第 04 篇的 ReAct 是「走一步看一步」。对于简单任务这已经足够，但面对步骤多、跨度长的任务，只看眼前一步很容易迷失方向。这一篇讲 Agent 如何规划、如何检查自己的工作，以及什么时候不该规划。

一、为什么需要规划

设想一个任务：「分析上个季度的销售数据，找出增长最快和下滑最快的品类，分析原因，写一份报告。」

如果只用 ReAct，Agent 可能查完第一个品类就开始深挖，忘了还要比较其他品类；或者分析到一半，忘了最后要写报告。任务越长，越容易出现这些问题：

• 遗漏：忘了任务的某个部分。
• 跑偏：在某个细节上花太多步数。
• 重复：忘了已经做过什么，又做一遍。

规划的作用就是给 Agent 一张地图。

二、任务分解的几种方式

1. 先计划后执行（Plan-and-Execute）

先让模型列出完整步骤，再逐步执行：

计划：
1. 查询上季度各品类销售额及环比变化
2. 找出增长和下滑最快的各 3 个品类
3. 分别查询这 6 个品类的价格、库存、促销记录
4. 分析变化原因
5. 撰写报告

优点是结构清晰，执行前可以让人审核计划；缺点是计划可能和实际情况不符。

2. 动态待办列表

给 Agent 一个待办列表工具，它可以随时添加、勾选、修改任务项。开始时列一个粗略计划，执行过程中根据新发现调整。这是目前很多 Agent 产品采用的方式，兼顾了结构和灵活性。

待办列表还有一个附带好处：它是 Agent 进度的可视化，用户可以一眼看到做到了哪里。

3. 分层分解

复杂任务先拆成几个大的子任务，每个子任务再细分。子任务可以交给子 Agent 独立完成（下一篇讲）。

三、反思与自检

人做完一件事会检查一遍，Agent 也应该如此。常见做法：

• 步骤后检查：每完成一步，判断结果是否符合预期，是否需要调整计划。
• 完成前检查：给出最终结果前，对照原始需求逐项核对，有没有遗漏。
• 用事实验证：写完代码就运行测试，算完数据就用另一种方式交叉验证。能用客观手段检查的，就不要只靠模型「觉得」对了。

避免「自己给自己打分」

让同一个模型在同一段上下文里检查自己的工作，效果有限：它刚刚说服了自己，往往会认为结果没问题。更好的做法：

• 用一个新的上下文来检查，只给它需求和结果，不给推导过程；
• 给检查者明确的检查清单，而不是笼统地问「这样对吗」；
• 尽可能用代码、测试、数据核对等客观手段。

四、适度原则：什么时候不规划

规划有成本：多一次模型调用，多一段上下文，多一些延迟。以下情况不需要显式规划：

• 任务只需要一两步就能完成；
• 任务本质上是探索性的，下一步完全取决于上一步的发现，比如排查一个未知原因的故障；
• 模型本身足够强，在简单任务上自然能把握方向。

另外，计划必须可以被推翻。执行中发现原计划不对，应该果断修改，而不是硬着头皮执行下去。在 System Prompt 里明确告诉模型这一点。

五、规划与人的协作

对于代价高、不可逆的任务，计划阶段是让人参与的最好时机：

• Agent 先出计划，人审核确认后再执行；
• 人可以在计划阶段补充信息、修正方向，比执行完再返工便宜得多；
• 执行中遇到计划外的重大决策，暂停并询问。

本篇小结

• 规划解决长任务中的遗漏、跑偏、重复。
• 方式：先计划后执行、动态待办列表、分层分解。
• 自检：步骤后检查、完成前核对、用客观手段验证，避免在同一上下文里自评。
• 简单任务和探索性任务不必规划；计划要能推翻。
• 高代价任务在计划阶段引入人工审核。

思考与练习

• 把「排查网站下单量突降」拆成可执行的步骤。哪些步骤的顺序是固定的，哪些要根据结果决定？
• 设计一个检查清单，用来让独立的检查者核对一份数据分析报告。

上一篇：AI Agent原理篇09：RAG：检索增强生成原理
下一篇：AI Agent原理篇11：多 Agent 协作：编排、子 Agent 与交接
返回系列总目录