Hạ tầng chạy AI Agent: hàng đợi, retry và xử lý lỗi

Agent đang tạo đơn hàng cho khách thì mất kết nối giữa chừng, để lại một đơn hàng "nửa vời" trong hệ thống mà không ai biết nên xử lý tiếp hay huỷ bỏ — đây là tình huống mà bất kỳ đội kỹ thuật nào từng đưa agent vào chạy thật cũng đã ít nhất một lần gặp phải, và nguyên nhân gốc rễ thường không nằm ở agent mà nằm ở phần hạ tầng chạy phía sau chưa được thiết kế để chịu lỗi.

Vì sao agent chạy thật cần hạ tầng riêng

Khi mới chạy thử ở môi trường phát triển, agent thường được gọi trực tiếp và chờ phản hồi ngay lập tức, nên mọi lỗi xảy ra đều dễ thấy và dễ sửa vì có người ngồi theo dõi trực tiếp. Nhưng khi đưa vào chạy thật với hàng trăm hàng nghìn phiên mỗi ngày, agent buộc phải xử lý những tình huống mà môi trường thử nghiệm hiếm khi gặp: mất kết nối mạng giữa chừng, model bên thứ ba quá tải trả lỗi tạm thời, hoặc chính agent gọi nhầm một công cụ khiến quy trình bị treo lại giữa chừng. Nếu hạ tầng phía sau không được thiết kế để chịu được những tình huống này, hậu quả không chỉ là một câu trả lời sai mà có thể là dữ liệu dở dang thật sự trong hệ thống — một đơn hàng được tạo nửa chừng, một email được gửi hai lần, hay một khoản thanh toán bị trừ mà không ghi nhận đơn hàng tương ứng.

Bài viết này đi qua năm bước kỹ thuật cốt lõi giúp hạ tầng chạy agent của bạn chịu lỗi tốt hơn, được sắp xếp theo đúng thứ tự ưu tiên nên làm trước — bạn có thể áp dụng dần từng bước thay vì phải làm hết cùng lúc mới bắt đầu triển khai được.

Một điều cần lưu ý trước khi đi vào chi tiết: các bước dưới đây không phải lý thuyết xa vời chỉ dành cho hệ thống quy mô lớn, mà là những nguyên tắc chịu lỗi cơ bản đã được áp dụng từ lâu trong ngành phát triển phần mềm phân tán, giờ chỉ cần điều chỉnh lại cho phù hợp với đặc thù của agent — nơi mỗi "công việc" không chỉ là một lệnh ghi dữ liệu đơn giản mà có thể là một chuỗi nhiều bước suy luận và gọi công cụ nối tiếp nhau, nên rủi ro dở dang giữa chừng cũng cao hơn hẳn so với một API thông thường.

Bước 1: Dùng hàng đợi thay vì gọi trực tiếp

Thay vì để hệ thống gọi thẳng vào agent và chờ phản hồi ngay (đồng bộ), bạn nên đưa mỗi yêu cầu vào một hàng đợi công việc (job queue) trước, để một tiến trình riêng lấy việc từ hàng đợi ra xử lý. Cách làm này mang lại hai lợi ích rõ rệt: thứ nhất, nếu agent đang quá tải hoặc tạm thời gặp sự cố, yêu cầu vẫn nằm an toàn trong hàng đợi chờ xử lý tiếp thay vì bị mất hẳn; thứ hai, bạn có thể kiểm soát số lượng phiên agent chạy đồng thời để tránh vượt quá giới hạn tốc độ gọi của nhà cung cấp model, tránh tình trạng bị từ chối request hàng loạt vào giờ cao điểm.

Với đội kỹ thuật đã quen dùng các công cụ hàng đợi phổ biến như Redis Queue, AWS SQS hay các cấu phần hàng đợi có sẵn trong nền tảng agent đang dùng, việc thêm lớp này không quá phức tạp; nhưng nếu hệ thống hiện tại đang gọi agent trực tiếp theo kiểu đồng bộ, đây nên là việc ưu tiên làm trước tiên trước khi tính tới các bước chịu lỗi phức tạp hơn ở dưới.

Bước 2: Thiết kế thử lại có kiểm soát

Khi một bước trong agent thất bại — ví dụ gọi API bên thứ ba bị lỗi tạm thời — hệ thống cần tự động thử lại thay vì để cả phiên xử lý thất bại hoàn toàn. Tuy nhiên, thử lại không kiểm soát cũng nguy hiểm không kém việc không thử lại: nếu agent thử lại ngay lập tức và liên tục khi hệ thống đích đang quá tải, nó có thể khiến tình trạng quá tải càng nặng thêm. Cách làm đúng là áp dụng "exponential backoff" — tăng dần thời gian chờ giữa mỗi lần thử lại (ví dụ 2 giây, rồi 4 giây, rồi 8 giây) và giới hạn số lần thử lại tối đa (thường 3-5 lần), sau đó nếu vẫn thất bại thì chuyển sang trạng thái "cần người xử lý" thay vì thử lại vô hạn.

Một điểm quan trọng khác là không phải lỗi nào cũng nên thử lại: lỗi do dữ liệu đầu vào sai (ví dụ mã đơn hàng không tồn tại) sẽ không bao giờ thành công dù thử lại bao nhiêu lần, nên hệ thống cần phân loại rõ giữa lỗi tạm thời (đáng thử lại) và lỗi vĩnh viễn (nên dừng ngay và báo lỗi) để tránh lãng phí tài nguyên và thời gian.

