Multi-agent

Multi-agent là chia một tác vụ cho nhiều agent, mỗi agent có ngữ cảnh riêng. Đây không phải kỹ thuật để “thông minh hơn” - nó giải quyết đúng hai vấn đề: ngữ cảnh hữu hạn và thiên vị với công việc của chính mình.

Hai lý do chính đáng để dùng multi-agent

1. Ngữ cảnh: đẩy việc ngốn ngữ cảnh ra ngoài

Việc khám phá đọc rất nhiều file, nhưng bạn chỉ cần kết luận. Một subagent đọc 30 file trong ngữ cảnh riêng và trả về 20 dòng tóm tắt - ngữ cảnh chính chỉ nhận 20 dòng.

Đây là lý do có giá trị nhất, và nó thuần túy về context engineering.

2. Thiên vị: một ngữ cảnh mới review tốt hơn

Model vừa viết code có xu hướng bảo vệ code đó. Một agent mới, chỉ thấy diff và tiêu chí bạn đưa - không thấy chuỗi suy luận đã tạo ra nó - sẽ đánh giá kết quả một cách độc lập.

Đây là lý do pattern Writer–Reviewer hiệu quả, và là lý do /code-review chạy trong subagent chứ không trong phiên chính.

Các pattern

Pattern	Hình dạng	Dùng khi
Orchestrator–Worker	Một agent chính giao việc con cho nhiều worker, gộp kết quả	Việc chia được thành các phần độc lập (đọc nhiều module, migrate nhiều file)
Writer–Reviewer	Một agent làm, một agent khác review trong ngữ cảnh sạch	Trước khi coi việc là xong; kiểm tra diff đối chiếu kế hoạch
Judge panel	N agent giải cùng bài theo các hướng khác nhau, một agent chấm và tổng hợp	Không gian giải pháp rộng, chưa rõ hướng nào đúng
Adversarial verify	N agent được yêu cầu phản biện một phát hiện; giữ lại nếu đa số không phản biện được	Loại bỏ phát hiện “nghe hợp lý nhưng sai”
Pipeline	Mỗi item đi qua nhiều chặng độc lập, không chờ nhau	Xử lý nhiều item với các bước giống nhau
Loop-until-dry	Tiếp tục sinh agent tìm kiếm đến khi K lượt liền không tìm thêm gì mới	Khám phá không biết trước quy mô (tìm bug, tìm edge case)

Cái giá phải trả

Multi-agent không miễn phí, và trong nhiều trường hợp không đáng:

Chi phí nhân lên. Mỗi agent phải dựng lại ngữ cảnh từ đầu, khám phá lại, rồi báo cáo - và agent chính lại phải đọc báo cáo đó. Ba lần trả tiền cho cùng một thông tin.
Ngữ cảnh không chia sẻ. Các subagent chia sẻ filesystem nhưng không chia sẻ lịch sử hội thoại. Điều gì orchestrator muốn worker biết thì phải nói ra trong lời giao việc (hoặc ghi ra file).
Độ trễ theo agent chậm nhất. Nếu có rào cản chờ đồng bộ (barrier), toàn bộ phải chờ agent chậm nhất.
Xung đột ghi file. Nhiều agent sửa cùng file song song thì đè lên nhau. Dùng git worktree để cô lập.
Khó debug. Khi kết quả sai, phải truy qua nhiều transcript để biết agent nào hiểu sai gì.

Quy tắc thực dụng: nếu bạn tự làm xong việc đó trong vài lần gọi tool, đừng giao cho subagent. Chi phí dựng lại ngữ cảnh vượt phần tiết kiệm được.

Multi-agent trong Claude Code

Cơ chế	Là gì
Subagent	Agent chạy trong ngữ cảnh riêng, có bộ tool riêng, trả về tóm tắt. Gọi bằng `Task` hoặc nói “dùng subagent để…”
Fork	Bản sao hội thoại hiện tại - thừa hưởng cả ngữ cảnh và system prompt của agent cha
Worktree	Mỗi phiên một git checkout riêng trên branch riêng - cô lập ở mức filesystem
Agent team	Nhiều phiên được phối hợp tự động, có task dùng chung, nhắn tin giữa các agent, và một team lead
Workflow	Script điều phối nhiều subagent một cách tất định - bạn viết vòng lặp/điều kiện/fan-out bằng code, không để model quyết

Điểm phân biệt quan trọng giữa hai cái cuối: agent team để model tự phối hợp; workflow để bạn quyết định cấu trúc phối hợp bằng code. Workflow phù hợp khi bạn muốn đảm bảo “N agent này chạy song song, rồi kết quả đi qua bước xác minh này” - chứ không phải hy vọng model tự nghĩ ra cấu trúc đó.

Thiết kế lời giao việc cho subagent

Chất lượng kết quả phụ thuộc gần như hoàn toàn vào lời giao việc, vì subagent không thấy hội thoại của bạn:

Nêu đủ ngữ cảnh. Subagent không biết bạn đã bàn gì với agent chính.
Nêu rõ định dạng kết quả cần trả về. “trả về danh sách đường dẫn file kèm một dòng giải thích mỗi file” tốt hơn “tìm hiểu về auth”.
Khoanh phạm vi. Không khoanh → subagent đọc hàng trăm file, chậm và tốn.
Giao đủ ngay lần đầu. Giao dở, chờ, rồi giao lại là mất trắng chi phí dựng ngữ cảnh.
Cam kết với việc đã giao. Đừng tự làm lại việc subagent vừa làm hay tự suy ra lại kết luận của nó.

Đọc thêm

Subagent - cách tạo và cấu hình.
Context engineering - lý do gốc của multi-agent.
Đánh giá & độ tin cậy - dùng agent để kiểm chứng agent.
Best practices - chạy song song trong thực tế.