规划与任务拆解

一句话理解：计划是 Agent 写给自己的备忘录，也是写给用户的承诺。好的规划不在于一开始想得多细，而在于每一步都能验证完成，并且在事实变化时及时改计划。

一个 Agent 在第 3 步时还清楚自己要做什么，到第 30 步时，上下文里已经堆满了工具输出，最初的目标可能只剩一句话被埋在很前面。它开始重复做已经做过的事，或者做完一半就宣布完成。长任务里的这类“跑偏”，很大程度上是规划问题。

规划还有另一面：用户需要知道 Agent 打算怎么做。一个要改 20 个文件的任务，如果用户在开始前就能看到计划并纠正方向，远比改完之后再返工便宜。上一课介绍了 Plan-and-Execute 的思想，这一课讲落地时的具体形态和设计方法。

四种规划形态

形态	计划存在哪里	谁能看到	适合	例子
隐式规划	模型的推理过程中	通常只有模型	短任务、步骤少的任务	回答一个需要查两次数据的问题
Todo 列表	上下文中一份持续更新的清单	模型和用户	中长任务、需要跟踪进度	修复 5 个失败的测试
计划模式（先计划、后批准）	单独输出的计划文档	用户确认后才执行	改动大、方向错了代价高的任务	跨模块重构、批量改线上数据
结构化计划 + 程序执行	JSON 等结构化格式，由程序校验和调度	程序、用户	批量、可并行、需要审计的任务	200 个页面的 SEO 检查、100 条工单的批量排查

四种形态可以排成一条线，越往右，计划越外显、越结构化：

图 1 · 规划形态的选择：越往右越可见、可控，也越重

以 Claude Code 为例，可以看到几种形态并存：

任务清单工具：Claude Code 提供了用于创建和更新任务清单的工具，让模型把多步工作写成可跟踪的列表。值得注意的是，它的文档提到，在较新的模型上这些工具默认不再提供，因为模型不依赖书面清单也能跟踪多步工作，而工具定义本身会占用上下文。这说明显式规划是有成本的，需要多少外部结构，取决于模型能力和任务长度。
计划模式：在计划模式下，Claude 会读取文件、运行只读的探索命令并写出计划，但不修改源代码；用户批准计划后才开始编辑。用户可以按 Shift+Tab 切换进入，或者在单条提问前加上 /plan。

什么样的拆解是好拆解

同一个任务，“一次排查 100 条待处理工单”，看两种拆解：

差的拆解：
  1. 查询所有工单信息
  2. 分析问题原因
  3. 给出建议

好的拆解：
  1. 拉取 100 条工单的基础信息和分类标记
     完成标准：100 条记录都已获取，失败的工单号列入待重试清单
  2. 按问题类型分组（发货延迟 / 支付 / 商品质量 / 其他）
     完成标准：每条工单恰好属于一组，“其他”组单独列出
  3. 各组并行排查（每组内部按 Skill 中的 SOP 执行）
     完成标准：每条工单都有原因和至少一条工具证据，或标记为“证据不足”
  4. 找出共性原因（同一商品、同一支付渠道、同一时间段）
     完成标准：每个共性结论都注明影响的工单数量和工单号
  5. 生成报告，按影响面排序
     完成标准：报告中的工单总数与第 1 步一致

好拆解的几个特征：

每一步都有可检查的完成标准。 “分析问题原因”无法判断是否完成，“每条工单都有原因和证据，或标记为证据不足”可以。
粒度与验证能力匹配。 一步太大，出错时不知道错在哪；一步太小，计划本身变成负担。经验法则：每一步都应该对应一个可以独立验证的中间产出。
显式标出依赖和可并行的部分。 第 3 步的各组互不依赖，可以并行；第 4 步必须等第 3 步全部完成。
不确定的地方先安排探索。 如果不知道数据长什么样，第一步应该是“抽样查看 5 条工单的数据结构”，而不是假设字段存在。
为失败留出位置。 “失败的单号列入待重试清单”“标记为证据不足”这类设计，让 Agent 在部分失败时仍能推进，而不是卡死或编造结果。

把好的拆解画成依赖图，可并行的部分和检查点就很清楚：

图 2 · 好拆解：每一步都有完成标准，依赖与可并行部分一目了然

动态重规划

计划是在信息最少的时候制定的，执行中一定会出现新情况。关键是定义清楚什么时候应该改计划：

图 3 · 重规划不是从头再来：保留成果、写明原因、重大变更请用户确认

重规划时容易忽视的三件事：

保留已完成的成果。 重新规划不等于从头再来。已经查清的 60 条工单，不应该因为计划变动而重新查询。这需要把任务状态记录在上下文之外，见「任务状态与 Checkpoint」。
记录为什么改。 “原计划按 4 类分组，第 2 步发现 23 条为优惠券未生效，新增一类”这样的记录，既帮助模型保持连贯，也帮助用户理解 Agent 的行为。
重大变更要让用户知道。 如果新计划明显扩大了范围（比如要额外查询退款系统），应该告知用户或请求确认，而不是悄悄执行。

计划如何展示给用户

计划不仅是内部机制，也是产品界面的核心元素。用户看到“目标、步骤、当前进度、已完成的产出”，才能在合适的时机介入。具体的交互设计在「计划与进度」展开，这里只强调一点：展示的计划要和 Agent 实际执行的计划是同一份。界面上显示一套步骤、后台执行另一套逻辑，会迅速摧毁用户的信任。

常见误区

“计划越详细越好。” 开始时信息有限，过细的计划很快会过时，反而增加重规划的成本。前几步可以细，后面的步骤保持粗粒度，边做边细化。
“计划批准后就不应该改。” 批准的是方向，不是每一个细节。应该事先约定哪些变更需要重新确认（扩大范围、涉及写操作），哪些可以自主调整。
“所有任务都应该先做计划。” 对于两三步就能完成的任务，强制先写计划只会增加延迟和 Token。规划的深度应该与任务的长度和出错代价相匹配。
“计划写在上下文里就不会丢。” 长任务中上下文会被压缩，计划可能被摘要得面目全非。关键的计划和进度应该保存在外部状态中。

产品经理检查清单

这类任务的典型长度是多少步？是否需要显式的计划或任务清单？
哪些任务在执行前必须让用户确认计划？判断标准是什么（改动范围、是否涉及写操作、预计成本）？
计划中的每一步是否都有可检查的完成标准？
哪些情况会触发重新规划？重新规划后是否需要用户再次确认？
任务中断后，能否根据保存的计划和进度继续，而不是从头开始？
用户界面上展示的计划，与 Agent 实际执行的计划是否一致？

练习

为「上线前 SEO 全站检查」设计计划（约 40 分钟）：

场景：新版网站明天上线，共 180 个页面，分商品页、文章页和活动页三类。
写出一份 5–7 步的计划，每一步包含：做什么、完成标准、是否可以并行、失败时怎么处理。
列出至少 3 个重规划触发条件，例如“发现 30% 以上的页面带有 noindex”时应该怎么办（很可能是预发布配置被带上线，此时逐页检查已无意义，应立即上报）。
标出哪一步之前需要用户确认，并说明原因。

下一步

计划解决了“怎么往前走”，下一课「停止条件」解决“什么时候该停”：最大步数、预算上限、完成判定与死循环检测。

规划与任务拆解