Agent 降级策略：模型挂了，业务不能跟着停

一、一个凌晨三点的告警：模型超时引发订单积压

凌晨三点，监控面板上订单队列的红色数字在跳动。12 分钟内积压了 3000 多单，原因很直接——大模型 API 返回了 503。Agent 在等待模型响应时同步阻塞，整个任务链卡死。

这不是模型质量问题，这是架构设计缺陷。把 Agent 的生命周期和大模型可用性强绑定，等于把业务的命脉交给了一个你无法控制的外部服务。任何依赖外部 API 的系统，默认假设都应该是"它随时可能挂"。

生产环境中模型不可用的原因比想象中多：服务商限流、网关超时、内容安全拦截、模型版本回滚。每一条都足以让你的 Agent 停摆。所以降级策略不是"锦上添花"，而是上线前的必选项。

二、降级决策的核心模型：条件判断 + 路由分发

Agent 降级的本质是"在模型不可用时，系统如何优雅地继续运作"。设计上分三层：

检测层：捕获错误类型（超时、限流、内容过滤、服务不可用），区分可重试和不可重试错误。

决策层：根据错误类型和上下文，选择降级路径——重试、切换备选模型、使用缓存结果、回退到规则引擎，或者直接返回兜底响应。

执行层：执行降级动作，并记录决策链路用于后续分析。

flowchart TD A[用户请求] --> B[Agent 接收任务] B --> C{调用大模型} C -->|成功| D[返回结果] C -->|失败| E{错误类型判断} E -->|超时 5xx| F[指数退避重试] F -->|重试耗尽| G{降级决策} E -->|限流 429| H{降级决策} E -->|内容过滤| G H --> G G -->|缓存命中| I[返回缓存结果] G -->|备选模型| J[切换到 GPT-4o-mini] G -->|规则引擎| K[规则匹配返回] G -->|兜底响应| L[返回预设回复] I --> M[记录降级日志] J --> M K --> M L --> M M --> D

这个流程的关键在于：决策层不是固定的 if-else，而是可配置的。不同业务场景对"可接受的降级"定义不同。客服场景可以返回预设话术，但金融交易场景必须保证数据一致性，宁可排队也不返回不确定的结果。

三、Go 实现：带重试和降级的 Agent 调用器

