模型选型与成本工程

前面的章节反复强调一个公式：Agent = Model + Harness。但"Model"这个位置从来不是一个单数——截至 2026 年中，任何一家主流供应商的产品线都至少分出旗舰、中档、轻量三档，价格相差一个数量级以上。把哪个步骤交给哪一档模型，是 harness 工程师自己做的决策，模型不会替你选。 这个决策同时落在三条轴上：能力（这一步做错了代价多大）、成本（这一步要跑多少次）、延迟（这一步挡不挡用户的路）。

这正是模型路由（model routing）要回答的问题。它和上下文工程是 harness 里仅有的两个"每转一圈都在花钱"的环节：上下文决定每次调用多大，路由决定每次调用多贵。

模型分层的经济学

先看账。截至 2026 年中，主流 API 的价格结构大致是（具体数字随版本更迭极快，以官方定价页为准——Anthropic、OpenAI、Google）：

档位	输入价格量级（每百万 token）	输出价格量级	典型用途
旗舰（Opus / GPT 旗舰级）	约 5–15 美元	约 25–75 美元	复杂规划、疑难调试、终审
中档（Sonnet 级）	约 2–3 美元	约 10–15 美元	日常编码与写作主力
轻量（Haiku / mini / Flash 级）	约 0.1–1 美元	约 0.8–5 美元	分类、摘要、格式转换、监控

三个观察值得记住：

价差是真钱。 旗舰档与轻量档之间普遍有 10–30 倍的单价差。而 agent 负载的特点是输入极长、输出极短（上下文工程里引过 Manus 的数据：平均输入输出比约 100:1），所以输入价格才是 agent 账单的主体——路由决策主要看输入列。

能力差距不是均匀的。 小模型在分类、抽取、重写这类"有确定答案形状"的任务上，与旗舰的差距很小；差距集中在长链条推理、歧义消解、罕见错误恢复这些"没有地图"的地方。路由的全部利润空间，就藏在这种不均匀里。

延迟也分层，而且方向与价格相反。 小模型首 token 更快、生成速度更高。对挡在用户面前的交互步骤，"快但够用"常常优于"强但慢"——延迟本身就该是路由的一个输入维度，后面会展开。

同一个任务，不同的步骤配不同的模型

Agent 的一次任务不是均质的调用流，而是不同难度步骤的混合体。一个合理的默认分层：

┌────────────────── 一次 agent 任务里的模型分层 ──────────────────┐
│                                                                │
│  规划/重规划 ──────────► 旗舰模型      （次数少、错不起）        │
│  关键决策点（歧义消解、终审）──► 旗舰模型                         │
│  常规执行步骤 ──────────► 中档模型      （次数最多、账单主体）    │
│  工具结果分类/摘要 ─────► 轻量模型      （答案形状确定）          │
│  子 agent 的窄任务 ─────► 轻量/中档模型 （见 /components/subagents）│
│  上下文压缩（compaction）─► 专用/轻量模型（高频、机械）           │
│                                                                │
│  原则：贵的模型按"决策点"计费，便宜的模型按"吞吐"计费             │
└────────────────────────────────────────────────────────────────┘

这个分层在业界早有先例。规划与任务分解里讲过 Plan-and-Execute 的一个隐性红利：贵的模型做 planner，便宜的模型做 executor。Cognition 走得更远——在 Devin 案例里可以看到，他们专门训练了一个压缩模型来做 compaction，因为长时程 agent 每小时可能触发多次压缩，这是典型的"高频、机械、答案形状确定"的步骤，不值得让旗舰模型做。

一条反直觉的经验

分层最大的阻力不是技术，是心理：工程师总担心小模型"会不会差一点点"。正确的问题不是"小模型够不够好"，而是**"这一步失败的代价是多少、能不能被下一步发现"**。能被下游步骤或验证器捕获的错误，用便宜模型试错；一步错、全盘输的决策点，才值得旗舰价。

三种路由模式

决定"这一步给谁"的机制，按智能程度分三档。

模式一：规则路由

最朴素也最常用：harness 代码里写死"规划用旗舰、执行用中档、分类用轻量"，或者按任务的静态特征分派（issue 带 bug 标签走 A 模型，带 refactor 走 B 模型）。

