第 29 章 模型路由：谁用哪个模型，怎么用得起

全用最强模型，账单先扛不住

第 28 章讲了多 Agent 怎么协调。这一章回答另一个规模化问题：一群 Agent 里，每个环节该用哪个模型？

最省事的答案是"全部路由到最强模型"。但这会悄悄把成本顶上去，负载高了吞吐还下降。最省钱的答案是"全用便宜模型"，但复杂问题它真想不明白。真正的答案在中间：按任务路由模型，让每个环节用"够用且最便宜"的那个。

这一章讲四个模式，从"两档分工"到"流水线分工"到"预算约束"到"按性格分工"：

1. Oracle and Worker（Oracle 与 Worker）：便宜 Worker 干活，贵 Oracle 只在大决策时出场。
2. Multi-Model Orchestration（多模型编排）：复杂任务拆成多段，每段配专门的模型。
3. Budget-Aware Model Routing（预算感知路由）：路由层带硬成本上限。
4. Agent Modes by Model Personality（按模型性格分模式）：不同模型性格不同，给它们不同的工作模式。

模式一：Oracle 与 Worker（Oracle and Worker Multi-Model Approach）

问题

依赖单一 AI 模型，在能力和成本之间只能二选一。高性能模型干常规任务太贵，性价比模型又缺复杂问题需要的推理力。

方案

实现两档系统，角色专门化：

• Worker（Claude Sonnet 4）：快、能、性价比高，负责批量工具使用和代码生成。
• Oracle（OpenAI o3 / Gemini 2.5 Pro）：强、贵，留给高层推理、架构规划、调试复杂问题。

Worker 卡住或需要更好策略时，可以显式请求 Oracle 咨询。 Oracle 审查 Worker 的方案、建议纠偏，而不污染主 Agent 的上下文。

用户请求 → Worker Agent
Worker → 需要 Oracle? → 是 → Oracle 咨询 → 战略指导 → Worker 实现 → 完成
                     → 否 → 直接执行 → 完成

证据

• 证据等级：新兴（emerging）。
• 有价值发现：Sourcegraph 生产验证，对比全 frontier 方案省了约 90% 成本；学术基础来自模型级联研究（FrugalGPT，最高 98% 成本下降且质量持平）。
• 未验证：最优 Oracle 调用阈值因应用而异。

怎么用

• 开发环境、复杂编码任务、架构决策、初始方案失败的调试会话。
• 文献里也叫模型级联（model cascading）、弱-强模型路由、层级模型系统。

取舍

• 好处：frontier 模型用得省；复杂问题解决能力强；专业化的"AI 团队"打法。
• 代价：多一层编排复杂度；模型切换有潜在延迟；Oracle 调用逻辑要仔细设计。

模式二：多模型编排（Multi-Model Orchestration for Complex Edits）

问题

单个大语言模型再强，也不一定适合复杂操作里的每个子任务。多文件代码编辑这种任务，理解广阔上下文、生成精确代码、应用编辑，可能各自需要专门的模型能力。

方案

用一个多模型流水线或编排，每个模型专门负责复杂任务的不同部分。 不同模型擅长不同的认知任务，专门化胜过通用化。对代码编辑，可以是：

1. 检索模型：从代码库收集相关上下文。
2. 大型智能生成模型（如 Claude 3.5 Sonnet）：理解用户意图，基于检索到的上下文生成主要代码修改。
3. 其它自定义或更小模型：跨多个文件精确应用生成的编辑，或做细粒度调整。

模型之间只传提炼后的结论，不传完整对话历史。 这降 token 成本、保持清晰的阶段边界。协调地利用不同模型的优势，比单个模型更稳健、更有效。

用户请求: 多文件编辑 → 检索模型: 收集上下文 → 主生成模型: 生成编辑 → 编辑应用模型: 跨文件应用 → 编辑后的代码库

证据

• 证据等级：生产验证（validated-in-production），来自 Aman Sanger（Cursor）。
• FrugalGPT（2023）：模型级联实现成本下降；RAG（Lewis 等人，2020）：检索和生成分离提升表现。

怎么用

• 任务需要规划、执行、回退之间有显式控制流时用。
• 先在一个高流量工作流上用，再推广到所有 Agent 车道。
• 为每个阶段定义负责人，失败才能快速路由和恢复。
• 模型阶段之间只传提炼后的结论，不传完整对话历史。

