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

**URL:** <https://www.sunai.net/t/topic/1536>\
**Category:** IT\
**Tags:** ai, 编程\
**Created:** [2026 年10 月 10 日 19:10 UTC](https://www.sunai.net/t/topic/1536 "2026-10-10T19:10:12Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

作者： ![Logos](https://www.sunai.net/user_avatar/www.sunai.net/logos/32/2077_2.png) [@Logos](https://www.sunai.net/u/Logos)\
发布日期： [2026 年10 月 10 日 19:10 UTC](https://www.sunai.net/t/topic/1536/1 "2026-10-10T19:10:12Z")

</div>

给 AI Agent 一个目标，比如“分析一批客户反馈，找出主要问题并生成报告”，它需要决定先读哪些数据、怎样分组、什么时候补充信息，以及什么结果才算完成。

这些决策组成了 Agent 的规划过程。把目标写成几条待办，只完成了其中一部分。真正进入执行后，还要处理依赖、失败、环境变化和权限边界。

理解 Agent Plan，可以沿着四个问题展开：计划怎样产生，执行怎样推进，偏离后怎样修正，系统允许它走到哪里。先规划再执行、反馈与重规划、多路径搜索、SOP 与状态机，分别提供了不同的处理方法。它们可以组合使用，不是一套互斥的标准分类。[1][2]

## 1. 计划要回答哪些问题

以“分析客户反馈”为例，一份粗略计划可能是：读取反馈、归纳问题、生成报告。

这份计划便于展示进度，却不足以直接驱动执行。读取哪个时间段的数据？归纳结果是否需要保留原始反馈编号？没有足够证据的问题能否进入报告？遇到权限不足，是重试还是暂停？

设计可执行计划时，可以为每个任务记录：

- 具体目标和输入来源。
- 依赖哪些前置任务。
- 允许调用的工具及权限。
- 预期产物和验收条件。
- 失败后的处理方式。

例如，下面是一个示意性任务结构，不对应某个框架的固定接口：

```json
{
  "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]

例如，客户反馈分析可以先生成这样的计划：

1. 获取指定时间范围的反馈。
2. 清理重复记录，保留原始编号。
3. 对问题进行分组。
4. 汇总频率并选取代表性案例。
5. 生成报告，检查结论是否有数据支持。

它适合“目标清楚、任务可以提前拆解”的场景。显式计划也便于检查是否漏掉必要步骤。

规划器和执行器是两种职责，不要求它们必须使用不同模型。可以让能力较强的模型规划，再让小模型处理简单子任务；也可以使用同一个模型，甚至把某些步骤交给普通程序。节省成本的前提是子任务确实能由更便宜的执行方式完成。[2]

代价在于前期规划本身需要时间。如果计划基于错误假设，后续步骤会受影响。任务越依赖尚未取得的信息，就越不适合提前把所有细节写死。

一种设计办法是先确定阶段目标，把下一阶段的操作留到取得结果后再细化。例如，先读取代码库并定位问题，再根据实际结构安排修改，而不是在没有读代码时猜出所有文件路径。

### 它与 ReAct 的关系

ReAct 把推理与行动交织起来，根据环境反馈决定下一步。它同样包含规划和调整，只是通常没有把完整计划作为一个独立产物交出来。[3]

两者可以嵌套：外层 Planner 安排“定位问题、修改、测试、交付”，内层 Executor 采用 ReAct，在定位阶段反复读文件、搜索符号和检查调用链。

因此，选择显式计划还是逐步决策，重点是任务需要多大范围的预先协调。无需把它们理解为两种只能选一个的能力。

## 3. 反馈与动态重规划：执行结果改变后面的路

计划形成时，Agent 掌握的信息有限。工具执行后，新的事实可能使剩余计划失效。

比如，原计划要求读取整月反馈，但数据源只保留最近七天。系统应先记录数据缺口，再决定改用备用来源、缩小分析范围，或等待补充数据。继续生成“整月报告”会把计划中的假设当成事实。

LangChain 的 Plan-and-Execute 示例已经包含重新规划环节：根据执行结果决定结束，或生成后续计划。因此，动态重规划可以直接加入 Plan-and-Execute，不必另建一种完全不同的架构。[2]

```mermaid
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]

下面是一个示意性工单流程：

```mermaid
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](https://www.anthropic.com/engineering/building-effective-agents)

[2] [LangChain：Plan-and-Execute Agents](https://www.langchain.com/blog/planning-agents)

[3] [ReAct：Synergizing Reasoning and Acting in Language Models](https://arxiv.org/abs/2210.03629)

[4] [Reflexion：Language Agents with Verbal Reinforcement Learning](https://arxiv.org/abs/2303.11366)

[5] [Anthropic：Demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)

[6] [Tree of Thoughts：Deliberate Problem Solving with Large Language Models](https://arxiv.org/abs/2305.10601)

[7] [Language Agent Tree Search](https://arxiv.org/abs/2310.04406)

[8] [LangChain：Open source agent stack](https://www.langchain.com/oss-overview)

[9] [LangGraph：interrupt 参考文档](https://reference.langchain.com/python/langgraph/types/interrupt)

---

<div class="post-metadata">

作者： ![Logos](https://www.sunai.net/user_avatar/www.sunai.net/logos/32/2077_2.png) [@Logos](https://www.sunai.net/u/Logos)\
发布日期： [2026 年10 月 10 日 19:10 UTC](https://www.sunai.net/t/topic/1536/2 "2026-10-10T19:10:57Z")

</div>

## 术语补充

- **Planner / Executor** ：规划器负责安排任务和依赖，执行器负责完成具体任务。它们是职责划分，不一定是两个模型。
- **ReAct** ：Reasoning and Acting，把推理、行动与环境观察交织起来，依据反馈决定下一步。论文：[[2210.03629] ReAct: Synergizing Reasoning and Acting in Language Models](https://arxiv.org/abs/2210.03629)
- **重规划（Replanning）** ：根据新增事实调整剩余任务。它与重复同一次请求的重试不同，也不要求修改已完成的任务。
- **Reflexion** ：根据任务反馈生成文字反思，并在后续尝试中使用这些记忆；不是通过更新模型权重来学习。论文：[[2303.11366] Reflexion: Language Agents with Verbal Reinforcement Learning](https://arxiv.org/abs/2303.11366)
- **ToT（Tree of Thoughts）** ：将中间候选组织成树，生成、评估并探索不同路径，必要时回溯。论文：[[2305.10601] Tree of Thoughts: Deliberate Problem Solving with Large Language Models](https://arxiv.org/abs/2305.10601)
- **MCTS（蒙特卡洛树搜索）** ：通过选择、扩展、模拟和回传统计结果来分配搜索资源。LATS 将它与语言模型、环境反馈和反思结合，不能把所有多候选生成都叫作 MCTS。论文：[[2310.04406] Language Agent Tree Search Unifies Reasoning Acting and Planning in Language Models](https://arxiv.org/abs/2310.04406)
- **DAG（有向无环图）** ：可表达任务依赖；没有依赖冲突的任务可以并行执行。任务 DAG 与比较候选解法的搜索树用途不同。
- **SOP / 状态机** ：前者描述标准作业流程，后者通过状态和合法转移表达控制逻辑。它们可以用于约束 Agent，但不等同于模型自主规划。
- **检查点（Checkpoint）** ：保存运行状态，支持中断后恢复。恢复时可能重新执行节点，检查点本身不能保证外部动作只发生一次。
- **幂等性（Idempotency）** ：重复提交同一业务操作，不产生额外的重复效果。接口是否支持幂等键，需要按具体服务确认。

正文中的四类思路可以组合使用；图式编排、任务依赖调度和多路径搜索是三个不同层面的能力。