规划与任务分解

一个只会「走一步看一步」的 Agent，在单轮问答里看不出问题；一旦任务拉长到几十步、跨多个工具，它就会丢目标、绕圈子、做到一半宣布完成。规划（Planning）模块解决的就是这件事：把「接下来做什么」从模型的即兴发挥，变成一个可以检查、可以修订、可以度量的显式过程。

本文按工程实践的角度梳理规划能力的完整谱系：四个经典模式各自解决什么问题、Todo 清单为什么成了 2025 年主流编码 Agent 的标配、推理模型崛起后显式规划还有没有存在必要，以及什么时候上规划模块、什么时候它纯属过度设计。

一、规划在 Agent 中的位置

回顾 Agent 全景解剖里的经典循环：感知 → 决策 → 行动 → 观察。没有规划能力时，「决策」这一步是纯粹的反应式的——模型看着当前的 context，临时决定下一个动作。这就是 ReAct 之前的 Agent 形态，也是很多玩具 demo 的形态。

反应式决策有三个结构性短板：

1. 目标会稀释。随着 observation 不断塞进 context window，最初的用户目标在注意力里的权重越来越低，Agent 容易被中间步骤「带跑」。
2. 错误会复利。每一步都基于前一步的结果即兴决策，第 3 步走偏了，第 4 步会在错误的方向上继续加码，没有人回头检查。
3. 资源不可预算。用户无法预知这个任务会烧多少 token、调多少次工具、跑多长时间，也就无法中途干预。

规划的本质，是在反应式循环之上加一层慢思考：先把「做什么」想清楚（或写清楚），再让快循环去执行「怎么做」。用 Agent Loop 的语言说，规划是在 loop 之外（或 loop 的特定节点上）运行的元认知过程。

无规划 Agent（反应式）:
  goal ──> [observe → decide → act] ──> [observe → decide → act] ──> ...
              ↑ 每一步即兴决策，错了没人发现

有规划 Agent:
  goal ──> [Planner: 生成计划] ──> [Execute step 1 → 2 → 3 ...]
                                       ↑
                              [Replanner: 结果偏离？修订计划]

二、经典模式谱系

规划研究不是一条直线，而是四种互补的范式，各自针对不同的失败点。理解它们的差异比记住名词重要。

2.1 ReAct：边想边做（2022）

ReAct（Reasoning + Acting，Yao et al.，arXiv:2210.03629，ICLR 2023）是所有现代 Agent 的奠基模式。它的洞察很朴素：让模型在每一步先输出一段 Thought（推理），再输出 Action（工具调用），拿到 Observation 后继续下一轮。推理轨迹和动作轨迹交错，互相锚定——Thought 让 Action 有依据，Observation 让 Thought 不跑偏。

# ReAct 循环的最小骨架（伪代码，示意 prompt 结构）
messages = [system_prompt, user_task]
while True:
    reply = llm(messages)  # 模型输出 Thought + Action
    if reply.has_tool_call:
        observation = execute_tool(reply.tool_call)
        messages.append(reply)            # Thought: ... Action: search("...")
        messages.append(observation)      # Observation: 搜索结果...
    else:
        break  # 模型输出最终答案，循环结束

ReAct 的规划是局部的、即时的：每个 Thought 只管眼前这一步。这在短任务上是优点（灵活、不浪费 token），在长任务上就是第一节说的三个短板的来源。今天几乎所有编码 Agent（包括 Claude Code）的主循环仍然是 ReAct 式的，差别只在于外面套了什么。

2.2 Plan-and-Execute：先规划后执行（2023）

Plan-and-Solve Prompting（Wang et al.，arXiv:2305.04091，ACL 2023）先在纯推理任务上证明了一件事：让模型先制定计划、再按计划逐个解决子任务，能显著减少 Zero-shot CoT 的「漏步骤」错误。同年 LangChain 把这个思想工程化为 Plan-and-Execute 模式，BabyAGI 等早期自治 Agent 也走了类似路线。

