一个答案可能来自两项已被接收的工作
主供应商在接受请求后迟迟没有返回首字节，应用于是把同一任务交给备用供应商。备用方很快成功，用户只看到一个答案；主供应商却可能在后台完成并计量。问题不是界面重复，而是故障转移发生时，第一项工作是否仍可停止。
调查样本必须保留两家供应商的请求编号、接收时刻、首字节、完成或取消结果和最终用量。若只能看到备用方成功，不能据此认定主请求没有费用；反过来，也不能假定所有超时都会计费，结论应以每家供应商的正式记录为准。
三种触发条件承担的风险不同
连接建立失败发生在工作被远端接受之前的概率较高，适合作为较积极的切换信号；首字节超时只说明应用尚未收到输出，不代表供应商尚未计算；明确拒绝则最容易证明主任务不会继续，但等待拒绝可能增加客户延迟。三者不能共用一个超时数字。
还要区分读取超时、总时限和本地进程超时。若本地在20秒放弃，但供应商允许任务运行60秒，备用请求将与主请求重叠40秒。把这些时间写进矩阵，团队才知道缩短等待是在改善体验，还是扩大重复费用窗口。
用50次延迟注入取得本系统的数据
测试环境中分别注入DNS或连接失败、首字节延迟、响应中断、明确的限流拒绝和供应商5xx。每种场景运行10次，共50次；固定模型、输入规模、输出上限与备用顺序，避免把模型波动误当作切换策略效果。
每次记录客户是否收到完整答案、总等待时间、主请求是否被接受、取消是否确认、两家是否都产生用量以及是否出现两个不同答案。供应商的取消语义可能变化，测试日期和官方文档链接也要进入记录。
把体验、费用和确定性放在一张矩阵里
没有适用于所有网站的最佳触发条件。结账辅助可能更看重短等待，后台摘要则可以等待明确失败；高输出任务的重复费用也远高于短分类任务。决策矩阵应按真实业务路径分别评分，而不是全站采用一个全局超时。
| 触发条件 | 客户等待 | 重复计费风险 | 适用前提 | 上线门槛 |
|---|---|---|---|---|
| 连接失败 | 较短 | 较低但需实测 | 能区分未连接与已接收 | 50次中无未追踪主任务 |
| 首字节超时 | 可控 | 通常较高 | 可取消或单次费用很低 | 重复付费比例在批准阈值内 |
| 明确拒绝 | 可能较长 | 较低 | 供应商能及时返回拒绝 | 客户完成率达到业务目标 |
| 不自动切换 | 最长或失败 | 最低 | 允许人工重试的后台任务 | 错误提示与恢复路径已验证 |
上线时给切换规则设置停止条件
先向少量流量开放，并设定重复付费调用比例、客户完成率和p95延迟的回退门槛。若任何主请求失去追踪，或两家供应商同时完成的比例超过审批值，应恢复原策略并调查，不能只因总体成功率上升就继续扩大。
避免串联第三家、第四家供应商来掩盖故障。每增加一层切换，就增加取消语义、账单来源和隐私路径；双供应商尚未能闭环对账之前，不应扩展更长的故障转移链。
结论：只在可证明停止或可接受重复时切换
双供应商决策矩阵的最终结论不是推荐某个秒数，而是为每条业务路径写明触发条件、重复费用上限、回退门槛和负责人。Pro可作为累计费用的保护层，但不能替代对主请求是否继续运行的验证。
把“主供应商超时、备用供应商成功：怎样避免一次回答两次计费”的双供应商决策矩阵用于第一次真实安装。免费下载 AI Cost Circuit Breaker，先从 Monitoring 开始，验证预期信号和回退方式后再启用强制控制。