Module 5 • Bài 4340 phút

Chiến Lược Recovery Khi Một Bước Giữa Chuỗi Bị Lỗi

Xây dựng cơ chế Checkpoint, Idempotent Retry và Compensating Rollback khi mắt xích giữa chuỗi bị gãy để bảo toàn trạng thái hệ thống.

Thiết kế cơ chế Checkpoint, Retry an toàn và Rollback / Compensating Action
Xây dựng cây quyết định xử lý lỗi kết hợp Retry Budget và Escalation Gate

Chiến Lược Recovery Khi Một Bước Giữa Chuỗi Bị Lỗi

Trong các tương tác AI đơn lượt (single-turn), khi model trả lời sai hoặc gặp sự cố, giải pháp rất đơn giản: yêu cầu người dùng bấm "Thử lại" (Regenerate). Nhưng trong một agentic workflow nhiều bước, khi một mắt xích ở giữa chuỗi bị gãy, vấn đề phức tạp hơn gấp nhiều lần: các bước trước đó có thể đã thay đổi dữ liệu, trừ tiền hoặc gọi API bên ngoài, để lại "tàn dư tác dụng phụ" (unintended side effects) nếu không được xử lý chuẩn xác.

Ví dụ xuyên suốt bài: TravelPlanner — agent tự động đặt trọn gói chuyến công tác (vé máy bay + phòng khách sạn) cho nhân viên công ty.

1. Bộ ba công cụ phục hồi: Checkpoint, Retry và Rollback

Khi thiết kế cơ chế khôi phục lỗi (Failure Recovery) cho chuỗi hành động của agent, PM cần trang bị 3 khái niệm:

  • Checkpoint (Điểm kiểm tra trạng thái): Bản lưu snapshot trạng thái dữ liệu và tiến trình tại một mốc cụ thể trong chuỗi. Khi có sự cố, hệ thống có thể phục hồi từ checkpoint gần nhất thay vì bắt agent chạy lại từ đầu.
  • Retry (Thử lại): Kích hoạt agent thực hiện lại bước vừa gặp lỗi. Ràng buộc sống còn: Chỉ được phép tự động Retry nếu bước đó có tính Idempotent (đã học ở Lesson 41). Retry một bước không idempotent (như bấm thanh toán thẻ) sẽ dẫn đến rủi ro trừ tiền 2 lần.
  • Rollback / Compensating Action (Hành động bù trừ / Hoàn tác): Chuỗi hành động nhằm hủy bỏ hoặc đảo ngược tác dụng phụ của các bước đã chạy thành công trước đó, khi bước phía sau thất bại không thể cứu vãn và khiến toàn bộ nhiệm vụ bị đình trệ.

Cây Quyết Định Xử Lý Lỗi (Failure Recovery Strategy)

Xác định khi nào Retry, khi nào Rollback hoàn tác và khi nào Escalate cho con người.

Chọn kịch bản lỗi khi bước giữa chuỗi bị gãy:

2. Compensating Action / Rollback (Hoàn tác tác dụng phụ)

Điều kiện kích hoạt: Lỗi nghiệp vụ không thể tự cứu (Hết phòng, Thẻ từ chối) HOẶC đã hết Retry Budget.
Hành động hệ thống (Recovery Action): Tự động gọi API hủy bỏ / hoàn tác các bước đã chạy thành công trước đó để tránh để lại tàn dư dữ liệu sai.
Minh họa trên TravelPlanner: Khách sạn hết phòng thật → Tự động hủy vé máy bay (trong hạn free cancel) hoặc khóa tạm giữ vé.
Case Study TravelPlanner (Đặt vé máy bay + Khách sạn)

Bước 1 (Đặt vé máy bay) đã thành công và trừ tiền. Bước 2 (Khách sạn) bị từ chối do hết phòng. Hệ thống bắt buộc phải Rollback bước 1 hoặc Escalate kèm gói đề xuất thay thế.

Chỉ Retry khi bước đó Idempotent và còn Retry Budget; nếu lỗi nghiệp vụ hoặc hết ngân sách, bắt buộc kích hoạt Rollback.

2. Ví dụ: Khi bước 1 Pass hoàn hảo nhưng bước 2 thất bại

