Bài 4 — Khi nào NÊN (và KHÔNG nên) dùng Agent

Quyết định sai ở đây khiến bạn đốt tiền và thời gian. Agent không phải câu trả lời cho mọi bài toán. Bài này cho bạn một khung ra quyết định thực dụng.

Nguyên tắc gốc: dùng thứ đơn giản nhất hiệu quả

Thứ tự ưu tiên khi thiết kế giải pháp:

1. Code cứng / rule       (nếu logic cố định, rõ ràng)
2. Automation / RPA       (nếu là chuỗi bước lặp cố định)
3. LLM một lượt           (nếu chỉ cần hiểu/sinh ngôn ngữ 1 lần)
4. Workflow có LLM         (nếu vài bước có điều kiện, ít nhánh)
5. Agent tự hành          (chỉ khi thực sự cần tự quyết + nhiều nhánh)

Chỉ leo lên bậc thang khi bậc dưới không giải quyết được.

Khi NÊN dùng agent — 4 dấu hiệu

• Đường đi không đoán trước được: số bước và thứ tự phụ thuộc dữ liệu chạy thật (ví dụ điều tra sự cố: mỗi ca một kiểu).
• Cần dùng nhiều tool và tự chọn tool nào: bài toán mở, không thể vẽ hết nhánh bằng if-else.
• Cần lập luận trên ngôn ngữ tự nhiên ở mỗi bước (đọc ticket, hiểu ngữ cảnh mơ hồ).
• Chấp nhận được sai số nhỏ và có con người giám sát khâu quan trọng.

Khi KHÔNG nên dùng agent — 4 dấu hiệu

• Luồng cố định, rõ ràng: "đơn mới → hóa đơn → mail". Automation làm rẻ, nhanh, ổn định hơn.
• Yêu cầu chính xác tuyệt đối / tuân thủ pháp lý: agent có xác suất sai, không hợp cho tính lương, chuyển tiền tự động không kiểm soát.
• Độ trễ và chi phí là ràng buộc cứng: agent gọi LLM nhiều lần → chậm và đắt.
• Khối lượng cực lớn, đơn giản: xử lý triệu bản ghi giống nhau — dùng automation/batch.

Ví dụ đối chiếu

• "Gửi email nhắc hạn thanh toán hàng ngày cho danh sách khách trễ" → automation (luồng cố định). Dùng agent là lãng phí.
• "Đọc email khách gửi tới, phân loại, tra thông tin liên quan rồi soạn phản hồi phù hợp" → agent (mỗi email một kiểu, cần lập luận + nhiều tool).
• "Tính tổng doanh thu tháng" → code/SQL. Đừng để LLM cộng số.

Khung 5 câu hỏi trước khi chọn agent

• Tôi có thể vẽ hết luồng bằng flowchart if-else không? → Nếu có, dùng automation.
• Mỗi lần chạy, các bước có khác nhau tùy dữ liệu không? → Nếu có, nghiêng về agent.
• Sai 5% có chấp nhận được (có người review) không? → Nếu không chấp nhận và không thể review, tránh agent ở khâu đó.
• Chi phí/độ trễ nhiều lần gọi LLM có ổn không?
• Đã có phương án đơn giản hơn chưa thử chưa?

Nếu câu 1 = có → bạn gần như chắc chắn không cần agent.

Chiến lược "agent lai": tốt nhất trong thực tế

Đừng chọn cực đoan. Thực chiến thường là: automation lo phần cố định + agent lo phần cần phán đoán. Ví dụ: automation nhận và chuẩn hóa dữ liệu đơn hàng, agent chỉ vào cuộc khi có khiếu nại phức tạp. Rẻ, ổn định, mà vẫn linh hoạt.

Bài toán "có vẻ cần agent" nhưng thực ra không

Nhiều bài toán mặc áo agent nhưng cởi ra thì đơn giản. Ví dụ: "đọc email khách và trả lời tự động". Nghe rất agent, nhưng nếu 90% email chỉ rơi vào 5 loại câu hỏi cố định, thì một bộ phân loại + mẫu trả lời (automation có chút LLM) giải quyết gọn hơn, rẻ hơn và ổn định hơn nhiều một agent tự hành. Chỉ 10% ca thật sự phức tạp mới cần đến khả năng phán đoán của agent. Bài học: hãy phân tách bài toán theo tần suất và độ phức tạp, đừng để phần nhỏ phức tạp kéo cả hệ thống lên mức agent không cần thiết. Đây cũng chính là tinh thần của kiến trúc lai.

Chi phí và độ trễ: hai ràng buộc hay bị bỏ quên

Agent gọi LLM nhiều lần cho mỗi tác vụ — một tác vụ 5 vòng lặp là 5 lần gọi model, mỗi lần kèm toàn bộ lịch sử ngày càng dài. Ở demo với vài chục request, chi phí không đáng kể. Nhưng ở quy mô 100.000 request/ngày, hóa đơn LLM có thể lớn gấp hàng chục lần so với automation làm cùng việc. Tương tự, độ trễ: một agent chạy nhiều vòng có thể mất 10–30 giây, không phù hợp cho trải nghiệm cần phản hồi tức thì. Trước khi chọn agent, hãy ước lượng: số vòng lặp trung bình × chi phí mỗi lần gọi × lưu lượng. Con số đó thường khiến quyết định trở nên rõ ràng.

Sai lầm thường gặp

• "Dùng agent cho ngầu" một bài toán mà rule/automation làm tốt — đốt tiền vô ích.
• Giao khâu nhạy cảm (tiền, pháp lý) cho agent tự chạy không có chốt phê duyệt của con người.
• Không tính chi phí ở quy mô: demo 10 request thì rẻ, 100.000 request/ngày thì hóa đơn LLM khổng lồ.
• Bỏ qua phương án lai, ép mọi thứ vào một agent duy nhất khổng lồ, khó kiểm soát.
• Không phân tách bài toán theo tần suất: để 10% ca phức tạp kéo cả hệ thống lên mức agent.

Đã biết khi nào dùng, bài 5 ta bắt tay thiết kế một agent cụ thể trên giấy trước khi code.