AI Agent 如何做计划：从任务拆解、动态重规划到搜索与状态机

2026-10-110 评论1 阅读3.9k 字

给 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 与状态机	限定允许的业务流程	稳定业务、审批和权限边界明确的流程	流程维护及例外处理