稳定性架构

鼎惠API 通过统一网关聚合多模型和多通道资源。稳定性既取决于平台路由，也取决于调用侧的超时、重试、降级和成本控制。

调用侧建议

能力	建议
超时	给每类任务设置明确超时时间
重试	只对 429、5xx、网络超时做有限重试
退避	使用指数退避，避免瞬间打满并发
降级	复杂模型失败时切换备用模型或简化任务
幂等	批量任务带任务 ID，避免重复扣费和重复写入
日志	记录请求 ID、模型、耗时、状态码

推荐重试策略

错误	是否重试
400	不重试，修改参数
401	不重试，检查 Key
403	不重试，检查权限
404	不重试，检查地址和模型
429	可重试，降低并发
500 / 502 / 503 / 504	可重试，限制次数

生产服务建议最多重试 2 到 3 次，并在最终失败时返回清晰错误。

Agent 工具稳定性

Claude Code、Codex、Cline、Kimi Code 等 Agent 工具会自动读取上下文和多轮调用。建议：

• 任务描述尽量明确。
• 限定需要修改的文件范围。
• 对大项目先让工具做结构分析，再分步执行。
• 失败后不要无限继续，先检查请求日志和工具输出。

业务服务稳定性

如果鼎惠API 被接入自己的后端服务，建议增加：

• 请求队列和并发限制。
• 用户级或租户级额度。
• 慢请求日志。
• 异常模型降级。
• 结果缓存。
• 失败告警。

排查慢请求

慢请求通常来自：

• 输入上下文过大。
• 输出要求过长。
• 模型推理复杂。
• 图像或多模态任务。
• 上游通道排队。

先用更小的输入复现，再逐步增加上下文，可以更快定位原因。