生产环境 AI API 故障
当你的 AI 功能在凌晨 2 点崩溃时，错误信息很少能说明问题的全貌。我运行 OpenAI 和 Anthropic 集成已有一年时间。我学会了根据故障对调试的意义进行分类。
处理速率限制 (Rate Limits)
OpenAI 的 429 错误有不同的原因。你必须检查错误代码以决定如何应对。
- 每分钟请求数 (RPM) 限制会在几秒钟内恢复。
- 每分钟 Token 数 (TPM) 限制会在 60 秒内恢复。
- 每月配额耗尽会导致持续故障，直到你充值或计费周期重置。
不要针对配额问题使用指数退避 (exponential backoff)。那只会浪费你的时间。
Anthropic 的 529 错误意味着提供商过载。将其视为 503 错误处理。问题出在他们那边。请稍后重试并通知你的团队。
处理 400 错误
这些故障通常是你的责任。注意以下三种模式：
- 模型版本不匹配。你在某个地方更新了名称，但没有在重试处理程序中更新。
- 上下文窗口溢出。对话历史记录变得过大。这通常是由于错误的截断逻辑导致的。
- Schema 验证失败。你的 JSON 结构包含不支持的类型或递归引用。
要修复这些问题，请记录 400 错误的完整请求负载 (payload)。首先脱敏用户数据。响应体 (response body) 会准确告诉你哪个字段失败了。
处理超时 (Timeouts)
超时很难追踪，因为提供商端看起来一切正常。
- 连接超时 (Connect timeout)。握手失败。这发生在提供商服务降级 (brownouts) 或 DNS 问题期间。请检查你的出站网络。
- 读取超时 (Read timeout)。模型已启动但未完成。你的应用必须能够处理部分流式输出。
- 网关超时 (504)。你的代理先超时了。请求可能仍在提供商端运行。在重试之前请使用去重机制。
为了进行调试，请将连接超时与读取超时分开。记录首个 Token 生成时间 (time-to-first-token)，以找出延迟所在的位置。
处理提供商问题
- 500 错误通常在两秒后重试一次即可解决。
- 503 错误意味着服务正在降级。如果提供商的状态页面显示发生故障，请使用熔断器 (circuit breaker)。
- 务必记录哪个模型版本失败了。不同的模型具有不同的可靠性水平。
不要一看到日志就立刻跳到 Slack 去。先检查提供商的状态页面。这能帮你省去 20 分钟的恐慌时间。
Optional learning community: https://t.me/GyaanSetuAi