Agent 服务故障时如何通过熔断、降级和重试实现高可用？

核心回答

Agent 服务高可用要同时保护单次任务、依赖服务和用户状态。先用超时、限流和资源隔离控制负载；瞬时故障在任务预算内退避重试；某个依赖持续异常时熔断，快速转到可接受的备用模型、只读流程、缓存或人工处理；恢复后只放少量探测流量，确认稳定再逐步恢复。

这套机制不能保证所有故障都让用户完全无感。尤其是退款、发消息等写操作，超时不代表没有执行，重试前必须查明结果或复用业务幂等键。没有满足质量和权限要求的备用方案，就应保存任务进度并明确告知可恢复状态。

展开解析

1. 先防止一个依赖拖垮整个服务

模型请求通常耗时较长，连接、并发槽位和队列都有上限。应同时设置连接超时、首个有效输出等待时间、空闲读超时和任务总截止时间；取消要传递到真正执行请求的客户端。线程池、连接池或并发配额按依赖隔离，入口按租户和任务成本限流，避免一个供应商堵塞占满全部资源。

限流控制进入系统的压力，熔断隔离已经不健康的依赖，二者用途不同。备用链路也要有容量和限流，不能把主链路全部流量瞬间倾倒过去。

2. 熔断后的恢复要验证业务能力

熔断器通常有三个状态：

• Closed：正常放行，统计近期可用性故障和慢调用。
• Open：达到配置条件后停止正常调用，快速失败或进入降级。
• Half-Open：冷却后允许受控探测；探测仍失败则重新打开，达到恢复条件后再放量。

统计窗口、最小样本量、错误比例和探测量根据流量与服务目标确定，不能把“失败两次”当作通用规则。参数非法、用户无权限之类请求错误，也不应直接计成供应商整体不可用。

flowchart LR
 C[Closed 正常放行] -->|故障达到配置条件| O[Open 暂停正常调用]
 O -->|冷却后受控探测| H[Half-Open 半开探测]
 H -->|探测失败| O
 H -->|达到恢复条件| C

健康页返回成功只能证明一部分链路可用。探测最好覆盖实际受影响的模型或工具路径，同时限制费用和副作用；恢复时观察成功率、尾延迟和队列，而不是一次成功就全量切回。

3. 降级必须保持任务语义

以售后助手为例：模型不可用时，可以先保留工单、提供已有政策入口，或把退款建议转成人工审核；不能返回“退款成功”充当兜底。切备用模型前要验证它能否处理当前上下文、工具协议、结构化输出和数据使用要求。缓存还需要检查用户权限、版本和时效。

已向用户发送的两个模型的输出片段不能直接拼成一条完整答复；后台生成失败也不能重跑整段工作流，把已完成的业务动作再做一次。应记录任务、步骤和尝试的独立标识，恢复到经过确认的进度。

4. 用演练验证保护是否生效

可分别模拟模型超时、持续过载、备用链路不可用、写操作成功但回包丢失，检查熔断是否隔离到正确依赖、重试是否放大流量、状态能否恢复、用户能否分辨完成与处理中。观察任务完成率、重试增量、降级比例、重复副作用和恢复耗时，才能判断保护措施是否有效。

追问

自动恢复为什么可能反复抖动？

探测过早、恢复流量过大或统计窗口过短，都可能让依赖刚恢复就再次过载。可以延长冷却、限制半开并发、逐步恢复，并对异常提供人工强制开关。

为什么不能让 SDK、网关和 Agent 各自重试？

多层重试会叠加尝试次数，还会重复已有工作。应确定主要重试层，其他层关闭重复策略或共享总截止时间和尝试预算。

对应教程

参考资料