Tại sao cần nhiều agent? — Khi single agent bất lực trước task phức tạp

Bạn đã từng chứng kiến agent demo chạy mượt mà trên laptop, nhưng khi deploy lên production với dữ liệu thật thì "tan nát"? Đó là hiện tượng thường gặp: single agent hoạt động như một developer solo cố gắng làm đồng thời architect, DevOps, tester và technical writer — kết quả là context window biến thành bãi rác, lỗi một chỗ lan truyền xuyên suốt 20 bước suy luận, và agent dần "quên" mục tiêu ban đầu. Bài viết này phân tích tại sao single agent thất bại trên task phức tạp, và tại sao kiến trúc multi-agent không phải là "bonus" mà là bắt buộc để đạt độ ổn định production.

Vấn đề

Single LLM agent hoạt động như một bộ não đơn độc phải đồng thời: lập kế hoạch (planning), truy xuất bộ nhớ (retrieval), gọi tool (tool use), và tự kiểm tra (critique). Khi task vượt quá 3 lĩnh vực cognitive domain khác nhau (ví dụ: phân tích tài chính + viết code + review bảo mật), hiện tượng "mode collapse" xảy ra — mô hình bị kẹt giữa các vai trò, mỗi vai trò "lây nhiễm" context của vai trò khác.

Các failure modes đã được Microsoft AI Red Team và cộng đồng nghiên cứu xác định bao gồm:

1. Context Degradation: Cơ chế attention của Transformer gán trọng số mũ cho token gần nhất. Sau 50 turns hội thoại, constraint quan trọng ở turn 1 bị "pha loãng" không phải do giới hạn bộ nhớ, mà do attention dilution — zero-sum game giữa các token.
2. Specification Drift: Instruction ban đầu bị tái diễn dịch (reinterpreted) dựa trên statistical likelihood của context hiện tại thay vì ý định gốc. Agent bắt đầu "sáng tạo" giải pháp lệch lạc vì nó "nghĩ" bạn muốn vậy.
3. Scope Creep: Không có compile-time constraint, agent lan sang hành động ngoài phạm vi (ví dụ: xóa database production khi được hỏi "clean up test data") bằng lý lẽ "giúp đỡ" nghe có vẻ hợp lý.
4. Error Cascade: Một hallucination ở bước 3 (truy xuất sai document) được dùng làm premise cho 17 bước sau, tạo thành "laundered error" — sai lầm được "giặt sạch" qua nhiều lớp reasoning trung gian, khó phát hiện hơn sai lầm trực tiếp.

Reddit community và paper arXiv:2503.13657 ghi nhận: trên task đơn giản, single agent tối ưu có thể ngang multi-agent; nhưng trên task phức tạp đa bước (multi-step), tỷ lệ thất bại của single agent lên tới 90% trong production, trong khi multi-agent giảm xuống còn ~40% capability boost khi có tool optimization (và giảm hơn nữa khi có kiến trúc tốt).

Ý tưởng cốt lõi

Multi-agent không phải là "nhiều agent cho vui" — nó là kiến trúc encapsulation tương tự như chia monolith thành microservices. Dưới đây là 4 trụ cột kỹ thuật:

Context Sharding: Phân mảnh để tránh "lost in the middle"

Thay vì nhét 10 quy trình khác nhau vào một system prompt 8K tokens, mỗi agent nắm giữ shard (mảnh) context riêng biệt. Agent A chỉ thấy spec kiến trúc, Agent B chỉ thấy codebase, Agent C chỉ thấy test cases.

Hệ quả trực tiếp: recency bias bị cô lập trong từng shard. Khi Agent B viết code, nó không bị "nhiễu" bởi constraint marketing mà Agent A đang xử lý. Đây là cách triển khai lý thuyết "working memory" của Cowan (4±1 chunks) vào AI — giới hạn attention span có chủ đích thay vì cố gắng mở rộng context window vô tận.

Role Specialization: Mỗi agent một "danh tính"

Trong role-based agents, mỗi agent được gán persona cứng (architect, builder, reviewer) với toolset riêng. Ví dụ GoClaw sử dụng AGENTS.md định nghĩa:

## Coder Agent
**Tools**: file_edit, shell_exec, git_commit  
**Blocked by**: Security Review Agent  
**Shared workspace**: /workspace/shared/

## Security Review Agent  
**Tools**: static_analysis, dependency_check
**Inbound permissions**: read-only on /workspace/src/

Sự phân chia này tạo ra cognitive firewalls: architect không biết cụ thể lệnh shell nào có sẵn, nên không thể "tạm thời" viết lệnh nguy hiểm khi đang thiết kế. Đây là capability-based security — agent chỉ "thấy" những gì được phép thấy qua permission links (outbound/inbound/bidirectional) như đã phân tích trong agent communication patterns.

Failure Containment: Cô lập "blast radius"

