Thiết kế hàng đợi tác vụ cho AI Agent để tránh mất dữ liệu

Một AI Agent nhận đơn hàng từ email, trích thông tin rồi ghi vào ERP. Mọi thứ chạy tốt cho đến buổi chiều ERP bảo trì đột xuất trong một giờ. Những email đến trong giờ đó đi đâu? Nếu agent xử lý thẳng từng yêu cầu ngay khi nhận, câu trả lời thường là: một phần bị lỗi và bị bỏ qua, một phần được thử lại vô hạn, và không ai biết chính xác đơn nào đã vào hệ thống.

Hàng đợi tác vụ là lớp đệm giữa lúc công việc phát sinh và lúc nó được làm xong. Bài viết đi vào kiến trúc hàng đợi nội bộ cho AI Agent: ai đẩy việc vào, ai lấy việc ra, khi nào được coi là xong, thử lại bao nhiêu lần, việc hỏng đi đâu, việc gấp đi trước ra sao, và phục hồi thế nào sau khi một dịch vụ sập.

1. Hàng đợi tác vụ giải quyết vấn đề gì

Công việc của AI Agent thường gồm nhiều bước chậm và dễ lỗi: gọi mô hình ngôn ngữ, đọc tài liệu, gọi API của CRM hay ERP. Nếu làm tất cả trong lúc người dùng hoặc hệ thống gửi yêu cầu đang chờ, chỉ cần một bước chậm là cả chuỗi bị treo, và một bước lỗi là yêu cầu biến mất. Hàng đợi tách hai việc: ghi nhận yêu cầu một cách chắc chắn, và xử lý yêu cầu khi có điều kiện.

Bài này bổ sung cho hai chủ đề gần kề. Phía nhận sự kiện từ bên ngoài, như webhook gửi lặp hay đến sai thứ tự, và cách chống xử lý trùng được trình bày ở bài webhook retry và idempotency. Việc tôn trọng hạn mức gọi API của từng hệ thống thuộc bài xử lý API rate limit. Còn bài AI Agent đa kênh đã nêu nhu cầu có hàng đợi đồng bộ khi nối nhiều kênh với CRM; ở đây ta đi vào bên trong hàng đợi đó.

2. Các thành phần cần thiết kế

1. Producer

Producer là phần đưa việc vào hàng đợi: bộ nhận webhook, bộ đọc email, giao diện chat, lịch chạy định kỳ. Nguyên tắc quan trọng nhất là producer chỉ báo “đã nhận” cho bên gửi sau khi việc đã được ghi bền vào hàng đợi, không phải sau khi đưa vào bộ nhớ. Mỗi tác vụ cần có mã duy nhất, loại tác vụ, dữ liệu đầu vào đủ để xử lý độc lập, thời điểm tạo và nguồn phát sinh. Không nên nhét cả tệp đính kèm lớn vào tác vụ; lưu tệp ở kho riêng và để tác vụ tham chiếu tới.

2. Consumer

Consumer, hay worker, là tiến trình lấy việc ra và làm. Nên có nhiều worker chạy song song và mỗi worker có thể dừng bất cứ lúc nào mà không làm hỏng dữ liệu. Muốn vậy, mỗi tác vụ phải được thiết kế để làm lại từ đầu vẫn an toàn: nếu worker chết sau khi đã ghi vào ERP nhưng trước khi đánh dấu xong, lần chạy lại không được tạo bản ghi thứ hai. Nên tách tác vụ dài thành các bước nhỏ, mỗi bước là một tác vụ riêng, để một bước lỗi không buộc làm lại cả chuỗi.

3. Acknowledgement

Ack là tín hiệu worker gửi cho hàng đợi để nói “việc này xong rồi, xóa đi”. Lỗi phổ biến nhất gây mất dữ liệu là ack quá sớm, tức ngay khi lấy việc ra. Nếu worker chết giữa chừng, việc đã bị xóa khỏi hàng đợi mà chưa hoàn thành. Quy tắc là chỉ ack sau khi kết quả đã được ghi thành công vào hệ thống đích. Hàng đợi cũng cần thời gian khóa: nếu worker lấy việc mà quá thời gian chưa ack, việc được trả lại để worker khác làm. Thời gian này phải dài hơn thời gian xử lý bình thường, kể cả lượt gọi mô hình chậm.

