Xử lý API rate limit khi AI Agent kết nối nhiều hệ thống

Một AI Agent chăm sóc khách hàng có thể phải đọc CRM, tra trạng thái đơn trong hệ thống bán hàng, kiểm tra tồn kho, gửi tin qua nền tảng nhắn tin và gọi mô hình ngôn ngữ, tất cả trong một lượt trả lời. Mỗi hệ thống đó đều có giới hạn số lượt gọi trong một khoảng thời gian. Ngày thường không ai để ý. Đến hôm chạy khuyến mãi, lượng tin nhắn tăng vọt, một API bắt đầu trả lỗi 429 “quá nhiều yêu cầu”, agent gọi lại liên tục và làm tình hình tệ hơn.

API rate limit không phải lỗi hiếm mà là điều kiện vận hành bình thường khi agent kết nối nhiều hệ thống. Bài viết trình bày cách thiết kế để agent sống chung với hạn mức: biết hạn mức của từng nơi, tự điều tiết, giảm số lượt gọi không cần thiết, ưu tiên đúng việc và suy giảm có kiểm soát khi thiếu tài nguyên.

1. Vì sao AI Agent dễ chạm hạn mức

Phần mềm truyền thống thường có số lượt gọi API tỷ lệ thuận với thao tác của người dùng: bấm một nút, gọi một lần. AI Agent thì khác. Một câu hỏi có thể khiến agent gọi ba, bốn công cụ; nếu kết quả thiếu, agent gọi thêm; nếu mô hình lập kế hoạch chưa tốt, nó có thể gọi cùng một công cụ nhiều lần với tham số hơi khác. Cộng thêm tác vụ nền như đồng bộ lead, cập nhật trạng thái, nhiều phiên chạy song song, số lượt gọi có thể tăng nhanh hơn nhiều so với số khách.

Hạn mức cũng có nhiều dạng: theo giây, theo phút, theo ngày; theo khóa API, theo tài khoản, theo địa chỉ IP; với mô hình ngôn ngữ còn có hạn mức theo số token. Có hạn mức cứng (vượt là bị chặn) và hạn mức mềm (vượt thì bị tính thêm phí hoặc bị làm chậm). Bài AI Agent đa kênh đã nhắc tới giới hạn API của từng kênh nhắn tin; bài này đi vào cách xử lý hạn mức một cách có hệ thống cho mọi hệ thống mà agent chạm tới.

2. Các yếu tố cần thiết kế

1. Quota

Việc đầu tiên là lập bảng hạn mức: với mỗi hệ thống, hạn mức là gì, tính theo đơn vị nào, áp cho khóa nào, đặt lại lúc nào, vượt thì bị chặn hay bị tính phí, và hạn mức đó có dùng chung với ứng dụng khác của doanh nghiệp không. Điểm cuối rất hay bị bỏ qua: CRM có thể đang phục vụ cả website, phần mềm kế toán và agent trên cùng một hạn mức tài khoản. Agent dùng hết thì các hệ thống khác cũng hỏng theo. Bảng này nên do đội tích hợp giữ và cập nhật khi đổi gói dịch vụ.

2. Throttling

Thay vì gọi thoải mái rồi chờ bị chặn, agent nên tự điều tiết ở phía mình: mỗi hệ thống có một “van” giới hạn số lượt gọi đồng thời và số lượt gọi mỗi khoảng thời gian, đặt thấp hơn hạn mức thật để chừa phần cho hệ thống khác và cho lúc đột biến. Van này nằm ở lớp gọi công cụ, không nằm trong prompt, vì mô hình không đếm lượt gọi đáng tin. Khi van đầy, yêu cầu mới phải chờ hoặc được xử lý theo mức ưu tiên ở mục 6.

3. Queue

Những việc không cần trả lời ngay như đồng bộ dữ liệu, gửi tin hàng loạt, cập nhật CRM sau hội thoại nên được đưa vào hàng đợi và chạy với tốc độ vừa với hạn mức. Hàng đợi giúp hấp thụ đột biến thay vì dồn tất cả vào một lúc. Thiết kế hàng đợi đầy đủ (xác nhận, thử lại, dead letter, khôi phục) là một đề tài riêng, xem bài hàng đợi tác vụ AI Agent; ở đây chỉ cần nhớ nguyên tắc: việc có thể chờ thì đừng tranh hạn mức với việc có khách đang chờ.

4. Caching

Rất nhiều lượt gọi của agent là đọc lại cùng một dữ liệu: danh mục sản phẩm, giá niêm yết, giờ mở cửa chi nhánh, thông tin khách vừa tra hai phút trước. Cache những kết quả đọc này giảm đáng kể số lượt gọi. Mỗi loại dữ liệu cần thời hạn cache riêng theo tốc độ thay đổi; tồn kho và trạng thái đơn chỉ nên cache rất ngắn hoặc không cache. Cách phân biệt dữ liệu ổn định và dữ liệu thời gian thực có ở bài AI Agent và dữ liệu thời gian thực. Cache dữ liệu cá nhân phải tách theo người dùng để không trả nhầm cho người khác.

