Trả lời ngắn: Error handling là cơ chế phát hiện, phân loại và phản ứng khi một bước của hệ AI thất bại. Retry chỉ là một phản ứng: thử lại khi lỗi có tính tạm thời và operation an toàn để lặp. Lỗi quyền, input sai hoặc side effect chưa rõ thường cần sửa, kiểm tra, chuyển người hoặc dừng.

Đọc xong, bạn sẽ hiểu:

  • Vì sao không phải lỗi nào cũng nên retry.
  • Cách phân loại lỗi model, tool, quyền và business rule.
  • Retry budget, backoff, jitter và idempotency hoạt động ra sao.
  • Cách lập Retry Decision Card bằng workflow giả.

Lưu ý giáo dục: Bài dùng lịch và tool giả, không kết nối calendar hoặc API thật. Tham số timeout/retry phải được đo và kiểm thử theo hệ thống cụ thể; không sao chép máy móc con số minh họa vào production.

1. Error Handling & Retry là gì? Lặp lại không phải lúc nào cũng sửa lỗi

a. Error handling là một cây quyết định

Trong Guardrails & Safety #28, guardrail quyết định yêu cầu nào được đi tiếp. Khi một bước vẫn thất bại, error handling phải thu thập lỗi, phân loại nguyên nhân và chọn phản ứng: retry, repair, fallback, escalate hoặc stop.

Retry nghĩa là thực hiện lại một operation. Nó hữu ích khi mạng chập chờn hoặc dịch vụ tạm quá tải. Nhưng nếu địa chỉ email sai, token hết quyền hoặc schema thiếu trường bắt buộc, chạy lại cùng input thường chỉ tạo cùng lỗi.

Hãy hình dung bạn bấm chuông. Người trong nhà chưa nghe thì bấm lại có ích. Bạn đứng sai địa chỉ thì bấm mười lần vẫn sai. Nếu mỗi lần bấm lại tạo một đơn hàng, retry còn có thể gây thiệt hại.

Hình 1 — Retry chỉ là một nhánh sau classify, không phải câu trả lời mặc định cho mọi lỗi.

b. Thất bại và trạng thái chưa rõ là hai chuyện khác nhau

Trong workflow lịch giả, tool create_event có thể timeout. Client biết mình chưa nhận response, nhưng không biết server đã tạo sự kiện hay chưa. Gọi lại mù có thể tạo hai lịch.

Mỗi attempt cần được harness ghi outcome quan sát được và độ chắc về side effect. Khi timeout không có response, client ghi UNKNOWN_EFFECT rồi query status bằng request ID/idempotency key. Với trạng thái unknown, bước an toàn thường là query bằng request ID hoặc idempotency key trước khi retry.

c. Mục tiêu là phục hồi có kiểm soát

Hệ bền không phải hệ “không bao giờ lỗi”. Nó làm lỗi nhỏ không lan thành loop, retry storm, chi phí bất thường hoặc dữ liệu trùng. Mỗi lỗi phải có owner, attempt count, deadline và stop reason để con người hiểu hệ đã làm gì.

2. Phân loại lỗi trước khi chọn hành động

a. Sáu nhóm lỗi thực dụng

Ví dụ: 429 → rate limit → chờ theo retry hint trong budget; 403 → quyền/policy → không retry; JSON sai schema → repair trước khi gọi tool; timeout side effect chưa rõ → query status.

  1. Transient: timeout, disconnect hoặc 5xx; có thể hết khi thử lại.
  2. Rate limit: 429 hoặc quota tạm; chờ theo hướng dẫn rồi thử có giới hạn.
  3. Validation/model: JSON sai schema, thiếu field hoặc output không đạt; sửa output/prompt, không nhất thiết gọi tool lại.
  4. Authorization/policy: 401, 403 hoặc guardrail block; không retry cho tới khi quyền/policy thay đổi.
  5. Permanent/business: slot đã kín, recipient không tồn tại, input bất hợp lệ; cần input mới hoặc fallback.
  6. Unknown: không đủ bằng chứng; fail closed hoặc chuyển người duyệt.

Google Cloud phân biệt response tạm thời có thể retry với lỗi permanent cần thay đổi quyền, cấu hình hoặc request. Họ cũng nhấn mạnh phải xét idempotency trước khi lặp một request. Google Cloud — Retry strategy

b. Chuẩn hóa bằng error envelope

Error envelope là bản ghi có cấu trúc, ví dụ: operation, error_class, code, retryable, attempt, side_effect, request_id, safe_context. Không đưa secret hoặc dữ liệu cá nhân thừa vào log.

