AI Agent Orchestration — 6 Pattern điều phối Agent trong Production 2026

Posted on: 4/21/2026 1:10:44 AM

Khi hệ thống AI chuyển từ "một model, một prompt" sang kiến trúc multi-agent, câu hỏi lớn nhất không còn là model nào mạnh nhất mà là điều phối các agent như thế nào cho hiệu quả. Theo phân tích của Anthropic trên 200+ deployment enterprise, 57% dự án thất bại có nguyên nhân gốc rễ từ thiết kế orchestration — agent riêng lẻ đủ mạnh nhưng phối hợp kém.

Bài viết này đi sâu vào 6 orchestration pattern cốt lõi đang được sử dụng trong production, phân tích trade-off thực tế về chi phí, latency, và độ phức tạp để bạn chọn đúng pattern cho bài toán của mình.

1. Tại sao Orchestration là yếu tố sống còn?

Một single-agent đủ tốt cho task đơn giản: viết email, tóm tắt tài liệu, generate code snippet. Nhưng khi bài toán phức tạp hơn — phân tích dữ liệu từ nhiều nguồn, tự động hóa quy trình có nhiều bước phụ thuộc, hoặc xử lý input đa dạng — bạn cần nhiều agent chuyên biệt phối hợp với nhau.

Vấn đề là: thêm agent không tự động thêm giá trị. Nếu không có orchestration pattern rõ ràng, bạn sẽ gặp:

• Race conditions: agents ghi đè state của nhau
• Infinite loops: agent A gọi agent B, B lại gọi lại A
• Cost explosion: mỗi agent call tiêu tốn token, không kiểm soát sẽ gấp 10-50x chi phí dự kiến
• Quality degradation: agent downstream nhận input kém chất lượng từ agent upstream

2. Pattern 1: Sequential Pipeline

Đây là pattern đơn giản nhất và nên là lựa chọn đầu tiên. Các agent thực thi tuần tự trong một chuỗi xác định, output của agent trước trở thành input của agent sau.