架构上是明确的角色分离：

用户任务
   │
   ▼
┌──────────┐   完整步骤列表   ┌───────────┐
│ Planner  │ ──────────────▶ │ Executor  │ ──▶ 逐步调用工具执行
│ (大模型) │                  │ (可用小模型)│
└──────────┘                  └─────┬─────┘
      ▲                             │ 执行结果
      │        ┌────────────┐       │
      └────────│ Replanner  │◀──────┘
               │ 偏离则修订计划 │
               └────────────┘

相比 ReAct，它换来三样东西：全局目标始终写在计划里，不会被 observation 稀释；Planner 和 Executor 可以用不同档位的模型，省钱；计划本身是结构化产物，可以落盘、可以展示给用户确认。代价是刚性——计划在执行前定死，环境一旦和预期不符，要么频繁触发 replan（贵且慢），要么硬着头皮执行一个已经过时的计划。

这条线的延伸是 LLMCompiler（Kim et al.，arXiv:2312.04511）：Planner 输出的不是线性步骤，而是带依赖关系的 DAG，无依赖的工具调用并行执行。论文报告相比 ReAct 最高 3.7 倍延迟加速、6.7 倍成本节省。思路漂亮，但适用面窄——只有当你能提前确定工具间依赖时才有意义。

2.3 Tree of Thoughts：搜索式规划（2023）

前两种模式都是「一条道走到黑」。Tree of Thoughts（Yao et al.，arXiv:2305.10601，NeurIPS 2023）换了个思路：既然单条推理链可能走进死胡同，那就把推理变成搜索——每一步生成多个候选 Thought，用模型自己评估每个候选的价值（sure / maybe / impossible），再用 BFS/DFS 展开搜索树，走不通就回溯。

问题: 用 4 个数字凑出 24（Game of 24）
                    ┌─ 思路A: 先凑 6 和 4 ── 评估: maybe ── 展开 ─┐
  根节点 ── 生成3个 ─┼─ 思路B: 先凑 8 和 3 ── 评估: sure  ── 展开 ─┤── ... ── 找到解
  候选              └─ 思路C: 先凑 12 和 2 ─ 评估: impossible ✗ 剪枝

ToT 在 Game of 24 这类「解空间需要探索」的任务上效果惊人，但要清醒：它的评估器还是 LLM 自己，评估质量决定搜索质量；而且每个节点都是一次模型调用，成本随分支数爆炸。在 Agent 工程里，ToT 的纯正形态很少直接用于生产，它的思想更多被推理模型的训练吸收了（见第四节）。

2.4 Reflexion：反思修正（2023）

Reflexion（Shinn et al.，arXiv:2303.11366，NeurIPS 2023）针对的是另一个失败点：Agent 犯过的错，下一轮还会再犯，因为轨迹过去了就过去了。Reflexion 在任务失败后加一层口头反思——让模型对照失败轨迹写一段「这次错在哪、下次怎么改」的自然语言总结，存进 episodic memory，下次尝试时放进 context。

尝试1: 执行轨迹 ──▶ 失败信号（测试没过 / 环境反馈）
                        │
                        ▼
              Reflector: 生成反思文本
              「我假设了 API 返回 dict，实际是 list，
                下次应先打印类型再解析」
                        │
                        ▼
              存入记忆 ──▶ 尝试2 的 prompt 带上反思 ──▶ 通过

论文报告它在 HumanEval 上把 GPT-4 的 pass@1 推到了 91%。注意它和 ToT 的区别：ToT 在单次任务内搜索，Reflexion 在多次尝试间学习；ToT 防走错路，Reflexion 治重复踩坑。工程上 Reflexion 极廉价——不需要训练，只是一个额外的 LLM 调用加一段文本记忆，是投入产出比最高的规划增强手段之一。它与记忆系统的边界也在这里：反思文本本质上就是一种面向未来的经验记忆。

怎么选