Nếu mỗi tool trả lỗi tự do như “có gì đó không ổn”, orchestrator sẽ phải đoán. Envelope giúp policy quyết định nhất quán: TRANSIENT + NO_EFFECT có thể retry; AUTH phải stop; UNKNOWN_EFFECT phải kiểm status.

c. Tách lỗi model khỏi lỗi tool

Model trả JSON thiếu start_time là lỗi validation. Có thể repair output một lần bằng thông báo cụ thể. Chỉ sau khi schema hợp lệ mới gọi create_event.

Nếu tool đã được gọi và timeout, không quay lại sửa prompt như chưa có gì xảy ra. Hệ phải giữ request ID và kiểm side effect. Tách hai lớp tránh việc một lỗi format vô tình kích hoạt lại hành động bên ngoài.

3. Một retry an toàn cần những thành phần nào?

a. Timeout và retry budget

Timeout đặt giới hạn chờ cho từng operation. Retry budget đặt trần cho toàn vòng: tối đa bao nhiêu attempt, tổng thời gian, token, tool calls và chi phí. Khi hết một trần, hệ phải stop hoặc escalate.

Budget ngăn agent tự nói “thử thêm lần nữa”. Ví dụ giả: tối đa hai retry trong 20 giây. Đây chỉ là minh họa; production phải chọn theo latency, SLA, tác động và tải thật.

b. Exponential backoff và jitter

Backoff tăng thời gian chờ sau mỗi lần thất bại, thường theo cấp số nhân và có mức trần. Jitter thêm một khoảng ngẫu nhiên để nhiều client không retry cùng thời điểm.

Khi lỗi tạm thời, hệ thống có thể chờ 1 giây, rồi 2 giây, rồi 4 giây; thêm độ lệch nhỏ để nhiều máy không thử cùng lúc. Vẫn phải giới hạn số lần và thời hạn dừng. Nếu không có giới hạn, việc thử lại có thể làm dịch vụ đang quá tải càng quá tải. Google Cloud IAM — Retry failed requests · AWS Builders’ Library — Timeouts, retries, and backoff with jitter

Hình 2 — Backoff giảm nhịp gọi; jitter phân tán client; deadline buộc vòng retry kết thúc.

c. Idempotency bảo vệ side effect

Idempotency nghĩa là lặp cùng operation không làm kết quả cuối thay đổi thêm hoặc tạo side effect trùng. Với lịch giả, mọi lần gọi cho cùng ý định dùng key EVT-07. Server lưu key và trả lại sự kiện cũ thay vì tạo mới.

Ví dụ, chỉ tạo lịch nếu phiên bản slot vẫn là v3 (precondition); compare-and-set chỉ đổi trạng thái từ FREE sang BOOKED khi giá trị hiện tại vẫn là FREE. Nếu không chứng minh được an toàn, đừng tự động retry thao tác gửi, thanh toán, xóa hoặc publish.

d. Checkpoint và resume

Checkpoint lưu trạng thái sau một bước đã hoàn tất: input đã validate, slot đã chọn, event ID đã tạo. Khi workflow chạy lại, nó resume từ checkpoint thay vì làm lại từ đầu.

Checkpoint cần version, owner và bằng chứng hoàn tất. Không đánh dấu bước thành công chỉ vì model nói “done”; phải dựa trên response hoặc read-back của hệ thống đích.

4. Những lỗi retry phổ biến trong AI agent

a. Retry mọi exception

Một catch-all biến auth fail, schema fail và policy block thành cùng một vòng. Hệ tốn token nhưng nguyên nhân không đổi. Hãy allowlist lỗi retryable thay vì blocklist vài lỗi “không retry”.

b. Retry ở nhiều tầng

SDK retry ba lần, tool wrapper retry ba lần và orchestrator retry ba lần có thể nhân thành nhiều request. Chọn một tầng chịu trách nhiệm retry hoặc truyền attempt budget xuyên suốt. Log phải cho thấy attempt gốc và attempt con.

c. Không biết side effect đã xảy ra

Timeout không chứng minh server chưa xử lý. Đây là lỗi nguy hiểm nhất với action. Cần idempotency key, status endpoint hoặc human review; không dùng “response không về” làm bằng chứng “chưa tạo”.

d. Agent tự sửa đến khi “có vẻ đúng”

