task-decomposer

任务分解器

将自然语言问题拆分为适合作为 DAG 节点的子任务。这是元 DAG 的第一步：在构建或执行 DAG 之前，你需要先了解各个组成部分。

---

适用场景

✅ 适用于：

• 将模糊的问题拆分为具体的子任务
• 识别阶段、依赖关系和并行化机会
• 判断哪些子任务具体，哪些模糊（多潜能）
• 选择适合分解任务的领域元技能

❌ 不适用于：

• 根据子任务构建 DAG 结构（使用 dag-planner）
• 执行任务（使用 dag-runtime）
• 为任务分配技能（使用 dag-skills-matcher）

---

分解流程

flowchart TD
  P[Problem description] --> M{Domain meta-skill available?}
  M -->|Yes| L[Load meta-skill phase pattern]
  M -->|No| R{Research needed?}
  R -->|Yes| RA[Research standard decomposition]
  R -->|No| Z[Zero-shot decomposition]
  
  L --> D[Apply phase pattern to problem]
  RA --> D
  Z --> D
  
  D --> C[Identify concrete sub-tasks]
  D --> V[Identify vague/pluripotent sub-tasks]
  D --> DEP[Map dependencies between sub-tasks]
  D --> PAR[Identify parallelization opportunities]
  
  C --> O[Ordered sub-task list with metadata]
  V --> O
  DEP --> O
  PAR --> O

步骤 1：领域检测

将问题归类到某个领域，以选择合适的元技能：

领域信号	元技能
“build”“implement”“code”“app”“website”	software-project-decomposition
“research”“analyze”“report”“synthesize”	research-synthesis-decomposition
“design”“UI”“wireframe”“prototype”	product-design-decomposition
“strategy”“market”“business”“revenue”	business-strategy-decomposition
“data”“model”“train”“predict”	ml-project-decomposition

如果没有匹配的元技能，则回退到零样本分解。

步骤 2：识别阶段

应用元技能的阶段模式。并非所有问题都适用所有阶段。

判断：对于模式中的每个阶段，询问：“这个问题需要此阶段吗？”

• 需要，而且现在可以明确说明 → 具体子任务
• 需要，但要等前置阶段完成后才能明确说明 → 模糊／多潜能节点
• 不需要 → 跳过此阶段

步骤 3：指定子任务

对于每个具体子任务：

sub_task:
  id: unique-name
  description: "What this sub-task produces (1-2 sentences)"
  type: concrete | vague
  depends_on: [upstream-sub-task-ids]
  parallelizable_with: [sibling-sub-task-ids]
  estimated_complexity: simple | moderate | complex
  suggested_model_tier: 1 | 2 | 3
  suggested_skills: [skill-names if known]
  output_description: "What the output looks like"

对于每个模糊／多潜能子任务：

sub_task:
  id: unique-name
  description: "What this phase will address (1-2 sentences)"
  type: vague
  depends_on: [upstream-sub-task-ids]
  potential_paths:
    - "Path A: [exciting possibility 1]"
    - "Path B: [exciting possibility 2]"
    - "Path C: [exciting possibility 3]"
  expansion_trigger: on_upstream_complete

步骤 4：映射依赖关系

对于每对子任务，判断：

• 数据依赖：B 是否需要 A 的输出？→ 从 A 到 B 建立边
• 知识依赖：B 是否需要了解 A 的发现？→ 从 A 到 B 建立边
• 无依赖：A 和 B 是否相互独立？→ 可并行执行

步骤 5：输出

生成结构化分解：

decomposition:
  problem: "original problem description"
  domain: "detected domain"
  meta_skill_used: "meta-skill name or 'zero-shot'"
  phases:
    - phase: 1
      sub_tasks: [concrete tasks for this phase]
    - phase: 2
      sub_tasks: [mix of concrete and vague tasks]
  total_concrete: 5
  total_vague: 3
  estimated_waves: 4
  estimated_cost: "$0.08 - $0.25"

---

分解启发式

粒度

• 过细：“步骤 1：打开文件。步骤 2：读取第 1 行。”→ 合并为一个节点
• 过粗：“步骤 1：构建整个应用。”→ 拆分为设计、实现、测试、部署
• 合适：每个子任务都能由一个 Agent 通过一次大模型调用，使用 1-3 项技能完成

尽量减少依赖

依赖越少 = 并行性越高 = 执行越快。优先选择：

• 相互独立的并行轨道，而非漫长的顺序链
• 扇出模式（一个来源，多个使用者），而非串联链
• 尽可能晚地合并（在最后组合结果，而非逐步合并）

模糊也没关系

不要强行明确目前尚不明确的内容。标注为“构建解决方案（设计阶段结束后再确定细节）”的模糊节点，比虚假地具体化、最终却会出错的节点更诚实，也更有用。

---

反模式

过早具体化

错误：为依赖尚未完成的研究的阶段指定精确的实现细节。 正确：将依赖其他阶段的内容标记为模糊／多潜能，并列出可能的路径。

所有任务都按顺序执行

错误：将 10 项任务排成没有并行性的线性链。 正确：寻找相互独立的轨道。研究和内容撰写通常可以并行进行。

遗漏元技能

错误：将桥梁设计项目按软件项目的方式分解。 正确：检测领域，加载合适的元技能，并遵循其阶段模式。