Anthropic Exam ProDomain 1: Agentic Architecture & Orchestration·Task 1.2
Điều phối nhiều agent theo mô hình coordinator–subagent
Agent điều phối chia việc cho các subagent rồi gom kết quả. Cách chia cho đủ, không trùng, và vì sao mọi trao đổi nên đi qua agent điều phối.
- 7 phút đọc
- Đối chiếu docs 02/11/2026
- 3 nguồn
Đọc xong bạn nắm được
- Hiểu mô hình một agent điều phối đứng giữa, các subagent xung quanh
- Biết subagent không tự thấy cuộc hội thoại của agent điều phối
- Chia phạm vi cho các subagent để không sót và không trùng
- Thiết kế vòng lặp kiểm tra chỗ còn thiếu rồi giao việc bổ sung
- Nhận ra khi lỗi nằm ở cách chia việc chứ không ở subagent
Khi một việc quá lớn cho một agent, ta có thể dùng nhiều agent: một agent đứng ra điều phối, chia việc cho các agent con, rồi gom kết quả lại. Agent điều phối gọi là coordinator, các agent con gọi là subagent.
Nghe đơn giản, nhưng hệ thống kiểu này hay hỏng ở chỗ chia việc và chỗ truyền thông tin. Bài này giúp bạn trả lời: agent điều phối phải làm những việc gì, chia việc thế nào cho đủ, và vì sao các subagent không nên nói chuyện trực tiếp với nhau?
Ví dụ xuyên suốt: báo cáo về thị trường xe máy điện
Một công ty tư vấn dựng hệ thống viết báo cáo thị trường gồm:
- Agent điều phối: nhận đề bài, chia việc, gom kết quả.
- Subagent tìm kiếm: tìm bài báo, số liệu trên web.
- Subagent đọc tài liệu: đọc các báo cáo PDF dài và tóm tắt.
- Subagent tổng hợp: viết báo cáo cuối từ những gì hai subagent trên tìm được.
Đề bài: "Thị trường xe máy điện ở Việt Nam trong 3 năm tới."
Lần chạy đầu, báo cáo viết rất mạch lạc nhưng chỉ nói về giá xe và các hãng xe. Không có chữ nào về trạm sạc, pin, hay chính sách của nhà nước. Cả ba subagent đều chạy không lỗi. Vậy hỏng ở đâu? Mục cuối bài sẽ trả lời.
Mô hình hub-and-spoke
Mô hình này giống bánh xe đạp: agent điều phối ở trục giữa, các subagent là nan hoa. Tiếng Anh gọi là hub-and-spoke. Mọi trao đổi đều đi qua trục:
- Subagent nhận việc từ agent điều phối và trả kết quả về agent điều phối.
- Subagent tìm kiếm không gửi thẳng kết quả cho subagent tổng hợp. Agent điều phối nhận rồi chuyển tiếp.
- Subagent nào gặp lỗi thì báo về agent điều phối, và agent điều phối quyết định làm gì tiếp.
Đi vòng qua trục như vậy có ba cái lợi mà đề thi hay nhắc:
| Lợi ích | Nghĩa là |
|---|---|
| Dễ theo dõi (observability) | Mọi thông tin đều đi qua một chỗ, xem log của agent điều phối là biết chuyện gì đã xảy ra |
| Xử lý lỗi thống nhất | Lỗi ở đâu cũng về một nơi xử lý, không mỗi subagent tự xử lý một kiểu |
| Kiểm soát luồng thông tin | Agent điều phối quyết định ai được nhận thông tin gì |
Subagent không thấy những gì agent điều phối thấy
Mỗi subagent chạy với một ngữ cảnh riêng (isolated context). Nó không tự động nhận được cuộc hội thoại của agent điều phối. Theo tài liệu Agent SDK, thứ duy nhất đi từ agent điều phối sang subagent là đoạn prompt mà agent điều phối viết khi giao việc.
Trong ví dụ, nếu khách hàng dặn agent điều phối "chỉ lấy số liệu từ năm 2023 trở đi", mà agent điều phối không ghi câu này vào prompt giao cho subagent tìm kiếm, thì subagent tìm kiếm không hề biết.
Chiều ngược lại cũng vậy: subagent làm bao nhiêu bước trung gian, agent điều phối chỉ nhận về câu trả lời cuối cùng của nó. Nhờ vậy ngữ cảnh của agent điều phối không bị lấp đầy bởi hàng trăm kết quả tìm kiếm.
Cách viết prompt giao việc cho đủ thông tin nằm ở bài 1.3.
Agent điều phối làm những gì
Agent điều phối có bốn việc chính:
- Chia việc (task decomposition): tách đề bài thành các phần nhỏ.
- Giao việc (delegation): chọn subagent nào làm phần nào.
- Gom kết quả (result aggregation): nhận kết quả các subagent và ghép lại.
- Chọn subagent theo độ khó của câu hỏi: không phải lúc nào cũng gọi đủ cả ba subagent.
Việc thứ tư hay bị bỏ qua. Nếu khách chỉ hỏi "Tháng này có hãng nào ra mẫu xe máy điện mới không?", gọi một subagent tìm kiếm là đủ. Bắt câu hỏi này chạy qua cả tìm kiếm, đọc tài liệu và tổng hợp là phí thời gian và tiền.
Bài viết của Anthropic về hệ thống nghiên cứu nhiều agent của họ cho con số tham khảo: hỏi một sự thật đơn giản chỉ cần một agent với khoảng 3–10 lần gọi tool, còn nghiên cứu phức tạp mới cần hơn 10 subagent. Cũng theo bài đó, hệ thống nhiều agent tốn khoảng 15 lần số token so với một cuộc chat thường, nên chỉ đáng dùng cho việc đủ lớn.
Chia việc cho đủ và không trùng
Có hai lỗi chia việc hay gặp:
- Chia quá hẹp: các phần cộng lại không phủ hết đề bài.
- Chia chồng lên nhau: hai subagent cùng tìm một thứ, phí công mà kết quả lặp lại.
Cách tránh là giao cho mỗi subagent một phạm vi rõ ràng, không giao nhau. Ví dụ chia theo chủ đề con:
| Subagent | Phạm vi |
|---|---|
| Tìm kiếm 1 | Giá xe, các hãng, doanh số |
| Tìm kiếm 2 | Hạ tầng trạm sạc và đổi pin |
| Tìm kiếm 3 | Chính sách nhà nước, thuế, quy định khí thải |
Hoặc chia theo loại nguồn: một subagent đọc báo, một subagent đọc báo cáo của các công ty nghiên cứu thị trường.
Vòng lặp tìm chỗ còn thiếu
Một agent điều phối tốt không dừng ngay khi nhận bản tổng hợp đầu tiên. Nó đọc bản tổng hợp, tìm chỗ còn thiếu, rồi giao thêm việc. Tiếng Anh gọi là iterative refinement loop:
- Bản tổng hợp còn thiếu mảng nào của đề bài?Giao subagent tìm kiếm tìm đúng mảng đó
- Có số liệu mâu thuẫn hoặc chưa có nguồn?Giao subagent đọc tài liệu kiểm lại
- Vừa có thông tin mới?Gọi lại subagent tổng hợp với thông tin mới
- Còn lạiĐủ rồi: gửi báo cáo
Trong ví dụ, nếu có bước này, agent điều phối sẽ thấy báo cáo thiếu hẳn mảng trạm sạc và chính sách, rồi giao thêm việc trước khi gửi khách.
Báo cáo thiếu ý thì lỗi ở đâu
Quay lại câu hỏi đầu bài. Xem log của agent điều phối, bạn thấy nó đã chia đề bài thành ba phần: "giá xe máy điện", "các hãng xe máy điện", "doanh số xe máy điện". Cả ba phần đều xoay quanh chiếc xe. Không phần nào nói tới trạm sạc, pin hay chính sách.
Các subagent đã làm đúng việc được giao. Lỗi nằm ở chính cách chia việc: agent điều phối chia quá hẹp.