模式矩阵 /模式白皮书/R2

R2 · Complexity-Based Routing · 复杂度路由

它解决什么问题

把最贵最强的模型当默认选项用，是 2026 年 Agent 工业最常见的浪费。GPT-4o 和 GPT-4o-mini 之间价差 16 倍，Opus 和 Haiku 之间也接近这个量级。如果一个 Agent 把所有查询都路由到最贵的模型，而其中一大半其实是模板填空级的简单任务，那这部分账单就是纯冤枉钱。

复杂度路由把"全用贵模型"换成"按需分流"。它的前提是真实流量里易例多、难例少——简单查询占大头，复杂查询是少数。把简单查询路由到便宜模型，把贵模型留给真正需要的复杂查询，账单立刻砍掉一大半，质量基本不损失。行业数据显示做对路由的团队普遍能拿到 47% 到 80% 的成本下降。它和并行探索（R3）是一对互补姿态：路由负责日常省钱，并行负责关键决策买质量，两者在同一个 Agent 里并存。

为什么坐标是「推理 × 路由」

• 纵轴 · 推理：路由决策的本质是"这道题用便宜的快思考还是贵的慢思考"，选的是 reasoning policy，是推理策略层的事，不是把任务拆给多个 Agent。
• 横轴 · 路由：按输入的复杂度信号，把不同查询分发到不同的 reasoning depth（模型档 + effort 档）。这是天然的分支选择结构，一个查询进来选一条路走。

核心机制

一次复杂度路由由三段组成：

1. 提取信号 + 分类：从查询里提取复杂度信号（长度、关键词、领域、历史成功率），交给一个 classifier 判定走哪一档。Classifier 本身要用便宜模型或规则做，决策成本控制在整体的 5% 以内——不能上来就调贵模型做路由判断。
2. 分档执行：常见是三档（Cheap / Medium / Expensive），各档共用同一套调用接口，只切模型名字。路由不只是选模型，还要选模型的 effort 档位，两个维度组合。
3. 升档兜底：便宜档答完后检测结果是否可信（置信度、schema、长度），不达标就升档重试。升档链必须有硬上限（通常 3 档），到顶还不行就报错或转人工——任何 escalation 链都要熔断。

2026 年路由工业分裂成三条路线，决定团队怎么选：

严肃的生产 Agent 一般走 Harness 显式路线，因为成本控制是产品经济学的核心，把这个权力交给模型厂商或第三方都是放弃 control。PoC 和小项目可以用另两条。

适合的生产场景

• 易例多难例少、且 cost 敏感而 accuracy 不能掉：内部 BI 自助查询、客服问答、文档处理——大部分查询简单、少部分复杂，路由能精准把钱花在刀刃上。
• 多厂商混用场景：团队同时用 Claude / DeepSeek / 自家微调模型，没法把路由交给单一厂商，必须工程层做。
• 按动作类型分流的专门 Agent：代码改动用主模型、git 操作用 weak 模型这类，按动作而非按查询复杂度路由，是路由思路的一个变体。

容易出错的地方

• classifier 用纯规则：关键词匹配对没见过的查询形态泛化差，会把复杂查询错判到便宜档。生产里应该用便宜模型做分类，泛化更好，成本也只占整体 5% 以内。
• acceptable 校验只看长度：只检查输出够不够长，放过了 schema 不符、数值越界、引错源数据的结果。要做 schema-aware 校验。
• fallback 比直接走贵档更贵：便宜档先跑一遍不达标再升贵档，总成本反而高于一开始就走贵档。fallback rate 一高就得查 classifier 是不是失准了。
• 高风险查询也走便宜档：财务、隐私、合规相关的查询即使看起来简单也不能省，错的代价比 token 贵 100 倍，要强制走最稳的档。
• 单模型团队硬上路由：只用一个模型、或任务永远同一类、或便宜模型已经够用的场景，路由没有意义，是过度工程。

关键指标

• 每查询成本分布（健康区 long-tail）：便宜档 60-80%、中档 15-30%、贵档 <10%。贵档占比超过 30%，要么业务真的复杂，要么 classifier 把太多简单查询错路由到了贵档。
• 路由准确率（健康区 >90%）：便宜档处理后未升档的比例。只有 60% 不升档，说明 classifier 把太多复杂查询塞进了便宜档。
• 升档率 Fallback Rate（健康区 <10%）：便宜档触发升档的比例。这是其他指标的先行信号——它一高，成本分布立刻偏移、准确率立刻下降，要先把它压下来。
• 平均决策时间（健康区 <100ms）：classifier 自己做决定花多久。超过这个值说明路由判断太重，Agent 还没干活就先等。

最小骨架

查询进来 → 提取复杂度信号（长度 / 关键词 / 领域 / 历史）
classifier（便宜模型或规则）→ 选定档位 + 置信度
高风险查询（财务 / 隐私 / 合规）→ 强制最贵档，跳过分流
执行：
    便宜档跑 → 结果可接受？→ 返回
              不可接受 → 升档（schema 校验 + 成本估算）
    升档链有硬上限（如 3 档），到顶仍不行 → 报错 / 转人工
每次路由决策打 trace（查询摘要 / 档位 / 信号 / 置信度 / 实际成本 / 是否升档）

落地四个要点：classifier 用便宜模型替代纯规则；acceptable 校验做 schema-aware；fallback 链加成本上限避免极端 case 爆炸；定期把反复升档的查询类型直接默认到高档，省去重复升档开销。

企业落地一例

某中型 SaaS 公司的内部数据分析 Agent，让产品、增长、财务团队用自然语言查 BI 数据。第一版默认全用最贵的模型（"反正最强免得出错"），上线三个月后财务收到一张 48 万的月账单。团队拆开流量一看：41% 的查询是 SQL 模板填空（"上周注册用户数"），22% 是加个分组（"按地区分组的留存曲线"），真正需要多步归因的复杂查询只占 19%，需要因果建模的只占 4%。把模板填空类查询喂给最贵模型，等于花 15 倍冤枉钱。

重写时做了六个关键决策：三档分流加一档兜底（便宜档跑模板填空、中档跑分组、贵档跑归因、顶档跑因果建模）；classifier 用规则加便宜模型双轨（80% 走规则、20% 走便宜模型，路由成本压到每月 200 元以内）；升档时先估算总成本避免升了反而更贵；财务、隐私、合规三类高风险查询强制走最贵档；每次路由决策全量 trace、每周生成 health report；每 30 天把反复升档的查询类型直接默认到高档。三周后账单从 48 万降到 12 万，错误率维持在 0.5% 以内，p99 延迟也下降了。

与其他模式的关系

• 并行探索（R3）：互补。路由是单时间点选一档省钱，并行是同时开 N 条线买质量，同一个 Agent 里日常走路由、关键决策启动并行。
• 思维链（R1）：路由选的档位里就含 CoT 的 effort 档，路由是 CoT effort 控制从单次调用上升到任务级的版本。
• 双模架构（R5）：双模是路由的架构极致——普通路由是"选一档跑"，双模是"两档同时跑"，把"选档"推到了"拆 Agent"。
• 失败日记 / 守卫类模式：高风险查询强制走最稳档，和"有些边界不能省钱"的防护思路同源。

一句话记住它

复杂度路由的本质不是"看查询选模型"，而是把 token、延迟、质量三个变量做成 Pareto 前沿，按业务 SLA 在曲线上选具体的点——这是产品经济学的工作，不是模型调参的工作。

本页属于 ADPS 33 模式白皮书。返回 模式矩阵与白皮书目录， 或查看配套 可运行代码目录。