流式响应与重试

Chat Completions、Responses 和 Anthropic Messages 都支持 text/event-stream。客户端需要识别协议终态，再决定展示完整结果、提示中断或重试。

先判断调用是否完成

HTTP 200 不能单独证明流式调用成功。按所用协议读取事件，不能只拼接文本后等待连接关闭。

接口	结束与失败判定
Chat Completions	正常流以 data: [DONE] 结束；收到 error 时按失败处理。
Responses	response.completed 表示完成；response.incomplete 表示未完整完成；response.failed 或 error 表示失败。
Anthropic Messages	正常流以 message_stop 结束；收到 error 时按失败处理。

Chat 请求设置 stream_options.include_usage=true 时，[DONE] 前还会有一个 choices 为空的用量块，不应将其当作空回复或解析失败。

中断后如何处理

1. 尚未收到任何数据：先查看错误处理。认证、模型、余额或请求格式问题必须先修正；暂时性失败按下方条件判断能否重试。
2. 已经收到部分流内容：提示用户结果不完整，不要无条件重放同一请求。已交付内容或业务动作可能与重试结果重复。
3. 请求超时或连接中断，且未收到终态：执行结果可能未知。记录业务请求标识和已交付字节数，由上层工作流决定人工确认、继续或重新创建任务。

upstream_timeout 与 upstream_error 不表示模型一定未执行。对于会修改文件、执行命令或触发其他外部副作用的业务，先查询业务自身状态，再决定是否重新发起。

有界重试

对允许重试的暂时性失败采用有限次数、指数退避重试；将重试次数、总等待时间和并发预算设为显式配置。重试前应同时满足：

• 按错误处理确认当前错误允许重试，且未交付部分流内容；
• 业务操作可安全重复，或调用方持有可验证的幂等语义；
• 重试不会绕过余额日限额、并发预算或业务侧成本保护。

服务繁忙且响应包含 Retry-After 时，参考其中的非负秒数或 HTTP 日期，并继续遵守上述重试预算。

客户端实现建议

• 分别配置并记录连接、首字节和流空闲超时。
• 使用实际 SDK 版本验证正常完成、协议错误和部分流中断，检查 SDK 自带的自动重试是否符合上述条件。
• 取消请求后向用户展示“结果可能不完整”，不要把已收到内容标为成功完成。
• 记录平台请求编号、耗时、终态和重试次数等脱敏诊断信息，不记录 API Key、完整 prompt 或完整输出。