5. Batching

Nhiều API cho phép đọc hoặc ghi nhiều bản ghi trong một lần gọi. Khi agent cần cập nhật trạng thái cho nhiều lead, tra nhiều mã sản phẩm hay ghi nhiều ghi chú, gom lại thành một lô tiết kiệm hạn mức hơn nhiều so với gọi từng cái. Gom lô phù hợp với tác vụ nền; với tác vụ có khách chờ, chỉ gom trong phạm vi một lượt trả lời để không làm chậm câu trả lời. Khi một phần của lô bị lỗi, hệ thống phải biết phần nào đã thành công để không ghi lặp.

6. Ưu tiên

Khi tài nguyên thiếu, không phải việc nào cũng quan trọng như nhau. Thứ tự hợp lý thường là: khách đang chờ trả lời trong phiên chat; hành động khách đã yêu cầu như đổi lịch, hủy đơn; thông báo có thời hạn; rồi mới tới đồng bộ nền và báo cáo. Van điều tiết ở mục 2 nên dành riêng một phần hạn mức cho nhóm ưu tiên cao, để dù hàng đợi nền đang dài, khách vẫn được phục vụ.

7. Retry after

Khi bị chặn, nhiều API trả kèm thông tin nên chờ bao lâu (thường qua header Retry-After) hoặc số lượt còn lại. Agent phải đọc và tôn trọng thông tin này. Nếu không có, chờ theo khoảng tăng dần kèm một chút ngẫu nhiên để các phiên không cùng thử lại một lúc, và giới hạn tổng số lần thử. Thử lại một hành động ghi phải đi kèm khóa chống lặp, nếu không một lần tạo đơn có thể thành hai; cách làm idempotency được trình bày ở bài webhook retry và idempotency.

8. Cảnh báo

Đợi tới khi bị chặn mới biết là quá muộn. Hệ thống nên theo dõi tỷ lệ sử dụng hạn mức theo từng hệ thống và cảnh báo khi vượt một ngưỡng, số lỗi 429 theo thời gian, độ dài hàng đợi và thời gian chờ trung bình. Cảnh báo sớm cho phép đội vận hành tạm dừng tác vụ nền, tăng thời hạn cache hoặc liên hệ nhà cung cấp nâng hạn mức trước khi khách bị ảnh hưởng.

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

Bước 1: Lập bảng hạn mức và đo lượng gọi thực tế

Hoàn thành bảng quota ở mục 1, rồi đo xem một lượt hội thoại điển hình gọi bao nhiêu lần tới từng hệ thống, tách theo loại yêu cầu. Con số này cho biết ở lượng khách nào thì hệ thống nào chạm trần trước.

Bước 2: Phân loại lượt gọi

Đánh dấu từng loại lượt gọi là đọc hay ghi, có khách chờ hay chạy nền, có cache được không, có gom lô được không. Đây là căn cứ để đặt van, cache và mức ưu tiên.

Bước 3: Dựng lớp gọi công cụ có điều tiết

Mọi lượt gọi ra hệ thống ngoài đi qua một lớp chung: van theo hệ thống, cache, gom lô, thử lại có chờ, khóa chống lặp và ghi số liệu. Làm ở một chỗ thay vì rải trong từng công cụ giúp đổi cấu hình khi hạn mức thay đổi mà không sửa logic của agent.

Bước 4: Thử quá tải rồi chỉnh

Giả lập lượng yêu cầu cao hơn bình thường và giả lập API trả 429, rồi quan sát: khách có vẫn được trả lời không, hàng đợi có tự rút về không, có hành động nào bị ghi lặp không. Kịch bản kiểm thử tải đầy đủ được bàn ở bài load test AI Agent.

4. Ví dụ giả định

Một cửa hàng thời trang trực tuyến có AI Agent trả lời trên nhiều kênh, đọc tồn kho từ phần mềm quản lý bán hàng và ghi lead vào CRM. Trong đợt giảm giá, agent bắt đầu trả lời chậm rồi báo lỗi. Nhật ký cho thấy phần mềm bán hàng trả 429: tác vụ đồng bộ tồn kho định kỳ, chatbot tra tồn kho và website cùng dùng chung một hạn mức tài khoản.

Nhóm vận hành xử lý theo thứ tự. Trước mắt, tạm dừng tác vụ đồng bộ nền để dành hạn mức cho khách đang chat. Sau đó, thêm cache ngắn cho tồn kho theo mã sản phẩm, vì trong vài phút nhiều khách hỏi cùng một mẫu. Tác vụ ghi lead vào CRM được chuyển vào hàng đợi, gom lô và chạy chậm lại. Van điều tiết dành riêng một phần hạn mức cho lượt tra có khách chờ. Khi phần mềm bán hàng vẫn chặn, agent trả lời rằng đang không kiểm tra được tồn kho lúc này và đề nghị để lại số điện thoại để nhân viên báo lại, thay vì đoán còn hàng.

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

