给 AI Agent 一个目标，比如“分析一批客户反馈，找出主要问题并生成报告”，它需要决定先读哪些数据、怎样分组、什么时候补充信息，以及什么结果才算完成。
这些决策组成了 Agent 的规划过程。把目标写成几条待办，只完成了其中一部分。真正进入执行后，还要处理依赖、失败、环境变化和权限边界。
理解 Agent Plan，可以沿着四个问题展开：计划怎样产生，执行怎样推进，偏离后怎样修正，系统允许它走到哪里。先规划再执行、反馈与重规划、多路径搜索、SOP 与状态机，分别提供了不同的处理方法。它们可以组合使用，不是一套互斥的标准分类。[1][2]
1. 计划要回答哪些问题
以“分析客户反馈”为例，一份粗略计划可能是：读取反馈、归纳问题、生成报告。
这份计划便于展示进度，却不足以直接驱动执行。读取哪个时间段的数据？归纳结果是否需要保留原始反馈编号？没有足够证据的问题能否进入报告？遇到权限不足，是重试还是暂停？
设计可执行计划时，可以为每个任务记录：
- 具体目标和输入来源。
- 依赖哪些前置任务。
- 允许调用的工具及权限。
- 预期产物和验收条件。
- 失败后的处理方式。
例如，下面是一个示意性任务结构，不对应某个框架的固定接口：
{
"id": "cluster_feedback",
"depends_on": ["load_feedback"],
"input_ref": "artifacts.feedback",
"allowed_tools": ["analyze_text"],
"expected_output": "带原始反馈编号的问题分组",
"acceptance": [
"每条输入都有明确归属或被标记为未分类",
"每组结论能追溯到原始反馈"
],
"on_failure": "保留已完成结果，提交失败原因"
}
这里的 acceptance 仍然需要执行器或验证器落实。把验收条件写进 JSON，不等于系统已经会检查它。
LangChain 介绍的 LLMCompiler 就把工具、参数和依赖放进任务图，由调度器在依赖满足后执行任务。这说明规划的输出可以是供程序调度的数据结构，而不只是自然语言清单。[2]
2. Plan-and-Execute：把规划与执行分开
Plan-and-Execute 的基本结构是由 Planner 生成多步骤计划，再交给 Executor 执行。一个执行任务可以包含多次工具调用，也可以由局部 Agent 完成。[2]
例如，客户反馈分析可以先生成这样的计划：
- 获取指定时间范围的反馈。
- 清理重复记录，保留原始编号。
- 对问题进行分组。
- 汇总频率并选取代表性案例。
- 生成报告，检查结论是否有数据支持。
它适合“目标清楚、任务可以提前拆解”的场景。显式计划也便于检查是否漏掉必要步骤。
规划器和执行器是两种职责，不要求它们必须使用不同模型。可以让能力较强的模型规划，再让小模型处理简单子任务；也可以使用同一个模型，甚至把某些步骤交给普通程序。节省成本的前提是子任务确实能由更便宜的执行方式完成。[2]
代价在于前期规划本身需要时间。如果计划基于错误假设，后续步骤会受影响。任务越依赖尚未取得的信息，就越不适合提前把所有细节写死。
一种设计办法是先确定阶段目标，把下一阶段的操作留到取得结果后再细化。例如，先读取代码库并定位问题，再根据实际结构安排修改，而不是在没有读代码时猜出所有文件路径。
它与 ReAct 的关系
ReAct 把推理与行动交织起来，根据环境反馈决定下一步。它同样包含规划和调整，只是通常没有把完整计划作为一个独立产物交出来。[3]
两者可以嵌套：外层 Planner 安排“定位问题、修改、测试、交付”，内层 Executor 采用 ReAct，在定位阶段反复读文件、搜索符号和检查调用链。
因此，选择显式计划还是逐步决策，重点是任务需要多大范围的预先协调。无需把它们理解为两种只能选一个的能力。
3. 反馈与动态重规划：执行结果改变后面的路
计划形成时，Agent 掌握的信息有限。工具执行后，新的事实可能使剩余计划失效。
比如，原计划要求读取整月反馈，但数据源只保留最近七天。系统应先记录数据缺口，再决定改用备用来源、缩小分析范围，或等待补充数据。继续生成“整月报告”会把计划中的假设当成事实。
LangChain 的 Plan-and-Execute 示例已经包含重新规划环节：根据执行结果决定结束，或生成后续计划。因此，动态重规划可以直接加入 Plan-and-Execute，不必另建一种完全不同的架构。[2]
flowchart TD
A[目标与约束] --> B[生成或更新计划]
B --> C[执行任务]
C --> D[验证结果]
D -->|继续| C
D -->|需要调整| B
D -->|条件满足| E[交付]
D -->|需要授权或补充信息| F[暂停等待]
重试、重规划和反思处理的是不同问题
接口暂时超时，原来的方法仍然合理，可以做有限重试。数据源不存在，继续请求没有意义，需要改变计划。若希望后续尝试避免同类错误，还可以保存一段基于结果的经验总结。
Reflexion 研究的是后一类机制：Agent 根据任务反馈生成文字反思，将其保存在记忆中，影响后续尝试；这一过程不靠更新模型权重来完成。[4]
工程上可以据此分开处理错误：短暂故障走重试，方法失效走重规划，权限不足或目标不明确则暂停等待。不要让模型对所有错误都给出同一个“再试一次”。
反思需要可以检查的依据
让模型评价自己的答案，可以提供修改建议；是否真正解决问题，还要看外部结果。
代码任务可运行测试，数据任务可检查行数、字段和统计结果，发布任务可回读已保存的内容。开放式内容则可以用明确的评分规则和人工抽查。Anthropic 的 Agent 评估指南把程序判定、模型判定和人工判定作为不同工具，并指出模型判定需要校准。[5]
反思的触发频率也应按成本设计。一个可采用的办法是普通步骤做轻量检查，在阶段结束、关键假设变化或任务失败时，再调用模型评估。每次读文件都增加一轮长篇反思，会让简单任务变慢。
4. 多路径搜索：同时保留几种可能的解法
有些任务的困难在于“第一条路线很可能选错”。数学推导、组合问题，或具有明确测试标准的代码修复，可以考虑生成多个候选，再逐步筛选。
Tree of Thoughts 让模型生成和评价中间候选，并结合搜索方法探索、回溯。LATS 则把树搜索、行动、环境反馈和反思放在同一框架中。[6][7]
例如，修复一个解析器错误时，可以先提出三种假设：输入预处理错误、状态转换遗漏、边界判断错误。每条路径分别收集证据；与失败用例不符的路径被淘汰，剩余路径再继续细化。
这里要设计的是搜索过程，而不只是要求模型“给三个方案”：
- 一个节点代表什么，是假设、部分解还是环境状态？
- 候选如何产生，如何判断重复？
- 评分依据是什么，是否能够运行测试？
- 每次保留多少分支，最多搜索多久？
- 什么时候结束，失败时怎样回退？
这些问题决定搜索是否值得它的额外开销。
搜索图、任务图和流程图不是同一个东西
搜索图记录候选解法，可能只选一条路径执行。任务依赖图记录必须完成的工作，例如先获取数据，再并行统计不同字段。状态转换图记录系统允许的流程，例如申请必须经过审核才能进入执行。
它们都可以画成图，但含义不同。LangGraph 提供图式编排能力，并不意味着用它编写的 Agent 自动具备多路径搜索；搜索仍需设计候选生成、评分和探索逻辑。[2][8]
分支得分不等于真实成功概率
模型说某条路径“更有希望”，只是评价信号。候选生成可能漏掉好解法，评估器也可能判断错误。在有限搜索预算下，应把目标设为提高找到可接受解的机会，而不是承诺全局最优。[6][7]
搜索还要求环境适合探索。草稿、沙箱代码和可回滚状态比较容易试错；真实付款、发送邮件和删除数据，不应为了比较路线就重复执行。可以先搜索操作方案，再由权限与审批机制控制实际动作。
5. SOP 与状态机：把业务边界写进程序
有些流程本来就明确，例如客服工单必须先核实信息，再判断问题类型，最后进入允许的处理分支。这里应先表达业务规则，再决定哪些节点需要模型。
Anthropic 区分了预定义代码路径驱动的 workflow，与由模型动态决定过程的 agent。SOP 和状态机通常更接近前者，也可以在局部节点中嵌入自主 Agent。[1]
下面是一个示意性工单流程：
flowchart LR
A[接收工单] --> B[核实信息]
B --> C{信息完整}
C -->|否| D[等待补充]
D --> B
C -->|是| E[分类与拟定处理方案]
E --> F[规则检查或人工审核]
F -->|通过| G[执行允许的操作]
F -->|未通过| H[人工处理]
模型可以帮助分类、提取字段和拟定方案；程序负责检查必填字段、校验身份、限制操作范围和控制状态转换。
LangGraph 的官方介绍包含持久化、人类介入和确定性步骤与 Agent 步骤的组合能力。它适合表达这类流程，但合规规则仍需要业务代码、权限系统和审计机制落实。[8]
固定流程的代价是维护成本。规则调整要更新流程，出现未覆盖情况要有人工处理或明确的异常分支。系统需要给例外留出口，而不是让模型私自绕过规则。
6. 四种思路怎样选择和组合
| 思路 | 主要解决的问题 | 可优先尝试的场景 | 需要承担的代价 |
|---|---|---|---|
| Plan-and-Execute | 提前协调多个子任务 | 目标清楚、步骤可拆解的长任务 | 初始计划可能依赖错误假设 |
| 反馈与重规划 | 根据新事实修正后续行动 | 调研、排障、环境变化较多的任务 | 验证和重规划增加开销 |
| 多路径搜索 | 避免过早押注一种解法 | 有清晰评估标准、可探索的难题 | 分支增长、评分误差和搜索成本 |
| SOP 与状态机 | 限定允许的业务流程 | 稳定业务、审批和权限边界明确的流程 | 流程维护及例外处理 |
这张表是选型建议，不是性能排名。具体系统可以用真实任务评估后，再决定增加哪一层机制。
比如，一个处理客户反馈的系统可以用固定流程限定数据权限；在“分析”节点内由 Planner 拆分任务；对独立分组并行处理；在发现样本不足时重规划；最终由程序检查引用编号，再由人工审核报告。
多模型和多 Agent 都不是前提。先让一个模型、一组工具和一个执行循环完成任务，再根据实际瓶颈拆分角色，会更容易定位问题。这与 Anthropic 提倡先采用简单、可组合方案的建议一致。[1]
7. 生产系统还需要计划之外的保障
保存执行状态，不只保存待办清单
建议分别记录计划版本、任务状态、工具结果引用和失败原因。任务状态至少能区分未开始、执行中、成功、失败、等待输入和取消。
重新规划时，保留已经验证的产物，只修改受影响的后续任务。否则一次失败可能把整段工作重新跑一遍。
LangGraph 通过检查点保存执行状态，但恢复执行可能重新进入节点，不能假设每条外部操作都恰好执行一次。官方恢复机制说明，暂停恢复会从节点开头重新执行逻辑。[9]
有副作用的动作要单独保护
一个值得预先测试的故障是：外部系统已经接受请求，本地却没有收到响应。此时直接重试，可能重复发送或重复创建。
处理办法应与外部接口能力匹配：优先使用幂等键；缺少幂等支持时，先查询操作状态，再决定是否重试。检查点记录、业务操作记录和外部状态之间，也需要明确的一致性处理。
权限与预算由运行时强制执行
计划中写了“需要审批”，还要在工具调用入口拦住未审批的动作。重规划不能成为扩大授权范围的办法。
建议设置最大工具调用次数、超时、失败重试上限和搜索预算。达到边界后，应保存当前产物并说明未完成部分，避免无限循环。
工具返回内容可以影响事实判断，但不应被当成新的系统授权。检索到的网页、邮件和日志都可能含有要求改变行为的文字，执行器仍应遵守原来的权限范围。
8. 如何判断规划真的有用
评估时应比较最终结果和执行过程。计划看起来完整，不代表任务完成得更好。
可以准备一组有明确验收条件的任务，再加入几类故障：数据缺失、工具超时、权限拒绝、执行中途恢复，以及工具成功但本地未记录结果。
建议跟踪任务成功率、总耗时、单任务成本、无效工具调用、人工介入和错误动作。对结果正确性使用程序检查，对开放式质量使用评分规则和人工抽查。Anthropic 的评估指南也建议将能力评估与回归评估分开，避免改善一类任务时破坏已有能力。[5]
若加入显式规划后，成功率没有提高、耗时却明显增加，就应减少规划粒度或退回更简单的循环。若大多数错误来自无效工具参数，则先改工具接口和校验，比继续增加规划角色更直接。
Agent Plan 最终要解决的是如何组织并完成工作。显式拆解帮助协调任务，反馈机制修正错误假设，搜索比较候选解法，状态机限定业务边界。落地时还需要可验证的结果、可恢复的执行状态，以及不会被模型绕开的权限控制。
参考资料
[1] Anthropic：Building effective agents
[2] LangChain：Plan-and-Execute Agents
[3] ReAct：Synergizing Reasoning and Acting in Language Models
[4] Reflexion：Language Agents with Verbal Reinforcement Learning
[5] Anthropic：Demystifying evals for AI agents
[6] Tree of Thoughts：Deliberate Problem Solving with Large Language Models
[7] Language Agent Tree Search