04.2 — 任务分解
定位: Agent 处理复杂任务的核心能力——理解如何将大问题拆解为可执行的小步骤，以及不同的分解策略 面试高频度: ⭐⭐⭐⭐ 考查方式: 设计题（如何分解复杂任务）、对比题（不同分解策略的优劣）、实践题（给一个复杂任务，设计分解方案）
一、这是什么？为什么需要它？
是什么
任务分解（Task Decomposition） 是将一个复杂、高层次的目标拆解为一系列更小、更可执行的子任务的过程。在 Agent 中，这是规划能力的核心体现。
为什么需要任务分解？
❌ 没有分解的 Agent：
用户："帮我写一份市场分析报告"
Agent：[尝试一次生成整份报告]
→ 内容泛泛、结构混乱、容易遗漏关键部分
→ 超出 context window 限制
✅ 有分解的 Agent：
用户："帮我写一份市场分析报告"
Agent：[分解]
1. 收集行业数据（调用 search 工具）
2. 分析竞争对手（单独分析每家）
3. 识别市场趋势（基于数据）
4. 撰写各章节（一章一章来）
5. 整合并审阅
→ 每步专注一个子任务，质量更高
→ 中间结果可检查、可修正核心洞察：任务分解的本质是将"一次性解决大问题"转化为"逐步解决一系列小问题"——每个小问题更简单、更可控、更容易验证。
二、原理拆解
2.1 三种分解策略
① 自上而下（Top-down Decomposition）
先规划整体，再逐层细化。适合结构清晰、可预见的任务。
用户: "开发一个电商网站"
Level 0: 开发电商网站
├── Level 1: 前端开发
│ ├── Level 2: 商品列表页
│ ├── Level 2: 商品详情页
│ ├── Level 2: 购物车
│ └── Level 2: 结算页面
├── Level 1: 后端开发
│ ├── Level 2: 用户服务
│ ├── Level 2: 商品服务
│ ├── Level 2: 订单服务
│ └── Level 2: 支付服务
└── Level 1: 基础设施
├── Level 2: 数据库设计
├── Level 2: 部署配置
└── Level 2: 监控告警
优点：结构清晰，全局视角
缺点：信息不足时可能规划错误② 自下而上（Bottom-up Decomposition）
先做小任务，再逐步组合成完整方案。适合探索性、不确定性高的任务。
用户: "优化系统的性能"
→ Step 1: 先做性能基准测试
结果: 发现数据库查询最慢
→ Step 2: 分析慢查询
结果: 缺少索引
→ Step 3: 添加索引
→ Step 4: 重新测试
结果: 查询提升 10 倍
→ Step 5: 寻找下一个瓶颈...
优点：灵活，基于实际数据调整
缺点：缺乏全局视角，可能走弯路③ 分层规划（Hierarchical Planning）
结合自上而下和自下而上，在不同抽象层次上交替规划。
高抽象层（What）: 完成市场分析报告
└── 中抽象层（How）:
├── 数据收集阶段
├── 分析阶段
└── 输出阶段
└── 低抽象层（Execute）:
├── 撰写执行摘要
├── 撰写市场概况
├── 绘制增长图表
└── 整合排版2.2 分解策略选择矩阵
| 任务特征 | 推荐策略 | 原因 |
|---|---|---|
| 结构明确（如开发、写作） | 自上而下 | 可提前规划完整结构 |
| 探索性强（如研究、排错） | 自下而上 | 需要根据中间结果调整 |
| 超复杂（如大型项目） | 分层规划 | 多层级抽象管理复杂度 |
| 时间紧迫 | 自上而下 | 快速确定关键路径 |
| 质量敏感 | 自下而上 | 逐步验证，步步为营 |
2.3 任务分解的粒度控制
子任务太大或太小都有问题：
┌────────────────────────────────────────────┐
│ 分解粒度控制 │
│ │
│ 太大 (Coarse) 太小 (Fine) │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ 每个子任务 │ │ 每个子任务 │ │
│ │ 仍然很复杂 │ │ 过于简单 │ │
│ │ Agent 难以执行 │ │ 步骤太多太繁琐 │ │
│ │ 一步需要很多步 │ │ 规划成本高 │ │
│ └──────────────┘ └──────────────────┘ │
│ │
│ ✅ 合适 │
│ ┌──────────────────┐ │
│ │ 每个子任务: │ │
│ │ - 1-3 个工具调用 │ │
│ │ - 5-10 行输出 │ │
│ │ - 可独立验证 │ │
│ └──────────────────┘ │
└────────────────────────────────────────────┘粒度经验法则：
python
def check_task_granularity(task: dict) -> str:
"""检查任务分解粒度是否合适"""
if task.estimated_steps > 10:
return "任务太大，需要进一步分解"
if task.estimated_steps == 1 and not task.is_simple:
return "任务不够细，应该分解"
if len(subtasks) > 20:
return "分解太细了，可以合并一些步骤"
return "粒度合适"2.4 动态任务分解
Agent 中的任务分解不一定是"一次规划完"——可以根据执行情况动态调整：
python
class DynamicTaskDecomposer:
"""动态任务分解器"""
def __init__(self):
self.task_tree = {}
def decompose(self, task: str, depth: int = 1) -> list:
"""根据当前信息分解任务"""
prompt = f"""
任务: {task}
当前深度: {depth}
请将任务分解为 2-5 个子任务。
每个子任务应该独立可执行。
输出格式:
- 子任务1: 描述
- 子任务2: 描述
..."""
response = llm.call(prompt)
subtasks = self._parse_subtasks(response)
# 记录分解决策
self.task_tree[task] = {
"subtasks": subtasks,
"depth": depth,
"status": "planned"
}
return subtasks
def dynamic_replan(self, completed_task: str, result: str, remaining: list) -> list:
"""根据已完成任务的结果动态调整剩余计划"""
analysis = llm.call(f"""
已完成: {completed_task}
结果: {result}
剩余任务: {remaining}
基于已完成任务的结果，是否需要调整剩余计划？
如果需要调整，请给出新的子任务列表。
""")
if "需要调整" in analysis:
new_plan = self._parse_subtasks(analysis)
return new_plan
return remaining # 保持原计划三、图解全景
┌──────────────────────────────────────────────────────────────┐
│ 任务分解策略对比图 │
│ │
│ 自上而下 (Top-down) │
│ ┌─────────────────────────────────────────┐ │
│ │ 开发电商系统 │ │
│ │ ├── 前端 │ │
│ │ │ ├── 商品列表（具体可执行） │ │
│ │ │ ├── 购物车（具体可执行） │ │
│ │ │ └── 结算（具体可执行） │ │
│ │ ├── 后端 │ │
│ │ │ ├── API 开发（具体可执行） │ │
│ │ │ └── 数据库（具体可执行） │ │
│ │ └── 部署 │ │
│ └─────────────────────────────────────────┘ │
│ │
│ 自下而上 (Bottom-up) │
│ ┌─────────────────────────────────────────┐ │
│ │ 性能优化 │ │
│ │ Step 1: 基准测试 → 发现瓶颈 │ │
│ │ Step 2: 优化数据库 → 测试确认 │ │
│ │ Step 3: 优化缓存 → 测试确认 │ │
│ │ Step 4: 整体验证 │ │
│ └─────────────────────────────────────────┘ │
│ │
│ 分层规划 (Hierarchical) │
│ ┌─────────────────────────────────────────┐ │
│ │ Level 0: 目标 │ │
│ │ Level 1: 策略 │ │
│ │ Level 2: 执行 │ │
│ │ ← 各层级可独立调整 → │ │
│ └─────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────┘四、实战验证
4.1 任务分解实战：写市场分析报告
python
task = "分析 2025 年全球电动汽车市场趋势并生成报告"
# 步骤 1: 任务分解
decomposer = DynamicTaskDecomposer()
subtasks = decomposer.decompose(task)
print("任务分解结果:")
for i, sub in enumerate(subtasks, 1):
print(f" {i}. {sub}")
# 可能的分解输出:
# 1. 收集 2025 年全球电动车销量数据
# 2. 分析主要厂商（特斯拉、比亚迪等）的市场份额
# 3. 识别关键市场趋势（价格、技术、政策）
# 4. 对比不同区域市场（中国、欧洲、美国）
# 5. 撰写分析报告各章节
# 6. 整合并生成最终报告
# 步骤 2: 按顺序执行子任务
for subtask in subtasks:
result = agent.run(subtask) # 执行子任务
print(f"[完成] {subtask[:30]}...")
# 步骤 3: 每次完成后检查是否需要调整计划
remaining = subtasks[subtasks.index(subtask)+1:]
subtasks = decomposer.dynamic_replan(subtask, result, remaining)
# 步骤 4: 整合所有子任务结果
print("报告生成完成！")4.2 分解粒度对比测试
bash
# 测试不同分解粒度对任务完成质量的影响
# 任务：分析竞争对手产品
# 粗粒度（1 个子任务）:
# "分析竞争对手产品"
# 结果：泛泛而谈，缺少具体数据 ❌
# 中等粒度（4 个子任务）:
# 1. 收集竞品功能列表
# 2. 比较定价策略
# 3. 分析用户评价
# 4. 生成对比报告
# 结果：结构清晰，每部分有深度 ✅
# 细粒度（10 个子任务）:
# 1. 打开竞品官网
# 2. 记录首页功能
# 3. 记录定价页...
# 结果：步骤太多，规划成本 > 执行收益 ❌
# 结论：复杂任务的子任务数控制在 3-8 个最佳五、面试视角
| 追问 | 答案要点 |
|---|---|
| 三种任务分解策略及适用场景？ | 自上而下（结构明确的任务）、自下而上（探索性任务）、分层规划（超复杂任务）。选择依据：任务的可预见性、对灵活性的需求 |
| 任务分解到什么粒度最合适？ | 每个子任务 1-3 个工具调用，可独立验证，不依赖其他子任务的中间结果。复杂任务 3-8 个子任务为宜 |
| 分解过程中 Agent 如何应对不确定性？ | 动态规划（执行过程中根据中间结果调整计划）、预留缓冲（关键路径上多留一些步骤）、增量验证（每完成一个子任务就验证） |
| 任务分解和 CoT/ReAct 的关系？ | 任务分解是"横向切分"（把大任务分成并/串行执行的小任务），CoT/ReAct 是"纵向深化"（每个子任务内部的推理方式）。两者互补 |
| Agent 的任务分解和人类项目管理有啥不同？ | Agent 的分解更动态（随时调整）、更依赖 LLM 判断（没有固定流程）、更注重"可执行性"（每个子任务对应明确的工具调用）。人类的分解更依赖经验和模板 |
| 如何判断分解是否成功？ | 三条标准：每个子任务可独立执行、子任务间解耦（修改一个不影响其他）、合并子任务结果 = 完整任务目标 |
📚 相关链接
- **CoT与ReAct** — 推理范式
- **自我反思与修正** — 根据错误调整计划
- **角色分配与编排** — 多 Agent 中的任务分配
- **感知-行动循环** — Agent 循环中的任务执行
- ← 返回 **Agent规划与推理索引**