1.6 Task Decomposition Strategies
Task Decomposition คืออะไร
Task Decomposition คือการแตก task ใหญ่ออกเป็น subtasks ย่อยที่จัดการง่ายกว่า — เป็นทักษะสำคัญของ AI architect เพราะ agent ตัวเดียวทำงานได้ดีที่สุดเมื่อ task ชัดเจนและ scope เหมาะสม task ที่ใหญ่เกินไปทำให้ agent หลงทิศ ใช้ tokens เยอะ และได้ผลลัพธ์ไม่ดี
หลักการคือ: ถ้า task ต้องใช้ความรู้หลาย domain, ต้อง access ข้อมูลมาก, หรือมี steps ที่ independent กัน — decompose มัน ถ้า task ทำจบใน 1-2 tool calls — ไม่ต้อง decompose
เมื่อไหร่ควร Decompose
ควร Decompose
- Task ต้องการ > 10 tool calls
- ต้องอ่านไฟล์มากกว่า 5 ไฟล์
- มี subtasks ที่ independent (ทำ parallel ได้)
- ต้องการ expertise ต่าง domain (code + design + writing)
- Context window จะเต็มถ้าทำทั้งหมดใน agent เดียว
ไม่ควร Decompose
- Task ง่าย ทำจบใน 1-2 steps
- Subtasks มี dependency แน่น (ต้องรอผลลัพธ์กันตลอด)
- Overhead ของ decomposition > benefit
- Task ต้องการ context เดียวตลอด (เช่น long conversation)
Decomposition Patterns
1. Horizontal Decomposition (By Scope)
แบ่งตาม scope ของงาน — แต่ละ subtask ครอบคลุม area ต่างกัน:
# Task: "Review entire codebase for security issues"
subtasks = [
"Review authentication code in src/auth/",
"Review API endpoints in src/routes/",
"Review database queries in src/models/",
"Review file upload handling in src/uploads/",
]
# Execute in parallel — independent scopes
results = await parallel([
lambda: agent(task, {label: f"reviewer-{i}"})
for i, task in enumerate(subtasks)
])
2. Vertical Decomposition (By Stage)
แบ่งตามขั้นตอน — pipeline ที่ output ตัวหนึ่งเป็น input ตัวถัดไป:
# Task: "Write a technical blog post about MCP"
# Stage 1: Research
research = await agent("Research MCP protocol - features, use cases, examples")
# Stage 2: Outline
outline = await agent(f"Create blog post outline based on: {research}")
# Stage 3: Draft
draft = await agent(f"Write full draft following this outline: {outline}")
# Stage 4: Edit
final = await agent(f"Edit and polish this draft: {draft}")
3. Recursive Decomposition
Agent ตัว orchestrator decompose task เอง แล้วแต่ละ subtask อาจถูก decompose ต่อ:
DECOMPOSE_SCHEMA = {
"type": "object",
"properties": {
"subtasks": {
"type": "array",
"items": {
"type": "object",
"properties": {
"description": {"type": "string"},
"depends_on": {"type": "array", "items": {"type": "integer"}},
"complexity": {"type": "string", "enum": ["simple", "complex"]}
}
}
}
}
}
# Let the orchestrator decompose
plan = await agent(f"""
Decompose this task into subtasks:
Task: {complex_task}
Rules:
- Each subtask should be completable by one agent
- Mark dependencies between subtasks
- Mark complexity (simple = one agent, complex = needs further decomposition)
""", {schema: DECOMPOSE_SCHEMA})
# Execute — further decompose complex ones
for subtask in topological_sort(plan.subtasks):
if subtask.complexity == "complex":
result = await decompose_and_execute(subtask)
else:
result = await agent(subtask.description)
4. Dependency Graph
ใช้ dependency graph เพื่อหา subtasks ที่ทำ parallel ได้:
# Task dependencies
# A (research) → C (design)
# B (analyze) → C (design)
# C (design) → D (implement)
# C (design) → E (test plan)
# Round 1: A and B are independent → parallel
a, b = await parallel([
lambda: agent("Research requirements"),
lambda: agent("Analyze existing system")
])
# Round 2: C depends on A and B
c = await agent(f"Design solution based on: {a} and {b}")
# Round 3: D and E depend on C but not each other → parallel
d, e = await parallel([
lambda: agent(f"Implement design: {c}"),
lambda: agent(f"Write test plan for: {c}")
])
Key Concepts
- Granularity Sweet Spot — subtask ที่ดีคือ 3-8 tool calls ต่อ subtask; เล็กเกินมี overhead มากเกินทำไม่ดี
- Topological Sort — เรียงลำดับ execution ตาม dependencies; independent tasks ทำ parallel
- Decomposition Overhead — การ decompose เองก็ใช้ tokens/time ถ้า task ง่ายอย่า overthink
- Context Loss — ทุกครั้งที่ decompose จะ lose context; ต้อง pass ข้อมูลสำคัญ explicitly
Exam Tips
- ข้อสอบจะให้ scenario แล้วถามว่าควร decompose อย่างไร — ดูว่ามี independent parts ไหม (parallel), มีลำดับไหม (pipeline)
- Recursive decomposition เหมาะเมื่อไม่รู้ล่วงหน้าว่า task ซับซ้อนแค่ไหน
- Dependency graph ช่วยหา critical path — bottleneck อยู่ที่ longest chain
- เสมอ trade-off: decompose มาก = parallism ดี แต่ context loss + overhead มาก
- ตอบคำถาม “เมื่อไหร่ไม่ควร decompose” ได้ด้วย — ง่าย, dependent, context-heavy tasks