取舍

• 好处：改善多步工作流的协调；减少隐藏控制流；用"合适大小的模型选择"做成本优化。
• 代价：编排复杂度增加，要调试的状态更多。

模式三：预算感知路由（Budget-Aware Model Routing with Hard Cost Caps）

问题

Agent 系统常常默认把每个请求路由到最强模型，悄悄抬高成本，负载高了还降吞吐。提示词里的软预算指导没用，因为模型选择发生在控制代码里，不在语言输出里。团队需要确定性的护栏：困难任务保住质量，常规工作防止 token 花到失控。

方案

引入一个带显式预算契约的路由层，对每个请求、用户、工作流车道设硬上限。

关键要素：

• 分层模型目录（small、medium、frontier），带能力元数据。
• 策略引擎：每次调用前算最大允许花费。
• 确定性回退规则：选定模型会超预算时怎么办。
• 质量覆盖路径：安全关键或高价值工作流可以升级。

典型流程：

1. 分类任务复杂度和风险。
2. 分配预期的 token 信封和最大美元预算。
3. 选满足必需能力的最便宜模型。
4. 每个模型/工具步骤前强制硬上限。
5. 只有客观信号证明额外成本值得时才升级。

级联路由：先试最便宜且够用的模型；质量门不过就升级到更强的。用人类偏好数据训练的学习式路由策略可以在尊重预算约束的同时提高选择准确率。

budget = policy.max_cost(task_type, user_tier)
candidate = router.pick_model(task_features, budget)

if estimate_cost(candidate, context) > budget:
    candidate = router.next_cheaper(candidate)

result = call_model(candidate, context)
if quality_gate.failed(result) and policy.can_escalate(task_type):
    result = call_model(router.next_stronger(candidate), context)

证据

• 证据等级：成熟（established），来自 Codex（OpenAI）。
• 学术基础：FrugalGPT（Stanford，2023）、RouteLLM（ICLR 2024）、xRouter（2025）。

怎么用

• 模型账单涨得比产品价值快时用。
• 从高流量、质量目标可衡量的工作流开始。
• 加路由遥测：选定模型、估算成本、实际成本、升级原因。
• 定义超上限的硬失败行为（延迟、部分回答、或转人工）。

取舍

• 好处：花费可预测；容量规划更好；升级策略清晰。
• 代价：控制面复杂度更高；分类弱的话，困难请求可能被配到过弱的模型。

模式四：按模型性格分模式（Agent Modes by Model Personality）

问题

不同 AI 模型有根本不同的性格和工作风格。把所有模型一视同仁、期待它们表现一样，结果就是次优。用户期待一致的界面，但 Opus 4.5 这类模型"爱扣扳机"，想立刻跑命令；GPT-5.2 这类模型"懒"，喜欢先做彻底研究再行动。

方案

为每个模型的性格设计不同的 Agent 模式，而不是把所有模型塞进一个交互模式。每种模式有自己的：

• UI/UX 模式（字体、提示词长度指引）。
• 工具配置。
• 预期设定。
• 工作风格。

关键洞见：不是模型选择的事，是"不同工作方式"的事。

识别出的模型性格：

模型	性格	工作风格	最适合
Claude Opus 4.5	爱扣扳机、互动	跑命令、问问题、快速反馈循环	快速往返、交互任务
GPT-5.2	懒、彻底、深度研究者	跑 45 分钟以上、广泛研究、带回全面结果	边界清晰的问题、大任务、找信息

实现机制：

• 系统提示词：每种模式定义性格特定的指令。
• 温度/采样：低（0.1-0.3）做一致受控模式；中（0.4-0.7）平衡创造力；高（0.7-1.0+）做创意模式。
• 工具配置：模式特定的权限集和约束。

模式差异化策略：

1. 视觉/UI 差异化：不同模式不同字体；不同提示词长度指引（Deep 模式最少 100+ 字）；让它"感觉像发短信 vs 写信"。
2. 工具配置：Smart 模式用优化快速执行的工具；Deep 模式用优化彻底研究的工具（比如不要用户反馈问题工具）。
3. 预期设定：Smart 模式"看着 Agent 干活"；Deep 模式"派出去，60 分钟后回来查"。

