模型故障切换应先保工具调用能力

给 AI Agent 配备用模型，按响应速度排序，看起来很合理：最快的先上，超时或返回 5xx 再换一家。作者却遇到了一种监控很难发现的故障：请求很快成功了，回答也很流畅，但模型根本没有调用搜索工具，直接编出了一份对比结果。

这篇文章讨论的，是备用路由应该先保证什么。作者的结论是：先确认模型能完成当前步骤，再按质量排序，把延迟作为预算约束。对正在接多模型、搭 Agent 或维护 LLM 网关的程序员，这比单纯优化响应时间更值得关注。

请求成功了，为什么任务仍然失败

作者搭建的 Agent 会先搜索网页，抓取几个页面，再根据材料生成回答。最初的备用链只处理常见的服务故障：优先请求最快的提供商，遇到超时或 5xx 就切换。

问题出在「成功」的定义上。

一次需要多次检索的对比请求，被某个提供商立即返回了。它没有报错，却也没有发起工具调用，而是直接生成了一段像模像样的回答。速度快、价格低，任务要求却没完成。

在 Agent 循环里，模型承担着明确的接口职责：读取 schema，生成工具调用，接收工具结果，然后继续执行。该调用工具时输出一段正文，就是违反执行约定。仅看延迟分位数，监控仍然可以一路正常。

备用路由需要接住原路由承担的能力，而不只是接住一次请求。

原文引用的 Inworld 路由指南也强调了类似边界：当工具行为、数据政策或质量要求严格时，自动切换应限定在工具、schema 和安全行为兼容的候选集合内。价格、吞吐量、延迟和基准排名，不能单独保证这种兼容性。

为什么质量和速度相加，会排出错误顺序

作者引用预印本 2605.14241，展示了一种看似合理的奖励函数。它试图用一个分数，同时奖励质量、惩罚延迟：

r = α · quality − (1 − α) · latency

要看的是 (1 − α)：当 α = 0.4 时，质量权重为 0.4，延迟惩罚权重为 0.6。

按论文给出的例子，某提供商的延迟为零、质量只有 0.1，最终得分是 0.04；另一个提供商的延迟取满值、质量为 0.65，得分却是 −0.34。几乎不能完成任务的选项，凭借即时响应排到了前面。

这个例子揭示了加权求和的一个问题：如果质量没有最低门槛，速度优势就可能抵消能力缺失。对于必须联网取证的步骤，「立即给出无依据回答」不能因为更快就成为优选。

论文提出的另一种计分形式是 u / (1 + τ / L_ref)，试图让延迟反映服务容量的消耗，而不是直接与回答质量交换。作者明确说，自己没有复现数学推导，也不为这个具体公式背书；它仍是一篇未经同行评审的预印本。

因此，能从这里拿走的是建模思路，而不是一个可以直接复制进生产配置的公式：延迟帮助判断一路服务能承载多少请求，完成任务的能力需要另外评价。

作者怎样调整候选池和备用顺序

作者最终把路由决策拆成了几步。

首先，用质量决定排序，把延迟当作预算。某条路由超出当前请求的延迟预算，就跳过；但响应更快，不再获得足以压过质量的额外分数。作者报告，这项调整消除了前面那种快速返回空洞回答的问题，不过没有给出改动前后的样本量和成功率。

其次，对没有历史数据的路由采用中性先验，也就是先放在排序中间，再由实测结果决定升降。

作者最初把未知路由的初始分设得很低，结果是已知表现差的模型也可能排在新模型前面。备用链反复选择老面孔，自然无法发现新出现的更便宜、更好的选项。中性初始分让未知路由获得被尝试的机会，但原文没有交代具体探索比例和更新方法。

最后，反复违反执行约定的路由进入 blocklist，直接移出候选池，直到有理由重新手工测试。

这里不能只降分。降分仍保留了偶尔被选中的可能，而一个持续忽略 schema、用摘要代替工具调用的模型，每次入选都可能破坏整个循环。

作者还引用了另一位 LLM 网关运营者的经历：按速度排列备用链、把最快模型放在前面后，24 小时内就收到用户投诉，随后回滚配置。这是另一个经验案例，尚不足以量化这种策略的普遍风险。

我的判断

我赞同先设能力门槛，再讨论排序。对于需要工具调用的 Agent，工具参数是否符合 schema、该检索时是否真的检索，比接口有没有返回正文更接近任务成败。

但标题里的「延迟是错误指标」需要限定范围。作者自己的方案仍然使用延迟，只是把它从主要排序依据改成预算。对有明确等待上限的交互，延迟当然有价值，问题在于不能让它补偿关键能力缺失。

相比单纯按速度排序，这套方案更贴近任务要求；相比复杂的加权打分，它也更容易解释某条路由为什么有资格入选。不过，原文没有提供对照实验，不能据此认定它在所有团队里都更优。

论文另一个发现也应谨慎理解：研究者用几百个问题测试了 3 家接口和输出形式相同的网页搜索提供商，报告成本、延迟均未与答案质量呈现相关性，最佳提供商还会随查询变化。这个结果支持按任务评估，却不能直接推广到所有模型和负载。

还有一个实施前必须厘清的边界：历史质量未知，与工具能力未经验证，是两回事。中性先验适合解决前者；对于后者，我会先验证兼容性，再让它参与探索。原文没有完整说明这两层如何衔接。

能拿来做什么

• 给需要搜索或工具调用的 AI 编程流程增加完成条件检查。除了接口状态，还要确认必要的工具调用确实发生，不能仅凭返回了一段文字就判定成功。
• 在 Node 服务的备用配置里，把候选资格、质量排序和延迟预算分别表达，便于定位一次切换究竟是能力问题、质量问题，还是等待时间超限。
• 为通过兼容性验证的新路由保留试用机会，并记录实际任务结果；对反复忽略 schema 的路由移出候选池，复测通过后再恢复。