Vấn đề của agent "làm tất"
Khi mới bắt đầu, hầu hết mọi người nhồi tất cả nhiệm vụ vào một agent: trả lời khách hàng, tra cứu đơn hàng, viết email, tạo báo cáo. Kết quả là một agent cồng kềnh, prompt dài 3000 từ, nhầm lẫn công cụ, và cực khó debug khi sai. Đây chính là lý do ta chuyển sang mô hình đội agent cho phòng ban: mỗi agent làm một việc rõ ràng, phối hợp qua orchestration.
Ví dụ cụ thể: phòng Chăm sóc khách hàng (CSKH)
Một phòng CSKH thật có nhiều "vai": lễ tân tiếp nhận, chuyên viên tra cứu đơn, chuyên viên khiếu nại, trưởng nhóm duyệt hoàn tiền. Đội agent mô phỏng đúng cấu trúc đó:
- Router agent (lễ tân): phân loại yêu cầu đến.
- Order agent (tra cứu): gọi API đơn hàng.
- Refund agent (nghiệp vụ hoàn tiền): xử lý theo chính sách.
- Escalation agent (trưởng nhóm): chuyển việc cho người thật khi vượt hạn mức.
Khi nào nên tách agent — khung 3 câu hỏi
Dùng khung này trước khi quyết định tách một vai thành agent riêng:
- Khác mục tiêu? Vai này có KPI/thành công riêng không? (ví dụ: giảm thời gian phản hồi vs. đúng chính sách hoàn tiền)
- Khác công cụ/quyền? Vai này cần bộ tool hoặc quyền truy cập khác (ghi DB, gọi API thanh toán)?
- Khác rủi ro? Sai ở vai này gây hậu quả nặng hơn (hoàn tiền nhầm) so với vai khác (trả lời sai giờ mở cửa)?
Các bước tư duy khi khởi động
- Vẽ sơ đồ quy trình phòng ban HIỆN TẠI trên giấy (ai làm gì, chuyển việc cho ai).
- Đánh dấu các bước lặp đi lặp lại, tốn thời gian, ít cần phán đoán tinh tế — đó là ứng viên tự động hóa.
- Gom mỗi cụm nhiệm vụ đồng nhất thành một "vai agent".
- Xác định điểm HAND-OFF (chuyển việc) giữa các vai.
- Chọn 1 vai có ROI cao nhất để làm pilot trước, không làm cả đội cùng lúc.
Cấu trúc khai báo một đội (pseudocode)
team: cskh
router: router_agent # điều phối
agents:
- name: order_agent
tools: [get_order, get_shipping]
- name: refund_agent
tools: [check_policy, create_refund]
guardrail: refund_limit <= 2000000
- name: escalation_agent
action: handoff_to_human
Lưu ý điểm quan trọng: refund_agent có guardrail riêng — đây là lợi ích lớn của việc tách vai, mỗi agent có ranh giới quyền hạn riêng.
Ba lợi ích cụ thể của mô hình đội
Để thuyết phục sếp và đội kỹ thuật, hãy nắm ba lợi ích đo được của mô hình đội so với một agent "biết tuốt":
- Dễ kiểm thử (testability): mỗi agent nhỏ, prompt ngắn nên bạn viết được bộ test riêng cho từng vai. Khi order_agent sai, bạn test một mình nó, không phải chạy cả chuỗi 3000 từ prompt để tái hiện lỗi.
- Cô lập rủi ro (blast radius): một agent lỗi chỉ gây hại trong phạm vi tool của nó. Router hiểu nhầm cũng không thể hoàn tiền vì nó không có tool đó. Với agent "biết tuốt", một hiểu nhầm có thể chạm tới mọi hành động nguy hiểm.
- Nâng cấp độc lập: cần đổi chính sách hoàn tiền? Bạn chỉ sửa refund_agent, không đụng phần tra cứu đơn hay FAQ. Mỗi vai tiến hóa riêng, giảm rủi ro hồi quy (regression) lan sang phần khác.
Checklist khởi đầu
- [ ] Đã vẽ quy trình phòng ban hiện tại
- [ ] Đã liệt kê 3–6 vai rõ ràng
- [ ] Mỗi vai có 1 mục tiêu, 1 bộ tool, 1 mức rủi ro
- [ ] Đã chọn 1 vai pilot ROI cao
- [ ] Đã xác định điểm hand-off
Sai lầm thường gặp
- Tách quá mịn (over-decomposition): 15 agent cho việc mà 3 agent làm được → chi phí điều phối và độ trễ tăng vọt. Bắt đầu ít, tách thêm khi thật sự cần.
- Gộp quá thô: một agent vừa tra đơn vừa hoàn tiền vừa xin lỗi khách → không thể đặt guardrail riêng, sai một chỗ hỏng cả chuỗi.
- Làm cả đội một lúc: không có pilot, không đo được ROI, khó thuyết phục sếp mở rộng.
- Bắt chước sơ đồ tổ chức 1:1: cơ cấu phòng ban con người tối ưu cho con người, không nhất thiết tối ưu cho agent — hãy tối ưu theo LUỒNG CÔNG VIỆC, không theo chức danh.