AI agent gặp lỗi: khi nào retry, fallback, dừng hay bàn giao?

Khi AI agent gọi tool bị lỗi, nên làm gì?

Trả lời ngắn: đừng cho AI agent retry ngay. Trước hết, hãy phân loại lỗi và xác định side-effect state — hành động chưa bắt đầu, chắc chắn chưa tạo thay đổi, đã hoàn tất, hay chưa biết kết quả. Sau đó mới chọn một trong bốn route:

1. Retry trong một ngân sách hữu hạn nếu lỗi có khả năng tạm thời và action có thể replay phù hợp.
2. Fallback nếu đường thay thế vẫn đáp ứng quyền, độ mới và output contract đã định.
3. Stop nếu input, quyền, policy hoặc dependency không cho phép tiếp tục.
4. Human handoff nếu outcome chưa biết, action khó đảo ngược hoặc cần người có quyền quyết định.

Điểm quan trọng nhất: timeout không chứng minh action chưa xảy ra. Nếu tool có thể đã gửi email, tạo invoice hay cập nhật CRM, hãy reconcile trạng thái hoặc dùng cơ chế idempotency trước khi replay.

Bạn có thể tải ba tài sản thực hành:

• Mẫu failure policy cho AI agent — YAML
• Bộ 10 test case xử lý lỗi — CSV
• Biên bản bàn giao sự cố — Markdown

Giới hạn: đây là bộ mẫu biên tập v1.0 của Đũa Thần AI, chưa được xác thực độc lập. Nó không phải standard, benchmark, security certification hay bằng chứng production readiness. Hãy tùy chỉnh và kiểm tra theo tool, API, quyền, dữ liệu và hậu quả thực tế.

Hình 1. Cùng một thông báo lỗi có thể dẫn đến route khác nhau tùy side effect, quyền và evidence.

Rà soát ngày 07/09/2026. Owner sửa nội dung: Nghiêm Xuân Hào. Gửi yêu cầu đính chính qua trang liên hệ.

Bắt đầu bằng hai câu hỏi: lỗi gì và action đang ở trạng thái nào?

Một nhãn như “tool error” quá rộng để quyết định. Hãy tách ít nhất hai lớp.

Failure class cho biết nguyên nhân vận hành có thể thuộc nhóm nào:

• dependency tạm thời không phản hồi;
• rate limit và có tín hiệu Retry-After;
• input sai schema;
• credential hoặc permission không hợp lệ;
• output không đúng contract;
• policy/guardrail từ chối;
• quá số bước, quá thời gian hoặc quá ngân sách;
• outcome không xác định sau một action có side effect.

Side-effect state cho biết môi trường bên ngoài có thể đã thay đổi hay chưa:

AWS định nghĩa idempotent operation là operation có thể retransmit hoặc retry mà không tạo thêm side effect; đồng thời lưu ý contract này làm dịch vụ phức tạp hơn và không phù hợp với mọi giải pháp (AWS Builders’ Library, truy cập 07/09/2026). Vì vậy, đừng tự gắn nhãn “idempotent” cho một tool chỉ vì request trông giống nhau.

Khi nào nên retry?

Retry phù hợp khi lỗi có khả năng tạm thời, action đáp ứng replay-safety đã biết và lần thử vẫn nằm trong retry budget. Retry không phải vòng lặp “thử đến khi được”.

Một retry policy tối thiểu cần:

1. failure class nào đủ điều kiện;
2. số lần hoặc tổng thời gian tối đa;
3. nguồn quy định backoff, jitter và Retry-After;
4. cách kiểm idempotency hoặc reconcile;
5. stop condition;
6. receipt cho từng attempt.

AWS Prescriptive Guidance khuyến nghị dùng retry/backoff cho transient failure, fail fast với non-transient error và xem xét idempotency; tài liệu cũng cảnh báo retry quá nhiều có thể làm dependency đang lỗi chịu thêm tải (AWS, truy cập 07/09/2026). Microsoft cũng lưu ý nhiều request cùng retry có thể cộng lại thành retry storm, ngay cả khi từng request có giới hạn riêng (Microsoft Azure Architecture Center, truy cập 07/09/2026).

Đừng sao chép một con số retry “chuẩn”. Budget phải dựa vào tài liệu provider, latency cho phép, hậu quả của duplicate, tổng tải và test thực tế.

Vì sao timeout cần nhánh “outcome unknown”?

Timeout chỉ mô tả việc caller chưa nhận response đúng hạn. Nó không khẳng định server chưa xử lý action.

Hãy tưởng tượng một consultant dùng agent để gửi email follow-up sau cuộc họp:

1. Agent tạo bản nháp và gọi tool gửi mail.
2. Client chờ 15 giây rồi timeout.
3. Mail server có thể đã nhận và gửi, nhưng receipt chưa về.
4. Nếu agent retry ngay, khách hàng có thể nhận hai email giống nhau.

