X记录空间前言
很多 AI 产品上线初期都运行得不错。
但随着用户增长，很快会出现：
- 请求失败；
- API 超时；
- 成本突然升高；
- 第三方模型偶尔不可用；
- 单个用户刷爆接口。
这些问题往往不是模型造成的，而是系统缺少稳定性设计。
在传统互联网中，这类问题通常通过：
- 限流（Rate Limit）
- 重试（Retry）
- 熔断（Circuit Breaker）
来解决。
AI 应用同样需要这些能力，而且重要性更高。
为什么 AI 接口更容易失败？
AI 请求通常具有几个特点：
- 响应时间长；
- Token 消耗高；
- 外部依赖多；
- 成本敏感。
相比普通 HTTP 接口，更容易受到网络波动和第三方服务状态影响。
因此，稳定性设计不能等到线上出现问题再补。
限流：保护系统的第一道防线
限流的目的不是限制用户，而是保护整个系统。
常见策略包括：
用户维度
例如：
每分钟最多 20 次请求
IP 维度
防止恶意刷接口。
API Key 维度
适合开放平台。
推荐使用：
Redis + 滑动窗口算法。
相比固定窗口，滑动窗口更加平滑，不容易出现临界点突发流量。
重试：并不是越多越好
很多开发者遇到错误后第一反应：
失败
↓
立即重试
如果第三方服务已经出现故障。
大量立即重试只会让情况更严重。
推荐：
指数退避（Exponential Backoff）。
例如：
第一次：
等待 1 秒
第二次：
等待 2 秒
第三次：
等待 4 秒
同时设置最大重试次数。
通常：
2～3 次即可。
哪些错误适合重试？
并不是所有错误都应该重试。
适合重试：
- 网络超时；
- 临时不可用；
- 429（限流）；
- 部分 5xx 错误。
不适合重试：
- 参数错误；
- 权限错误；
- 请求格式错误；
- 模型不存在。
否则只会浪费资源。
熔断：避免雪崩效应
假设：
某个 Provider 已经连续失败。
如果系统仍不断发送请求。
不仅不会恢复，还可能拖垮整个应用。
熔断器的思路是：
达到失败阈值后。
暂时停止请求。
等待一段时间。
再尝试恢复。
常见状态包括：
Closed
↓
Open
↓
Half Open
↓
Closed
这是经典的 Circuit Breaker 模式。
降级策略
如果高级模型不可用。
可以考虑：
自动切换：
GPT-4.1
↓
GPT-4.1 mini
或者：
提示用户稍后重试。
而不是：
直接报错。
降级的目标不是保持完全一致，而是尽可能保证服务可用。
幂等性的重要性
对于生成类接口：
重复请求可能导致重复计费。
因此可以设计：
请求 ID。
当同一个请求重复到达时。
直接返回之前的结果。
避免重复调用模型。
监控指标
生产环境至少应监控：
- 请求成功率；
- 平均响应时间；
- Provider 错误率；
- Token 消耗；
- 熔断次数；
- 限流次数。
没有监控，就很难发现潜在问题。
日志设计
每次请求建议记录：
Request ID
User ID
Provider
Model
Latency
Retry Count
Token Usage
Status
这样不仅方便排查问题，也能为后续成本分析提供依据。
推荐整体架构
Client
↓
Gateway
↓
Auth
↓
Rate Limit
↓
Retry
↓
Circuit Breaker
↓
Provider Router
↓
OpenAI / Claude / Gemini
其中每一层都保持单一职责。
不要把所有逻辑混在一个请求函数中。
总结
很多团队关注：
Prompt。
模型。
Agent。
却忽略了：
稳定性。
真正能够长期运行的 AI 产品，往往不是模型最强，而是系统最稳定。
限流、重试、熔断这些传统架构思想，在 AI 时代不仅没有过时，反而变得更加重要。
只有把这些基础能力做好，AI 应用才能真正进入生产环境，并支撑不断增长的业务规模。
