𝗔𝗜 𝗠𝗼𝗱𝗲𝗹 𝗙𝗮𝗶𝗹𝗼𝘃𝗲𝗿 𝗗𝗿𝗶𝗹𝗹𝘀: 𝗞𝗲𝗲𝗽 𝗔𝗴𝗲𝗻𝘁𝘀 𝗨𝘀𝗲𝗳𝘂𝗹 𝗪𝗵𝗲𝗻 𝗣𝗿𝗼𝘃𝗶𝗱𝗲𝗿𝘀 𝗕𝗿𝗲𝗮𝗸

仅在架构图中生效的模型回退方案称不上是韧性。那不过是一个包装得更好的计划。

如果你的产品使用了 AI Agent，一个响应缓慢的供应商或一次速率限制（rate-limit）峰值就可能毁掉用户体验。真正的危险并非完全停机，而是“半残”的回退方案。当备份模型在不告知用户的情况下，悄悄更改数据格式、丢失工具状态或跳过引用时，这种情况就会发生。

在生产流量迫使你通过惨痛教训学习之前，你必须进行实际的故障转移演练。

目标并不是让每个模型都变得可以互换，而是在主模型失效时，确保工作流的安全与可靠。

大多数团队使用简单的链式逻辑：尝试主模型，不行就用备份模型，最后报错。这忽略了 AI 系统中真正的问题。AI 的失效往往是隐蔽的：

• 备份模型返回的 JSON 字段含义发生了变化。 • 更便宜的模型忽略了你的工具策略。 • 供应商的 Token 流式输出速度过慢。 • 回退模型缺乏相同的函数调用（function-calling）格式。 • Agent 不断重试，耗尽了用户的预算。

AI 模型故障转移演练是一项有计划的测试。你通过故意中断某个模型路径，来观察产品是否依然安全。

一次好的演练会检查：

  • 工作流是否能持续运行？
  • 是否保留了 Schema 和工具状态？
  • 是否保持在成本和延迟预算之内？
  • 是否为下次演练创建了回归测试？

不要一上来就试图让每个 Prompt 都能适配多个供应商。应该从那些“一旦失效就会摧毁信任”的工作流开始。

高优先级工作流：

  • 面向客户的聊天
  • 报告生成
  • 调用工具的 Agent 工作流
  • 带有引用的 RAG 回答
  • 提取到结构化字段的数据提取

最好的设计始于“契约”（contract），而非模型名称列表。回退契约定义了在所有供应商之间必须保持一致的事项。对于一个客服 Agent，这可能包括：

  • 输入和输出的结构（shapes）
  • 置信度水平和引用
  • 工具权限和剩余预算
  • 质量门禁和验证规则

有时，正确的回退方案并不是另一个模型。它可能是：

  • 请求用户确认
  • 返回部分结果
  • 将任务排队稍后处理
  • 将工作流转交给人工审核

不要把每一次失败都当作尝试另一个模型的理由。使用模型适配器 (model adapter) 来规范化错误和格式。这会让你的演练变得更容易，因为你可以在不改变主逻辑的情况下模拟故障。

从以下三个演练开始：

  1. 超时演练 (The Timeout Drill)：强制主模型进入休眠。验证回退 (fallback) 是否在你的延迟预算内发生。
  2. 速率限制演练 (The Rate Limit Drill)：强制触发 429 错误。验证你的系统是否使用了退避机制 (backoff) 并保护了租户预算。
  3. Schema 演练 (The Schema Drill)：强制模型返回无效的 JSON。验证你的系统是否验证了输出，或者是否安全地停止了工作流。

用户不需要知道你的供应商详情。他们需要的是诚实的行为。

糟糕的消息：出错了。 良好的消息：我仍然可以提供帮助，但实时操作暂时受限。我可以为您起草下一步操作供您审阅。

通过清晰的边界来建立信任，而不是假装一切正常。

来源：https://dev.to/jackm-singularity/ai-model-failover-drills-keep-agents-useful-when-providers-break-1p5j

可选学习社区：https://t.me/GyaanSetuAi