4. Retry

Không phải lỗi nào cũng nên thử lại. Lỗi tạm thời như hết thời gian chờ, dịch vụ đích quá tải, mạng chập chờn thì thử lại có ích. Lỗi vĩnh viễn như dữ liệu sai định dạng, khách hàng không tồn tại trong CRM, quyền bị từ chối thì thử lại bao nhiêu lần cũng vậy. Worker cần phân loại lỗi để quyết định. Với lỗi tạm thời, khoảng cách giữa các lần thử nên tăng dần và có giới hạn số lần; vượt giới hạn thì chuyển sang dead letter thay vì thử mãi.

5. Dead letter

Dead letter queue là nơi chứa những tác vụ đã hết lượt thử hoặc gặp lỗi vĩnh viễn. Nó chỉ có ích nếu có quy trình xử lý tay đi kèm: ai được thông báo, xem thông tin gì, và có những thao tác nào. Mỗi tác vụ trong dead letter cần giữ nguyên dữ liệu đầu vào, lịch sử các lần thử và thông báo lỗi cuối cùng. Người xử lý có thể sửa dữ liệu rồi đẩy lại vào hàng đợi chính, xử lý thủ công trên hệ thống đích, hoặc đóng tác vụ kèm lý do. Dead letter không được xử lý sẽ âm thầm trở thành nơi dữ liệu biến mất.

6. Ưu tiên

Không phải việc nào cũng gấp như nhau. Tin nhắn có khách đang chờ trả lời cần đi trước việc đồng bộ lịch sử hội thoại vào CRM; yêu cầu hủy đơn cần đi trước báo cáo cuối ngày. Cách đơn giản là tách vài hàng đợi theo mức ưu tiên và dành riêng worker cho hàng gấp. Cần đề phòng việc ưu tiên thấp bị bỏ đói mãi, bằng cách đảm bảo mỗi hàng luôn có ít nhất một phần năng lực xử lý.

7. Quan sát

Hai con số quan trọng nhất là độ dài hàng đợi và tuổi của tác vụ cũ nhất. Độ dài tăng liên tục nghĩa là việc vào nhanh hơn việc ra. Tuổi tác vụ cũ nhất cho biết khách hoặc hệ thống đang chờ lâu đến mức nào, và thường là tín hiệu cảnh báo tốt hơn độ dài. Ngoài ra cần theo dõi tỷ lệ thử lại, số tác vụ vào dead letter theo loại lỗi, và thời gian xử lý mỗi loại tác vụ. Mỗi tác vụ nên mang mã theo dõi xuyên suốt để tra được từ lúc vào đến lúc ghi xong, tương tự cách nhật ký AI Agent ghi mỗi lượt xử lý.

8. Khôi phục

Khi hệ thống đích sập, hàng đợi sẽ phình ra. Khi hệ thống đó trở lại, nếu tất cả worker cùng lao vào xử lý thì dễ làm nó sập lần nữa. Cần có cơ chế tạm dừng tiêu thụ cho từng hệ thống đích, và khi mở lại thì tăng tốc từ từ. Chính hàng đợi cũng phải bền: dữ liệu hàng đợi phải còn nguyên sau khi máy chủ khởi động lại. Nên diễn tập kịch bản dịch vụ đích mất một giờ để biết hàng đợi chứa được bao nhiêu, mất bao lâu để xử lý hết phần tồn và có tác vụ nào hết hạn giá trị trong lúc chờ không.

3. Quy trình triển khai thực tế

Bước 1: Liệt kê loại tác vụ và yêu cầu của từng loại