• 优点：零额外延迟，行为完全可预测、可审计；出问题能精确归因到某条规则。
• 缺点：规则是拍脑袋的先验，不随真实分布调整；任务难度是连续谱，规则的边界必然切错一部分。

模式二：级联（cascade）：先小后大，不行再升级

级联把"规则"换成了"置信度"：每个请求先给最便宜的模型，由一个打分器（scorer）判断这次输出是否可信，可信就用，不可信就升级到下一档。

┌──────────────────── LLM 级联 ────────────────────┐
│                                                  │
│  请求 ──► 轻量模型 ──► 打分器 ──可信──► 直接返回   │
│              │            │                      │
│              │            └─不可信──► 中档模型 ──► │
│              │                         打分/升级  │
│              ▼                                   │
│         少数难题最终到达旗舰模型                    │
│                                                  │
│  期望成本 = Σ (到达该档的概率 × 该档单价)           │
└──────────────────────────────────────────────────┘

这条路线的理论奠基是 Stanford 的 FrugalGPT（arXiv:2305.05176，TMLR 2024 收录）：在 HEADLINES 等分类任务上，级联能在匹配 GPT-4 精度的同时把成本降低最高 98%，或者在同成本下反超 GPT-4 约 4 个百分点。引用这个数字时必须带上脚注：这些是 2023 年模型代际上的窄分类任务，打分器廉价易训；"98%"不能外推到 agentic 编码这类开放任务上。级联真正的门槛是那个打分器——判断"这次输出可信吗"本身就是个难题，在开放式生成任务上，一个可靠的置信度估计器可能比省下的钱还贵。

模式三：学习型路由器

再进一步：不用人工规则也不用逐步升级，而是训练一个专门的路由模型，在请求进来时一次性预测"这个查询给弱模型能否得到满意答案"，直接分派。LMSYS 的 RouteLLM（arXiv:2406.18665，开源实现）是代表：用人类偏好数据训练路由器，在 MT-Bench 上报告了超过 85% 的成本削减而基本不掉质量，且路由器对测试时更换强弱模型有一定的迁移能力。

• 优点：一次预测，没有级联的串行延迟；路由边界从数据里学出来，不靠拍脑袋。
• 缺点：需要训练数据（偏好对、历史轨迹的质量标注）；模型代际一换，路由器就要重训；而且路由器本身也是一个要被评测、被维护的组件。

维度	规则路由	级联	学习型路由器
决策时机	静态（代码/配置）	逐请求，先小后大	逐请求，一次分派
额外延迟	零	高（串行多级）	低（一次前向）
需要的资产	工程师的先验	可靠的打分器	训练数据 + 重训管线
错误形态	边界切错	打分器漏判/误判	分布漂移失效
适用	步骤类型固定的 harness	查询难度方差大的服务	有历史轨迹数据的大流量产品

工业界参照：Devin Fusion 的动态切换

截至 2026 年中，公开的工程文献里对 agentic 场景模型路由最坦诚的一篇是 Cognition 的 Devin Fusion（细节见 Devin 案例）。它把上面三种模式揉成了一个生产级方案，两个设计值得抄：

1. 不在任务开始时分派，而在会话中途动态切换。 轻量分类器持续判断当前阶段该升级还是降级——因为 agent 任务的难度分布在时间轴上，开始时的任务标签预测不了第 40 步的难度。
2. 把切换安排在 compaction 时刻。 模型切换会使 KV cache 前缀全部失效（机制见上下文工程的 KV cache 一节，此处不重复），而压缩本来就要重建上下文——把切模型和压缩对齐，切换的缓存代价就降为零。这是"路由决策必须懂推理基础设施"的绝佳示范。

结果是 Fusion 以低约 35%（后续数据至 60%）的成本维持前沿级表现。Cognition 也直言教训：那些在 benchmark 上好看的通用路由方案，"写出的代码你不会合并"——agentic 路由的评测必须在真实任务轨迹上做，静态问答基准上的路由收益不代表 agent 场景的收益。

Fallback 与重试设计

