Your AI Agent không cần phải thông minh hơn. Nó cần phải có tính Idempotent

Hầu hết các AI agent trong môi trường production không thất bại vì suy luận kém. Chúng thất bại vì các lỗi mạng.

Mô hình chọn đúng công cụ. Nó điền đúng các chi tiết. Sau đó, nó lại tính phí khách hàng hai lần.

Điều này xảy ra vì các agent có khả năng ghi (write-capable) hoạt động trong các mạng không đáng tin cậy.

  • Các yêu cầu bị hết thời gian chờ (timeout).
  • Kết nối bị ngắt.
  • Các framework thực hiện lại (retry) các bước đã hoàn thành.

Với một agent chỉ đọc (read-only), việc retry là miễn phí. Với một agent có khả năng ghi, việc retry là một hành động thứ hai không thể đảo ngược.

Giải pháp chính là tính idempotency.

Hãy nhìn vào lỗi phổ biến này:

  1. Agent gọi một hàm để gửi hóa đơn.
  2. Dịch vụ tạo hóa đơn.
  3. Kết nối bị ngắt trước khi phản hồi đến được agent.
  4. Agent thấy timeout và thực hiện retry.
  5. Giờ đây, bạn có hai hóa đơn.

Một mô hình thông minh hơn sẽ không giải quyết được vấn đề này. Một mô hình thông minh hơn thậm chí có thể làm mọi chuyện tệ hơn do thực hiện retry một cách quyết liệt hơn.

Bạn có thể học hỏi từ các hệ thống thanh toán như Stripe. Họ sử dụng một Idempotency-Key. Máy chủ lưu lại kết quả của yêu cầu đầu tiên. Nếu client gửi lại cùng một key đó, máy chủ sẽ trả về kết quả đã lưu thay vì thực hiện hành động đó lần thứ hai.

Đối với một AI agent, bạn phải tạo ra key này từ ý định (intent).

Đừng sử dụng các ID ngẫu nhiên. Hãy sử dụng một bản hash của tên công cụ và các tham số ổn định của nó.

Ví dụ:

  • Tool: charge_customer
  • Params: {customer_id: 42, amount: 500}
  • Key: hash(tool + params)

Nếu agent thực hiện retry chính xác cùng một giao dịch tính phí, key vẫn sẽ giữ nguyên. Hệ thống sẽ nhận diện được và ngăn chặn việc tính phí trùng lặp.

Một lời cảnh báo: Key của bạn chỉ hiệu quả khi định nghĩa về một hành động đơn lẻ của bạn chính xác.

  • Nếu bạn đưa timestamp vào bản hash, mỗi lần retry sẽ nhận được một key mới. Cơ chế bảo vệ của bạn sẽ thất bại.
  • Nếu bạn đưa nội dung tin nhắn do LLM viết vào, mô hình có thể thay đổi chỉ một từ. Điều này tạo ra một key mới và dẫn đến hành động trùng lặp.

Luôn tạo key dựa trên các dữ liệu ổn định như customer ID hoặc invoice ID. Hãy loại bỏ bất cứ thứ gì mà mô hình có thể thay đổi.

Hãy ngừng việc cố gắng cải thiện độ tin cậy của agent bằng những prompt tốt hơn.

Độ tin cậy là việc làm cho chi phí của một quyết định lặp lại trở về bằng không. Nếu agent của bạn thực hiện cùng một hành động hai lần, không có gì được phép bị lỗi.

Source: https://dev.to/gs_sanjana_3e822112e14f8/your-ai-agent-doesnt-need-to-be-smarter-it-needs-to-be-idempotent-2736

Optional learning community: https://t.me/GyaanSetuAi