Từ "một prompt làm tất cả" đến một dây chuyền sản xuất
Khi mới dùng LLM để viết code, ai cũng bắt đầu bằng một prompt duy nhất: "Viết cho tôi API quản lý đơn hàng, có test, có tài liệu". Với task nhỏ thì ổn. Nhưng khi yêu cầu phức tạp hơn, agent đơn lẻ bắt đầu "quên" ràng buộc, trộn lẫn việc thiết kế với việc gỡ lỗi, và không có ai kiểm tra lại chính nó. Đó là lúc mô hình đa agent phát huy tác dụng.
Ý tưởng cốt lõi rất giống một đội phần mềm thật: mỗi vai trò có một trách nhiệm hẹp và rõ ràng.
- Planner: đọc yêu cầu, chia thành các task nhỏ, xác định thứ tự và tiêu chí hoàn thành.
- Coder: nhận từng task, viết code đúng phạm vi được giao.
- Reviewer: đọc code của coder, tìm lỗi logic, vi phạm quy ước, rủi ro bảo mật.
- Tester: viết và chạy test, báo cáo pass/fail kèm bằng chứng.
Ví dụ cụ thể
Giả sử yêu cầu là: "Thêm chức năng đặt lại mật khẩu qua email". Một agent đơn lẻ dễ viết luôn cả endpoint, cả email template, cả migration DB trong một lần và bỏ sót việc giới hạn số lần gửi (rate limit). Trong mô hình đội:
- Planner tách thành 4 task: (a) sinh token, (b) endpoint yêu cầu reset, (c) endpoint xác nhận, (d) rate limit + hết hạn token.
- Coder làm task (a), xong bàn giao.
- Reviewer phát hiện token đang lưu plaintext, yêu cầu hash.
- Tester viết test kiểm tra token hết hạn sau 15 phút.
Khung tư duy: khi nào nên tách agent
Dùng checklist sau để quyết định:
- Task có nhiều loại tư duy khác nhau không (lập kế hoạch vs. viết vs. phản biện)? Nếu có → nên tách.
- Bạn có cần một "con mắt thứ hai" độc lập để bắt lỗi không? Nếu có → cần reviewer riêng.
- Đầu ra có tiêu chí đúng/sai kiểm chứng được không (test chạy xanh)? Nếu có → cần tester riêng.
- Ngân sách token/độ trễ có cho phép nhiều lượt gọi không? Nếu quá eo hẹp → gộp bớt vai trò.
Yêu cầu → [Planner] → danh sách task
↓
[Coder] → code
↓
[Reviewer] → chấp nhận / trả lại
↓
[Tester] → xanh / đỏ → (lặp nếu đỏ)
Lợi ích thực tế
- Tách bạch trách nhiệm: coder không tự chấm điểm chính mình.
- Context nhỏ hơn cho mỗi agent: mỗi agent chỉ cần đủ thông tin cho vai trò của nó, giảm nhiễu và giảm chi phí.
- Dễ debug quy trình: khi kết quả sai, bạn biết ngay nút nào (plan sai? code sai? test thiếu?).
Cái giá phải trả
Đa agent không miễn phí: nhiều lượt gọi hơn (tốn token, chậm hơn), cần hạ tầng điều phối (orchestration), và nếu thiết kế cẩu thả các agent sẽ "cãi nhau" vô tận. Vì vậy nguyên tắc là: tách vai trò tối thiểu cần thiết, không tách cho vui.
Sai lầm thường gặp
- Tách quá nhiều vai trò (planner, sub-planner, architect, coder, sub-coder...) khiến hệ thống chậm và khó kiểm soát mà không thêm giá trị.
- Cho các agent chung một context khổng lồ, làm mất đi lợi ích cách ly và tăng nhiễu.
- Không định nghĩa tiêu chí hoàn thành cho từng vai trò, khiến reviewer/tester không biết dựa vào đâu để phán xét.
- Kỳ vọng đa agent tự sửa mọi lỗi: nếu không có tester chạy code thật, cả đội chỉ đang "tưởng tượng" là code đúng.