路由的另一面是失败处理。模型 API 不是稳定的基础设施：限流、过载、超时、内容拒绝、上下文超长，每一类的正确响应都不同。把 fallback 写成裸的 try: call() except: retry() 是 agent 账单的常见出血点。

按错误类型分流：

错误	性质	正确响应
限流（429）/ 过载	瞬时	指数退避 + 抖动重试；或降级到中档模型/备用供应商
超时	瞬时，但可能已产生计费	有限次重试；注意长输出的调用超时要按流式首 token 计，不是总时长
上下文超长	确定性，重试无用	不要重试——先压缩或降级到长上下文档位，再重发
内容拒绝	确定性	重试无效；改写输入或换模型，并记录为可观测事件
输出格式错误	模型侧	原样重试偶发有效；更好的做法是把解析失败连同错误信息回灌给模型让它自修

三条纪律：

• fallback 链要有终点。 旗舰 → 中档 → 备用供应商 → 明确报错，最多三到四跳。无限降级会把一个"疑难任务失败"悄悄变成"疑难任务被轻量模型答错"——后者危险得多，因为它不出错日志，只出错结果。
• 重试要预算化。 给每次任务设重试次数与总成本上限，超限就走权限与人机协作里的升级路径，向人求助。没有成本上限的重试循环，在限流风暴里能把账单烧穿。
• 切换即失效点。 任何"换模型/换供应商"的 fallback 都会改变系统行为（不同模型的工具调用风格、格式习惯都不同），切换事件必须写进轨迹日志——它是可观测性里最重要的异常信号之一。

一个隐蔽的账单黑洞

级联与 fallback 叠加时会出现"双倍计费"：轻量模型答错 → 升级中档 → 超时 → 重试 → 再升级旗舰。同一次用户请求被四个模型各收一遍钱。设计上要让"升级"记住已有尝试（把轻量模型的输出作为上下文传给下一档，既省 token 又给它线索），并在任务级设成本熔断。

成本旋钮全景

路由是最显眼的成本杠杆，但不是唯一的。完整的旋钮清单，按杠杆大小排：

旋钮	量级	要点
模型路由	一个数量级	本文主题；账单主体是输入 token，盯住输入列
Prompt 缓存	命中部分输入价降至约 1/10	机制与纪律（前缀稳定、只追加）见上下文工程；路由侧的启示是别轻易换模型，换模型 = 缓存全废
批处理 API	全线 5 折	OpenAI Batch API 与 Anthropic Message Batches 均为 50% 折扣、24 小时返回；评测集、夜间批跑、离线数据标注这类"不要即时响应"的负载应一律走批量
上下文瘦身	线性	每省一个 token 都省一份输入钱；压缩、工具结果清理、just-in-time 检索都是这里
max_tokens 纪律	防失控	给每步设输出上限，防模型陷入长篇独白；对"只返回 JSON"的步骤压到最小
结构化输出	间接	严格的 schema 约束减少重试次数，省的是 fallback 的钱

旋钮之间的相互作用

这些旋钮不是独立的。缓存纪律约束路由（切模型时机要对齐压缩点）；批处理和路由叠加（批量任务更应该用便宜模型，因为没有即时性压力，可以承受级联的串行延迟）；max_tokens 纪律影响 fallback 设计（截断的输出会被格式校验拦下，触发重试）。做成本工程时要把它们当成一个互相咬合的系统，而不是一张可以逐项勾选的清单。

延迟与体验的权衡

成本之外，路由的第二条轴是延迟。agent 的延迟体验由三件事决定：

流式输出是最廉价的体验优化。 不改变任何成本结构，只把"等 30 秒看到完整回答"变成"1 秒内看到第一个 token"。对 harness 的代价是解析逻辑变复杂——工具调用参数要边流边解析，格式错误要到流尾才能发现。

推测执行（speculative execution）。 两个层面。推理侧的推测解码（speculative decoding，Leviathan 等人 2023）用小模型起草、大模型并行验证，把大模型的有效生成速度提高数倍——这是供应商侧的优化，但它解释了为什么"大模型 + 小草稿模型"的服务架构能在不明显加价的前提下更快。应用侧的对应物是 OpenAI 的 Predicted Outputs：当输出的大部分可以预知时（比如代码改写只动几行），把预测内容作为参考传入，模型只需"确认与修补"，官方报告此类场景延迟可降低数倍。这本质上是harness 把自己的先验（我知道输出大概长什么样）变现成延迟收益。