Với mỗi loại tác vụ, ghi rõ: nguồn phát sinh, hệ thống đích, mức ưu tiên, thời gian chờ chấp nhận được, tác vụ có an toàn khi làm lại không, và lỗi nào coi là vĩnh viễn. Bảng này quyết định số hàng đợi, số lần thử và ngưỡng cảnh báo.

Bước 2: Thiết kế tác vụ để làm lại an toàn

Mỗi tác vụ ghi vào hệ thống đích cần một khóa để nhận ra “việc này đã làm rồi”, chẳng hạn mã tác vụ lưu cùng bản ghi. Với hệ thống đích không hỗ trợ khóa như vậy, worker phải tra trước khi ghi. Đây là điều kiện để ack muộn và retry không sinh bản ghi trùng.

Bước 3: Xây quy trình dead letter và phân quyền xử lý

Chỉ định người nhận cảnh báo dead letter cho từng loại tác vụ, viết hướng dẫn xử lý các lỗi hay gặp, và cung cấp màn hình hoặc công cụ để xem, sửa, đẩy lại hay đóng tác vụ. Mọi thao tác xử lý tay đều được ghi nhật ký.

Bước 4: Diễn tập sự cố rồi mới vận hành thật

Tắt từng hệ thống đích trên môi trường thử, dừng worker giữa chừng, gửi dữ liệu sai định dạng, đẩy lượng lớn tác vụ cùng lúc. Kiểm tra không có tác vụ nào mất, không có bản ghi trùng, cảnh báo đến đúng người, và phần tồn được xử lý hết mà không làm sập lại dịch vụ đích.

4. Ví dụ giả định

Một nhà phân phối dùng AI Agent đọc email đặt hàng của đại lý, trích sản phẩm và số lượng, rồi tạo đơn nháp trong ERP. Bộ đọc email đưa mỗi email vào hàng đợi kèm mã duy nhất, chỉ đánh dấu email đã đọc sau khi ghi vào hàng đợi thành công. Worker gọi mô hình để trích thông tin, rồi gọi ERP tạo đơn nháp với mã tác vụ làm khóa chống trùng, và chỉ ack sau khi ERP trả về mã đơn.

Buổi chiều ERP bảo trì, lỗi kết nối được xếp là tạm thời, worker thử lại với khoảng cách tăng dần. Cảnh báo tuổi tác vụ cũ nhất báo cho nhóm vận hành, và việc tiêu thụ cho ERP được tạm dừng. Khi ERP trở lại, worker mở dần, phần tồn được xử lý hết. Riêng hai email có mã sản phẩm không tồn tại bị xếp lỗi vĩnh viễn, vào dead letter, và nhân viên bán hàng liên hệ đại lý để sửa. Ví dụ này là giả định, dùng để minh họa luồng xử lý.

5. Rủi ro và giới hạn

• Ack ngay khi lấy việc ra khiến tác vụ mất khi worker chết giữa chừng
• Thử lại vô hạn với lỗi vĩnh viễn làm tắc hàng đợi và tốn chi phí gọi mô hình
• Dead letter không có người xử lý trở thành nơi dữ liệu biến mất âm thầm
• Mở lại toàn bộ worker cùng lúc sau sự cố làm dịch vụ đích sập lần nữa

Hàng đợi cũng làm hệ thống phức tạp hơn và tăng độ trễ cho từng việc. Với tác vụ đơn giản, lưu lượng thấp và không ghi vào hệ thống quan trọng, gọi trực tiếp có thể vẫn đủ. Hàng đợi đáng đầu tư khi việc mất hoặc trùng một tác vụ gây thiệt hại thật, như đơn hàng, thanh toán hay yêu cầu của khách.

6. Phân chia trách nhiệm vận hành

Đội kỹ thuật chịu trách nhiệm hạ tầng hàng đợi, cấu hình retry, thời gian khóa, cảnh báo và quy trình khôi phục. Chủ sở hữu nghiệp vụ của từng loại tác vụ quyết định mức ưu tiên, thời gian chờ chấp nhận được và cách xử lý tác vụ trong dead letter. Người vận hành theo dõi bảng quan sát, xử lý dead letter theo hướng dẫn và báo lên khi một loại lỗi lặp lại nhiều.