Route tốt hơn là:

• giữ trạng thái unknown;
• tra cứu message ID hoặc sent folder qua nguồn có thẩm quyền;
• nếu tool hỗ trợ, dùng cùng idempotency key trong validity window;
• nếu không thể reconcile, stop và bàn giao receipt cho người;
• chỉ replay khi policy và evidence cho phép.

OpenAI Agents SDK là một ví dụ cụ thể về việc retries được quản lý có điều kiện: tài liệu nêu timeout, backoff/jitter và replay-safety boundary có thể ngăn retry sau khi output hoặc local side effect bắt đầu. Đây là hành vi của một SDK/version cụ thể, không phải quy tắc chung cho mọi agent (OpenAI Agents SDK, Models, truy cập 07/09/2026).

Fallback khác retry thế nào?

Retry lặp lại route chính vì cho rằng lỗi có thể hết. Fallback chọn một route khác để tiếp tục với điều kiện chấp nhận riêng.

Fallback không tự động tương đương với đường chính. Một cache, model khác, endpoint dự phòng hoặc quy trình thủ công có thể khác về:

• data freshness;
• permission scope;
• output schema;
• độ đầy đủ;
• chi phí và latency;
• khả năng audit;
• hậu quả downstream.

Vì vậy, hãy viết fallback acceptance criteria trước khi cần dùng. Ví dụ: “Có thể dùng bản contact list cache không quá 24 giờ để soạn draft, nhưng không được gửi; trước khi gửi phải reconcile với CRM live.” Đây là một điều kiện kiểm được, không phải lời hứa rằng fallback luôn tốt.

Circuit breaker dùng khi nào?

Circuit breaker tạm chặn call đến dependency có khả năng tiếp tục thất bại; retry chỉ thử lại một operation.

Microsoft mô tả ba trạng thái thường gặp:

• Closed: call đi qua và failure được quan sát.
• Open: call bị chặn trong thời gian/điều kiện đã định.
• Half-open: cho phép recovery probe có giới hạn trước khi mở lại.

Ngưỡng, thời gian và probe phải phù hợp workload. Circuit breaker có thể làm hệ thống phức tạp hơn hoặc trì hoãn recovery, nên không phải workflow nhỏ nào cũng cần (Microsoft Azure Architecture Center, cập nhật 21/03/2025; truy cập 07/09/2026).

Hình 2. Retry budget giới hạn một run; circuit breaker giới hạn áp lực lên dependency ở cấp rộng hơn.

Khi nào phải stop hoặc human handoff?

Stop khi agent không còn route hợp lệ trong quyền và policy. Handoff khi người nhận cần evidence để ra quyết định hoặc tiếp tục an toàn hơn.

Những trigger thực hành:

• authentication/permission bị từ chối;
• input sai nhưng agent không có source để sửa;
• outcome của action có side effect vẫn unknown;
• action khó đảo ngược hoặc tác động cao cần approval;
• retry budget đã hết;
• fallback không đạt acceptance criteria;
• circuit đang open;
• receipt thiếu evidence cần thiết;
• policy nói rõ “không tự tiếp tục”.

OWASP liệt kê tool abuse, excessive autonomy, cascading failure và unbounded loop trong các rủi ro của AI agent; hướng dẫn khuyến nghị least privilege, explicit authorization, action preview, approval cho action tác động cao và audit trail (OWASP AI Agent Security Cheat Sheet, truy cập 07/09/2026). Tuy nhiên, “có người bấm duyệt” không tự động làm action đúng: người duyệt vẫn cần thấy target, arguments, evidence, phần chưa biết và hậu quả.

OpenAI Agents SDK minh họa một cơ chế pause trước sensitive tool call, surface arguments, serialize state rồi resume hoặc reject một call cụ thể (OpenAI Agents SDK, Human-in-the-loop, truy cập 07/09/2026). Với framework khác, bạn cần kiểm tài liệu và state model tương ứng.

Biên bản bàn giao cần ghi gì?

Một handoff tốt cho phép người nhận biết action nào có thể đã xảy ra, evidence nào đã có và chính xác điều kiện nào cho phép tiếp tục.

Hình 3. Handoff chuyển cả state và evidence, không chỉ chuyển câu “tool bị lỗi”.

Bộ trường do bài này đề xuất:

1. workflow/version, run ID, tool/operation và attempt ID;
2. timestamp kèm timezone;
3. failure class;
4. side-effect state;
5. retry budget đã dùng;
6. reconciliation/idempotency evidence;
7. approval ID và trạng thái;
8. observed outcome;
9. next owner, next action và exact resume condition;
10. retention/redaction note.