AMP 的例子： 三个模式。Smart 模式用 Opus 4.5 做交互助手活；Rush 模式用 Haiku 做快而不太聪明的任务；Deep 模式用 GPT-5.2 做彻底研究和自主工作。团队刻意不做"模型选择器"下拉框，而是把它们呈现为不同的工作模式。

证据

• 证据等级：中（medium），来自 AMP（Thorsten Ball、Quinn Slack）。
• 有价值发现：行业平台用系统提示词和温度实现性格模式（Anthropic：Normal/Concise/Explanatory/Formal；OpenAI：Default/Cynic/Robot/Listener/Nerd）；多 Agent 框架（AutoGen、CrewAI）通过 system_message 和 backstory 参数支持基于角色的性格配置。
• 未验证：性格模式随模型演进的长期稳定性。

怎么用

实现清单：

• 内部测试识别你技术栈里的模型性格
• 模式名描述工作风格，不是模型名
• UX 差异化，让每种模式感觉不同
• 按模式配工具，优化模型的强项
• 设定用户预期，说明什么时候用哪种模式

什么时候用哪种模式：

Smart 模式（Opus 类）： 快速配置任务；快速迭代调试；需要频繁人工反馈的任务；"配好我的 .zshrc 并重载"这类任务。

Deep 模式（GPT-5.2 类）： 边界清晰的问题；需求明确的大任务；研究和信息收集；"去查这个部署问题"这类任务。

提示词差异：

# Smart 模式提示词
style: 对话式
length: 短到中
feedback: 快速、交互

# Deep 模式提示词
style: 详细规格
length: 长（建议 100+ 字）
feedback: 最少、结尾批量

在文本框里传达预期的挑战："全是文本框，当它全是文本框时，真的很难在文本框里传达预期。"根本挑战是：不同模式需要根本不同的用户预期，但 UI（一个文本框）看起来一模一样。解法：视觉差异化（字体、颜色）、显式指令（"Deep 模式最少 100 字"）、UI 里的模式特定指引。

取舍

• 好处：为每个模型强项优化，比一刀切结果更好；用户预期清晰，知道怎么和每种模式互动；减少挫败感，用户不用和模型的自然倾向对着干；结果更好，不同模型走不同路径达到同样好的结果。
• 代价：复杂度增加，多种模式要维护和文档化；用户困惑，有些人就想要"最好的模型"；模型演进风险，新版本性格会变；测试开销，每种模式要独立验证。

四个模式怎么选

场景	推荐模式
常规活 + 偶尔大决策，想省 frontier 成本	Oracle 与 Worker
复杂任务拆多段，每段配专门模型	多模型编排
账单失控，要硬成本上限	预算感知路由
模型性格差异大，要不同工作方式	按模型性格分模式

四个模式是模型路由的四个打法：Oracle/Worker 按"任务难度"分两档，多模型编排按"任务阶段"分流水线，预算路由按"预算"加硬上限，性格模式按"模型性格"分工作方式。可以叠加：用预算路由管成本，用 Oracle/Worker 管分工，用性格模式管交互。

实践清单

• 两档分工：便宜 Worker 干批量活，贵 Oracle 只在卡住/大决策时出场
• 复杂任务拆流水线：检索 / 生成 / 应用各配专门模型，阶段间只传提炼结论
• 模型目录分档（small / medium / frontier）+ 能力元数据
• 路由层对每个请求/用户/车道设硬成本上限，选满足能力的最便宜模型
• 级联路由：便宜模型质量门不过再升级，记录升级原因
• 加路由遥测：选定模型、估算成本、实际成本
• 识别模型性格，模式名描述工作风格不描述模型名
• 每种模式配自己的提示词、温度、工具配置、预期设定
• 别做"模型选择器"下拉框，呈现为不同的工作模式

本章小结

• Oracle 与 Worker：Worker 干活、Oracle 咨询，省约 90% 成本。
• 多模型编排：检索 / 生成 / 应用各配专门模型，阶段间只传结论。
• 预算感知路由：硬成本上限 + 级联升级，花费可预测、质量不塌。
• 按模型性格分模式：Smart / Deep 各配工作方式，别和模型的自然倾向对着干。
• 模型路由让"用哪个模型"从默认全用最强，变成按任务、按预算、按性格的精细决策。

下一章讲推理搜索结构：从学术谱系看推理增强。思维树、思维图、自发现、LATS。