Agent Fallback 链条设计：当主模型不可用时，产品不能直接挂掉

Agent Fallback 链条设计当主模型不可用时产品不能直接挂掉一、Agent 系统的可靠性瓶颈不在模型能力而在可用性Agent 工作流设计通常聚焦在任务拆解、工具调用和结果合并上。但生产环境里更常见的问题不是模型能力不足而是模型服务不可用。API 超时、限流、区域故障、价格变动导致的供应商切换这些可用性问题比推理质量问题出现频率高得多。如果一个 Agent 只依赖单一模型服务任何一次服务中断都会导致整个工作流卡住。用户看到系统繁忙请稍后的频率远高于回答不够好的频率。Fallback 链条设计就是为了解决可用性问题主模型不可用时自动切换到备选模型而不是让产品直接挂掉。二、Fallback 链条要按质量优先级排列Fallback 不是随机选择一个备用模型。应该按照质量优先级排列首选模型提供最佳输出次选模型提供可接受输出兜底模型保证至少有结果。flowchart TD A[Agent 任务请求] -- B[首选模型GPT-4] B -- C{调用成功} C --|是| D[高质量输出] C --|否-超时| E[次选模型Claude-3] C --|否-限流| E E -- F{调用成功} F --|是| G[可接受输出标注降级] F --|否| H[兜底模型本地小模型] H -- I{调用成功} I --|是| J[基础输出标注严重降级] I --|否| K[预设回复模板] D -- L[返回结果] G -- L J -- L K -- L每个降级层级都应该标注当前使用的模型等级。用户看到此回答由次选模型生成后对输出质量的预期会相应调整。这比让用户以为回答来自首选模型但实际质量差更好。三、Fallback 链条的超时与重试策略type ModelTier { name: string; provider: string; timeoutMs: number; maxRetries: number; qualityLabel: string; }; const fallbackChain: ModelTier[] [ { name: gpt-4, provider: openai, timeoutMs: 5000, maxRetries: 1, qualityLabel: 高质量 }, { name: claude-3, provider: anthropic, timeoutMs: 4000, maxRetries: 1, qualityLabel: 可接受 }, { name: local-small, provider: local, timeoutMs: 2000, maxRetries: 0, qualityLabel: 基础 }, ]; export async function callWithFallback(prompt: string): PromiseFallbackResult { for (const tier of fallbackChain) { for (let attempt 0; attempt tier.maxRetries; attempt) { try { const result await callModel(tier.provider, tier.name, prompt, { timeoutMs: tier.timeoutMs, }); return { content: result, qualityLabel: tier.qualityLabel, usedModel: tier.name, isFallback: tier ! fallbackChain[0], }; } catch (error) { if (attempt tier.maxRetries) continue; // 当前层级耗尽重试次数进入下一层级 console.warn(模型 ${tier.name} 不可用尝试下一个层级); } } } // 所有层级都失败返回预设模板 return { content: 系统暂时无法处理请稍后重试或手动操作。, qualityLabel: 模板回复, usedModel: template, isFallback: true, }; } type FallbackResult { content: string; qualityLabel: string; usedModel: string; isFallback: boolean; };超时时间的设置有讲究。首选模型给5秒次选给4秒兜底给2秒。越往后超时越短因为用户已经等了更久。总等待时间不应超过12秒超过后直接返回模板回复。四、Fallback 输出质量的不一致性需要管理Fallback 链条最大的副作用是输出风格不一致。首选模型和次选模型的写作风格、格式偏好和专业度差异很大。用户连续两次提问第一次得到高质量回答第二次因为首选模型限流而得到风格完全不同的回答体验会割裂。缓解方式是在降级输出时限制回答范围。次选模型只做事实性回答不做创意性输出兜底模型只做简单格式化不做复杂推理。通过缩小降级模型的输出范围来缩小风格差异的影响。还要注意 Fallback 的调用统计。如果次选模型被频繁触发说明首选模型的服务稳定性有问题应该考虑切换首选供应商或增加更多备选。Fallback 链条是应急机制不应该成为常态路径。最后是成本管理。次选模型的调用价格可能和首选不同。高频 Fallback 场景下的成本增长需要监控。设置每日报价上限超过后直接跳到模板回复避免成本失控。五、总结Agent Fallback 链条按质量优先级排列主模型不可用时依次降级到次选和兜底模型。每个降级层级标注质量等级让用户调整预期。超时时间随层级递减总等待不超过12秒。降级输出时限制回答范围以缩小风格差异。Fallback 触发频率高时应重新评估首选供应商。成本监控设置日报价上限防止 Fallback 导致成本失控。