Khi thêm loại tác vụ mới hoặc nối thêm hệ thống đích, cần cập nhật bảng loại tác vụ, cấu hình hàng đợi và hướng dẫn xử lý. Khi hệ thống đích thay đổi API, các tác vụ đang chờ có thể không còn đúng định dạng; cần kiểm tra phần tồn trước khi chuyển đổi.

7. Chỉ số nên theo dõi

• Độ dài hàng đợi và tuổi tác vụ cũ nhất theo từng hàng
• Tỷ lệ tác vụ phải thử lại và số lần thử trung bình
• Số tác vụ vào dead letter theo loại lỗi và thời gian xử lý tay
• Thời gian từ khi tác vụ phát sinh đến khi ghi xong vào hệ thống đích

Số tác vụ xử lý thành công mỗi ngày không cho biết có tác vụ nào mất hay không. Cách kiểm chứng tốt hơn là đối soát định kỳ: đếm số yêu cầu ở nguồn và số bản ghi ở đích trong cùng khoảng thời gian, mọi chênh lệch phải giải thích được bằng tác vụ đang chờ hoặc đang ở dead letter.

8. Checklist trước khi vận hành

• Producer chỉ báo đã nhận sau khi ghi bền vào hàng đợi
• Worker chỉ ack sau khi hệ thống đích xác nhận ghi thành công
• Mỗi tác vụ làm lại an toàn nhờ khóa chống trùng ở hệ thống đích
• Lỗi được phân loại tạm thời và vĩnh viễn, retry có giới hạn và giãn dần
• Dead letter có người nhận, hướng dẫn xử lý và công cụ đẩy lại
• Đã diễn tập dịch vụ đích sập, worker chết giữa chừng và tải dồn

9. Câu hỏi thường gặp

AI Agent nhỏ có cần hàng đợi tác vụ không? Không phải lúc nào cũng cần. Nếu agent chỉ trả lời câu hỏi và không ghi vào hệ thống quan trọng, gọi trực tiếp có thể đủ. Khi agent tạo đơn, cập nhật CRM hay xử lý yêu cầu mà mất một việc là có thiệt hại, hàng đợi đáng được đầu tư.

Vì sao không nên ack ngay khi worker lấy tác vụ ra? Vì nếu worker chết hoặc hệ thống đích lỗi sau thời điểm đó, tác vụ đã bị xóa khỏi hàng đợi mà chưa hoàn thành, tức là mất. Ack sau khi ghi xong đảm bảo việc chưa xong sẽ được trả lại để làm tiếp.

Tác vụ trong dead letter nên xử lý thế nào? Mỗi loại tác vụ cần một người nhận và hướng dẫn xử lý: xem dữ liệu và lỗi, sửa rồi đẩy lại, xử lý tay trên hệ thống đích, hoặc đóng kèm lý do. Mọi thao tác đều được ghi nhật ký để đối soát sau.

Làm sao biết hàng đợi đang có vấn đề? Theo dõi tuổi của tác vụ cũ nhất và độ dài hàng đợi theo thời gian. Tuổi tăng liên tục nghĩa là có việc bị kẹt hoặc năng lực xử lý không đủ; số tác vụ vào dead letter tăng đột ngột thường báo hiệu hệ thống đích hoặc dữ liệu nguồn vừa thay đổi.

Kết luận

Hàng đợi tác vụ giúp AI Agent không đánh mất việc khi một phần hệ thống gặp sự cố. Điểm mấu chốt là ghi bền trước khi báo đã nhận, chỉ ack sau khi ghi xong, thử lại có giới hạn, có người xử lý dead letter, ưu tiên việc có người đang chờ, và quan sát tuổi tác vụ. Diễn tập sự cố trước khi vận hành thật sẽ cho biết thiết kế có giữ được dữ liệu như mong muốn hay không.

Trao đổi với Naventic để thiết kế luồng xử lý tác vụ bền vững cho AI Agent. Đọc thêm: AI Workflow Automation.