四种模式不是替代关系，是正交的工具。生产系统的常见配方是：ReAct 做主循环 + Todo 清单做轻量计划（第三节）+ 失败时触发一次反思。纯正的 Plan-and-Execute 适合步骤可预测的长流程（如数据管道、报表生成），ToT 留给真正需要探索的离线任务。

三、Todo 清单机制：被低估的规划原语

2025 年以来，Claude Code、Codex 等一线编码 Agent 不约而同地内置了 todo_write 类工具。这不是巧合，而是一个非常划算的工程决策。有人逆向分析了 Claude Code 的实际 API 请求（见参考资料），几个细节值得抄：

• Todo 通常是第一个工具调用。拿到复杂任务后先建清单，再动手。
• 每次更新重写完整清单。没有增量更新逻辑，全量覆盖——简单粗暴但杜绝了状态不一致。
• 工具返回结果里夹带指令。TodoWrite 的 tool result 里固定附带「继续按清单执行下一项」的提醒，每次调用都在强化行为，比只在 system prompt 里写一遍的服从率高得多。
• 系统按清单状态动态注入 reminder。比如清单为空时提醒「可以考虑建 Todo」，清单变化后把最新内容贴进对话。

为什么一张 Todo 表效果这么显著？因为它同时解决了三个问题：

1. 对抗目标稀释。任务状态从「埋在几百轮对话历史里」变成「context 里一张常驻的表」，模型每看一眼清单就被重新锚定一次目标。这本质是 Context Engineering 的技巧：把最重要的状态放在最显眼的位置。
2. 进度可观测。清单同时是 UX 组件——用户能看到 Agent 走到哪一步，这是廉价的可观测性。
3. 干预有抓手。用户可以直接说「跳过第 3 项」「先做最后一项」，计划成了人机协作的共享工件，这与 Human-in-the-Loop 的设计天然契合。

Todo 清单可以看作 Plan-and-Execute 的「平民版」：计划不再是执行前一次性定死的契约，而是一份随执行不断重写的活文档。它放弃了严格性（没有强制 replan 触发条件），换来的是和 ReAct 主循环零冲突的兼容性。实践证明，对大多数编码和办公任务，这个折中比严格的双层架构更好用。

别迷信清单

Todo 机制防「忘事」，不防「做错事」。清单里的每一项都可能执行错，Agent 也可能把没做完的项标成 completed。清单是记忆的脚手架，不是正确性的保证——验收仍然要靠测试、lint、人工 review 这类外部信号。

四、推理模型时代：长思维链取代显式规划了吗

2024 年 9 月 OpenAI 发布 o1，2025 年 1 月 DeepSeek-R1 开源，「推理模型」范式确立：模型通过强化学习训练出内部的长思维链，在回答前自动进行数十秒到数分钟的推理，中间自发包含分解、验证、回溯——听起来像把 CoT、Self-Consistency、ToT、Reflexion 的能力都内化进了权重。

于是一个争论贯穿了 2025-2026 年：显式规划模块是不是已经可以进博物馆了？

诚实的回答是：取代了「推理型规划」，没取代「工程型规划」。

被取代的部分：解题式的规划。数学证明、逻辑谜题、单文件算法题——这类任务的规划完全发生在模型的脑子里，不需要工具、不需要中间产物。推理模型在这类任务上确实让手写 ToT 搜索变得多余，论文里精心设计的 prompt 技巧被训练直接吸收。

没被取代的部分，原因很具体：

1. 规划的产物不只是给模型看的。长思维链是一段私有独白，跑完即弃；而显式计划是可以展示给用户确认、写进工单系统、被另一个 Agent 读取的公共工件。多 Agent 协作里，计划就是接口文档（见多智能体架构）。
2. 长任务超出单次推理的跨度。一次思考几分钟，解决不了跑几小时的任务。跨会话的任务状态必须外化——这正是 Todo 清单和记忆系统存在的理由。
3. 可验证性与可追责。当 Agent 犯错时，显式计划让评估与调试有锚点：是计划错了还是执行错了？对着一段黑盒思维链，这个问题很难回答。
4. 成本可控。推理模型的思考 token 按量计费且不可预知；显式规划可以把「想清楚」这一步集中在一次高质量调用里，执行阶段用便宜模型——Plan-and-Execute 的成本结构优势在推理模型时代反而更清晰了。

