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): Promise<FallbackResult> { 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 导致成本失控。