一句话定义：任务分解（Task Decomposition）是把一个笼统的目标，拆成一串有先后依赖、能单独执行、做完能判断对错的小步骤。
老板说“把用户流失率降下来”，这不是任务，是愿望。它没法执行，也没法验收。拆开来看：先定义什么叫“流失”，再拉数据看谁走了，然后分层找原因，挑一个最可能的假设，设计一次实验，最后看结果有没有变化。每一小步都能交给一个人或一个智能体去做，做完都能说清“成了没有”。
打个厨房里的比方。要做一桌年夜饭，你不会写一张平铺的清单就开干。你得知道：炖汤要两小时，所以最先上火；凉菜可以提前拌；炒青菜必须最后，因为凉了就不好吃；两个灶眼不能同时被占满。真正的分解不是列清单，而是说清谁卡着谁。清单是平的，分解是有向的——它更像一张流程图，术语叫有向无环图（DAG），意思是任务之间存在“必须先做 A 才能做 B”的关系，且不能绕成死循环。
还有两个容易忽略的要点。一是粒度：太粗没法执行，太细会淹死在细节里，好的粒度是“一个人一次能做完，且能交付一个可检查的东西”。二是可验证：每一步都要能判断对错，否则拆了等于没拆，只是把迷茫摊薄了。
| 概念 | 管的是什么 |
|---|---|
| 提示词工程 | 怎么把一件事说清楚 |
| 任务分解 | 这件事该分成哪几件事，顺序如何 |
| 规划 | 更大一层：选目标、分解、排顺序，并按结果重排 |
| 工作流 | 把已经稳定的步骤固化成管道，反复跑 |
可见，任务分解是规划（Planning）的核心动作，但不是全部；工作流是分解结果稳定之后的产物，而分解本身往往要边做边改——第一步的结果不理想，后面几步就得重排。
对做智能体（Agent）的人，这是真正的分水岭。单步能力（写段代码、查个网页、调个接口）早就够用了，卡住的地方在于：一句模糊指令进来，拆得对不对、顺序合不合理、某步失败后能不能重排。工具调用、记忆、反思机制，全都挂在这棵分解出来的树上。评测一个智能体，常常就是拿它拆出的步骤和人类专家的比——差在哪一步漏了、哪一步顺序反了。
对普通职场人，这条同样实用。接到模糊需求时先别动手，问自己一句：这件事由哪几件必须按顺序发生的事组成？能把一件事拆成三步并说清依赖关系的人，既用得好 AI，也不容易被 AI 顶掉。
具体工具的分解能力上限，以官方页面为准。