- Sub-agents chạy cô lập, fire-and-forget, phù hợp pipeline 2-4 bước tuần tự.
- Agent Teams dùng shared task list peer-to-peer, rẻ hơn 3-5 lần ở quy mô 10+ agents song song.
- Chọn sai kiến trúc là sai ngay từ đầu - không phải optimize sau.
TL;DR
Câu hỏi đúng không phải "có nên dùng nhiều agent không?" mà là "task này cần kiểu phối hợp gì?"
Claude cung cấp hai paradigm riêng biệt: sub-agents (cô lập, fire-and-forget) và agent teams (persistent, peer-to-peer). Bề ngoài giống nhau - nhưng về kiến trúc, chúng giải quyết hai bài toán hoàn toàn khác nhau. Chọn sai từ đầu, tối ưu sau không cứu được.
Nhầm lẫn mà hầu hết mọi người mắc phải
Task phức tạp - phản xạ đầu tiên của hầu hết mọi người là đẽo ngay một hệ multi-agent. Đó gần như luôn là instinct sai.
Việc chia công việc theo role (planner, implementer, tester) trông có vẻ gọn gàng, nhưng thực ra tạo ra một telephone game: implementer không có đủ context của planner, tester không biết những quyết định implementer đã đưa ra. Chất lượng rớt ở mỗi handoff.
Tư duy đúng là context-centric decomposition: hỏi "subtask này thực sự cần context gì?" Nếu hai subtask cần thông tin chồng chéo nhiều, chúng thuộc về cùng một agent. Chỉ tách khi context có thể genuinely isolated.
Sub-agents - Cô lập để song song hóa
Sub-agent là một Claude instance chuyên biệt chạy trong context window riêng biệt hoàn toàn. Mental model chuẩn: bạn là research lead. Bạn không đọc từng nguồn tài liệu gốc - bạn giao câu hỏi tập trung cho các researcher, họ trả về findings đã distill, và bạn tổng hợp output cuối. Đó chính xác là sub-agents làm.
Mỗi sub-agent có:
- System prompt định nghĩa chuyên môn riêng
- Bộ tool riêng chỉ dùng cho nhiệm vụ của nó
- Context window sạch, isolated
- Một job duy nhất cần hoàn thành
Field description trong AgentDefinition là routing signal - đây là thứ orchestrator dùng để quyết định gọi agent nào. Nếu prompt nói "security vulnerabilities" thì agent security-reviewer được chọn, không phải performance-optimizer. Viết description cụ thể, không viết chung.
Sub-agents là fire-and-forget: nhận task, hoàn thành, báo cáo lại. Không có memory giữa các lần gọi, không có trạng thái tồn tại, không có giao tiếp giữa các sub-agent với nhau.
Điểm yếu ở quy mô lớn: mọi kết quả đều chảy về context của orchestrator. Với pipeline 10+ sub-agents, orchestrator có thể tích lũy 20,000+ tokens - đắt và dễ hit context limit.
Agent Teams - Phối hợp qua trạng thái chung
Agent Teams là model hoàn toàn khác. Sub-agents là workers tạm thời - Agent Teams là team tồn tại lâu dài, giao tiếp trực tiếp, phối hợp qua shared state.
Ba thành phần cốt lõi:
- Team lead - điều phối công việc, giao task, tổng hợp kết quả
- Teammates - các agent instance độc lập, mỗi cái có context window riêng, chạy song song
- Shared task list - kanban board dùng chung: theo dõi trạng thái (pending, in-progress, completed) và dependencies giữa các task
Điểm khác biệt lớn nhất so với sub-agents: giao tiếp peer-to-peer trực tiếp. Teammates có thể nhắn tin cho nhau, chia sẻ findings, báo blocker mà không cần đi qua lead. Frontend agent có thể nói với backend agent "cấu trúc API response cần thay đổi" và backend agent điều chỉnh ngay.
Field blockedBy trong task list làm thật sự tự động hóa sequencing: test-writer không start cho đến khi backend-dev xong, không cần lead quản lý thủ công.
Hiệu quả token ở quy mô lớn: mỗi teammate chỉ load 2,000-4,000 tokens context cần thiết cho task của mình, thay vì orchestrator phải accumulate tất cả. Với 10+ agents, teams rẻ hơn 3-5 lần so với sub-agent pattern.
Lưu ý quan trọng: Agent Teams hiện còn experimental, disabled by default. Cần enable qua env var CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS và Claude Code v2.1.32+.
Khi nào dùng cái nào
| Tiêu chí | Sub-agents | Agent Teams |
|---|---|---|
| Quy mô | 2-4 bước | 10+ agents song song |
| Giao tiếp | Qua orchestrator | Peer-to-peer trực tiếp |
| Token efficiency | Tốt khi nhỏ | 3-5x rẻ hơn ở quy mô lớn |
| Debugging | Dễ (single control flow) | Khó hơn (distributed) |
| Setup | Đơn giản | Phức tạp hơn |
| Dependencies | Mạnh, sequential | Cần đặt task ordering |
Dùng sub-agents khi công việc embarrassingly parallel: research độc lập, exploration codebase, lookup - nơi parent chỉ cần summary. Dùng agent teams khi công việc cần ongoing negotiation: agents cần reconcile output trước khi tiến tiếp, hoặc discovery trong một thread ảnh hưởng thread khác.
5 patterns phối hợp agent thực tế
Bất kể dùng paradigm nào, 5 patterns này bao phủ hầu hết nhu cầu thực tế:
- Prompt chaining - bước tuần tự, mỗi call xử lý output của bước trước. Dùng khi thứ tự quan trọng và các bước phụ thuộc nhau.
- Routing - classifier quyết định handler nào nhận task. Câu dễ đi Haiku, câu khó đi Sonnet. Đây là cách kiểm soát chi phí không bị bùng.
- Parallelization - subtasks độc lập chạy đồng thời. Hai dạng: sectioning (chia task khác nhau) và voting (chạy cùng task nhiều lần để lấy confidence).
- Orchestrator-workers - agent trung tâm phân rã task, delegate cho workers, tổng hợp kết quả. Đây là kiến trúc dominant trong production.
- Evaluator-optimizer - một agent generate, một agent evaluate và feedback trong loop. Dùng khi quality quan trọng hơn speed.
Ba lỗi khiến multi-agent thất bại
Nhiều team đã mất hàng tháng xây pipeline multi-agent phức tạp, rồi phát hiện prompting tốt hơn trên single agent cho kết quả tương đương. Start simple.
1. Task descriptions mơ hồ: Agent không có objective rõ ràng sẽ duplicate công việc của nhau mà không ai biết. Mỗi agent cần: mục tiêu cụ thể, output format, nguồn/tool nào dùng, và explicit boundaries về những gì không cần cover.
2. Verification agent không verify thật: Thiếu instruction cụ thể ("chạy full test suite, cover đủ N cases, không mark complete cho đến khi từng case pass") sẽ tạo ra false positives.
3. Token cost tăng nhanh hơn dự tính: Tier model theo mức độ quan trọng thực sự. Route công việc routine về model rẻ hơn. Build budget controls.
Một cảnh báo đặc biệt cho coding: parallel agents viết code sẽ tạo ra implicit assumptions xung đột. Khi merge lại, những quyết định ngầm đó conflict theo cách cực khó debug. Sub-agents cho coding nên answer questions và explore - không viết code song song với main agent.
Kết luận
Design agent systems từ first principles: hỏi context thực sự cần là gì, không phải split theo role hay org chart.
Start với single agent. Push nó đến điểm gãy. Failure point đó sẽ cho biết chính xác cần thêm gì. Multi-agent systems xứng đáng với chi phí khi context bloat là vấn đề thật, khi parallelism mang lợi ích đo được, hoặc khi task genuinely cần conflicting system prompts.
Thêm complexity chỉ khi nó giải quyết vấn đề đo được - không phải vì task "có vẻ phức tạp".
Nguồn: Claude Code Docs - Sub-agents, Claude Code Docs - Agent Teams, Anthropic Engineering Blog.