Bài 1 — Vì sao triển khai agent khác với deploy web app thông thường

Bạn đã có một agent chạy ngon trên máy local: nó gọi LLM, dùng vài tool, trả lời khá thông minh. Nhưng khi đưa lên production, mọi thứ vỡ: request timeout, hóa đơn LLM tăng vọt, agent bị gọi trùng, và không ai biết vì sao một tác vụ "treo" 4 phút. Bài này giúp bạn hiểu bản chất khác biệt để chọn đúng kiến trúc.

Agent không giống một API CRUD

Một API web thông thường: nhận request, query DB, trả về trong 100ms. Agent thì:

• Chạy lâu và không đoán trước được: một lượt "suy nghĩ" có thể gọi LLM 5–10 lần, mỗi lần 2–20 giây. Tổng thời gian dao động mạnh.
• Tốn tiền theo token: mỗi lần retry mù quáng là đốt thêm tiền thật.
• Có trạng thái (stateful) theo hội thoại: cần nhớ ngữ cảnh, lịch sử tool call.
• Phụ thuộc dịch vụ ngoài dễ lỗi: LLM API, vector DB, tool bên thứ ba — bất kỳ cái nào cũng có thể 429/500.

Ba trục quyết định kiến trúc

Khi thiết kế triển khai, luôn hỏi ba câu:

• Tác vụ chạy bao lâu? Dưới ~30 giây thì serverless đồng bộ ổn. Trên đó phải tách async bằng queue.
• Ai kích hoạt agent? Người dùng bấm nút (đồng bộ) hay hệ thống khác bắn sự kiện (webhook, cron)?
• Lưu lượng có gai không? Lúc 0 request, lúc 500 request/phút — điều này quyết định serverless (co giãn về 0) hay container luôn chạy.

Ví dụ cụ thể

Một agent "tóm tắt hợp đồng PDF":

• Người dùng upload file → API nhận (nhanh).
• Trích xuất text + gọi LLM nhiều lần để tóm tắt từng phần → mất 2–5 phút.

Nếu bạn xử lý đồng bộ trong 1 HTTP request, gateway sẽ cắt ở 30–60 giây và người dùng thấy lỗi. Kiến trúc đúng: API nhận → đẩy job vào queue → trả về job_id ngay → worker chạy nền → khi xong bắn webhook/notification cho client.

Khung tư duy: "Nhận nhanh — Làm chậm — Báo lại"

[Client] --request--> [API nhận, xác thực, tạo job_id] --push--> [Queue]
                                                                  |
                                                          [Worker/Agent chạy]
                                                                  |
                              [Webhook / WebSocket / polling] <---+

Ghi nhớ ba lớp: lớp tiếp nhận phải nhẹ và nhanh; lớp xử lý có thể chậm và co giãn; lớp thông báo trả kết quả bất đồng bộ.

Các bước áp dụng ngay

• Liệt kê mọi entrypoint gọi agent của bạn (UI, cron, webhook bên thứ ba).
• Đo thời gian p50 và p95 của một lượt agent thực tế (đừng đoán).
• Với entrypoint nào p95 > 25 giây → đánh dấu "cần async".
• Xác định trạng thái cần lưu (lịch sử hội thoại, checkpoint tool) và nơi lưu (DB/Redis).
• Vẽ sơ đồ 3 lớp "Nhận – Làm – Báo" cho từng luồng.

Checklist sẵn sàng production

• [ ] Đã biết p95 thời gian chạy của agent.
• [ ] Đã tách rõ luồng đồng bộ và bất đồng bộ.
• [ ] Có idempotency key để chống chạy trùng.
• [ ] Có nơi lưu trạng thái độc lập với process.
• [ ] Có kế hoạch retry với backoff, không retry mù.

Sai lầm thường gặp

• Nhét toàn bộ agent vào một HTTP handler đồng bộ: hoạt động lúc demo, chết khi tác vụ dài hoặc traffic tăng.
• Retry toàn bộ lượt agent khi lỗi ở bước cuối: đốt lại toàn bộ token của các bước trước.
• Coi LLM API là luôn sẵn sàng: không xử lý 429/timeout dẫn tới sập dây chuyền.
• Lưu trạng thái trong RAM của process: serverless/container tái tạo là mất sạch ngữ cảnh.
• Không đo trước khi thiết kế: chọn kiến trúc theo cảm tính thay vì theo p95 thật.

Hiểu ba trục (thời lượng, người kích hoạt, độ gai của traffic) là nền tảng cho toàn bộ các lựa chọn serverless, container, queue, webhook ở các bài sau.