Repair loop có thể làm output trôi xa yêu cầu. Đặt repair budget trước theo loại lỗi và eval; ví dụ demo này cho phép tối đa một lượt sửa schema. Hết budget hoặc lỗi không đổi thì trả partial/escalate. Nếu vẫn sai, trả partial result hoặc escalate, không tự nới schema.

e. Fallback che mất sự cố

Fallback là đường giảm cấp, như chỉ tạo draft khi tool gửi lỗi. Nó phải được gắn nhãn và đo, không giả vờ là kết quả đầy đủ. Circuit breaker ở mức nhập môn có thể tạm ngừng gọi dependency đang lỗi liên tục, cho nó thời gian phục hồi và tránh retry storm.

5. Bài tập 15 phút: lập Retry Decision Card

a. Case lịch giả

Trên giấy hoặc Markdown, tạo workflow: kiểm slot rồi tạo lịch giả EVT-07. Tool giả gồm check_slot và create_event; không kết nối calendar. Viết bốn error card: timeout, 429, invalid schema và permission denied.

b. Mẫu đối chiếu: Retry Decision Card đã điền

Trường Mẫu điền
Operation create_event cho EVT-07
Error class Timeout; side effect UNKNOWN
First action Query status bằng key EVT-07
Idempotency Giữ cùng key cho mọi attempt
Retry budget Tối đa 2 lần trong 20 giây
Wait 2s, 4s cộng jitter
Stop Auth/policy fail hoặc hết deadline
Escalate Status vẫn unknown sau hai lần kiểm

Hình 3 — Quyết định retry phải gắn với loại lỗi, side effect, ngân sách và điều kiện dừng.

c. Chấm bốn error card

Timeout với effect unknown: query status trước. 429: chờ theo retry hint, backoff + jitter trong budget. Invalid schema: repair output, chưa gọi tool. Permission denied: stop và yêu cầu quyền phù hợp, không retry.

Nếu bạn chưa viết được stop reason cho một card, vòng phục hồi chưa hoàn chỉnh. “Hết retry” chỉ mô tả số lần; stop reason phải nói nguyên nhân và bước tiếp theo.

6. Tổng kết: retry có điều kiện, dừng có chủ đích

a. Năm ý chính

  • Error handling phân loại lỗi rồi chọn retry, repair, fallback, escalate hoặc stop.
  • Chỉ retry lỗi tạm thời và operation an toàn để lặp.
  • Retry cần timeout, budget, backoff, jitter và deadline.
  • Side effect cần idempotency key, precondition hoặc status check.
  • Checkpoint, error envelope và stop reason giúp resume, audit và bàn giao an toàn.

b. Câu hỏi tự kiểm tra

  • Vì sao timeout không chứng minh operation chưa chạy?
  • Lỗi validation khác lỗi tool thế nào?
  • Jitter giải quyết vấn đề gì?
  • Khi nào permission denied được retry?

c. Gợi ý đáp án

Xem gợi ý câu 1Server có thể đã xử lý nhưng response bị mất; cần idempotency hoặc status check. → Xem mục 1.
Xem gợi ý câu 2Validation sửa output trước tool; lỗi tool xảy ra khi gọi dependency và có thể đã tạo side effect. → Xem mục 2.
Xem gợi ý câu 3Jitter làm các client không retry đồng loạt, giảm spike và tranh chấp. → Xem mục 3.
Xem gợi ý câu 4Chỉ sau khi quyền hoặc credential thật sự thay đổi; lặp cùng trạng thái không có ích. → Xem mục 2.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Error handling Phát hiện, phân loại và phản ứng với lỗi.
Retry Thực hiện lại một operation.
Transient error Lỗi tạm thời có thể hết.
Permanent error Lỗi cần đổi input, quyền hoặc config.
Error envelope Bản ghi lỗi có cấu trúc.
Retry budget Trần attempt, thời gian và chi phí.
Backoff Tăng khoảng chờ giữa lần thử.
Jitter Thêm độ trễ ngẫu nhiên.
Idempotency Lặp operation không tạo hiệu ứng trùng.
Checkpoint Trạng thái lưu để resume an toàn.

e. Nguồn tham khảo

f. Học tiếp gì?

Xem lại Guardrails & Safety #28 nếu chưa rõ fail closed và human escalation. Học tiếp Framework Harness Engineering #30: ghép routing, tool, MCP, multi-agent, guardrail và retry thành một khung thiết kế thống nhất.

Nhắc lại giáo dục: Retry production phải được thiết kế theo API, side effect, tải, SLA và rủi ro thật; ví dụ trong bài không phải cấu hình mặc định.