任务拆解

它是什么

任务拆解是把一个复杂目标分成范围更明确、能够执行和检查的子任务，并说明这些子任务怎样组合回最终结果。好的拆解不只是列出更多步骤，还会标明每一步需要什么输入、产生什么输出、依赖谁以及何时算完成。Least-to-Most Prompting 展示了一种从较简单子问题开始、利用前一步答案继续解决后续问题的方法。[S1]

为什么需要它

一次要求模型同时研究、判断、写作和执行，任何局部错误都可能藏在最终答案里，也很难知道该从哪里返工。拆成子任务后，系统可以给不同步骤配置合适的资料、工具和验收标准，并在昂贵或不可逆动作前停下来检查。它把“希望模型完成”转成一组可以观察和管理的工作单元。

它如何工作

先写清最终交付物和验收条件，再找出必须先完成的事实收集、判断与执行步骤；为每个子任务定义输入、输出、负责人和失败处理，并画出依赖顺序。边界清楚且路径稳定的任务可以使用固定工作流；只有下一步确实要依据中间结果决定时，才需要模型动态规划。执行过程中逐步校验，最后还要检查局部结果组合后是否满足整体目标。[S1][S2]

必须澄清的误会

任务拆解 ≠ Agent 规划。 任务拆解产出的是步骤清单；规划还要排先后、定依赖、决定哪一步该找人接手，是拆解的上一层。

任务拆解 ≠ 提示链。 提示链是把固定流程串成多段调用，步骤事先定死；任务拆解面对新任务现拆，拆法随任务变化。

真实例子

产品经理要生成一份竞品发布评估，可以拆成：确认评估问题与时间范围、收集各竞品一手公告、提取统一字段、逐项核对出处、比较差异、形成结论、检查结论是否超出证据。字段提取必须等资料收集完成，结论必须等出处核验完成；若某项缺少一手来源，就标记未知，而不是让后续步骤补猜测。

什么时候适合与不适合

任务拆解适合多来源研究、跨工具执行、多人协作和需要审计的复杂流程。简单问答或单步转换通常不值得增加编排。拆得太粗仍会掩盖错误，拆得太细则增加调用、状态传递和协调成本；依赖关系错误还会让每一步看似正确，合起来却偏离目标。[S2] 拆解不能替代最终的整体复核。

亲自试一下

选择一个你本周要完成的复杂任务，写出最终交付物和三条验收条件，再拆成 4-7 个子任务。为每项填写“输入、输出、前置依赖、完成标准、失败后怎么办”。让另一位同事只看这张表说明执行顺序；若他无法判断某一步何时开始或何时结束，就继续收紧边界。

接下来学什么

先用提示链把固定子任务串成可检查流程，再学习Agent 规划处理无法预先确定的步骤；需要外部信息或动作时，继续学习工具调用。

来源与修订

从简单子问题开始并按依赖顺序求解的机制参考 Least-to-Most Prompting 论文 [S1]；固定工作流、动态编排及复杂度取舍参考 Anthropic Agent 工程指南 [S2]。论文中的数据集结果不外推为所有业务任务的效果保证。