package agent import ( "context" "errors" "fmt" "math" "sync" "time" "github.com/sony/gobreaker" ) // FallbackStrategy 降级策略枚举 type FallbackStrategy int const ( FallbackCache FallbackStrategy = iota // 使用缓存 FallbackAltModel // 切换备选模型 FallbackRule // 规则引擎 FallbackDefault // 兜底响应 ) // DegradeDecision 降级决策结果 type DegradeDecision struct { Strategy FallbackStrategy Reason string Latency time.Duration } // ModelCaller 模型调用器，内置重试+降级 type ModelCaller struct { primary LLMClient // 主模型客户端 fallback LLMClient // 备选模型客户端（如 GPT-4o-mini） cache *ResponseCache // 响应缓存 rules *RuleEngine // 规则引擎 breaker *gobreaker.CircuitBreaker maxRetries int baseBackoff time.Duration mu sync.RWMutex } // CallWithFallback 带降级策略的模型调用 func (m *ModelCaller) CallWithFallback( ctx context.Context, prompt string, msgHistory []Message, ) (string, *DegradeDecision, error) { // 先查缓存——零成本降级的第一选择 if cached, ok := m.cache.Get(prompt); ok { return cached, &DegradeDecision{ Strategy: FallbackCache, Reason: "cache_hit", }, nil } // 熔断器检查：如果主模型已经被熔断，直接降级 if m.breaker.State() == gobreaker.StateOpen { return m.degrade(ctx, prompt, msgHistory, "circuit_open") } // 尝试主模型调用，带指数退避重试 result, err := m.callWithRetry(ctx, prompt, msgHistory) if err == nil { // 成功：异步写入缓存 go m.cache.Set(prompt, result, 5*time.Minute) return result, nil, nil } // 主模型失败，触发降级决策 return m.degrade(ctx, prompt, msgHistory, err.Error()) } // callWithRetry 指数退避重试 func (m *ModelCaller) callWithRetry( ctx context.Context, prompt string, history []Message, ) (string, error) { var lastErr error for attempt := 0; attempt < m.maxRetries; attempt++ { // 每次重试前检查 context 是否已取消 select { case <-ctx.Done(): return "", fmt.Errorf("context cancelled: %w", ctx.Err()) default: } result, err := m.primary.Call(ctx, prompt, history) if err == nil { return result, nil } // 不可重试的错误直接返回 if isNonRetryable(err) { return "", fmt.Errorf("non-retryable error: %w", err) } lastErr = err // 指数退避：100ms, 200ms, 400ms... backoff := m.baseBackoff * time.Duration(math.Pow(2, float64(attempt))) // 加上随机抖动，避免惊群效应 backoff += time.Duration(randInt63n(int64(backoff / 2))) select { case <-ctx.Done(): return "", ctx.Err() case <-time.After(backoff): } } return "", fmt.Errorf("max retries exceeded: %w", lastErr) } // degrade 执行降级决策 func (m *ModelCaller) degrade( ctx context.Context, prompt string, history []Message, reason string, ) (string, *DegradeDecision, error) { // 策略 1：尝试备选模型 if m.fallback != nil { if result, err := m.fallback.Call(ctx, prompt, history); err == nil { return result, &DegradeDecision{ Strategy: FallbackAltModel, Reason: fmt.Sprintf("primary_failed: %s", reason), }, nil } } // 策略 2：规则引擎匹配 if m.rules != nil { if result, ok := m.rules.Match(prompt); ok { return result, &DegradeDecision{ Strategy: FallbackRule, Reason: fmt.Sprintf("rule_match: %s", reason), }, nil } } // 策略 3：兜底响应（根据业务场景定制） defaultResp := "系统繁忙，请稍后重试。您的问题已记录，客服将在工作时间回复。" return defaultResp, &DegradeDecision{ Strategy: FallbackDefault, Reason: fmt.Sprintf("all_fallback_exhausted: %s", reason), }, nil } // isNonRetryable 判断是否不可重试 func isNonRetryable(err error) bool { // 内容安全过滤、参数错误等不应重试 return errors.Is(err, ErrContentFilter) || errors.Is(err, ErrInvalidParam) }

四、降级策略的边界与权衡

不是所有场景都适合降级。比如支付确认、合同签署这类强一致性场景，返回一个"可能对"的结果比返回错误更危险。对于这类场景，降级策略应该是"快速失败 + 异步补偿"：立即返回失败，同时把请求写入死信队列，等服务恢复后重放。

缓存是把双刃剑。缓存能大幅降低延迟和成本，但过期数据可能导致过时回答。必须设置合理的 TTL，并且在知识库更新时主动失效相关缓存。

备选模型有隐形成本。GPT-4o-mini 比 GPT-4o 便宜，但如果降级频率过高，总额外成本可能超预期。建议对降级调用量做独立计费和告警。

熔断器阈值需要调优。太敏感会导致误降级，太迟钝则失去保护作用。建议基于历史错误率设定阈值，并在运行时动态调整。半开状态的探测间隔也需要根据恢复速度灵活配置。

五、总结

Agent 的降级策略本质上是"外部依赖不可靠"这一前提下的系统工程。三层架构（检测→决策→执行）提供了清晰的关注点分离。核心原则：缓存优先、备选兜底、规则保底、快速失败留给强一致性场景。生产部署时务必监控降级率、降级延迟和降级类型分布，这些指标直接反映系统的韧性边界。模型会挂，业务不能停——这是 AI 工程化的第一课。