把 GPT-5.5 接进应用后，很多线上问题不是“模型不会答”，而是调用链路没处理好。
超时、429、流式中断、重复点击、备用模型切换，这些问题不提前设计，上线后迟早会遇到。
1. 先判断哪些失败可以重试
不是所有失败都该重试。
| 失败类型 | 是否重试 | 处理建议 |
|---|---|---|
| 网络超时、临时 5xx、连接中断 | 可以 | 指数退避，限制次数 |
| 429 限流 | 可以 | 读取 Retry-After，加退避和上限 |
| 参数错误、鉴权失败 | 不建议 | 修请求，不要原样重发 |
| 上下文超限 | 不建议 | 缩短输入或改异步任务 |
| JSON Schema 明显不合法 | 视情况 | 带校验错误重试一次 |
| 内容安全拦截 | 不建议绕过 | 按业务规则拒答或人工处理 |
重试只适合临时性失败。
2. 超时要分层设置
大模型调用不要只设一个总超时，建议拆成三层：
- 连接超时：供应商或网关连不上时快速失败。
- 首 token 超时：流式输出迟迟没有第一个 token，要及时判断是否切换。
- 总响应超时：长任务不能无限等，尤其是用户实时等待场景。
普通问答可以给 20 到 40 秒。复杂代码分析、长文档处理可以更长，但最好放到异步任务里。GPT-5.5 支持更长上下文，但任务越重，越要区分实时请求和后台批处理。
3. 重试用指数退避，加 jitter
最基本的重试策略是指数退避。
async function callWithRetry(request: ModelRequest, maxRetries = 3) {
for (let attempt = 0; attempt <= maxRetries; attempt++) {
try {
return await callModel(request);
} catch (error) {
if (!isRetryable(error) || attempt === maxRetries) {
throw error;
}
const delayMs = Math.min(1000 * 2 ** attempt, 8000);
await sleep(delayMs + randomJitter(0, 300));
}
}
}
两个重点：
- 加
jitter，避免大量请求同时重试，造成新的尖峰。 - 限制最大次数。模型调用有延迟和成本，重试并不免费。
4. 有写操作时，幂等 key 必须提前设计
只读问答重试比较简单，涉及写操作时就复杂很多。
比如模型创建工单、提交报销、发送邮件、生成订单。第一次请求可能已经成功，只是响应超时；第二次重试就可能重复执行。
解决办法是给每个业务动作生成幂等 key。同一个用户、同一个业务动作、同一批输入，对应同一个 key。服务端发现 key 已执行，就返回之前的结果。
工具调用场景尤其要注意。工具描述里最好直接写清楚：
{
"name": "create_ticket",
"side_effect": true,
"idempotency_required": true,
"retry_policy": "retry only when idempotency_key is provided"
}
不要指望模型每次都猜对。
5. 流式输出中断，要有产品方案
流式输出常见问题是：内容已经输出一半，连接断了。此时不能简单重发请求，再把新结果接在旧结果后面，两次生成不一定一致。
更稳的做法：
- 短内容：提示“生成中断，请重新生成”，并保留原输入。
- 长内容：按段落或步骤生成，每段保存状态，失败后从最近的完整段继续。
- 结构化任务：先生成大纲或任务计划，再逐步生成每个节点，失败时重跑当前节点。
GPT-5.5 适合长任务，但长任务更需要状态管理。没有状态管理，流式越长，失败体验越差。
6. 降级不是随便换个模型
备用模型有用，但不能随便切。LiteLLM 的思路是：先在同一模型组内重试，失败后再 fallback 到其他模型组。 工程上，模型切换最好放在路由层，不要散落在业务代码里。
比如先走 GPT-5.5，遇到限流、成本阈值或区域网络问题，再通过内部网关或 147AI 这类中转入口切到 Claude Opus 4.7、Claude Sonnet 4.6、Gemini 3.1 Pro Preview 等备用模型。
降级前先确认三件事：
- 备用模型是否支持同样的上下文长度和输入模态。
- 备用模型是否能稳定输出同样的 JSON 格式。
- 备用模型的安全策略和拒答边界是否符合业务要求。
降级不是“能答就行”，而是要保证产品契约不被破坏。
7. 失败日志要能复盘
每次失败至少记录：
- 请求 ID、业务模块、用户等级
- 模型名、HTTP 状态码、供应商错误码
- 错误类型、重试次数、是否降级、最终模型
- 耗时、token 用量、失败阶段
- 结构化输出的校验失败原因
这些日志不是为了好看，而是为了回答问题：失败来自哪个模型？哪个模块最容易超时？重试有没有提高成功率？降级后质量有没有下降？成本是不是被重复重试吃掉了？
8. 推荐的最小策略
线上应用可以先按这个版本落地：
- 429、网络超时、临时 5xx：最多重试 2 到 3 次，指数退避加 jitter。
- 上下文超限、参数错误、鉴权失败：不重试，直接进入错误处理。
- 用户实时请求：短超时，失败后给可理解提示。
- 后台任务：允许更长超时，支持任务状态查询。
- 有副作用工具：必须带幂等 key。
- 备用模型：只在明确可兼容的任务上启用。
GPT-5.5 的能力上限很高，但生产系统看的是坏天气里的表现。重试、幂等、降级和日志做扎实，模型能力才真正能落到业务里。