Xét quy trình 2 bước của TravelPlanner:

  1. Bước 1 — Đặt vé máy bay: Agent gọi API hãng bay, trừ tiền vé và nhận mã đặt chỗ #VN_882Step DoD: Pass 100%.
  2. Bước 2 — Đặt khách sạn: Agent gọi API khách sạn đối tác gần địa điểm họp → Kết quả: Khách sạn báo hết phòng trong ngày đó.

Nếu kỹ sư chỉ cài đặt một logic ngây thơ: "Lỗi bước nào thì retry bước đó 3 lần", hệ thống sẽ retry bước 2 vô ích vì khách sạn thực sự đã hết phòng (lỗi nghiệp vụ, không phải lỗi mạng timeout).

Sau khi hết lượt thử, nếu hệ thống dừng lại và báo lỗi đơn thuần, nhân viên sẽ rơi vào tình trạng: Đã bị trừ tiền mua vé máy bay nhưng không có phòng khách sạn để ở. Nhiệm vụ hoàn toàn vi phạm Overall Completion Criteria (Lesson 38).

Giải pháp chuẩn sản phẩm: Hệ thống kích hoạt Compensating Action (Rollback bước 1) — tự động gọi API hủy vé máy bay (nếu trong thời hạn hủy miễn phí) hoặc tạm giữ mã vé và lập tức gửi thông báo Escalate cho nhân viên: "Đã giữ chỗ vé máy bay, nhưng khách sạn A hết phòng. Bạn muốn đổi sang khách sạn B (cách 2km) hay muốn hủy vé máy bay?"

3. Cây quyết định Recovery: Retry Budget và Escalation Gate

Khi một bước trong chuỗi báo lỗi, hệ thống phải duyệt qua cây quyết định sau:

Bước gặp lỗi
   ├── Bước có tính Idempotent không?
   │      ├── CÓ ──> Còn Retry Budget không?
   │      │            ├── CÓ ──> RETRY bước đó (Exponential Backoff)
   │      │            └── KHÔNG ──> Kích hoạt ROLLBACK các bước trước & ESCALATE cho người
   │      └── KHÔNG ──> DỪNG NGAY LẬP TỨC ──> Giữ Checkpoint & ESCALATE cho người
Tình huống lỗiHành động xử lý chuẩnVí dụ
Lỗi mạng tạm thời (Timeout, Rate limit)Retry có kiểm soát (với Idempotency Key)API tra cứu giá vé bị quá tải
Lỗi dữ liệu nghiệp vụ (Hết hàng, Hết phòng)Không Retry → Kích hoạt Rollback & HandoffĐặt khách sạn bị từ chối do kín phòng
Hết Retry Budget (Chạm Max Iterations - AI Literacy Lesson 12)Kích hoạt Rollback về Checkpoint an toàn nhấtĐã thử gọi cổng thanh toán 3 lần đều fail

4. Ẩn dụ: Phục vụ bữa tiệc nhiều món

Cơ chế phục hồi giống như quy trình của một bếp trưởng phục vụ tiệc:

  • Món chính bị cháy (Lỗi cục bộ): Đầu bếp làm lại đĩa thịt mới (Retry), không cần phải vứt bỏ đĩa súp khai vị khách vừa ăn xong (giữ Checkpoint).
  • Phục vụ nhầm bàn: Nếu món khai vị dọn nhầm sang bàn của khách ăn chay (Tác dụng phụ sai lệch), nhà hàng không thể phớt lờ và cứ thế mang món tráng miệng ra. Phục vụ phải thu hồi đĩa sai (Rollback), xin lỗi khách và điều chỉnh lại toàn bộ thực đơn.

Bài tập 43.1: Bạn thiết kế CampaignPublisher — agent tự động xuất bản chiến dịch marketing gồm 3 bước:

  1. Bước 1: Tạo hình ảnh banner quảng cáo bằng AI model.
  2. Bước 2: Đăng bài viết kèm banner lên Fanpage Facebook (đã public bài viết).
  3. Bước 3: Gọi API Facebook Ads để nạp ngân sách chạy quảng cáo 2.000.000đ cho bài viết đó.

Giả sử Bước 1 và Bước 2 đã hoàn thành xuất sắc, nhưng Bước 3 bị từ chối do thẻ visa công ty bị từ chối thanh toán.

  • Phân tích rủi ro nếu hệ thống không có cơ chế Recovery.
  • Hãy thiết kế quy trình Rollback / Compensating Action và thông điệp Escalation gửi cho Marketing Lead.