2025-2026 年工程和研究的共识（见参考资料中 Zylos 的调研）是：部署失败的 Agent，头号问题不是推理不够深，而是计划僵化——现实和预期分叉时无法回溯、无法重规划。这恰恰是推理模型内置能力覆盖不到、必须靠架构解决的问题。所以当前的最佳实践是分层：推理模型负责「每一步想清楚」，显式机制负责「全程不走丢」。

五、分层任务分解与子目标管理

当任务大到一张扁平 Todo 表装不下（几十上百个子任务），就需要分层分解：高层目标 → 里程碑 → 子任务 → 原子动作。这是经典 AI 里 HTN（Hierarchical Task Network）规划的思路，在 LLM Agent 时代的工程要点有三条：

分解的粒度以「可验证」为界。一个子任务拆到「能用一条明确的信号判断完成」就该停——测试通过、接口返回 200、文件生成且格式校验通过。再往下拆（「打开文件」「读第 10 行」）是在浪费规划成本，那是执行层的即兴空间。

子目标之间显式声明依赖，而不是隐式假设顺序。扁平清单默认顺序执行，但「设计数据库 schema」和「写前端页面」其实可以并行，「联调」必须等两者都完成。依赖关系写清楚，才知道失败时影响面有多大、哪些可以重试。LLMCompiler 的 DAG 思路在人工设计的工作流里同样适用。

高层计划稳定，底层计划易变。好的分层里，越接近根节点的目标越不该改（改了说明需求本身变了），越接近叶子的计划越允许随时推翻。把「重规划」限制在尽可能低的层级，是控制 replan 成本的关键——不要因为一个 API 调用失败就把整个项目计划重生成一遍。

一个典型的三层结构：

目标: 给产品加「导出报表」功能
├─ M1: 后端导出接口           ← 里程碑，有明确验收: 接口返回正确 xlsx
│   ├─ 设计导出任务的数据模型
│   ├─ 实现生成逻辑(依赖: 数据模型完成)
│   └─ 接口 + 单测(依赖: 生成逻辑完成)
├─ M2: 前端导出按钮与进度轮询  ← 与 M1 可并行开发
└─ M3: 联调与验收             ← 依赖 M1+M2

实践中，顶层分解值得用最强模型认真做一次（甚至让人审一遍），底层子任务交给执行 Agent 用 ReAct 循环自由发挥。这也是 Claude Code 的 Task 工具派发子 Agent 的思路：主 Agent 管分解和验收，子 Agent 管执行，互相不知道对方的细节，靠任务描述和验收标准对接。

六、规划失败模式与对策

规划模块自己会引入新的失败方式。2025-2026 年生产环境的复盘里，下面四种出现频率最高：

失败模式	症状	根因	对策
过度规划	简单任务也要先花几千 token 写计划；规划时间超过执行时间	不分任务复杂度一律套规划模板	设复杂度门槛（见第七节）；允许 Agent 判断「此任务无需计划」
计划僵化	环境变了（接口改了、文件不存在）仍按原计划执行到底	缺少 replan 触发器，或触发阈值太高	硬性规定：任何步骤失败 N 次、或 observation 与计划假设矛盾，必须停下来重规划
目标漂移	做着做着去优化无关的东西；交付物和原始需求对不上	长 context 里原始目标被稀释	目标显式化（Todo 首项 / 每轮 reminder 复述目标）；里程碑验收时回读原始需求
子任务爆炸	计划递归生成子计划，层级越来越深，token 烧光没产出	分解没有终止条件，把「规划」当成了进展	限制分解深度（2-3 层封顶）；限定「只有超过 X 步的子任务才允许再拆」；监控规划 token 占比

