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 导致成本失控。