AI agent 模型路由与回退链设计：任务复杂度、成本和风险如何决定该用哪个模型

很多团队做 AI agent 时，第一版都会先把模型写死。这样做在 Demo 阶段很正常，但一旦进入真实业务，就会立刻遇到三个问题：简单任务用大模型太贵，复杂任务用小模型又不稳，高风险动作还不能只看“平均效果”。

模型路由真正要解决的，不是“怎么省几分钱”，而是让系统根据任务复杂度、时延预算、风险等级和历史质量，选到最合适的那条执行链。否则系统只会在两个极端摇摆：要么全量用最贵模型，要么为了省成本把低质量结果推给用户和人工复核。

建议先结合 AI agent 成本控制与预算治理、AI agent 灰度发布与功能开关、AI agent 产品成功指标 和 AI agent Shadow Mode 上线方法 一起看。

先给结论：模型路由先看 4 个维度，再决定谁主谁备

如果没有这张表，系统里的“模型选择”大概率只是硬编码习惯，而不是治理结果。

一、不要把模型路由理解成“便宜模型优先”

最常见的误区是：模型路由就是尽量先打小模型，失败了再上大模型。这个策略只有在任务差异很小的时候才成立。真实场景里，更常见的是：

• 信息抽取适合小模型
• 多步规划适合强模型
• 高风险判断需要更稳定的 reasoning 路径
• 纯格式化或改写未必要动最强模型

也就是说，路由不是单纯的成本排序，而是“任务类型与模型能力边界匹配”。

二、模型路由请求最好先被结构化，不要让模型自己决定该找谁

更稳的做法，是先把请求转成一份 route envelope：

{
  "runId": "run_123",
  "taskType": "draft_review",
  "riskLevel": "high",
  "latencyBudgetMs": 12000,
  "costTier": "standard",
  "requires": ["structured_output", "tool_use"],
  "fallbackPolicy": "degrade_then_review"
}

这里最关键的是：模型选择发生在执行层，而不是 prompt 里。Prompt 可以描述输出要求，但不应该自己决定“我今天想用哪个模型”。

三、路由表最好显式维护，不要散在代码分支里

一个最小可执行的路由矩阵通常长这样：

路由表的价值不只是配置方便，而是故障复盘时你能回答：为什么这个请求走了这条链，而不是另一条。

进一步说，路由结果本身也值得落成一份可审计的 decision record，而不是只在内存里返回一个模型名：

{
  "runId": "run_123",
  "routeVersion": "router_v7",
  "taskClass": "high_risk_review",
  "chosenModel": "reasoning-pro",
  "fallbackChain": ["reasoning-lite", "human_review"],
  "decisionReasons": ["risk_high", "structured_output_required"],
  "budgetGuard": {
    "latencyBudgetMs": 12000,
    "costTier": "standard"
  }
}

这类记录的价值在于，后面无论是复盘质量事故、解释成本波动，还是比较不同路由版本，你都不需要靠猜测还原“当时系统为什么这么选”。

四、回退链不是“失败了就换模型”，而是要带停止条件

很多系统的问题不在没有 fallback，而在 fallback 没有 stop condition：

1. 主模型失败
2. 换备模型
3. 备模型结构不稳
4. 再换主模型或再试一次

最后系统既花了钱，也没有得到更稳结果。一个更健康的回退链应该明确：

• 哪类失败允许 fallback
• fallback 最多走几层
• 什么情况下直接停止或转人工

例如：

primary_model_failed(timeout)
  -> fallback_model
  -> if still schema_invalid then human_review

这比“只要失败就继续换”稳定得多。

五、高风险任务不要只靠模型能力路由，还要叠加风险闸门

假设一个 agent 要发送对外邮件。即便模型路由已经把它分到“最强模型”，也不代表它就该自动继续。真正稳的做法是：

• 先按任务类型和风险等级路由模型
• 再经过 AI agent Policy Engine 规则分层
• 最后视结果决定自动继续、降级还是进入 AI agent 人工审批控制台设计

模型路由解决的是“谁来做”，不是“可不可以做”。

此外，路由切换本身最好也有明确的转正和退出门槛。很多团队的问题不是没有路由，而是新路由一上线就全量接管，等到人工返工率上升才发现切换过快。更稳的做法通常是先在 shadow 或 canary 流量里盯住这些门槛：

路由不是配好一次就结束，而是要像发布策略一样有观察窗口和退出条件。

六、上线后要盯路由质量指标，而不是只看单模型成功率

建议持续观察这些指标：

如果 fallback rate 很高但 accepted run 没提升，说明你不是在做路由，而是在做昂贵的试错。

七、失败案例：为了省钱把所有请求先打小模型，结果人工返工更贵

某个内容 agent 把所有任务都先路由到低成本模型，只有完全失败才切到强模型。上线一周后，账面 token 成本下降了，但编辑团队的返工时间暴涨。复盘发现：

• 简单任务确实省钱
• 复杂任务虽然“没有失败”，但输出质量不够，全部落到人工重写
• 系统只统计 API 成本，没有统计返工成本

修复后，团队把路由改成“按任务复杂度分流”，并把 accepted run 的总成本写入看板，模型选择才真正和业务结果对齐。

八、模型路由 Checklist

• 是否先定义任务复杂度、风险、时延和成本四个路由维度
• 请求是否先被结构化成 route envelope
• 是否有显式路由矩阵，而不是散落在代码里的 if/else
• 是否记录 routeVersion、chosenModel 和 fallbackChain
• fallback 是否带最大层数和停止条件
• 高风险任务是否叠加 policy 与人工闸门
• 新路由放量前是否设定 accepted quality、cost 和 escalation 的退出门槛
• 是否持续监控 route hit、fallback success 和 accepted cost
• 是否把返工时间一起算进模型路由收益

结语

AI agent 的模型路由，不是“先便宜后昂贵”的简单开关，而是把任务复杂度、风险等级、时延预算和成本预算一起翻译成执行链。只有这样，系统才不会在节省 API 成本的同时，把更大的成本转嫁给人工返工和业务风险。

延伸阅读：

• AI agent 成本控制与预算治理
• AI agent 灰度发布与功能开关
• AI agent Shadow Mode 上线方法
• AI agent Policy Engine 规则分层