两条横切的工程纪律：

• 给规划本身设预算。规划消耗的 token / 时间超过总预算的 20-30% 还没有开始执行，基本可以判定出了问题——要么任务该拆给人工，要么规划策略该降级。
• 失败信号必须来自环境，不能来自模型自我感觉。「我觉得这步完成了」不算完成。测试、schema 校验、HTTP 状态码、文件 diff——能拿到外部信号的步骤才有资格标 completed。这条做不到，Todo 清单会退化成自我表扬的清单。

更多踩坑案例见实践避坑指南。

七、实战建议：什么任务值得上规划模块

最后给一个可操作的判断框架。按任务的步骤数和步骤可预测性两个维度分：

                步骤可预测性高          步骤可预测性低
             ┌─────────────────────┬─────────────────────┐
  步骤少     │ 不要规划模块          │ ReAct 裸循环          │
  (<5 步)    │ 直接执行/固定工作流    │ 每步即兴决策即可       │
             ├─────────────────────┼─────────────────────┤
  步骤多     │ Plan-and-Execute      │ ReAct + Todo 清单      │
  (>10 步)   │ 严格计划 + DAG 并行    │ + 失败触发 Reflexion   │
             ├─────────────────────┼─────────────────────┤
  探索型     │ Tree of Thoughts /    │ 分层分解 + 子 Agent     │
  任务       │ 采样多条方案再选        │ 主 Agent 管分解与验收   │
             └─────────────────────┴─────────────────────┘

三条压缩版经验：

1. 5 步以内、单人单次能完成的任务，任何规划模块都是过度设计。直接 ReAct 循环，把预算留给执行。
2. 跨工具、十分钟以上、步骤大致可列的任务，先加 Todo 清单——这是投入产出比最高的一步，往往加完就不需要别的了。参照第三节 Claude Code 的四个实现细节抄。
3. 只有当任务可以拆成「验收标准明确」的并行子任务，且失败代价高时，才上分层分解 + 子 Agent。这套架构的调试和维护成本是实打实的，多数应用用不上。

想亲手把一个带规划能力的 Agent 从零写出来，可以按自建 Agent 教程的路线，先实现 ReAct 主循环，再加 Todo 工具，最后实验失败反思——每一步都能直观看到成功率和 token 消耗的变化。相关论文的深入解读见核心论文精读。

参考资料

• ReAct: Synergizing Reasoning and Acting in Language Models (arXiv:2210.03629) —— ReAct 原论文，ICLR 2023，边想边做范式的起点。
• Tree of Thoughts: Deliberate Problem Solving with Large Language Models (arXiv:2305.10601) —— ToT 原论文，NeurIPS 2023，把推理变成可回溯的搜索。
• Reflexion: Language Agents with Verbal Reinforcement Learning (arXiv:2303.11366) —— Reflexion 原论文，NeurIPS 2023，失败反思写入记忆的范式。
• Plan-and-Solve Prompting (arXiv:2305.04091) —— Plan-and-Execute 的 prompt 层源头，ACL 2023，证明「先计划后执行」减少漏步骤错误。
• LLMCompiler: An LLM Compiler for Parallel Function Calling (arXiv:2312.04511) —— 计划即 DAG、并行执行工具调用，报告最高 3.7 倍延迟加速。
• Agent design lessons from Claude Code —— 逆向分析 Claude Code 的 API 请求，Todo 清单、系统提醒等机制的实证细节。
• AI Agent Planning, Backtracking, and Adaptive Replanning (Zylos Research, 2026) —— 2026 年调研：生产 Agent 的头号失败是计划僵化，重规划能力是鲁棒性核心。
• Agent Planning: ReAct vs Plan-and-Execute Tradeoffs —— 两种主流规划模式的工程取舍对比，含 LangGraph 实现示例。