Agent 的模型 Fallback 链：GPT-4o 太贵退到 Claude Sonnet 再退到 mini 和本地模型

我有一个朋友，Agent 项目从头到尾都用 GPT-4o。月底账单出来那天，他盯着那个数字，好久没说话。我说：你可以退到便宜模型啊。他一脸警惕：那不是会笨吗？这个怕变笨，是做 Agent 的人共同的焦虑。但你可能会问，那为什么不一开始就用便宜模型？因为便宜模型在复杂任务上真的会笨。所以真正的答案不是用哪个模型，而是每个任务该用哪个模型。Fallback 链要解决的，就是这件事。

先拆一个常见误解：很多人以为 fallback 链就是 try/catch——主模型失败，就抛给备用模型。如果你这样做了，你得到的是一个 failover 系统，不是 fallback 链。两者的差别在于：failover 只管谁还能接活，fallback 要回答这个任务值得让哪一档模型来做。

Agent 任务的复杂度差别极大。同样是查一下上周的销售数字，一个步骤搞定，mini 模型和 GPT-4o 差距不大；但把三个表格合并、跟外部系统对一遍，再给客户写一封正式邮件，小模型会丢中间步骤。把前者交给旗舰模型，是浪费；把后者交给 mini，是灾难。Fallback 链的意义，就是把每个任务匹配到它配得上的模型。

先画一张能力地图，再谈退路

在做 fallback 链之前，你需要先有个判断：哪类任务配得起哪个模型。我根据实际跑 Agent 的感受，给了一张不严谨但实用的表：

档位	典型模型	适合	不适合	Agent 里的角色
旗舰	GPT-4o、Claude Opus	多步推理、长程规划、复杂工具编排	简单查询、重复性格式化	总控 / 最终裁决
中端	Claude Sonnet、GPT-4o 级别	代码生成、结构化输出、大多数工具调用	需要极高可靠性的长链条推理	主力 Worker
轻量	GPT-4o mini、Claude Haiku	分类、抽取、判断、简单问答	复杂 JSON schema、多步骤工具组合	预处理器 / 分类器
本地	Qwen 7B、Llama 8B	隐私敏感、离线、极低延迟	复杂指令、需要世界知识	本地过滤器 / 最后兜底

所以一个正确的 fallback 链，策略不是从最贵的开始，而是从一个中间档开始。Agent 收到任务，先做复杂性判断：单轮、固定格式、工具调用次数少于 2 的，直接交给 mini 层；需要组合多个信息源的，才轮到中端；只有当 Agent 计划超过 5 步、需要从多个系统取数交叉验证时，才动用旗舰。用旗舰的地方，贵得有理由；用 mini 的地方，便宜得有底气。

Fallback 不是 try/catch，是分流器

很多人以为 fallback 链就是 try/catch，主模型抛异常就换下一个。确实有现成工具支持这种写法，比如 LiteLLM 的 fallbacks 参数，看起来就像这样：

from litellm import completion

resp = completion(
    model='gpt-4o',
    messages=[{'role': 'user', 'content': '...'}],
    fallbacks=[
        'claude-3-7-sonnet-20250219',
        'gpt-4o-mini',
        'ollama/qwen2.5:7b'
    ]
)

这段代码的含义是：如果 gpt-4o 抛出异常或超时，自动换 Claude Sonnet；再不行换 mini；最后用本地模型。看着很规整，但这里有几个隐藏问题，我逐个说。

第一，失败的判定太窄。上面这个 fallback 链只对 API 异常生效。GPT-4o 返回 200 但输出没有按 schema 走，或者函数调用参数少了字段，这种情况在 Agent 任务里太常见了。如果只靠异常触发，链路大部分时候是废的。你需要在校验结果的那一层决定要不要降级，但那是你自己的业务逻辑，LiteLLM 默认做不了。

第二，切换模型不等于切换脑袋。同样一段 messages，在 GPT-4o 眼里是清晰的指令，在 Claude 眼里可能需要更明确的语气标记，在 Qwen 眼里可能直接被忽略掉。不同模型的 tokenizer 和偏好差异很大，我是建议每个档位预备一个 system prompt 模板，切换时替换。

第三，可观测性。一条 request 从 gpt-4o 退到 qwen，最后跑通了，但如果日志里不记录当前用的是哪个模型，出问题时你根本没法定位。我踩过这个坑：一次任务结果错误，我翻日志只看到 gpt-4o 的调用记录——因为那一次根本没触发异常，是后面的流程出的错。后来我强制在每次响应的 metadata 里记 model、cost、latency，这样每个结果都有模型路径。

mini 和本地模型，适合当备胎但不是主角

题目里的 mini 指的是 GPT-4o mini 这类轻量模型。单看分类、抽取，它们和旗舰的差距没那么大；但 Agent 的核心是长链路工具调用，mini 模型容易犯两个错：漏填函数参数，或者忽略指令里的数量和时间限制。我见过一个例子，Agent 让 mini 模型写邮件，它竟然把收件人字段填成了自己的名字。所以在降级到 mini 时，我一般会把任务切成更小的子任务，或者把输出格式用模板包起来。不要让它直接接手原任务，它可能撑不住。

本地模型是最后一道防线。它的价值是离线、私密、可预期，适合网络断了也能跑的极简功能。但工具调用能力和指令跟随能力普遍弱于 API 模型。我给它的角色是只读任务：总结文本、打标签、生成草稿。任何需要精确格式或外部系统交互的任务，都不要指望它。

这里还有一个很多人忽略的问题：函数调用的 schema 兼容性。同一个 function schema，在 GPT-4o 上完美解析，在 Claude 上可能需要把 description 写得更详细，在 mini 上可能直接少掉一个参数。我最早天真地以为 API 都是 OpenAI 格式，后来发现 Anthropic 的工具格式差异非常大。如果你要用 fallback 链，必须在每个档位都做一次工具调用的格式测试，而不是只在便宜的档位做简化。

三个容易踩的坑

用网关还是自己写？

如果只是单模型调用，自己写两行就够了；但需要 fallback 链时，你已经面对多模型、多策略的复杂度。像 OpenRouter 或 LiteLLM 这类网关内置了超时、重试、熔断、日志统计，比自己写 if-else 更稳。但网关不知道你的任务语义，它只处理 HTTP 层的失败，质量校验得在网关外面的回调里做。