• Thử lại dồn dập làm hệ thống đích quá tải thêm
• Cache quá lâu khiến agent trả lời bằng dữ liệu đã cũ
• Tác vụ nền chiếm hết hạn mức của việc có khách chờ
• Hạn mức dùng chung khiến agent làm hỏng các hệ thống khác

Doanh nghiệp không kiểm soát được hạn mức của nhà cung cấp bên ngoài; điều kiểm soát được là cách agent dùng phần hạn mức mình có. Rủi ro đáng lo nhất khi thiếu tài nguyên không phải là agent chậm, mà là agent che giấu việc thiếu dữ liệu bằng câu trả lời đoán. Mọi đường suy giảm phải dẫn tới câu trả lời trung thực: không tra được, sẽ báo lại, hoặc chuyển nhân viên. Cam kết thời gian phản hồi với khách cũng cần tính tới giới hạn này; xem thêm bài SLA AI Agent.

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

Đội tích hợp giữ bảng hạn mức, cấu hình van, cache và hàng đợi. Chủ các hệ thống nguồn (CRM, bán hàng, kho) thông báo khi đổi gói hoặc đổi hạn mức, và cùng quyết phần hạn mức dành cho agent. Người vận hành agent theo dõi cảnh báo và có quyền tạm dừng tác vụ nền khi cần. Bộ phận chăm sóc khách hàng duyệt các câu trả lời khi hệ thống suy giảm, để khách nhận được thông tin rõ ràng và nhất quán.

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

• Tỷ lệ sử dụng hạn mức theo từng hệ thống và từng khóa API
• Số lỗi 429 và thời gian chờ thử lại theo hệ thống
• Tỷ lệ trúng cache và số lượt gọi trung bình trên mỗi lượt hội thoại
• Độ dài và tuổi của hàng đợi tác vụ nền

Số lượt gọi trên mỗi lượt hội thoại là chỉ số hay bị bỏ quên nhưng rất đáng xem: nếu nó tăng sau một lần sửa prompt hay thêm công cụ, agent đang gọi thừa, và chuyện chạm hạn mức chỉ còn là vấn đề thời gian.

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

• Bảng hạn mức đủ cho mọi hệ thống, ghi rõ hạn mức dùng chung
• Mọi lượt gọi ra ngoài đi qua lớp điều tiết chung
• Cache có thời hạn theo loại dữ liệu, tách theo người dùng
• Thử lại tôn trọng Retry-After, có giới hạn và khóa chống lặp
• Phần hạn mức riêng cho việc có khách chờ
• Cảnh báo trước khi chạm trần và câu trả lời khi suy giảm đã duyệt

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

Vì sao AI Agent hay chạm rate limit hơn phần mềm thông thường? Vì một yêu cầu của người dùng có thể khiến agent gọi nhiều công cụ liên tiếp, gọi lại khi kết quả chưa đủ, và nhiều phiên chạy song song cùng dồn vào một hệ thống. Thêm vào đó, mô hình ngôn ngữ cũng có hạn mức riêng. Nếu không có lớp điều tiết, số lượt gọi tăng nhanh hơn nhiều so với số người dùng.

Khi API trả lỗi 429 thì AI Agent nên làm gì? Không gọi lại ngay. Agent nên đọc thời gian chờ mà hệ thống gợi ý nếu có, chờ với khoảng tăng dần kèm một chút ngẫu nhiên, và giới hạn số lần thử. Nếu khách đang chờ, agent nói rõ là đang tra cứu chậm hoặc hẹn trả lời sau, thay vì im lặng hoặc bịa kết quả.

Có nên cache dữ liệu để tránh rate limit không? Nên, với dữ liệu đọc ít thay đổi như danh mục sản phẩm, chính sách, thông tin chi nhánh. Không nên cache lâu với dữ liệu thay đổi nhanh như tồn kho, trạng thái đơn, số dư. Mỗi loại cache cần thời hạn riêng và cách làm mới khi dữ liệu gốc đổi.

Làm sao biết trước sắp chạm hạn mức API? Theo dõi số lượt gọi theo từng hệ thống và từng khóa API so với hạn mức, đọc các thông tin hạn mức còn lại mà nhiều API trả về kèm phản hồi, và đặt cảnh báo khi vượt một tỷ lệ nhất định. Cảnh báo sớm cho phép hạ bớt tác vụ nền trước khi tác vụ có khách chờ bị ảnh hưởng.

Kết luận

Khi AI Agent kết nối nhiều hệ thống, rate limit là điều kiện vận hành chứ không phải sự cố hiếm. Lập bảng hạn mức, điều tiết phía agent, cache và gom lô đúng chỗ, ưu tiên khách đang chờ, thử lại có kỷ luật và cảnh báo sớm giúp agent chạy ổn cả lúc đông khách. Khi vẫn thiếu tài nguyên, agent phải nói thật thay vì đoán.

Trao đổi với Naventic để rà các điểm tích hợp và hạn mức API của AI Agent. Đọc thêm: AI Workflow Automation.