一、Agent 不稳，往往不是模型「变笨了」
线上最常见的体验是：偶尔超时、工具偶发失败、重试把账单打爆、降级策略缺失导致整条链路挂死。Agent 比普通 API 更脆，因为它是多步循环：模型 → 工具 → 模型 → 工具……任何一环抖动都会被放大。
二、超时：分层设，而不是只设一个全局 60 秒
- 模型调用超时：按模型与是否流式分别配置（例如非流式 30～60s，流式首包 10s）。
- 工具超时：HTTP 工具 3～10s；本地命令更短，并禁止无超时。
- 整轮 Agent 超时：限制单次用户任务的总墙钟时间（如 120s），超时后返回已完成步骤摘要。
原则：越靠近外部不确定性，超时越短；总超时必须存在，否则会出现「永远在思考」的僵尸会话。
三、重试：只对可重试错误重试，且带预算
可重试：网络闪断、429（尊重 Retry-After）、上游 502/503。
不可重试：参数错误、鉴权失败、业务 4xx、已经产生副作用的写操作。
建议默认：
- 最大重试 2～3 次
- 指数退避 + 抖动
- 按租户/任务设置重试预算（次数与 Token）
- 流式已输出部分内容时：默认不整体重试Agent 场景特别容易「工具失败 → 模型再调一次同样工具」形成隐式重试风暴，需要在运行时记录 tool_call_id，避免无意义循环。
四、降级：先保可用性，再保智能上限
降级阶梯可以从轻到重：
- 主模型失败 → 切换更稳/更便宜的备模型
- 工具失败 → 跳过该工具，改用检索/缓存/人工模板
- 多 Agent 失败 → 退回单 Agent 最小闭环
- 全部失败 → 返回明确错误与「已尝试步骤」，而不是空白
降级要可观测：每次降级打点（原因、从哪到哪），否则你只知道「今天变笨了」，不知道系统其实在自救。
五、和限流/熔断一起用
稳定性三件套在网关与 Agent Runtime 都要有：超时控制爆炸半径，重试对抗偶发，降级保住底线；再配合限流与熔断，避免把上游与自己一起打崩。详细网关策略可参考站内《大模型 API 网关设计：限流 / 熔断 / 缓存》。
六、最小检查清单（上线前）
- 是否所有外部调用都有超时？
- 重试是否有上限与退避？写操作是否默认不重试？
- 是否有备模型/无工具降级路径？
- 是否限制最大步数与最大 Token？
- 失败时用户能否看到可读原因？
Agent 的稳定，不是把温度调低，而是把失败当成一等公民来设计。