Khi Agent B hallucinate và xóa nhầm file, lỗi này không lan sang Agent A đang xử lý planning. Kiến trúc này dùng shared task board (blackboard pattern) — các agent ghi trạng thái vào /workspace/shared/task_board.json dưới dạng append-only log, không trực tiếp manipulate state của nhau.

Ví dụ trong GoClaw:

task_board:
  - task_id: 1
    status: in_progress
    owner: coding_agent
    blocked_by: [architecture_approval]
    checkpoint: "src/api/routes.py"

Nếu coding_agent "đi lạc" và sửa file sai, orchestrator có thể rollback chỉ checkpoint của agent đó mà không ảnh hưởng context của agent khác. Đây là transaction boundary giữa các agent.

Orchestration: Tuần tự, song song, và evaluate loops

Không phải lúc nào cũng cần nhiều agent chạy đồng thời. Orchestration patterns cho phép:

• Sequential: Extract → Transform → Load, mỗi bước một agent chuyên môn, tránh "context pollution" giữa các phase.
• Parallel: Fan-out đến 3 research agent độc lập, sau đó aggregator agent vote kết quả — giảm variance 66% theo benchmark SMAC (StarCraft).
• Evaluate Loops: Generator agent viết code → Critic agent review → Generator sửa. Loop dừng khi Critic "pass" hoặc đạt max iteration.

Tại sao nó hoạt động

Bản chất toán học: Transformer attention là zero-sum. Khi bạn nhét "làm sao viết React hook" và cùng lúc "check security OWASP Top 10" vào cùng một context, các token trọng số attention cạnh tranh nhau. Agent phải "juggle" liên tục, dẫn đến interference — hiện tượng gradient descent trong không gian xác suất bị kéo lệch bởi nhiều objective function.

Tương tự tổ chức con người: Một developer solo không thể đồng thời làm code review chính mình với độ khách quan cao. Separation of concerns tạo ra "division of cognitive labor" — mỗi agent optimize cho một reward function duy nhất (architect: feasibility; coder: syntax correctness; reviewer: security).

Hard boundaries vs Soft prompts: Single agent dùng prompt để "nhắc nhở" ("Hãy nhớ kiểm tra bảo mật") — đây là soft constraint dễ bị override bởi recency bias. Multi-agent dùng MCP (Model Context Protocol) và permission links để tạo hard boundary: agent coder đơn giản không có tool deploy_to_production trong schema, nên không thể gọi dù muốn.

Ý nghĩa thực tế

Khi nào dùng single agent, khi nào bắt buộc multi-agent?

Quy tắc vàng từ cộng đồng: "Simplicity scales better than coordination" — nếu task của bạn chưa cần đến 3 domain khác nhau, single agent + good tooling vẫn thắng. Chỉ chuyển sang multi-agent khi bạn thấy agent "quên" constraint sau 10 turn hoặc lỗi cascade xuyên suốt workflow.

Production realities

• Claude Code Sub-Agents (Anthropic 2026): Tự động spawn sub-agent cho từng file lớn, tránh "context bloat" trong main session.
• CrewAI: Yêu cầu định nghĩa rõ role, goal, backstory cho mỗi agent — tạo "identity file" để tránh role dilution.
• AutoGen: Dùng GroupChat để các agent "tranh luận" trước khi đưa ra quyết định — tận dụng "echo chamber" có kiểm soát để bắt lỗi sớm.

Trade-off phải chấp nhận

Multi-agent không miễn phí:

1. Coordination overhead: Mỗi handoff giữa agent tốn 1-2 giây (LLM round-trip) + token cost cho context serialization.
2. Echo chamber risk: Agent có thể "củng cố" hallucination của nhau nếu không có ground truth (shared task board với append-only log).
3. Complexity explosion: Debugging multi-agent giống như debug distributed system — cần observability với span tracing qua từng agent.

Đào sâu hơn

Docs & Papers:

• "Why Do Multi-Agent LLM Systems Fail?" (arXiv:2503.13657) — Phân tích 14 failure modes cụ thể chia thành 3 nhóm: Interaction, Alignment, Task.
• "MAST Taxonomy" (Galileo 2026) — Framework phân loại Memory, Action, Specification, Temporal failures.
• Microsoft AI Red Team Whitepaper (2025) — Phân biệt Safety vs Security failures trong agent systems.

Cùng cụm Multi-Agent & Teams:

• Agent Teams: Shared task board, delegation, handoff — Cấu hình GoClaw blocked_by và permission links cụ thể.
• Agent Communication: Permission links, direction control, concurrency — Hiểu sâu về inbound/outbound/bidirectional links và ACP protocol.
• Role-based Agents: Mỗi agent một chuyên môn — Chi tiết về SIRD method và structural role discovery.
• Orchestration Patterns: Sequential, parallel, evaluate loops — Chọn đúng topology cho workflow của bạn.

Đọc tiếp:

• Hooks & Quality Control — Thêm 25+ lifecycle events để kiểm soát chất lượng giữa các agent handoff.
• Kiến trúc nâng cao (Level 2) — Khi cần scale lên 1000+ agents và xử lý Byzantine fault tolerance.