Series 4 - Bài 6: Failure Modes trong Multi-Agent System

Multi-agent system fail khác single-agent fail. Không phải một điểm fail rõ ràng — mà là subtle failures lan rộng qua nhiều agents, thường không có error message rõ ràng.

Hiểu failure modes là bước đầu tiên để design system có thể survive chúng.

Failure Mode 1: Cascade Failure

Cascade:

  Orchestrator giao task cho 3 workers:
    Worker A: Analyze
    Worker B: Implement (cần A's output)
    Worker C: Test (cần B's output)

  Worker A fail →
    Orchestrator retry A (fail lần 2) →
    Orchestrator giao cho A2 (backup) →
    A2 return partial result →
    Worker B nhận partial result, proceed →
    B output sai →
    Worker C test sai output → kết quả có vẻ pass →
    Orchestrator report success →
    User nhận buggy result

  Chỉ một fail → chain của silent failures

Phòng chống:

• Define "sufficient" output spec rõ ràng
  B không accept partial result từ A
  B trả lỗi nếu input không đủ

• Orchestrator validate output trước khi handoff
  Kiểm tra output A đủ fields và format không
  Chỉ pass sang B khi đã validate

• Circuit breaker: fail fast thay vì degrade silently
  Sau N retry thất bại → abort toàn bộ pipeline
  Report rõ ràng cho user thay vì silent degrade

Failure Mode 2: Coordination Deadlock

Deadlock:

  Worker A chờ Worker B complete một phần
  Worker B chờ Worker A complete một phần khác

  Ví dụ thực tế:
  A: "Tôi cần biết B đã xác nhận schema trước khi viết code"
  B: "Tôi cần xem code hiện tại của A trước khi xác nhận schema"

  Cả hai đợi nhau → timeout → orchestrator stuck

Phòng chống:

• Design dependency graph không có cycles
  Trước khi run, validate: có circular dependency không?
  Nếu có → redesign task breakdown

• Timeout cho mọi wait
  Không bao giờ wait indefinitely
  Sau timeout → orchestrator can thiệp, quyết định

• Orchestrator là tie-breaker
  Nếu hai workers có conflict → orchestrator quyết
  Không để workers tự resolve việc của nhau

Failure Mode 3: Context Drift

Context Drift:

  Session bắt đầu:
  Orchestrator: "Refactor payment service, không thêm deps"

  Sau 20 turns + nhiều worker handoffs:
  Context gốc bị diluted bởi:
    • Tool results (10,000 tokens)
    • Worker summaries (5,000 tokens)
    • Intermediate decisions (3,000 tokens)

  Original constraint "không thêm deps" nằm ở giữa context
  → LLM "quên" constraint này (lost in the middle)
  → Worker suggest thêm lodash dependency
  → Orchestrator approve không kiểm tra

Phòng chống:

• Re-inject original constraints mỗi turn
  Orchestrator luôn include original user constraints
  trong mỗi task delegation

• Constraints không được nằm trong history
  Constraints ở system prompt, không trong conversation
  → Lúc nào cũng có attention mạnh

• Constraint validation trong synthesis step
  Orchestrator kiểm tra final output trước khi report
  xét từng constraint user đã nêu

Failure Mode 4: Hallucinated Coordination

Hallucinated Coordination:

  Orchestrator LLM assume một worker đã làm gì đó
  mà thực ra worker chưa làm.

  Orchestrator: "Based on what Worker A found earlier..."
  Thực tế: Worker A chưa chạy, orchestrator hallucinate

  → Orchestrator gửi fake context cho Worker B
  → B proceed với false premise
  → B's output sai toàn bộ

Phòng chống:

• Explicit task tracking
  Orchestrator maintain state machine:
  task_A: pending | running | done | failed
  Không ever refer đến "what A found"
  nếu task_A.status != "done"

• Structured handoff (không trust LLM memory)
  Orchestrator không rely vào LLM để remember
  worker results. Store explicit trong code.
  LLM chỉ synthesize — không là source of truth.

Failure Mode 5: Quality Regression

Quality Regression:

  Từng worker individually produce quality output.
  Khi aggregate:
    Worker A: recommend X
    Worker B: recommend not-X (mâu thuẫn)
    Worker C: recommend X with conditions

  Orchestrator aggregate: nên làm X hay không?
  Nếu orchestrator prompt không đủ rõ về conflict resolution
  → Orchestrator chon arbitrarily
  → Final output worse than any individual worker

Phòng chống:

• Explicit conflict resolution policy trong orchestrator prompt
  "Nếu workers có conflicting recommendations:
   1. Hiển thị cả hai cho user
   2. Giải thích trade-off
   3. Để user quyết định nếu không có objective tiebreaker"

• Worker specialization rõ ràng
  Nếu workers được specialized đúng, tần suất conflict giảm
  Security worker và Performance worker có different concern
  Không cùng comment về cùng điều

Failure Detection: Observability bất buộc

Mọi agent phải emit:

  start_event: { agent_id, task_id, timestamp }
  end_event:   { agent_id, task_id, status, duration }
  tool_event:  { agent_id, tool, input, output, duration }
  error_event: { agent_id, error_type, message, recoverable }

Orchestrator track:
  task_states: Map<task_id, state>
  worker_states: Map<worker_id, state>
  timeout_watchdog: alert nếu task chạy quá lâu

Không có observability, failure ở đâu trong system là mystery.

Kết luận

• Cascade failure: một worker fail → silent degrade qua chain. Fix bằng strict output validation và circuit breaker.
• Coordination deadlock: agents chờ nhau. Fix bằng acyclic dependency graph và timeout.
• Context drift: original constraints bị lost. Fix bằng re-inject constraints và explicit validation.
• Hallucinated coordination: orchestrator assume kết quả chưa có. Fix bằng explicit state tracking trong code.
• Quality regression: aggregate worse than individual. Fix bằng conflict resolution policy rõ ràng.
• Observability là bắt buộc — không thể debug distributed agent system mà không có traces.