现实场景 01
代码能力最强的模型，写中文政府报告却满是“AI 味”。
在代码 benchmark 上领先，不代表它擅长中文政务表达；套话、翻译腔和重复总结可能比技术错误更难直接量化。
LLM Agent。
大模型本身只完成一次推理或生成；Agent harness 把模型放进一个可持续运行的闭环，负责维护状态、组织上下文、执行工具、处理失败，并判断任务是否完成。
框架为了分析 Router，我们把现代 LLM Agent 功能性地拆成四层,以看清每次模型调用的输入从哪里来、结果会改变什么。
一个现代 LLM Agent 的四层运行结构
FIGURE 01 / FUNCTIONAL DECOMPOSITION
LAYER 01
任务与应用层
定义 Agent 要完成什么，以及什么结果可以被接受。
用户目标系统指令权限与安全策略预算完成标准
LAYER 02 · CONTROL PLANE
Agent Harness / Runtime
把一次请求变成可运行的多步过程。Harness 决定模型看到什么、何时调用工具、失败后是否重试，以及何时结束。
session / event logcontext builderagent looptool dispatchmemory / retrievalretry / recoveryverificationtermination
LAYER 03 · INTELLIGENCE
模型推理层
LLM 读取 Harness 组装的上下文，生成自然语言、结构化计划或 tool call。模型提出动作，但通常不直接执行外部操作。
理解与推理规划代码生成tool-call generation答案生成
LAYER 04 · EXECUTION
工具与外部世界
真正产生可观察结果和副作用：文件被修改、命令退出、网页变化、数据库更新、测试通过或失败。
Shell / code sandboxbrowser / searchfilesdatabaseexternal APIenvironment state
1 · OBSERVE系统读取；复杂感知可用 LLM
2 · COMPILE规则为主；压缩/检索可用 LLM
3 · INFER执行本轮核心 LLM 推理
4 · ACT工具执行；动作通常由模型提出
5 · VERIFY测试/规则，或 LLM verifier
6 · LOOP规则或 LLM 判断继续/终止
如何读这六步：它们是系统阶段，不代表固定的六次 LLM 调用。INFER 必然调用模型；OBSERVE、COMPILE、VERIFY 和 LOOP 是否调用 LLM 取决于任务与 Harness；ACT 的外部执行通常由工具完成，但动作往往由前一步模型生成。
同一个模型放进不同 context、tool 和 recovery 机制，可能产生完全不同的成功率与成本。
Agent 每个部分对 LLM 推理、代码、工具和上下文能力的需求不同提供了重新路由的机会。
Router 不替代 Harness；它利用 Harness 暴露的状态，在模型调用边界选择合适的完整模型。
第一问：LLM Router 是什么？
本文定义LLM Router 是位于应用或 Agent harness 与模型服务之间的决策层：它既可以决定请求落到哪个服务端点，也可以选择由哪个完整模型处理，还可以在 Agent 运行过程中决定何时保持或重新选择模型。
本文的研究范围包含下面三个相互衔接的层次：服务入口决定“到哪里调用”，完整模型路由决定“调用谁”，Agent 路由进一步决定“沿轨迹何时继续使用或重新选择”。三者共同决定一次 Agent 任务的成功率、成本与延迟。
SCOPE 01 · GATEWAY ROUTING
同模型，选 provider / region
优化可用性、吞吐、价格或数据驻留；也决定故障切换、网络延迟与缓存能否延续。模型能力通常不变。
SCOPE 02 · FULL-MODEL ROUTING
多个完整模型之间选择
决定由 GPT、Claude、Gemini、DeepSeek 等哪组完整权重处理请求，是能力—质量—成本权衡的核心层。
SCOPE 03 · AGENT ROUTING
Agent 执行中，决定何时保持或切换模型
根据工具反馈、错误、剩余预算、cache 和当前执行阶段，继续使用当前模型，或切换、升级、回退到其他完整模型。
研究边界：上面三层都属于本文讨论的 Router 系统；本研究明确排除 MoE 内部 token-to-expert、Tool Router、RAG/Memory Router、多 Agent role selection、speculative decoding与动态层跳过。相邻方向可以提供理论参考，但不能混称为完整模型 Router。
第二问：为什么需要 Router？
因为“最强模型”“最便宜模型”和“当前最合适的模型”通常不是同一个概念。成本不仅是调用费用，也包括任务完成时间。要让 Router 真正产生价值，还需要下面四个条件同时出现。
01 · MODEL TRADE-OFFS
不同模型各有所长，调用代价也不同
没有一个模型能同时在推理、代码、工具使用、长上下文、速度、价格和隐私等方面全部占优。
02 · CHANGING BEST CHOICE
任务内需要出现“最佳模型变化”
简单步骤可能由便宜模型完成，复杂推理或失败恢复可能需要强模型；但这种阶段性反转是动态 Agent Router 必须实测的前提，不能预先当作事实。
03 · OBSERVABLE SIGNALS
系统必须能够判断当前更适合哪个模型
Prompt、执行历史、工具结果或验证状态，需要包含足以预测各候选模型成功率和成本的信号；否则 Router 只能猜测。
04 · NET SYSTEM SAVINGS
选对模型带来的收益必须超过路由开销
节省模型费用还不够；扣除 Router 计算、模型切换、cache 丢失、上下文重传和失败恢复后，整个任务仍需更便宜或更快。
推断前两个条件说明“存在 Oracle 空间”，第三个条件决定能否学习，第四个条件决定系统是否真正节约成本。只证明模型价格不同，无法证明 Router 有净价值。
Router 的必要性不能由厂商数量证明：真正需要验证的是，不同模型是否会在任务或执行状态上各有胜负，以及扣除路由与切换开销后，动态选择是否仍优于固定使用一个模型。
Router 能否节约成本，要分别看一次调用和一项完整任务。
一次调用层决定当前 LLM request 交给哪个模型；完整任务层决定 Agent 在多轮推理和工具交互中采用什么模型策略。前者衡量一次响应，后者衡量一项任务能否以更少费用和时间成功完成，不能直接互相替代。
LEVEL 01 · LLM REQUEST
一次调用：为当前请求选择模型
输入主要是 prompt 与本次可见 context；路由当前请求，不观察后续 Agent 执行轨迹。
质量：本次回答或调用是否正确价格：本次 input、cache 与 output 费用时间：TTFT 与 request E2E latency
LEVEL 02 · AGENT TASK
完整任务：为多轮执行选择模型策略
一个任务可能包含多次模型调用、工具反馈、重试和恢复；模型可以固定，也可以在执行中切换。
质量：外部 verifier 判断任务是否成功价格：全部调用、工具、重试与切换费用时间：task wall-clock 与 time-to-success
一次调用层：同等准确率下，可以减少模型调用费用
FIGURE 02 / FRUGALGPT TABLE 3
最佳单模型成本FrugalGPT 达到同等准确率的成本
HEADLINES
−98.3%
$33.1 → $0.6matched accuracy
OVERRULING
−73.3%
$9.7 → $2.6matched accuracy
COQA
−59.2%
$72.5 → $29.6matched accuracy
AGNEWS
−75.4%
$64.6 → $15.9matched accuracy
SCIQ
−52.3%
$132.4 → $63.1matched accuracy
完整任务层：模型策略可同时提高成功率、缩短总时间
FIGURE 03 / TRACE-ROUTER TERMINAL-BENCH
固定使用 27B 模型TRACE-Router，α = 0.75
ALWAYS 27B
270 s
39.7% resolved
TRACE-ROUTER
172 s
46.8% resolved
−36%作者报告的平均 task wall-clock 变化
+7.1pp任务 resolved rate 同时提高
48Terminal-Bench matched tasks
Agent loop 会放大成本：多做几轮，就多次读入上下文
FIGURE 04 / UNPUBLISHED LOCAL EVIDENCE
MemoryCraft 不研究模型 Router。它在相同任务、memory store、ingestion 与预算下，只改变“由谁决定检索”，因此可用来观察 Agent 控制方式如何改变完整任务的调用次数与输入量。
01 · 只改变控制方式
谁决定何时检索？
Harness-issued
Harness 按固定协议构造并执行检索。
Harness 按固定协议构造并执行检索。
Agent-issued
LLM 在执行过程中自行决定并生成检索。
LLM 在执行过程中自行决定并生成检索。
02 · Agent-issued 相对 Harness-issued
模型轮次与输入量同时增加
MemOS
3.7×模型轮次
2.9×input tokens
Supermemory
3.1×模型轮次
2.5×input tokens
03 · Agent-issued 任务内
绝大多数 token 用于输入
< 1%三个系统的 output 仅占计量 token 的 0.65%–0.66%；其余主要是 cache-miss 与 cache-hit input。
与 Router 的关系：便宜模型若导致更多思考轮次、检索和恢复，就会反复读入上下文；因此“一次调用更便宜”不保证“完整任务更便宜”。Agent Router 的账本必须记录物理调用次数、输入重读与 cache 状态。
综合推断FrugalGPT 说明一次请求选对模型可以减少调用费用；TRACE-Router 说明完整任务的模型策略可能同时改善成功率和完成时间；MemoryCraft 则提示多轮执行会累积额外调用与上下文重读。因此，一次调用更便宜、更快，并不等于 Agent 任务的总费用更低、完成时间更短。
Agent Router 要核算的是完整任务成本，而不是 token 单价。
完整任务的成本按来源分别记录。每一项同时保留实际费用和经过时间，再与任务最终是否成功对应起来。
每次实际发给模型的请求，包括失败但已经消耗资源的 attempt。
价格：cache miss/read/write、input、output、reasoning token，本地 GPU 与能耗时间：queue、TTFT/prefill、decode/TPOT 与网络等待
决定选谁以及判断结果是否可接受所增加的计算。
价格：Router 的 CPU/GPU/token，Judge、verifier、profile 与在线校准时间：路由决策、探测候选、Judge/verifier 的额外等待
模型请求之外，为推进任务或恢复外部状态发生的实际操作。
价格：工具与外部服务、存储、数据库、环境重置等支出时间：工具执行与等待、timeout、环境回滚和恢复操作
从当前模型或 provider 转移到另一执行路径带来的额外负担。
价格：cache loss 后的重复 token、上下文重传、模型加载与驻留时间：序列化、重新 prefill、queue、网络与 handoff
价格侧怎么报告汇总所有物理 attempt 与外部服务支出，并报告 cost per successful task；失败任务产生的支出不能删除。
时间侧怎么报告报告 time-to-success 的 p50/p95 与 deadline success；只报成功任务的平均 latency 会低估失败和恢复。
避免重复计量：一次失败模型调用的 token 和时间记在“模型推理”；retry/recovery 用作原因与阶段标签，只有新增工具、调用或等待才计入额外成本。共享的训练与 profile 构建费用应单独披露摊销范围，不能随意除以任务数。
错误的不对称性：over-routing 通常只是多付一次强模型费用；under-routing 可能造成不可逆动作、污染状态或多轮恢复。因此 Router 不能只训练“最便宜模型分类器”，而应预测成功率、成本、延迟与失败风险，并用成功率下置信界约束选择。
主要云平台的类 Router 产品
公开产品模型选择已经成为云平台能力，但“Router”并不都在解决同一个问题：有的选择完整模型，有的选择推理档位，有的只负责 provider 故障切换。下表只呈现最关键的差别。
| 平台 / 产品 | 选择什么 | 何时选择 | 本页归类 |
|---|---|---|---|
OpenAI GPT-5 system router | 快速回答、深度推理与 mini | 每次响应 | 内部模型 / 推理档位选择 封闭产品 Router，并非开放的多模型 Agent Router。[V1] |
Microsoft Foundry Model Router | GPT、Claude、DeepSeek 等完整模型 | 每次请求；Agent 中每 turn | 完整模型选择 公开产品中最接近 per-turn Agent Router。[V2] |
Google Cloud Vertex AI Model Optimizer | Gemini 模型与 intelligence level | 每个 prompt | Prompt Router 用户先指定 Cost / Balanced / Quality。[V3] |
AWS Bedrock Intelligent Prompt Routing | 同一模型家族内的两个模型 | 每个 prompt | Prompt Router 按质量阈值选择，不读取 Agent 历史。[V4] |
OpenRouter Auto Router | 跨厂商完整模型与 provider | 按 prompt；可保持 session sticky | 模型选择 + 连续性 兼顾 cache 与 failover，但不读取 verifier 状态。[V5] |
Cloudflare AI Gateway Dynamic Routing | 模型或 provider endpoint | 每次请求 | 规则 / 流量路由 面向预算、配额、分流与 fallback。[V7] |
腾讯云 模型路由（内测） | 同一模型的不同供应商 | 请求失败时 | 可用性路由 解决故障切换，不按任务能力选模型。[V8] |
阅读结论平台公开产品主要覆盖 prompt-level 模型选择、session stickiness 和 provider failover；读取工具结果、错误恢复与外部验证状态的 Agent Router 仍少见。已审阅的 Anthropic、DeepSeek 与阿里云官方资料主要提供人工选型或模型目录，尚未核验到其第一方公开自动完整模型 Router；这不代表内部系统不存在。非云产品的 vLLM SAAR 作为 session-aware 系统先例放在后文讨论。[V6][V9][V10][V11] 完整结构化数据：CSV。
公开产品真正形成的共识
✓
一个 endpoint，背后多个模型
OpenAI、Microsoft、Google、AWS 和 OpenRouter 都在隐藏或简化模型选择。
✓
质量—成本不是固定权重
Balanced/Cost/Quality profile 或可调 threshold 已成为标准产品接口。
△
session continuity 只被部分系统正视
OpenRouter stickiness 与 vLLM SAAR 明确处理；许多 prompt router 仍逐请求独立。
×
公开产品很少决定“什么时候重新选择模型”
系统通常预先固定为 per-prompt、per-turn 或 sticky session，重新选择的时机很少由 Router 学习。
Router 已经从单次请求走进 Agent 轨迹，但研究问题还没有闭合。
前文说明了三件事：模型能力与价格存在差异，Agent loop 会改变任务成本，云平台也已把模型选择产品化。结合已核验论文，当前研究大致推进到下面四步。
当前成熟度判断：“选择哪个模型”已经覆盖 prompt、task、turn、call 和 workflow node 等多种粒度；trajectory-aware、history-aware、harness-native 与 session-aware 也已有明确先例。尚未充分解决的不是再增加一种固定粒度，而是判断什么新信息值得触发下一次模型选择，以及扣除全部系统代价后是否仍有净收益。
01 · PROMPT ROUTING
一次请求选模型
FrugalGPT、RouteLLM 与云产品已经证明 prompt-level 质量—成本选择具有价值；决策通常在请求开始时完成。[P1][P2]
02 · TASK COMMITMENT
整任务固定或条件升级
TRACE-Router 按任务固定模型，SWE-Router 让便宜模型探索固定 K 轮后决定是否升级；重决策时机仍由系统预设。[P5][P7]
03 · TRAJECTORY ROUTING
每 turn 或 call 读取历史
MTRouter、TwinRouterBench 与 Harness-Native 开始使用对话历史、工具结果、错误和 verification；默认仍在每 turn/call 重新决策。[P6][P3][P4]
04 · SYSTEM CONTINUITY
把切换后果放进策略
HyDRA 与 vLLM SAAR 开始考虑 session stickiness、cache、handoff 和 provider state，说明频繁切换并不是免费动作。[P8][V6]
评测没有同步跟上：很少有工作算清 Router 是否让 Agent 更快完成任务
FIGURE 05 / TIME EVIDENCE AUDIT
TRACE-Router 等工作已经报告积极的任务级结果，但单个案例不能说明整个领域是否形成完整证据。为此，我们审计了本页纳入的 18 项主要 Router 与直接邻近工作，检查它们从单次响应到成功完成任务分别测到了哪一层。
CALL · 首 TOKEN 时间模型请求到首个 token，衡量响应何时开始。
CALL · 单次请求总时长模型请求到最后一个 token，衡量一次调用。
TASK · 任务总时长Agent 从开始到终止，包含工具、重试与多轮调用。
TASK · 成功完成时间直到外部 verifier 确认成功，并把失败任务纳入统计。
如何读这些数字：“3 / 18 项”表示本页选定的 18 项完整模型 Router、Agent Router 与直接邻近系统中，有 3 项明确报告该类证据。它衡量的是测量覆盖，不是性能胜率；纳入清单与逐项判定见 [A1]。
A · 是否测到了用户真正等待的任务时间？
3 / 18 项明确实测 Agent 完整任务的 wall-clock
2 / 18 项报告任务级 p95/p99，而不只报告均值
0 / 18 项以外部验证成功为终点，并纳入失败任务
B · 是否算清了 Router 带来的额外等待？
2 / 18 项实测 Router 自身增加的决策时间
0 / 18 项完整拆分重试与错误恢复耗时
0 / 18 项单独归因跨模型切换与 cache loss 耗时
尚未被完全回答的问题
下一页将逐项说明已有方法如何回答、哪些假设尚未验证，以及哪些看似新颖的主张其实已有先例。
01
何时应该重新选择模型？
task、turn、call、tool observation 或 milestone 哪个粒度最合适？重决策时机能否成为策略变量，而不是固定超参数？
02
哪些状态真的带来新信息？
Prompt、工具结果、测试、错误和恢复状态中，哪些会改变最佳模型？哪些只是重复已有上下文？
03
动态选择是否产生净收益？
模型费用、Router、Judge、重试、queue、cache loss 与 handoff 全部计入后，是否仍优于最佳 task pinning？
04
局部选择是否造成终局改善？
观察日志混合了任务难度和策略选择；怎样用同状态、同世界、共同 continuation 的反事实执行获得可靠标签？
05
Router 应该看原始轨迹还是结构化状态？
完整历史信息多但昂贵；压缩状态更便宜，却可能丢失决定模型选择的关键信息或引入教师偏见。
06
方法能否跨模型与 Harness 泛化？
固定 model ID 分类器容易随模型池过时；改变 workflow 的方法又难与固定 Agent Router 公平比较。
下一页的内容：按决策粒度、观察状态、Router 类型、训练标签、成本口径和是否改变原 workflow，逐项拆解当前工作的内容、方法、结果与局限。继续阅读 Page 02 →
可以得到的初步判断
PAPER EVIDENCE → SYNTHESIS → OPEN QUESTION
已有论文表明“模型可以动态选择”，但还没有回答“Agent 应在何时重新选择”。
论文分别给出的证据：FrugalGPT 与 RouteLLM 说明，不同请求适合不同模型，选择模型可以改善质量—价格权衡；MTRouter 与 Harness-Native 进一步说明，对话历史、工具结果和错误状态能够进入 Agent 的模型选择；HyDRA 与 vLLM SAAR 则提醒我们，保持当前模型可以保留 cache 与会话连续性，切换并不是免费的。[P1][P2][P6][P4][P8][V6]
把这些结果放在一起：Agent 的中间状态可能改变最佳模型，但“看到更多状态”不等于“每一步都值得重新路由”。现有方法多把重决策时机预先固定为 task、固定 K 轮、每 turn、每 call 或特定系统事件；与此同时，跨模型切换还可能增加 Router 等待、上下文重读、cache loss 与失败恢复成本。已有论文分别覆盖了其中一部分，却尚未把信息收益与这些代价放在同一个任务级评测中比较。
因此得到的研究判断：下一步不应只是再训练一个“选择哪个模型”的 Router，而应先检验：工具反馈、验证结果或错误恢复等新事件出现后，重新选择模型带来的预期收益，是否足以覆盖切换的价格与时间代价。只有这个条件成立，研究“何时重新开放模型选择”才具有独立价值；否则，更简单的整任务固定或固定事件路由就已经足够。
来源与证据状态
- [P0] Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023；用于说明 reasoning、action 与 observation 交替的基本 Agent loop。
- [P1] Chen, Zaharia & Zou. FrugalGPT. TMLR 2024；图 02 重录其 Table 3。
- [P2] Ong et al. RouteLLM. ICLR 2025。
- [P3] TwinRouterBench. arXiv preprint, 2026；官方代码。
- [P4] Agentic Routing: The Harness-Native Data Flywheel. technical report/preprint, 2026；OpenSquilla。
- [L1] MemoryCraft local manuscript. 未正式发表投稿稿，公开网页版不提供原稿；仅作内部方法学证据，不能写作已发表结论。
- [V1] OpenAI GPT-5 System Card.
- [V2] Microsoft Foundry Model Router concepts；Agent integration。
- [V3] Google Cloud Vertex AI Model Optimizer announcement；pricing。
- [V4] AWS Bedrock Intelligent Prompt Routing.
- [V5] OpenRouter Auto Router；Provider Routing。
- [V6] vLLM Session-Aware Agentic Routing. 作者报告的 synthetic/live 结果只在其公开条件内陈述。
- [V7] Cloudflare AI Gateway Dynamic Routing.
- [V8] 腾讯云模型路由产品介绍.
- [V9] Anthropic: Choosing the right model；model IDs。
- [V10] DeepSeek Models & Pricing；reasoning model guide。
- [V11] Alibaba Cloud Model Studio models；pricing。
- [H1] DeepSeek Harness official repository, fixed commit 47f9438. 用于核验 session event、model-request hook、工具事件与 token/cache 计量能力。
- [P5] Raj et al. TRACE-ROUTER: Task-Consistent and Adaptive Online Routing for Agentic AI. arXiv preprint, 2026；图 03 重录正文 §4.2 的 Terminal-Bench 均值。
- [A1] RouteCraft local latency-evidence audit. 2026-08-17；逐项核对 18 项主要工作对 call、task、tail、router、queue/tool、retry/recovery 与 switch/cache 时间的覆盖，并链接论文原文。
- [P6] Zhang et al. MTRouter. ACL 2026 long paper；官方代码。
- [P7] Son et al. SWE-Router. ICML 2026 Workshop preprint；已核验官方 Hugging Face 组织，源码仓库未核验。
- [P8] Garg et al. HyDRA. arXiv preprint, 2026；官方代码未核验。
AI-assisted research disclosure：来源检索、比较、数据转录和页面撰写使用了 AI 辅助；关键事实以论文原文、官方文档或本地原稿核验。厂商文档会变化，正式发表或采购决策前应再次核验。