Bài học từ hệ thống nghiên cứu đa agent của Anthropic
Tóm tắt
Hệ thống đa agent của Anthropic tốt hơn 90,2% so với một agent trên eval nghiên cứu nội bộ, nhưng tiêu khoảng 15 lần token so với chat. Chỉ đáng dùng cho việc giá trị cao, chia nhỏ song song được; giao việc rõ và đánh giá sớm.
Nghiên cứu một chủ đề phức tạp là việc khó đoán trước: không biết cần tìm bao nhiêu nguồn, đi theo hướng nào. Anthropic chia sẻ cách họ xây tính năng Research của Claude bằng hệ thống đa agent, kèm số liệu, nguyên tắc viết prompt và những bài học vận hành thực tế. Đây là một trong những tài liệu thực chiến đáng đọc nhất về agent, đặc biệt ở phần "khi nào không nên dùng đa agent".
Kiến trúc orchestrator–worker
- Lead agent phân tích câu hỏi, lập kế hoạch và lưu kế hoạch vào bộ nhớ phòng khi context bị cắt.
- Lead agent sinh nhiều subagent tìm kiếm song song, mỗi subagent có context riêng và một hướng điều tra riêng.
- Lead agent tổng hợp kết quả, có thể sinh thêm subagent nếu còn thiếu.
- Một CitationAgent gắn nguồn cho từng nhận định trong báo cáo cuối.
Số liệu đáng chú ý
| Phát hiện | Con số |
|---|---|
| Đa agent (lead Opus 4, subagent Sonnet 4) so với một agent Opus 4 trên eval nghiên cứu nội bộ | Tốt hơn 90,2% |
| Lượng token dùng giải thích phương sai hiệu năng trên BrowseComp | Khoảng 80% |
| Token tiêu thụ so với chat thường | Agent ~4×, đa agent ~15× |
| Song song hoá subagent và tool call | Giảm thời gian nghiên cứu tới 90% với truy vấn phức tạp |
Thông điệp chính: đa agent hiệu quả phần lớn vì nó cho phép tiêu nhiều token hơn một cách song song. Đó vừa là sức mạnh vừa là chi phí.
Nguyên tắc viết prompt cho đa agent
- Tự mô phỏng agent từng bước để thấy nó hỏng ở đâu.
- Giao việc cho subagent phải có: mục tiêu, định dạng output, gợi ý tool, ranh giới nhiệm vụ. Thiếu thì các subagent làm trùng hoặc bỏ sót.
- Đặt quy tắc rõ về mức nỗ lực theo độ phức tạp câu hỏi (câu đơn giản chỉ cần 1 agent, ít lượt gọi).
- Thiết kế tool có mục đích riêng biệt, mô tả rõ; dùng chính Claude để chẩn đoán và viết lại mô tả tool (một trường hợp giảm 40% thời gian hoàn thành).
- Tìm rộng trước, thu hẹp sau.
Đánh giá agent
- Bắt đầu nhỏ: khoảng 20 truy vấn đại diện đã đủ thấy các thay đổi lớn.
- LLM-as-judge với rubric: chính xác sự kiện, chính xác trích dẫn, đầy đủ, chất lượng nguồn, hiệu quả dùng tool.
- Người thử vẫn bắt được lỗi máy bỏ sót, ví dụ agent ưu tiên trang SEO kém chất lượng hơn nguồn uy tín.
Khi nào không nên dùng đa agent?
- Các agent cần chung ngữ cảnh hoặc phụ thuộc nhau nhiều.
- Bài toán ít phần song song được, như phần lớn việc viết code.
- Việc giá trị thấp, không bù được chi phí token gấp nhiều lần.
Rủi ro vận hành
- Lỗi tích luỹ trong agent có trạng thái: cần resume từ checkpoint thay vì chạy lại từ đầu.
- Khó debug vì không tất định: cần tracing production để thấy mẫu quyết định.
- Deploy khi agent đang chạy dở: Anthropic dùng rainbow deployment, chuyển dần lưu lượng từ phiên bản cũ sang mới.
Áp dụng thế nào?
- Dev: Khi giao việc cho subagent, viết như giao cho đồng nghiệp mới: mục tiêu, phạm vi, định dạng kết quả.
- Tech Lead: Chỉ chọn đa agent cho việc tìm kiếm rộng, song song được; với code, một agent mạnh thường tốt hơn.
- PM: Tính chi phí theo hệ số ~15× token so với chat trước khi hứa tính năng "nghiên cứu sâu".
Nguồn & tham khảo
- How we built our multi-agent research system — Anthropic Engineering