task-decomposer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Task Decomposer

任务分解器

Breaks natural-language problems into sub-tasks suitable for DAG nodes. The first step of the meta-DAG: before you can build or execute a DAG, you need to understand what the pieces are.

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

When to Use

使用场景

✅ Use for:

Breaking a vague problem into concrete sub-tasks
Identifying phases, dependencies, and parallelization opportunities
Determining which sub-tasks are concrete vs. vague (pluripotent)
Selecting the appropriate domain meta-skill for decomposition

❌ NOT for:

Building the DAG structure from sub-tasks (use
```
dag-planner
```
)
Executing the tasks (use
```
dag-runtime
```
)
Assigning skills to tasks (use
```
dag-skills-matcher
```
)

✅ 适用场景:

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

❌ 不适用场景:

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

Decomposition Process

分解流程

mermaid

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

mermaid

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

Step 1: Domain Detection

步骤1：领域检测

Classify the problem into a domain to select the right meta-skill:

Domain Signals	Meta-Skill
"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`

If no meta-skill matches, fall back to zero-shot decomposition.

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

领域信号	元技能
"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`

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

Step 2: Phase Identification

步骤2：阶段识别

Apply the meta-skill's phase pattern. Not all phases apply to every problem.

Decision: For each phase in the pattern, ask: "Does this problem need this phase?"

Yes, and I can specify it now → Concrete sub-task
Yes, but I can't specify it until prior phases complete → Vague/pluripotent node
No → Skip this phase

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

决策逻辑：针对模式中的每个阶段，询问：“该问题是否需要这个阶段？”

是，且当前可明确 → 具体子任务
是，但需等前置阶段完成后才能明确 → 模糊/多能节点
否 → 跳过该阶段

Step 3: Sub-Task Specification

步骤3：子任务定义

For each concrete sub-task:

yaml

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"

For each vague/pluripotent sub-task:

yaml

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

针对每个具体子任务：

yaml

sub_task:
  id: unique-name
  description: "该子任务的产出内容（1-2句话）"
  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: "产出物的形态描述"

针对每个模糊/多能子任务：

yaml

sub_task:
  id: unique-name
  description: "该阶段要解决的问题（1-2句话）"
  type: vague
  depends_on: [upstream-sub-task-ids]
  potential_paths:
    - "路径A：[潜在可能性1]"
    - "路径B：[潜在可能性2]"
    - "路径C：[潜在可能性3]"
  expansion_trigger: on_upstream_complete

Step 4: Dependency Mapping

步骤4：依赖关系映射

For each pair of sub-tasks, determine:

Data dependency: Does B need A's output? → Edge from A to B
Knowledge dependency: Does B need to know what A discovered? → Edge from A to B
No dependency: A and B are independent → Parallelizable

针对每对子任务，判断：

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

Step 5: Output

步骤5：输出结果

Produce a structured decomposition:

yaml

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"

生成结构化的分解结果：

yaml

decomposition:
  problem: "原始问题描述"
  domain: "检测到的领域"
  meta_skill_used: "元技能名称或'zero-shot'"
  phases:
    - phase: 1
      sub_tasks: [该阶段的具体任务]
    - phase: 2
      sub_tasks: [具体任务与模糊任务的混合]
  total_concrete: 5
  total_vague: 3
  estimated_waves: 4
  estimated_cost: "$0.08 - $0.25"

Decomposition Heuristics

分解启发式规则

Granularity

粒度控制

Too fine: "Step 1: Open the file. Step 2: Read line 1." → Merge into one node
Too coarse: "Step 1: Build the entire app." → Split into design, implement, test, deploy
Right: Each sub-task is completable by one agent with 1-3 skills in one LLM call

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

Dependency Minimization

依赖最小化

Fewer dependencies = more parallelism = faster execution. Prefer:

Independent parallel tracks over long sequential chains
Fan-out patterns (one source, many consumers) over daisy chains
Late merging (combine results at the end, not incrementally)

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

独立并行轨道，而非长串行链
扇出模式（一个源节点，多个消费节点），而非菊花链
延迟合并（在最终阶段合并结果，而非逐步合并）

Vagueness is OK

允许模糊性

Don't force specificity where it doesn't exist yet. A vague node saying "Build the solution (details TBD after design phase)" is more honest and more useful than a fake-specific node that will be wrong.

不要在暂不具备明确条件的场景下强行具体化。一个标注为“构建解决方案（设计阶段完成后确定细节）”的模糊节点，比一个虚假的、后续会出错的“明确”节点更诚实、更有用。

Anti-Patterns

反模式

Premature Specificity

过早具体化

Wrong: Specifying exact implementation details for phases that depend on undone research. Right: Mark dependent phases as vague/pluripotent. Show potential paths.

错误做法：为依赖未完成研究的阶段指定确切实现细节。 正确做法：将依赖阶段标记为模糊/多能节点，列出潜在路径。

Sequential Everything

全串行化

Wrong: A linear chain of 10 tasks with no parallelism. Right: Look for independent tracks. Research and content writing can often happen in parallel.

错误做法：10个任务组成的线性链，无任何并行性。 正确做法：寻找独立执行轨道，比如研究和内容撰写通常可并行进行。

Missing the Meta-Skill

遗漏元技能

Wrong: Decomposing a bridge design project like a software project. Right: Detect the domain, load the appropriate meta-skill, follow its phase pattern.

错误做法：像分解软件项目一样分解桥梁设计项目。 正确做法：检测领域，加载对应的元技能，遵循其阶段模式。