任务分解（Task Decomposition）

智能体做不好复杂任务，很多时候不是能力问题，而是任务本身没有拆开。一个大目标里混着调研、决策与实现，模型很容易在中间跑偏或提前收尾。分解的目标是让每一步都有明确输入、明确产出与可判断的完成标准，并且步骤之间尽量少来回依赖——依赖越少，返工越少，也越容易把步骤并行交给多个执行单元。

拆到什么粒度

• 按可验收的产出拆：每一步结束时能拿出一个东西，例如一份清单、一个通过测试的改动。
• 按依赖顺序拆：先定接口再写实现，先跑通主流程再补边界，减少返工。
• 控制步数：以每步可独立验收为准，不设固定区间，步数过多会让调度与反复交代背景的开销超过收益。
• 把不确定的先做：把风险最高、最可能推翻方案的部分排在前面验证。
• 显式写出交接物：说明上一步的什么结果会被下一步用到，避免信息断档。

拆解结果要落到纸面

• 写成清单而不是留在对话里：上下文一长，口头计划就会被冲淡，清单可以逐项勾选。
• 标注每步的完成标准：用可判断的条件描述，例如「测试通过」「两个来源互相印证」。
• 标注每步的输入来源：指明依赖哪个上游产物，缺了就知道该回头补哪一步。
• 预留调整位：允许中途插入验证或修正步骤，计划不是一次定死。
• 明确回退点：哪一步失败要整体重来、哪一步只需局部重跑，事先说清。

拆解的两种切法

还有一层容易被忽略的取舍：按产出拆和按动作拆不是一回事。按产出拆时每一步都有可检查的东西，进度是可见的，失败也能局部重跑；按动作拆（先搜索、再阅读、再总结）看起来整齐，但中间产物没有意义，某一步出问题只能整段重来。工程上通常先按产出划出边界，再在单个步骤内部按动作组织提示词。

常见坑与相近概念

常见坑是拆得太细，退化成流水账，每步都要重新交代背景，反而更容易出错；反过来，只拆一层「先调研再实现」等于没拆，中间仍然是一个不可控的大黑盒。另一个坑是只拆动作不拆验收，做完一堆步骤却没人能判断是否达到目标。和提示链的区别是，两者都是事前规划：提示链固定的是提示序列与执行顺序，适合流程稳定的场景；任务分解固定的是子任务边界与交接物，子任务可以交给不同的执行单元，也可以并行推进。和子智能体配合时，每个子任务可以交给独立的执行单元去跑，但边界仍然由分解阶段确定。