Tài liệu OpenAI Agents SDK mô tả các exception cho max turns, model/tool timeout và tracing model generation, tool call, handoff, guardrail; đây là ví dụ cho loại event có thể quan sát, không phải yêu cầu universal (OpenAI Agents SDK, Running agents và Tracing, truy cập 07/09/2026). Log cũng có thể chứa dữ liệu nhạy cảm, nên hãy lưu reference thay vì raw secret và chỉ giữ dữ liệu phục vụ mục đích đã định.

Checklist 15 phút trước khi bật tool có quyền ghi

1. Chọn đúng một workflow và một operation.
2. Điền failure policy YAML.
3. Hỏi tool/API owner về idempotency và status lookup; không suy đoán.
4. Đặt retry budget và stop condition từ tài liệu/test hiện hành.
5. Định nghĩa fallback acceptance criteria.
6. Chỉ rõ action nào cần preview và approval.
7. Chạy 10 test case, nhất là outcome_unknown.
8. Tạo biên bản bàn giao từ một failure giả lập.
9. Giữ tool read-only nếu không thể xác minh duplicate, permission hoặc outcome.

Khi viết agent instructions, đưa failure class, giới hạn retry và handoff vào phần exception thay vì chỉ nói “hãy cẩn thận”; xem 7 thành phần của agent instructions. Với action cần người chịu trách nhiệm, chọn chế độ human-in-the-loop phù hợp. Sau mỗi recovery, nối receipt vào decision trail 6 trường và đưa failure mới vào bộ test, scorecard đánh giá AI agent.

FAQ

HTTP 429 có phải cứ retry không?

Không. Nó là tín hiệu để policy xem xét retry theo hướng dẫn provider, Retry-After, budget và tổng tải. Nếu budget hết hoặc circuit open, agent phải stop hoặc handoff.

Backoff có ngăn request bị trùng không?

Không. Backoff thay đổi thời điểm thử lại; idempotency hoặc reconciliation mới giải quyết câu hỏi replay có tạo thêm side effect hay không.

Fallback sang model khác có luôn chấp nhận được không?

Không. Model khác có thể thay đổi output contract, tool support, dữ liệu, latency hoặc quality. Chỉ dùng khi acceptance criteria và downstream check cho phép.

Human approval có đủ để agent an toàn không?

Không. Approval chỉ là một control. Nó không sửa input sai, quyền quá rộng, preview thiếu dữ liệu, log lộ secret hay outcome không kiểm được. OWASP cũng khuyến nghị kết hợp giới hạn functionality, permissions và autonomy (OWASP LLM06:2025, truy cập 07/09/2026).

Có nên chấm một “reliability score” chung không?

Không nên coi một điểm tổng là bằng chứng an toàn hoặc production readiness. NIST AI 600-1 là tài liệu quản trị rủi ro tự nguyện, không phải chứng nhận hay recipe xử lý retry cho một agent cụ thể (NIST, tháng 07/2024; truy cập 07/09/2026).

Bước tiếp theo

Tải failure policy, điền cho một operation và chạy test FT-02: timeout sau khi có thể commit. Nếu chưa có cách reconcile, idempotency evidence hoặc owner nhận handoff, hãy giữ operation ở read-only.

Muốn review một workflow thật? Gửi sơ đồ, policy và receipt đã khử dữ liệu nhạy cảm. Đũa Thần AI sẽ giúp bạn xác định câu hỏi và test cần bổ sung, không hứa chứng nhận hệ thống.

Nguồn tham khảo

• Featonby, Malcolm; AWS Builders’ Library. Making retries safe with idempotent APIs. Tài liệu hiện hành. Truy cập 07/09/2026. Nguồn.
• Amazon Web Services. Retry with backoff pattern. AWS Prescriptive Guidance, tài liệu hiện hành. Truy cập 07/09/2026. Nguồn.
• Microsoft. Circuit Breaker pattern. Azure Architecture Center, cập nhật 21/03/2025. Truy cập 07/09/2026. Nguồn.
• Microsoft. Transient Fault Handling. Azure Architecture Center, tài liệu hiện hành. Truy cập 07/09/2026. Nguồn.
• OpenAI. OpenAI Agents SDK: Models. Tài liệu hiện hành. Truy cập 07/09/2026. Nguồn.
• OpenAI. OpenAI Agents SDK: Running agents, Tracing, Human-in-the-loop. Tài liệu hiện hành. Truy cập 07/09/2026. Running agents, Tracing, Human-in-the-loop.
• OWASP Cheat Sheet Series. AI Agent Security Cheat Sheet. Tài liệu hiện hành. Truy cập 07/09/2026. Nguồn.
• OWASP GenAI Security Project. LLM06:2025 Excessive Agency. Phiên bản 2025. Truy cập 07/09/2026. Nguồn.
• National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). Tháng 07/2024. Truy cập 07/09/2026. Nguồn.