快模型前置。 延迟敏感的交互步骤（意图识别、下一步动作的草拟）用小模型先给即时反馈，慢而重的步骤放后台——这与成本分层天然同构，所以路由表应该同时标注每档的预期 TTFT 与吞吐。

权衡的核心是：延迟和成本经常可以用同一个旋钮换，但方向相反的操作会互相抵消。级联省钱但串行延迟最高；全旗舰最快也最贵；Fusion 式的"sidekick 并行"试图两头占——主 agent 与便宜 agent 并行跑，用算力冗余换"既快又省"的期望。没有免费午餐，只有明确标价的取舍。

评测先行：换模型必须跑回归

最后也是最容易被忽略的一条：模型路由的任何变更——换模型、改路由规则、调级联阈值——都是 harness 变更，必须跑回归评测。

理由很硬核。agent 的产出是模型与 harness 的联合结果（模型 vs Harness里引用的研究已经证明，同模型换 harness 分数差近 10 个百分点），而换模型对 harness 的影响是非对称的：新模型可能更聪明，但工具调用格式习惯不同、对压缩后摘要的鲁棒性不同、在 fallback 链里的失败模式不同。你为旧模型调好的提示纪律，可能恰好是旧模型的补丁，而不是普适的最佳实践。

工程上的最低要求：

• 每次路由变更跑一遍固定回归集（任务集、判分器、成本口径都冻结），比较通过率与单任务成本两个指标——只看质量会漏掉成本回退，只看成本会漏掉质量回退；
• 把模型版本钉在配置里，禁用 latest 别名——供应商静默升级是"你的 harness 没变但行为变了"的标准来源；
• 把路由决策本身纳入日志：哪一步走了哪档模型、为什么、花了多少——没有这份数据，账单异常时你无从下手。

方法论详见评测实践；评测集怎么建、判分器怎么写，那一章有完整展开。

给自建 harness 的默认建议

从规则路由起步（规划旗舰、执行中档、杂务轻量），先把按步骤的成本日志建起来；攒够几百条真实轨迹后，你才有数据判断级联或学习型路由器是否值得上。没有轨迹数据就训路由器，是在给自己的先验过拟合。动手路径见搭建自己的 harness与设计原则。

延伸阅读

• 上下文工程——KV cache 机制与前缀稳定纪律：路由决策的成本另一半
• 规划与任务分解——planner/executor 分层是模型路由的最古老形态
• 子 Agent——窄任务子 agent 是轻量模型最自然的去处
• 可观测性——按步骤记录"用了哪个模型、为什么、多少钱"
• 权限与人机协作——重试预算耗尽后向人升级的路径设计
• Devin 案例——Fusion 的 sidekick 模式与会话中动态路由
• 模型 vs Harness——为什么换模型必须视为系统变更
• 评测实践——路由变更的回归评测方法论

参考资料

• FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance (arXiv:2305.05176)——LLM 级联的奠基工作，含 prompt adaptation / approximation / cascade 三类策略
• RouteLLM: Learning to Route LLMs with Preference Data (arXiv:2406.18665) 与 LMSYS 发布博客——偏好数据训练的学习型路由器
• lm-sys/RouteLLM（开源实现）——路由器的训练与评测框架
• Cognition: Devin Fusion——sidekick 双 agent 结构与"compaction 时刻切模型"的工程细节
• OpenAI Batch API 文档——50% 折扣、24 小时窗口、独立限流池
• Anthropic Prompt Caching 文档——缓存写入约 1.25 倍、读取约 0.1 倍输入价的计费结构
• OpenAI Latency Optimization 指南——含 Predicted Outputs 的延迟优化手段
• Fast Inference from Transformers via Speculative Decoding (arXiv:2211.17192)——推测解码原始论文
• Anthropic 定价页 / OpenAI 定价页 / Gemini API 定价页——本文价格量级的核对来源（截至 2026 年中，变动频繁）