3.3 任务分解策略：自顶向下、层次化与递归
3.3 任务分解策略：自顶向下、层次化与递归
一个 Agent 接到「帮我做一份完整的竞品分析报告」，它不会一上来就写报告——那一定崩。它会先拆：「找竞品 → 收集数据 → 对比指标 → 总结结论 → 写报告」。把大任务拆成小任务，是处理长程复杂问题的根本方法。这一节讨论怎么拆、拆到多细、拆错了怎么办。
3.3.1 为什么需要任务分解
LLM 的能力与任务规模不成线性关系。给 LLM 一个「大而模糊」的任务，它会陷入三个困境：
| 困境 | 表现 | 后果 |
|---|---|---|
| 上下文超载 | 任务信息量超过单次推理容量 | 漏掉关键点 |
| 目标模糊 | 「做竞品分析」没有可验证的中间状态 | 无法判断进度 |
| 错误累积 | 一次大生成出错,全盘皆错 | 不可恢复 |
任务分解的根本动机是：把超出 LLM 单次能力的大问题，切成在其能力范围内的小问题。
| 维度 | 不分解 | 分解后 |
|---|---|---|
| 单步难度 | 高（超能力） | 低（在能力内） |
| 可验证性 | 弱（黑盒） | 强（每步可检） |
| 错误恢复 | 全盘重做 | 局部重试 |
| 上下文占用 | 集中爆炸 | 分散可控 |
💡 类比软件工程：没人会把一个百万行系统写成一个函数——会拆成模块、类、函数。Agent 也一样，任务分解是 Agent 的「模块化设计」。不分解的 Agent 就像一个巨函数，写得出但跑不稳。
3.3.2 三种分解粒度
按「拆几次、拆多深」，分解有三种粒度：
粒度一：一次性分解（扁平化 Decomposition）
把大任务一次性拆成 N 个并列子任务，分别解决后合并。
"做竞品分析" ├── 找竞品 ├── 收集数据 ├── 对比指标 └── 写总结
- 特点：一层、扁平、子任务独立。
- 适用：子任务之间无强依赖、规模中等。
- 代表：Decomposed Prompting（分解提示）。
粒度二：层次化分解（Hierarchical Decomposition）
把任务拆成树形——先拆大块，每块再拆小块，形成层级。
"做竞品分析" ├── 1. 数据收集 │ ├── 1.1 找竞品 │ ├── 1.2 抓产品功能 │ └── 1.3 抓定价 ├── 2. 对比分析 │ ├── 2.1 功能矩阵 │ ├── 2.2 价格矩阵 │ └── 2.3 评分 └── 3. 报告输出 ├── 3.1 写摘要 └── 3.2 写详细
- 特点：多层、树形、父子孙结构。
- 适用：任务规模大、有清晰层级。
- 代表：HuggingGPT 式任务图、Plan-and-Execute。
粒度三：递归分解（Recursive Decomposition）
不停拆，直到每个子任务变成「原子」（不可再分、可直接执行）。
"做竞品分析" └── 1. 数据收集 └── 1.2 抓产品功能 └── 1.2.1 抓竞品 A 功能 └── 1.2.1.1 调用爬虫 API └── (原子: 直接执行)
- 特点：递归到底、自动判断「是否原子」。
- 适用：复杂度未知、需动态判断粒度。
- 代表：Least-to-Most Prompting、递归式 Agent。
三种粒度的对比
| 维度 | 一次性 | 层次化 | 递归 |
|---|---|---|---|
| 层数 | 1 层 | 2-3 层 | 直到原子 |
| 可控性 | 高 | 中 | 低 |
| 灵活性 | 低 | 中 | 高 |
| 实现复杂度 | 低 | 中 | 高 |
| 典型场景 | 中等任务 | 大型任务 | 未知复杂度 |
⚠️ 递归分解的陷阱：递归看似强大，但有「无限递归」风险——Agent 可能把一个简单任务拆得越来越细，永远到不了「原子」。生产中必须设置最大递归深度与「何时停」的判定规则。
3.3.3 子任务之间的关系：依赖与并行
分解出的子任务不是孤立的，它们之间有两种基本关系：
| 关系 | 含义 | 处理 |
|---|---|---|
| 依赖 | B 需要 A 的输出才能开始 | 串行执行 |
| 独立 | A 和 B 互不依赖 | 并行执行 |
上图里 C 与 D 可以并行（都依赖 B，但互不依赖），而 B 必须等 A 完成。识别并行机会能显著降低总延迟——这是 Plan-and-Execute、ReWOO 等范式的核心动机（见 3.4 节）。
依赖图的工程意义
| 维度 | 全串行 | 有并行 |
|---|---|---|
| 总延迟 | Σ 每步延迟 | max(关键路径) |
| 资源利用 | 低 | 高 |
| 实现复杂度 | 低 | 中（需调度） |
💡 并行是免费的性能红利：很多 Agent 把所有子任务串行执行，白白浪费时间。识别可并行任务、用调度器同时跑，能让 Agent 总延迟降低数倍。这是 ReWOO 相对 ReAct 的核心优势之一。
3.3.4 HuggingGPT 式任务图：一个典型例子
HuggingGPT（Shen et al. 2023）是任务分解的标志性工作。它的核心思路：LLM 当「指挥家」，把复杂任务分解成子任务，调度专门的 AI 模型（视觉、语音、翻译等）去执行。
HuggingGPT 的四步流程：
| 步骤 | 内容 |
|---|---|
| 1. 任务规划 | LLM 把请求拆成子任务,生成有依赖的任务图 |
| 2. 模型选择 | 为每个子任务选最合适的 AI 模型 |
| 3. 任务执行 | 按依赖顺序执行,可并行的并行 |
| 4. 响应生成 | LLM 把所有结果合并成最终回答 |
HuggingGPT 揭示了任务分解的深层价值：它让 LLM 不必「什么都自己做」，而是「调度专家」。这与第 7 章多智能体协作的精神一脉相承——只不过 HuggingGPT 调度的是「模型」，多 Agent 调度的是「Agent」。
3.3.5 分解粒度的权衡：太粗 vs 太细
任务分解不是越细越好。粒度选择是个权衡：
| 粒度 | 问题 | 后果 |
|---|---|---|
| 太粗 | 子任务仍超出 LLM 能力 | 子任务失败 |
| 太细 | 子任务过多、协调开销大 | 延迟与成本爆炸 |
| 刚好 | 子任务在能力内、协调可控 | 最优 |
判断「原子任务」的经验法则
什么样的任务算「原子」（不必再拆）？几个判据：
| 判据 | 标准 |
|---|---|
| 可执行 | 能用一个工具调用或一次推理完成 |
| 可验证 | 结果对错可独立判定 |
| 有意义 | 不是机械切分（如「读一句话的一半」） |
| 不依赖 | 不需要其他子任务的中间结果 |
⚠️ 过度分解的反模式：把任务拆得过细，比如把「写一段总结」拆成「写第一句、写第二句……」。这会让 Agent 失去全局视野，输出支离破碎。分解的目的是让每块「可独立做好」,不是「机械切碎」。
3.3.6 分解失败的常见模式
任务分解不是万能的，它会失败。几种典型失败：
失败一：分解错误
LLM 把任务拆错了——漏掉关键步骤，或拆出不相关的子任务。
| 原因 | 例子 |
|---|---|
| 任务理解错误 | 把「竞品分析」理解成「找竞品」 |
| 漏掉隐含步骤 | 忘了「数据清洗」 |
| 拆错依赖 | 把本应串行的设成并行 |
失败二：子任务不可解
拆出的子任务超出了工具或模型能力。
分解: "评估这家公司的长期投资价值" 子任务: "预测未来 5 年股价" ← 不可解,任何工具都做不到
失败三：合并失败
子任务都做对了，但合并阶段出错——结果拼不上、矛盾、重复。
💡 合并是最被低估的环节：很多人以为分解完就万事大吉，其实「子任务全对 ≠ 最终结果对」。合并需要 LLM 综合多源信息，这一步本身的难度不亚于分解。生产中应当对合并结果做验证。
失败四：分解与执行脱节
分解时 LLM 看不到执行时的真实状态，可能给出「理论可行但实际跑不通」的计划。这是「先规划后执行」范式的通病，也是 ReAct「边走边调」兴起的动机（见 3.4 节）。
3.3.7 分解与其他规划策略的关系
任务分解不是孤立策略，常与其他策略组合：
| 组合 | 做法 | 适用 |
|---|---|---|
| 分解 + CoT | 每个子任务内部用 CoT 推理 | 子任务本身有难度 |
| 分解 + ReAct | 每个子任务用 ReAct 执行 | 子任务需工具调用 |
| 分解 + ToT | 在分解节点上做树搜索 | 分解方案不唯一 |
| 分解 + 并行 | 独立子任务并行执行 | 降低延迟 |
最常见且最强大的组合是「分解 + ReAct」：先一次性把任务分解成子任务列表（Plan 阶段），再对每个子任务用 ReAct 边走边调（Execute 阶段）。这正是 Plan-and-Execute 范式的核心，3.4 节会详细对比。
本节小结
- 任务分解的根本动机：把超出 LLM 单次能力的大问题，切成在其能力范围内的小问题。它是 Agent 的「模块化设计」。
- 三种粒度：一次性分解（扁平、中等任务）、层次化分解（树形、大型任务）、递归分解（动态、未知复杂度）。递归要防「无限递归」。
- 子任务之间有依赖与独立两种关系。识别独立任务并并行执行，是免费的性能红利。HuggingGPT 式任务图展示了「LLM 当指挥家、调度专家模型」的分解范式。
- 粒度权衡：太粗则子任务超能力，太细则协调爆炸。「原子任务」判据：可执行、可验证、有意义、不依赖。分解目的是「可独立做好」,不是「机械切碎」。
- 分解有四种典型失败：分解错误、子任务不可解、合并失败、分解与执行脱节。合并是最被低估的环节，应当对合并结果做验证。
- 分解常与其他策略组合，最强大的是「分解 + ReAct」（Plan-and-Execute）。这为 3.4 节的范式对比埋下伏笔。
下一节《3.4 规划范式对比》把 Plan-and-Execute、ReWOO、Plan-and-Solve、LATS 放在一起对比，回答「什么时候一次想完、什么时候边想边做」。