复杂任务拆解
2353 字约 8 分钟
domain/aiai/prompt
2026-07-24
复杂任务拆解是 Prompt 工程和 Agent 系统的核心能力，从语义理解到可执行操作的落地，是连接问题与解决方案的桥梁。
一句话解释
将一个大目标递归拆分为可独立执行、依赖关系清晰的原子操作，让 LLM 或多 Agent 系统能够分步完成，最终汇总结果。
核心问题
为什么 LLM 不能直接处理复杂任务？因为：
- 上下文溢出：完整问题+推理步骤+结果可能超出模型上下文窗口
- 错误扩散：一步错导致步步错，中间没有纠错机会
- 认知负荷：模型同时处理理解、推理、执行、输出，容易顾此失彼
- 依赖不清晰：哪些步骤可以并行，哪些必须顺序执行，不明确就无法优化
基础概念
现代智能体领域将任务分解划分为三个递进层级：
语义层（Semantic Decomposition）：将任务拆解为抽象的理解步骤，如"理解需求 → 明确受众 → 明确风格"。这是对任务的抽象描述，不可直接执行。
操作层（Operational Decomposition）：拆解为可执行的动作序列，如"生成大纲 → 扩写 → 校对 → 格式化"。仍未绑定具体工具。
执行层（Executable Decomposition）：拆解为"工具 + 状态 + 输入"的完整三元组，例如 generate_outline(tool) → 输入主题 → 返回大纲。这一层才是真正可工程化的任务分解，也是 AutoGPT、Devin、LangChain Agent 等系统的底层逻辑。
核心分解策略
三种分解范式
| 范式 | 工作原理 | 适用场景 |
|---|---|---|
| 层次化分解 | 将高层目标递归分解为子目标，再进一步分解为原子操作 | 大型项目规划、多领域复杂问题 |
| 顺序分解 | 子任务按线性顺序执行，前一步输出作为后一步输入 | 流水线式工作流，步骤间强依赖 |
| 并行分解 | 将无依赖关系的子任务同时执行，最后汇总结果 | 数据比对、多源信息收集 |
四种主流分解技术
| 技术 | 定义 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| Zero-shot Planning | 让模型直接生成计划 | 快速、简单、成本低 | 不稳定、步骤可能跳跃 | 简单任务、小自动化 |
| ReAct Planning | 推理+行动+状态更新，每步基于上一步反馈 | 灵活、动态调整 | 长任务容易烂尾、成本高 | 搜索类、需要迭代的任务 |
| 结构化规划（JSON/XML） | 结构化输出计划，可被程序解析 | 可控、稳定、可对接工作流引擎 | 模板设计需要经验 | 企业场景、多Agent协作 |
| Few-shot Planning | 通过示例驱动模型模仿分解方式 | 稳定、步骤结构清晰 | 需积累示例 | 复杂流程、跨领域规划 |
商业级智能体通常使用 结构化规划（JSON Schema） + ReAct 的组合方案。
子任务编排与依赖管理
依赖图建模（DAG）
任务依赖关系最适合用有向无环图（DAG）建模。Planner 一次性生成带有依赖标注的任务列表，再由调度器按拓扑序并行执行。
重新规划（Replanning）机制
Plan-and-Execute 架构的核心闭环：规划（Plan）→ 执行（Execute）→ 重新规划（Replan）。
重新规划器结合原始目标、初始计划和已执行结果，判断是否需要调整后续步骤。这是处理复杂任务不确定性的关键。
多 Agent 编排四种模式
- 串行链：Agent A 的输出 → Agent B 的输入
- 并行链：同时调用多个 Agent，最后汇总
- 路由分发：根据输入类型动态选择执行路径
- 循环：条件判断 + 迭代执行，直到满足终止条件
与 CoT/Few-shot 的关系
CoT 作为原子推理单元
Chain of Thought（思维链）本质上是将一个问题在语义层面拆解为推理步骤。它是任务分解的最基础形式。
| 维度 | CoT | Plan-and-Execute | ReAct |
|---|---|---|---|
| 交互性 | 无外部交互 | 先规划后执行 | 边推理边交互 |
| 适应性 | 静态推理 | 静态规划 | 动态调整 |
| 错误恢复 | 无法恢复 | 需重规划 | 自动反思调整 |
| 适用场景 | 纯推理问题 | 结构化任务 | 开放式任务 |
Tree of Thoughts（ToT）：将推理扩展为树状结构，允许同时探索多条推理路径，通过分支、回溯和剪枝找到最优解。在数学推理、策略规划领域显著优于线性 CoT。
Few-shot 示例驱动分解
Few-shot 在任务分解中扮演"示例驱动"的角色：通过提供 3-5 个分解示例，让模型模仿如何拆分任务。
实际应用中，常常将 Few-shot 示例与 JSON Schema 约束结合，既保证结构稳定性，又提供领域适配性。
多轮对话中的任务递进
核心策略
- 状态保持：每轮对话保留上轮关键上下文，使用工作记忆维持任务连贯性
- 逐步揭示：先确认理解，再逐层深入，避免一次性给出过多信息导致模型丢失焦点
- 检查点机制：在关键节点设置验证步骤，确认理解正确后再推进
迭代式自我完善（Reflexion）
Reflexion / Self-Refine 模式是关键的多轮递进技术：
生成 → 自我评估 → 识别问题 → 修正 → 再评估 → ... → 输出最终结果Agent 在初步生成答案后，对自己的输出进行批判性反思，并根据反馈不断修正，直到满足标准。
任务分解评估指标
任务分解的质量直接决定后续执行的成功率。以下指标可用于评估分解好坏：
| 指标 | 定义 | 评估方法 | 阈值参考 |
|---|---|---|---|
| 分解完整性 | 子任务是否覆盖原始目标的 100% | 检查所有原始需求是否被映射到至少一个子任务 | 100% 覆盖 |
| 原子性 | 子任务是否不可再分 | 对每个子任务问"能否再拆？"，可再分说明粒度偏大 | 90%+ 原子 |
| 依赖清晰度 | 子任务依赖关系是否明确无环 | 构建 DAG，检查是否有循环依赖 | 无环 |
| 可执行性 | 子任务是否有明确的输入、输出和成功标准 | 检查每个子任务是否包含三要素 | 100% 包含 |
| 并行度 | 可并行子任务占比 | 可并行子任务数 / 总子任务数 | 越高越好 |
快速检查清单：
常见误区
- 跳过语义层直接到执行层：还没理解问题就开始拆任务，导致方向错误
- 分解过粗：子任务仍然复杂，模型无法一次性完成
- 分解过细：产生大量不必要的小步骤，浪费 token 和时间
- 忽略依赖管理：并行执行有依赖关系的任务，导致结果错误
- 没有检查点：等到最后才发现前面错了，返工成本高
现实例子
Prompt 模板：层次化分解
你是一个任务规划专家。请将以下目标分解为具体可执行的步骤。
目标：{goal}
约束条件：
1. 每个步骤应当是原子操作，不可再分
2. 步骤之间有明确的依赖关系
3. 每个步骤应当有明确的成功标准
请以 JSON 格式输出：
{
"steps": [
{"id": "task1", "description": "...", "dependencies": [], "success_criteria": "..."}
]
}LLM Compiler 并行执行
LLM Compiler 框架借鉴编译器优化原理，构建依赖图，一旦某任务的前置依赖被满足，立即并行分发执行。论文报告在特定任务上比顺序执行快 2-3 倍（Kim et al., 2024）。
与其他概念的关系
- Chain of Thought使用边界 — CoT 是任务分解的基础原子单元
- Few-shot Prompt — Few-shot 提供示例驱动的分解能力
- Agent工作流 — 任务分解是 Agent 规划模块的核心职责
- Planner与Executor — 规划-执行架构以任务分解为基础
- ReAct模式 — ReAct 是动态分解，每步基于反馈调整
可继续补充的方向
- 不同领域（代码/写作/研究）的分解模式差异
- 不同领域下评估指标的权重如何设定（例如代码任务更看重“可执行性/可验证性”，研究任务更看重“覆盖度/引用闭环”）
- 如何自动化评估分解质量（基于 DAG 结构检查 + 执行日志/失败率统计）
- 自动学习分解模式的研究进展
关联笔记
- Prompt Engineering
- Prompt Engineering方法论
- Chain of Thought使用边界
- Few-shot Prompt
- Agent工作流
- Planner与Executor
- ReAct模式