graph LR
    A["Input"] --> B["Agent 1
Extract"]
    B --> C["Agent 2
Transform"]
    C --> D["Agent 3
Validate"]
    D --> E["Agent 4
Output"]
    style A fill:#e94560,stroke:#fff,color:#fff
    style B fill:#0f3460,stroke:#fff,color:#fff
    style C fill:#0f3460,stroke:#fff,color:#fff
    style D fill:#0f3460,stroke:#fff,color:#fff
    style E fill:#4CAF50,stroke:#fff,color:#fff

Hình 1: Sequential Pipeline — luồng xử lý tuyến tính, deterministic

2.1. Đặc điểm

• Thứ tự cố định: được xác định lúc thiết kế, không thay đổi runtime
• State truyền qua shared object: mỗi agent đọc/ghi vào cùng một state container
• Dễ debug: biết chính xác lỗi xảy ra ở bước nào
• Latency tuyến tính: tổng latency = sum of all agents

2.2. Khi nào dùng?

Pipeline phù hợp khi:

• Mỗi bước phụ thuộc output của bước trước
• Workflow có 3-5 bước rõ ràng
• Không cần xử lý song song
• Ưu tiên reliability và debugability hơn speed

# Ví dụ: Pipeline phân tích code review
from claude_agent_sdk import Agent, Pipeline

pipeline = Pipeline([
    Agent("code_reader", model="haiku",
          system="Đọc code và liệt kê các thay đổi chính"),
    Agent("security_scanner", model="sonnet",
          system="Phân tích security vulnerabilities từ diff"),
    Agent("style_checker", model="haiku",
          system="Kiểm tra coding style và conventions"),
    Agent("summarizer", model="sonnet",
          system="Tổng hợp findings thành review comment")
])

result = await pipeline.run(code_diff)

3. Pattern 2: Supervisor (Orchestrator-Worker)

Pattern phổ biến nhất trong enterprise. Một agent "thông minh" (supervisor) nhận task, phân tách thành sub-tasks, delegate cho worker agents chuyên biệt, và tổng hợp kết quả.

graph TD
    A["Task Input"] --> S["Supervisor Agent
(Opus/Sonnet)"]
    S --> W1["Worker 1
Research
(Haiku)"]
    S --> W2["Worker 2
Analysis
(Sonnet)"]
    S --> W3["Worker 3
Code Gen
(Sonnet)"]
    W1 --> S
    W2 --> S
    W3 --> S
    S --> R["Final Result"]
    style S fill:#e94560,stroke:#fff,color:#fff
    style W1 fill:#0f3460,stroke:#fff,color:#fff
    style W2 fill:#0f3460,stroke:#fff,color:#fff
    style W3 fill:#0f3460,stroke:#fff,color:#fff
    style R fill:#4CAF50,stroke:#fff,color:#fff

Hình 2: Supervisor Pattern — orchestrator phân tách và delegate cho workers

3.1. Trade-offs

3.2. Immutable State Pattern

Best practice quan trọng nhất khi implement Supervisor: sử dụng immutable state snapshots. Mỗi agent nhận state version N, xử lý, và trả về state version N+1. Không agent nào mutate state trực tiếp.

// Immutable state pattern với Claude Agent SDK
interface AgentState {
  readonly version: number;
  readonly data: Record<string, unknown>;
  readonly history: ReadonlyArray<AgentAction>;
}

function createNextState(
  current: AgentState,
  action: AgentAction,
  result: unknown
): AgentState {
  return {
    version: current.version + 1,
    data: { ...current.data, [action.key]: result },
    history: [...current.history, action]
  };
}

4. Pattern 3: Parallel Fan-Out / Fan-In

Khi bài toán có thể chia thành các phần độc lập xử lý song song, Fan-Out giúp giảm latency đáng kể. Một dispatcher phân phối task cho N agents đồng thời, một aggregator thu thập và tổng hợp kết quả.

graph TD
    I["Input"] --> D["Dispatcher"]
    D -->|"Chunk 1"| A1["Agent A"]
    D -->|"Chunk 2"| A2["Agent B"]
    D -->|"Chunk 3"| A3["Agent C"]
    D -->|"Chunk 4"| A4["Agent D"]
    A1 --> AG["Aggregator"]
    A2 --> AG
    A3 --> AG
    A4 --> AG
    AG --> O["Output"]
    style D fill:#e94560,stroke:#fff,color:#fff
    style AG fill:#e94560,stroke:#fff,color:#fff
    style A1 fill:#0f3460,stroke:#fff,color:#fff
    style A2 fill:#0f3460,stroke:#fff,color:#fff
    style A3 fill:#0f3460,stroke:#fff,color:#fff
    style A4 fill:#0f3460,stroke:#fff,color:#fff

Hình 3: Fan-Out/Fan-In — xử lý song song, aggregation cuối cùng

4.1. Chi phí và Latency

Fan-Out nhân chi phí theo số agent (N agents = ~N× cost) nhưng latency chỉ bằng agent chậm nhất + overhead aggregation. Pattern này chỉ đáng dùng khi:

• Latency là ưu tiên số 1 (user-facing realtime)
• Các chunk thực sự độc lập (không shared dependency)
• Budget cho phép chi phí gấp N lần

4.2. Ví dụ thực tế

# Fan-Out: phân tích nhiều documents cùng lúc
import asyncio
from claude_agent_sdk import Agent

async def analyze_documents(docs: list[str]) -> dict:
    analyzer = Agent("doc_analyzer", model="haiku",
                     system="Trích xuất key insights từ document")

    # Fan-Out: gửi tất cả documents song song
    tasks = [analyzer.run(doc) for doc in docs]
    results = await asyncio.gather(*tasks)

    # Fan-In: tổng hợp với model mạnh hơn
    synthesizer = Agent("synthesizer", model="sonnet",
                        system="Tổng hợp insights thành report")

    combined_input = "\n---\n".join(
        f"Document {i+1}: {r}" for i, r in enumerate(results)
    )
    return await synthesizer.run(combined_input)

5. Pattern 4: Router (Intelligent Dispatch)

Router pattern phân loại input và điều hướng tới agent chuyên biệt phù hợp nhất. Đây là pattern hiệu quả nhất về chi phí vì chỉ một agent xử lý mỗi request — router chỉ tốn chi phí phân loại.

graph TD
    I["User Request"] --> R["Router Agent
(Haiku - fast classify)"]
    R -->|"Simple Q&A"| A1["FAQ Agent
(Haiku)"]
    R -->|"Code task"| A2["Code Agent
(Sonnet)"]
    R -->|"Complex reasoning"| A3["Reasoning Agent
(Opus)"]
    R -->|"Data analysis"| A4["Analytics Agent
(Sonnet + Tools)"]
    style R fill:#e94560,stroke:#fff,color:#fff
    style A1 fill:#4CAF50,stroke:#fff,color:#fff
    style A2 fill:#0f3460,stroke:#fff,color:#fff
    style A3 fill:#9c27b0,stroke:#fff,color:#fff
    style A4 fill:#0f3460,stroke:#fff,color:#fff

Hình 4: Router Pattern — intelligent dispatch tới agent phù hợp nhất

5.1. Tại sao Router tiết kiệm nhất?

Giả sử hệ thống nhận 1000 request/ngày với phân bố:

• 60% simple (FAQ) → Haiku: $0.001/request
• 25% medium (code/analysis) → Sonnet: $0.015/request
• 15% complex (reasoning) → Opus: $0.075/request

Không có Router: dùng Sonnet cho tất cả = 1000 × $0.015 = $15/ngày

Có Router: (600 × $0.001) + (250 × $0.015) + (150 × $0.075) + Router overhead = $16.1/ngày nhưng chất lượng output cho complex tasks tốt hơn nhiều với Opus.

Thực tế, Router giảm chi phí 30-60% khi phần lớn traffic là simple requests.

6. Pattern 5: Hierarchical (Multi-Level)

Mở rộng từ Supervisor pattern lên nhiều tầng. Phù hợp cho organization-scale workflows nơi một supervisor không đủ context để quản lý tất cả workers.

graph TD
    CEO["Strategic Agent
(Opus)"]
    CEO --> M1["Manager: Backend
(Sonnet)"]
    CEO --> M2["Manager: Frontend
(Sonnet)"]
    CEO --> M3["Manager: QA
(Sonnet)"]
    M1 --> W1["API Worker
(Haiku)"]
    M1 --> W2["DB Worker
(Haiku)"]
    M2 --> W3["UI Worker
(Haiku)"]
    M2 --> W4["Style Worker
(Haiku)"]
    M3 --> W5["Test Writer
(Sonnet)"]
    M3 --> W6["Test Runner
(Haiku)"]
    style CEO fill:#e94560,stroke:#fff,color:#fff
    style M1 fill:#0f3460,stroke:#fff,color:#fff
    style M2 fill:#0f3460,stroke:#fff,color:#fff
    style M3 fill:#0f3460,stroke:#fff,color:#fff
    style W1 fill:#4CAF50,stroke:#fff,color:#fff
    style W2 fill:#4CAF50,stroke:#fff,color:#fff
    style W3 fill:#4CAF50,stroke:#fff,color:#fff
    style W4 fill:#4CAF50,stroke:#fff,color:#fff
    style W5 fill:#4CAF50,stroke:#fff,color:#fff
    style W6 fill:#4CAF50,stroke:#fff,color:#fff

Hình 5: Hierarchical Pattern — management hierarchy với nhiều cấp agent

6.1. Khi nào cần Hierarchical?

Pattern này chỉ nên dùng khi:

• Có 10+ workers chuyên biệt
• Workers có thể group thành domains rõ ràng
• Mỗi domain cần coordination logic riêng
• Một supervisor đơn lẻ sẽ bị overwhelm bởi context length

7. Pattern 6: Evaluator-Optimizer Loop

Pattern này chạy iterative refinement: một agent generate output, agent khác đánh giá chất lượng, nếu chưa đạt threshold thì loop lại. Đặc biệt hiệu quả cho tasks cần chất lượng cao như code generation, content writing, hoặc data transformation.

graph TD
    I["Input + Requirements"] --> G["Generator Agent"]
    G --> E["Evaluator Agent"]
    E -->|"Score < threshold"| F["Feedback"]
    F --> G
    E -->|"Score >= threshold"| O["Final Output"]
    style G fill:#0f3460,stroke:#fff,color:#fff
    style E fill:#e94560,stroke:#fff,color:#fff
    style F fill:#ff9800,stroke:#fff,color:#fff
    style O fill:#4CAF50,stroke:#fff,color:#fff

Hình 6: Evaluator-Optimizer Loop — iterative refinement cho output chất lượng cao

7.1. Implementation Key Points

# Evaluator-Optimizer Loop
from claude_agent_sdk import Agent

async def eval_optimize_loop(task: str, max_iterations: int = 3):
    generator = Agent("generator", model="sonnet",
                      system="Generate solution based on requirements and feedback")
    evaluator = Agent("evaluator", model="opus",
                      system="Score output 1-10, provide specific feedback for improvement")

    output = await generator.run(task)

    for i in range(max_iterations):
        evaluation = await evaluator.run(
            f"Task: {task}\nOutput: {output}\nScore (1-10) and specific feedback:"
        )
        score = extract_score(evaluation)

        if score >= 8:
            return output  # Đạt threshold

        # Feed evaluation back to generator
        output = await generator.run(
            f"Original task: {task}\nPrevious attempt: {output}\n"
            f"Feedback: {evaluation}\nImprove the output:"
        )

    return output  # Max iterations reached

7.2. Giới hạn iterations

Luôn đặt max iterations (thường 2-4). Lý do:

• Diminishing returns: iteration 3+ hiếm khi cải thiện đáng kể
• Cost linear: mỗi iteration = full cost of generator + evaluator
• Infinite loop risk: evaluator có thể không bao giờ hài lòng

8. So sánh tổng hợp 6 Patterns

9. Protocols kết nối Agents: MCP vs A2A

Trong hệ sinh thái multi-agent 2026, hai protocol chính đang cạnh tranh và bổ trợ nhau:

10. SDK & Frameworks cho Production 2026

Ba framework chính đang dẫn đầu thị trường orchestration:

11. Hướng dẫn chọn Pattern phù hợp

Decision framework dựa trên đặc điểm bài toán:

graph TD
    Q1{"Các bước có
phụ thuộc nhau?"}
    Q1 -->|"Có"| Q2{"Cần quality
iterative?"}
    Q1 -->|"Không"| Q3{"Cần tất cả
kết quả?"}
    Q2 -->|"Có"| P6["Evaluator-Optimizer"]
    Q2 -->|"Không"| Q4{"Nhiều hơn
10 agents?"}
    Q4 -->|"Có"| P5["Hierarchical"]
    Q4 -->|"Không"| Q5{"Cần dynamic
delegation?"}
    Q5 -->|"Có"| P2["Supervisor"]
    Q5 -->|"Không"| P1["Sequential Pipeline"]
    Q3 -->|"Có"| P3["Fan-Out/Fan-In"]
    Q3 -->|"Không"| P4["Router"]
    style P1 fill:#4CAF50,stroke:#fff,color:#fff
    style P2 fill:#4CAF50,stroke:#fff,color:#fff
    style P3 fill:#4CAF50,stroke:#fff,color:#fff
    style P4 fill:#4CAF50,stroke:#fff,color:#fff
    style P5 fill:#4CAF50,stroke:#fff,color:#fff
    style P6 fill:#4CAF50,stroke:#fff,color:#fff
    style Q1 fill:#e94560,stroke:#fff,color:#fff
    style Q2 fill:#0f3460,stroke:#fff,color:#fff
    style Q3 fill:#0f3460,stroke:#fff,color:#fff
    style Q4 fill:#0f3460,stroke:#fff,color:#fff
    style Q5 fill:#0f3460,stroke:#fff,color:#fff

Hình 7: Decision tree chọn orchestration pattern

12. Best Practices cho Production

12.1. Observability là bắt buộc

Multi-agent system phức tạp hơn single-agent gấp nhiều lần về debugging. Minimum cần có:

• Distributed tracing: mỗi agent call là một span, trace toàn bộ chain
• Token counting per agent: biết agent nào đang tiêu tốn nhiều nhất
• Latency breakdown: P50, P95, P99 cho từng stage
• Error rate per agent: isolate agent gây lỗi

12.2. Cost Controls

// Cấu hình budget limits cho multi-agent system
const orchestratorConfig = {
  maxTokensPerRequest: 100_000,
  maxAgentCalls: 10,
  timeoutMs: 30_000,
  costLimitPerRequest: 0.50, // USD
  fallbackBehavior: 'return_partial' // hoặc 'error'
};

12.3. Graceful Degradation

Khi một agent trong chain fail, hệ thống không nên crash toàn bộ. Strategies:

• Timeout + fallback: agent không response trong N giây → dùng cached result hoặc simpler model
• Circuit breaker: agent fail 3 lần liên tiếp → bypass và log
• Partial results: trả kết quả những agents đã complete thay vì fail toàn bộ

Nguồn tham khảo:

• AI Agent Orchestration Patterns — Azure Architecture Center
• 6 Multi-Agent Orchestration Patterns for Production — Beam AI
• Claude Agents SDK vs OpenAI Agents SDK vs Google ADK — Composio
• MCP vs A2A: Complete Guide to AI Agent Protocols 2026 — DEV Community
• Multi Agent Architecture: Patterns, Use Cases & Production Reality — TrueFoundry