Bước 3: Đảm bảo tính bất biến khi lặp lại

Đây là bước kỹ thuật dễ bị bỏ sót nhất nhưng lại chính là nguyên nhân gây ra tình huống "đơn hàng bị tạo hai lần" đã nhắc ở đầu bài. Khi agent thử lại một bước đã từng chạy nhưng không chắc chắn đã hoàn thành hay chưa (ví dụ mất kết nối ngay lúc đang gửi yêu cầu tạo đơn), nếu không có cơ chế kiểm soát, việc thử lại có thể vô tình tạo ra đơn hàng thêm một lần nữa. Giải pháp là gắn một khoá bất biến (idempotency key) duy nhất cho mỗi tác vụ ngay từ đầu, để hệ thống đích (ví dụ hệ thống quản lý đơn hàng) có thể nhận ra "yêu cầu này đã xử lý rồi" và bỏ qua thay vì tạo trùng lặp, dù agent có gửi lại yêu cầu bao nhiêu lần đi nữa.

Việc này đòi hỏi phối hợp từ cả hai phía: agent phải sinh và giữ nguyên khoá bất biến cho mỗi tác vụ trong suốt vòng đời của nó, còn hệ thống đích (API nội bộ hoặc dịch vụ bên thứ ba) phải hỗ trợ nhận diện khoá này để từ chối các yêu cầu trùng lặp — nên đây cũng là tiêu chí bạn cần kiểm tra khi làm việc với đội phát triển hệ thống nội bộ hoặc chọn API bên thứ ba để tích hợp.

Nếu hệ thống nội bộ hiện tại chưa hỗ trợ nhận diện khoá bất biến, một cách xử lý tạm thời là lưu lại nhật ký mọi tác vụ agent đã gửi đi kèm trạng thái hoàn thành, để trước khi thử lại, hệ thống trung gian tự kiểm tra xem tác vụ đó đã từng được đánh dấu "đã gửi thành công" hay chưa — tuy không hoàn hảo bằng việc hệ thống đích hỗ trợ sẵn nhưng vẫn giảm đáng kể rủi ro trùng lặp so với việc không kiểm tra gì cả.

Bước 4: Đặt giới hạn chi phí và thời gian mỗi phiên

Một agent gặp tình huống khó hiểu có thể rơi vào vòng lặp tự gọi công cụ hết lần này tới lần khác để cố tìm ra câu trả lời, khiến chi phí token của một phiên duy nhất tăng vọt bất thường nếu không có giới hạn chặn lại. Bạn nên đặt sẵn hai loại hạn mức cho mỗi phiên: hạn mức số bước tối đa agent được phép tự lặp lại trước khi bắt buộc dừng và chuyển cho người xử lý, và hạn mức chi phí token tối đa cho một phiên — khi vượt ngưỡng này, hệ thống tự động dừng phiên đó lại bất kể agent có đang "gần tìm ra câu trả lời" hay không.

Ngoài ra, cũng nên đặt giới hạn thời gian chạy tối đa cho mỗi phiên (timeout), vì một agent bị "treo" chờ phản hồi từ một công cụ bên ngoài quá lâu sẽ chiếm giữ tài nguyên hàng đợi mà không mang lại giá trị gì, ảnh hưởng tới tốc độ xử lý của các phiên khác đang chờ trong hàng đợi phía sau.

Bước 5: Giám sát và cảnh báo khi agent bị kẹt

Bốn bước trên giúp hệ thống tự chịu lỗi tốt hơn, nhưng vẫn cần một lớp giám sát để đội vận hành biết được khi nào có sự cố xảy ra thay vì chỉ phát hiện qua lời phàn nàn của khách hàng. Bạn nên thiết lập cảnh báo tự động khi: tỉ lệ phiên phải thử lại tăng bất thường so với ngày thường, số phiên bị dừng do vượt hạn mức chi phí tăng đột biến, hoặc hàng đợi công việc bị dồn ứ không được xử lý kịp — mỗi tín hiệu này đều báo trước một vấn đề cần xử lý trước khi nó ảnh hưởng tới trải nghiệm khách hàng trên diện rộng. Bạn nên phân công rõ ai là người nhận cảnh báo đầu tiên và có mặt trong bao lâu để phản hồi, vì một hệ thống cảnh báo dù thiết kế tốt đến đâu cũng vô nghĩa nếu không ai thực sự đọc và xử lý khi nó reo lên vào giữa đêm hay ngoài giờ làm việc.

Bạn có thể tham khảo thêm khung quản trị đầy đủ hơn tại bài quản trị và giám sát AI Agent để biết cách thiết lập nhật ký hành động và luồng phê duyệt đi kèm với phần hạ tầng kỹ thuật đã nêu ở trên.

Checklist hạ tầng trước khi chạy thật

• Mọi yêu cầu gửi tới agent đều đi qua hàng đợi, không gọi trực tiếp đồng bộ.
• Có cơ chế thử lại tăng dần thời gian chờ, giới hạn số lần thử lại tối đa.
• Mọi tác vụ có khoá bất biến để tránh tạo trùng lặp khi thử lại.
• Đã đặt hạn mức số bước, chi phí token và thời gian tối đa cho mỗi phiên.
• Có cảnh báo tự động khi tỉ lệ lỗi hoặc hàng đợi tồn đọng tăng bất thường.