Tất cả tập podcast
ai-agentsarchitecturesystem-designllm

Series 4 - Bài 3: Task Decomposition

Task decomposition quyết định multi-agent system hiệu quả hay không. Bài này phân tích các nguyên tắc decompose đúng và dependency graph để orchestration rõ ràng.

4 phút đọc
Tập này đang được chuẩn bị, quay lại sau nhé.

Task decomposition là kỹ năng quyết định multi-agent system hoạt động hiệu quả hay không. Orchestrator giỏi nhưng decompose sai → tất cả agents bên dưới làm sai. Decompose tốt → orchestrator đơn giản, workers hiệu quả.

Decomposition là gì

Decomposition là quá trình biến một task lớn thành các subtasks:

  • Có scope rõ ràng
  • Có dependencies xác định
  • Có kết quả measurable
Task gốc:
  "Implement credit scoring feature
   cho corporate loan application"

Decomposition:

  Subtask 1: Analyze existing data model
    Input: Entity definitions, DB schema
    Output: Understanding + gap analysis
    Worker: Backend specialist
    Dependencies: None

  Subtask 2: Design scoring algorithm
    Input: Business rules, domain docs
    Output: Scoring formula + edge cases
    Worker: Domain specialist
    Dependencies: None (parallel với ST1)

  Subtask 3: Implement scoring service
    Input: ST1 output + ST2 output
    Output: credit-scoring.service.ts
    Worker: Backend specialist
    Dependencies: ST1 và ST2 phải xong

  Subtask 4: Write tests
    Input: ST3 output
    Output: credit-scoring.service.spec.ts
    Worker: Test specialist
    Dependencies: ST3 phải xong

  Subtask 5: Security review
    Input: ST3 output
    Output: Security report
    Worker: Security specialist
    Dependencies: ST3 phải xong (parallel với ST4)

Task Dependency Graph

Dependency graph:

     ST1 (Analyze data)      ST2 (Design algo)
          │                       │
          └───────▼───────┘
                     │
              ST3 (Implement)
              │             │
              ▼             ▼
         ST4 (Tests)  ST5 (Security review)

Execution plan:
  Phase 1 (parallel):  ST1 + ST2
  Wait for both to complete
  Phase 2 (sequential): ST3
  Phase 3 (parallel):  ST4 + ST5
  Aggregate: Orchestrator synthesizes all

Phase structure cho orchestrator biết cần đợi gì trước khi bước tiếp.

Ba loại subtask

Independent subtasks:
  Không phụ thuộc vào nhau
  Có thể run parallel
  Ví dụ: analyze module A và analyze module B

Sequential subtasks:
  B vào là đầu ra của A
  Phải run theo thứ tự
  Ví dờ: implement xong rồi mới test

Conditional subtasks:
  Chỉ run khi điều kiện thỏa mãn
  Ví dụ: rollback chỉ run khi deploy fail
  Orchestrator phải evaluate condition trước

Decomposition Principles

Principle 1: Each subtask phải self-contained

Bad:
  Subtask A: "Look at the files and understand the codebase"
  Subtask B: "Based on what A found, write the service"

  Problem:
  • B phụ thuộc implicit vào A
  • Orchestrator phải serialize và pass A's findings sang B
  • Không rõ A cần tìm gì, B cần biết gì

Good:
  Subtask A: "Read loan.service.ts và loan.entity.ts.
               Output: JSON summary của current structure,
               public methods, và dependencies"

  Subtask B: Input là JSON summary từ A.
             "Implement credit-scoring.service.ts.
              Service phải inject LoanService (id: LoanService).
              Expose method: calculateScore(loanId: string)"

  • A có clear output spec
  • B có clear input spec
  • Orchestrator biết chính xác cần truyền gì

Principle 2: Subtask có verifiable output

Unverifiable:
  "Understand the payment architecture"
  → Orchestrator không biết task xong chưa

Verifiable:
  "Generate architecture diagram (ASCII) của payment module.
   Include: main classes, dependencies, data flow.
   Output phải có ít nhất 3 components."
  → Orchestrator có thể verify output đáp ứng spec

Principle 3: Không over-decompose

Over-decomposition:
  Subtask 1: Read file A
  Subtask 2: Read file B
  Subtask 3: Read file C
  Subtask 4: Compare A và B
  Subtask 5: Compare B và C
  Subtask 6: Synthesize comparison

  Problem:
  • Quá nhiều handoffs = overhead dominates
  • Mỗi handoff có thể introduce error
  • Một agent có thể làm toàn bộ

Right granularity:
  Subtask 1: "Read files A, B, C. Compare và synthesize.
               Output: so sánh dưới dạng table."

  Một agent, một task đủ lớn để context đệ

Principle 4: Failure isolation

Decompose để failure của một subtask không invalidate hết:

Bad decomposition (tight coupling):
  ST1 output là exact input của ST2
  ST2 output là exact input của ST3
  → ST1 fail = chain fail hoàn toàn

Good decomposition (loose coupling):
  ST1, ST2, ST3 độc lập, chỉ chia sẻ context qua orchestrator
  Orchestrator có thể retry ST1 mà không affect ST2, ST3

Dynamic vs Static Decomposition

Static decomposition:
  Orchestrator tạo toàn bộ plan trước khi bắt đầu
  Không thay đổi dựa trên kết quả

  +  Predictable
  +  Dễ debug
  -  Cứng nhắc, không adapt với unexpected findings

Dynamic decomposition:
  Orchestrator plan từng bước dựa trên kết quả trước

  +  Adaptive, tốt hơn khi task không predictable
  -  Khó predict total cost và duration
  -  Risk: orchestrator có thể "discover" task lớn hơn dự kiến

Buớc đầu dùng static. Chỉ thêm dynamic khi có specific need.

Kết luẫn

  • Decomposition chất lượng quyết định toàn bộ multi-agent system effectiveness.
  • Tốt: subtask self-contained, output verifiable, lỏi dụng parallelism.
  • Xấu: subtask quá nhỏ (overhead), implicit dependencies, unverifiable outputs.
  • Dependency graph làm rõ thứ tự execution và phần nào có thể parallel.
  • Failure isolation: decompose để một subtask fail không cascade toàn bộ.
  • Bắt đầu với static decomposition, thêm dynamic chỉ khi có need thực sự.