--- layout: post.njk source: https://yage.ai/share/agentic-multi-model-routing-20260729.html speaker: yage.ai title: 多模型路由进入 Agent 会话之后 date: '2026-07-29' summary: 文章探讨了多模型路由（Model Routing）在Agent连续对话和工具调用场景中的智能难题与工程瓶颈。核心问题在于，当路由从单轮问答扩展到多轮会话时，系统需要重构认知视野以理解完整任务进度，并面临历史格式不兼容、缓存失效以及隐式状态迁移等工程限制。文章提出了固定强模型、隔离子任务和有状态路由三种分化的工程路线作为应对困境的解决方案。 area: PAI category: ai-workflow tags: - model-routing - agent-workflow - stateful-router - inference-serving people: [] companies_orgs: [] products_models: - OpenRouter Auto Router - LiteLLM media_books: [] draft: true status: evergreen --- 多模型路由（Model Routing）的出发点很直接：在同一个 AI 系统里组织起能力、速度与价格不同的模型，由 Router 根据请求动态挑选执行者。强模型与小模型的 Token 单价通常相差 10 到 50 倍，速度也相差数倍。如果路由能准确判断，把简单的机械工作切给低成本小模型，只把复杂决策留给强模型，系统就能在保持回答质量的同时降低成本与延迟。用较低成本获得相近的综合体验，吸引了大量研究与工程尝试。 学术界与创业团队对此展开了诸多尝试。Stanford 提出的 FrugalGPT 与 UC Berkeley / LMSYS 发布的 RouteLLM 演示了在标准单轮问答基准上做成本与质量权衡；Martian（获得 900 万美元融资）、Not Diamond（获得 230 万美元种子轮融资）与 Unify（在 YC 孵化并获得 800 万美元融资）则尝试将动态选择做成独立服务。在开源工具层，OpenRouter Auto Router 与 LiteLLM 等网关路由也成为了常见的入口组件。 不过，这套在单轮问答上顺畅的思路，一旦进入 Agent 连续对话与工具调用场景，落地阻力就会明显增大。这篇文章就来探讨一下：这个看似直接的 idea，为什么在实际 Agent 工作流里总是步履维艰？它的智能难题与工程瓶颈究竟在哪里？ ## 单轮路由的逻辑与其在 Agent 场景的失效 要理解问题的根源，首先需要回顾早期模型路由的工作机制。 以往的主流方案大多把决策放在单次请求（Single-turn Query）上。Router 拿到当前的 prompt，评估其语义难度或分类意图，直接输出一个 model ID。这套机制在处理彼此独立的问答、翻译或信息抽取时相当顺畅。因为每一次请求都是孤立的，上一轮用了什么模型、下一轮用什么模型，彼此之间没有任何约束。 但在连续修改文件、调用工具并在多轮对话中推进同一项任务时，切换模型就不再只是挑选单个执行者；此前积累的上下文、工具状态与模型专属缓存，都会随这次选择一起发生改变。 vLLM Semantic Router issue #1439 记录过一个具体的失效案例：用户在做一项复杂的 Go 代码重构任务，强模型在前几轮顺畅推进。到了第四轮，用户只说了四个英文单词：looks good, commit it。 Router 只凭这几个词的语义评估难度，判断既短又不需要复杂推理，就把请求切给了 qwen2.5:0.5b。该模型回复了客套话，没有继续推进提交任务。问题不在于这四个词本身的语义难度，而是它必须承接上一轮刚建立好的任务状态。即便修正了对 commit it 的难度评估，只要 Router 依然只看最新一条消息，类似的失效仍会发生。 ## 智能挑战：路由器视野的维度重构 从 commit it 的失效可以看出，当路由从单轮问答进入多轮会话，系统首先面临的是认知视野的重构——如果路由器无法看清完整任务进度，算法就无法做出合理的选择。当 commit it 进入路由层，系统能看到多少上下文、依靠哪些信号做出判断，以及能执行哪些动作，会直接改变最终的路由决策。 从观察范围、判断依据和输出动作三个维度比较模型路由 首先限制路由的是观察范围。只看单条 query 时，系统只能获取当前这句输入，无法了解完整任务进度。不知道此前使用了什么模型、工具调用推进到了哪一步，路由决策就容易脱离真实上下文。拉长观察范围到多轮历史，增大的不只是输入 token 数，而是让路由能把当下请求与之前的任务状态连起来。 其次是判断依据的落差。Per-request router 习惯评估当下的语义难度或文本相似度。到了有状态路由，决策还得算上会话证据：上一轮由哪个模型处理、当前任务是否处于工具执行阶段，以及此时切换模型是否划算。 最后是输出动作的拓展。早期路由主要输出一个 model ID，或决定是否升级模型。后续方案拓展到了选择处理路径或协同执行，但只要观察范围依然局限在当前 query 上，动作定义得再丰富，也回答不了现在能否安全切换。只有把会话状态纳入控制，路由输出才从单一的目标模型，扩展到保持当前模型、锁住当前阶段或另开子任务。 ## 工程挑战：会话中换模型的四个现实限制 理解了路由视野在智能层面的重构之后，紧接着面临的便是底层的物理瓶颈。即便路由器具备了看清上下文的智能视野，在实际会话中真正执行模型切换时，依然会被硬核的工程硬件制约卡住手脚。在会话中切换模型远不止传递上下文那么简单，每次触发模型切换，系统都必须面对以下四个具体的工程限制： 历史格式不兼容与分布外风险是切换时遇到的第一道障碍。一旦更换 Model ID，配套的 Prompt 格式和工具调用语法可能发生变化。对新模型来说，由其他模型生成的历史 transcript 不仅属于 out-of-distribution，甚至可能包含自己无法解析的工具格式或函数调用语法，导致后续生成直接崩溃。 缓存失效带来的重读开销则是经济上的隐形损耗。在长上下文任务中，Prompt Cache 是降低延迟与成本的关键。Anthropic 等服务商把 model_changed 直接列为缓存未命中的原因。切换模型后，目标模型必须重新 Load 和解析漫长的前缀历史，导致切换首轮的开销陡增。中途频繁切换节省的微小成本，很容易被缓存未命中的重读开销完全抵消。 不可见的隐式状态无法迁移进一步加剧了断裂。可见的 message transcript 未必包含全部运行状态。Claude 的 Extended Thinking 签名、OpenAI 兼容接口的 reasoning items 以及 Gemini 的 thought signatures，都包含模型或 provider 专属的延续信息。官方只承诺相容路径，不承诺这些隐式思维链可以随意跨模型、跨 provider 平移。 多模态与工具产物的协调开销也是无法忽视的复杂负担。多模型决定由谁执行，多模态描述任务中流动的代码、截图或音频等工具产物。把不同模态切给专用模型时，如何验证并将不同模型产出的结构化结果无缝合回主任务，往往会带来远超单模型执行的额外工程胶水成本。 这些工程制约相互影响：切到更专长的模型可能改善眼前这一步，却带来缓存冷启动与状态迁移损耗；为了兼容历史而压缩上下文，又可能削弱新模型做判断所需的信息。 ## 领域现实：三条分化的工程路线 上层的智能视野重构与底层的工程制约缠绕在一起，使得动态路由在 Agent 场景下的理想算盘大打折扣。面对这种两难困境，目前业界并没有盲目推崇完全自主的动态路由，而是根据不同的取舍倾斜，分化出了三种不同的工程处理路线： 第一种是固定使用强模型（Best Fixed Model）。这是目前绝大多数生产级 Agent 的选择。最稳妥的策略往往是减少中途切换，将主会话自始至终固定在同一个最强模型上。虽然这会保留较高的 Token 费用，但能换来连续的 Prompt Cache 命中与明确的状态边界，完全避免了中途切换带来的不确定性与工程开销。 第二种是隔离子任务（Subagent Pattern）。Cursor 与 Claude Code 采用了这种解法：不在主会话中途动态切模型，而是把适合独立处理的工作交给拥有干净上下文的 subagent。它不要求新模型接管整段主会话，而是划出明确的子任务，通过结构化 handoff 传递必要信息。多模型协作依然发生，但状态边界在架构层被划得非常清晰。 第三种是由 Router 承担有状态切换（Stateful Router）。当任务路径无法预先固定、切换时机需要在运行中判断时，就需要 router 自己保存状态。vLLM Semantic Router 发布的 SAAR（Session-Aware Agentic Routing）尝试在路由层保存当前模型与任务阶段：工具调用尚未结束时先锁住模型；真正切换前，再检查状态能否迁移以及节省的成本是否足以覆盖冷启动。 围绕会话状态并列比较固定强模型、隔离子任务与有状态路由 ## 推理服务层的战略算盘与终局思考 分化的路线反映了应用层在面对路由瓶颈时的无奈与折冲。在看清了领域现实之后，一个自然的问题随之浮现：为什么像 vLLM 这类原本专注于单节点物理加速的开源推理引擎，会选择跨界入局做 Semantic Router 乃至提出 Mixture-of-Models（MoM）的构想？ 这源于其所在层级的物理位置优势。应用层 gateway 只能看到 prompt 语义，看不到底层 GPU 的 KV cache 分布与集群排队情况。处于 inference serving 层的 vLLM 能够获取物理缓存状态：若大模型的前缀缓存已在显存中，直接沿用大模型可能比切到小模型更划算。此外，单纯的单节点推理加速容易陷入同质化竞争，通过拓展集群调度（Production Stack）与路由控制层（Semantic Router），vLLM 尝试把模型选择、安全规则与会话连续性组合起来，向上提供一个统一的逻辑模型（Logical Model）抽象，避免被上层应用管道化。 但无论架构如何演进，最后依然要回到基线问题。正如 vLLM Semantic Router 团队在讨论多模型系统时提出的基线要求：多模型系统需要在近似相同的任务、预算、调用次数和延迟约束下，超过 best fixed model（最佳固定模型）。 状态管理、迁移和工具兼容带来的复杂度都要算进去，不能靠增加调用和重试抬高分数。如果固定使用一个强模型，总代价和成功率反而更好，那就应该选择固定模型。对独立、没有历史依赖的请求，按难度选择模型依然有效；到了有工具调用链和待完成 artifact 的 agent 工作负载，问题才会改变：不只是这条消息应该给哪个模型，还要评估此刻能否切换，状态怎么交接，是否更适合另开一个子任务。 looks good, commit it 是四个英文单词。router 读取积累的上下文和此前的决策，在保持当前模型、锁住阶段或另开子任务之间选择。为了给 Agent 选模型，我们最终又构建了一个 agent。而在投入更多复杂度之前，先回答净收益能否超过最佳固定模型，依然是最基础的参考线。