Cơ chế dự phòng AI bị "nhiễm độc" bởi lỗi 429

Tác nhân AI của bạn được cấu hình một chuỗi dự phòng: GPT-5.4 → DeepSeek → Gemini Flash. Khi GPT-5.4 gặp lỗi giới hạn tốc độ 429, không vấn đề gì — đó chính là lý do ta có cơ chế dự phòng, đúng không?

Thực tế lại khác. DeepSeek chưa kịp gửi yêu cầu đã thất bại ngay lập tức với thông báo lỗi y hệt và mã băm (hash) lỗi giống hệt như lỗi từ chối của GPT-5.4. Sau đó, nó bị đưa vào trạng thái chờ (cooldown).

Lỗi kỹ thuật

Vấn đề số #62672 đã ghi nhận chi tiết hiện tượng này với cấu hình ba nhà cung cấp:

• openai-codex/gpt-5.4 — Sử dụng OAuth, ChatGPT Plus
• deepseek/deepseek-chat — Sử dụng API key riêng biệt
• google/gemini-2.5-flash — Sử dụng API key riêng biệt

Khi Codex trả về lỗi 429, chuỗi dự phòng xác định DeepSeek là ứng viên tiếp theo. Tuy nhiên, nỗ lực kết nối của DeepSeek lại thất bại với bản xem trước lỗi và mã băm lỗi giống hệt nhau — đó là lỗi của Codex. DeepSeek thực tế chưa bao giờ được gọi.

Cơ chế "nhiễm độc" lỗi hoạt động như thế nào

Đối tượng phản hồi lỗi của mô hình chính được mang theo sang ngữ cảnh đánh giá của lần thử tiếp theo. Quá trình lan truyền lỗi diễn ra như sau:

Codex 429 → đối tượng lỗi (hash: sha256:2aa86b51b539) → chuyển sang dự phòng DeepSeek → DeepSeek được đánh giá dựa trên cùng một đối tượng lỗi → "Thất bại" với cùng mã băm → kích hoạt cooldown → chuyển sang dự phòng Gemini Flash → thành công

Gemini hoạt động vì đến ứng viên thứ ba, trạng thái "nhiễm độc" đã được tiêu thụ. Nhà cung cấp thứ hai (DeepSeek) không bao giờ có cơ hội công bằng để thử lại.

Mô hình vấn đề

Đây là lỗi thứ ba trong chuỗi dự phòng mà tôi đề cập:

• #55941 — Thời gian chờ xác thực (Auth cooldown) được áp dụng theo hồ sơ (profile) thay vì theo cặp (hồ sơ, mô hình).
• #62119 — Cờ candidate_succeeded vẫn được đặt thành true ngay cả khi gặp lỗi 404.
• Và bây giờ #62672 — Lỗi từ nhà cung cấp A "nhiễm độc" nhà cung cấp B.

Nguyên nhân chung là: các chuỗi dự phòng coi các nhà cung cấp như những ứng viên có thể thay thế cho nhau trong một đường ống duy nhất, trong khi thực tế mỗi nhà cung cấp là một miền lỗi độc lập.

Giải pháp khắc phục

Mọi ứng viên dự phòng cần một ngữ cảnh đánh giá sạch (clean evaluation context):

1. Yêu cầu mới với thông tin xác thực riêng (đang hoạt động tốt).
2. Đánh giá mới — không thừa kế trạng thái lỗi (đây là lỗi cần sửa).
3. Thời gian chờ độc lập dựa trên lỗi riêng của họ.

Dành cho các nhà xây dựng Agent

1. Coi mỗi lần dự phòng là một nỗ lực hoàn toàn độc lập.
2. Đối tượng lỗi không bao giờ được vượt qua ranh giới giữa các nhà cung cấp.
3. Kiểm tra nhà cung cấp thứ hai, không chỉ kiểm tra nhà cung cấp thứ ba.
4. Cơ chế loại bỏ trùng lặp dựa trên mã băm (hash-based dedup) rất nguy hiểm khi áp dụng chéo giữa các miền.

Nếu cơ chế dự phòng của bạn không thể sống sót qua một lỗi 429 từ nhà cung cấp chính, thực chất là bạn không hề có dự phòng nào cả.

Nguồn: openclaw/openclaw#62672.