Kế hoạch Rollback cho AI Agent: Hoàn tác các hành động sai lầm trước khi người dùng mất lòng tin
Một AI agent đáng tin cậy không cần phải hoàn hảo. Nó cần biết cách dừng lại, giải thích lỗi sai và phục hồi.
Nếu agent của bạn cập nhật sai trường dữ liệu CRM hoặc gửi một khoản thanh toán trùng lặp, việc thử lại (retry) đơn thuần sẽ không thể khắc phục thiệt hại. Bạn cần một kế hoạch rollback trước khi đối mặt với một sự cố thực tế.
Khi các agent chuyển từ việc trò chuyện sang thực hiện công việc thực tế, chúng bắt đầu làm thay đổi trạng thái (mutate state). Điều này biến rollback trở thành một tính năng của sản phẩm, chứ không chỉ là một tác vụ ở backend.
Các chế độ lỗi phổ biến:
- Agent sử dụng sai ID bản ghi.
- Việc retry lặp lại một hành động hai lần.
- Việc chuyển đổi model làm thay đổi cách một công cụ hoạt động.
- Một workflow tiếp tục chạy với bộ nhớ cũ.
- Một chuỗi hành động không hoàn chỉnh khiến dữ liệu không nhất quán.
Cách xây dựng một lớp phục hồi (recovery layer):
Sử dụng Sổ cái Hành động (Action Ledger) Đừng chỉ dựa vào logs. Hãy tạo một sổ cái ghi lại mọi thay đổi trạng thái. Mỗi lần gọi công cụ (tool call) phải tạo một mục ghi chép trước và sau khi thực thi. Đây chính là nguồn dữ liệu chuẩn (source of truth) để phục hồi.
Phân loại các hành động của bạn Không phải hành động nào cũng giống nhau.
- Chỉ đọc (Read-only): Không cần rollback.
- Cập nhật nội bộ (Internal updates): Khôi phục giá trị trước đó từ một bản snapshot.
- Bên ngoài có thể đảo ngược (External reversible): Xóa sự kiện hoặc cập nhật trạng thái.
- Bên ngoài không thể đảo ngược (External irreversible): Sử dụng cơ chế bù đắp (compensation) thay vì một lệnh undo thực sự. Đối với email hoặc thanh toán, bạn không thể "thu hồi" chúng. Bạn phải gửi một thông báo đính chính hoặc thực hiện hoàn tiền.
Áp dụng tính lũy đẳng (Idempotency) Model không tự áp dụng tính lũy đẳng. Runtime của công cụ phải làm việc đó. Hãy sử dụng các idempotency key để đảm bảo rằng nếu agent thử lại một tác vụ, nó sẽ không tạo ra các tác dụng phụ (side effects) trùng lặp.
Sử dụng Saga Pattern Đối với các workflow dài, mỗi hành động tiến tới (forward action) đều cần một hành động bù đắp (compensating action).
- Tạo một tác vụ? Hành động bù đắp là xóa hoặc hủy nó.
- Cập nhật một trường dữ liệu? Hành động bù đắp là khôi phục giá trị cũ.
- Gửi một email? Hành động bù đắp là gửi một email đính chính.
Triển khai các điểm kiểm soát (Checkpoints) Đừng yêu cầu model "tự tìm xem chúng ta đang ở đâu" sau khi bị crash. Hãy sử dụng các checkpoint để lưu trữ trạng thái hiện tại, các hành động đã hoàn thành và các tác vụ đang chờ xử lý. Hệ thống nên tải checkpoint để tiếp tục công việc.
Xây dựng Hàng đợi Phục hồi (Recovery Queue) Khi một bước xác minh thất bại, hãy chuyển tác vụ đó vào hàng đợi phục hồi. Điều này cho phép bạn tiếp tục, bù đắp hoặc đóng tác vụ. Đối với các lỗi có rủi ro cao, hãy luôn yêu cầu sự phê duyệt từ con người.
Niềm tin được xây dựng thông qua quá trình phục hồi minh bạch. Khi một agent mắc lỗi, đừng sử dụng ngôn ngữ mơ hồ. Hãy nói chính xác cho người dùng biết điều gì đã thay đổi, tại sao nó xảy ra và bạn đã khắc phục nó như thế nào.
Hãy xây dựng kế hoạch rollback trước khi sự cố đầu tiên xảy ra.
Optional learning community: https://t.me/GyaanSetuAi