路由不是一次难度分类

发布边界：产品能力和公开案例绑定来源；通用控制面、检查点与副作用账本属于工程设计，不宣称为供应商内部实现。

摘要

生产模型路由不能被简化为一次 Prompt 难度分类。路由器首先应按隐私、区域、模态、上下文、工具与供应商策略构造可行域，再优化质量、延迟、成本和负载；长任务只在有限状态检查点重新决策，并通过幂等键、副作用账本和 fencing 防止切换产生重复后果。

关键词

模型路由、Hard Constraints、Checkpoint、Idempotency、LLM Gateway

目录

很多模型 Router 的原型都从同一个问题开始：先看一眼请求，预测它“简单”还是“困难”，简单请求交给便宜模型，困难请求交给强模型。这个设计对单轮、无工具、无副作用的问答可能成立，但它不是生产级 Agent 路由控制面的完整形式。生产任务的真实难度并不完全写在入口 Prompt 里，端点的队列、缓存和错误率也会在执行期间变化；更重要的是，数据驻留、允许模型、模态、上下文容量和写操作权限不是可以用低价格抵消的偏好，而是决定一条路径能否执行的硬条件。

因此，生产路由的目标不是永远挑到“最强”或“最便宜”的模型，而是在硬约束形成的可行域内，选择满足成功概率、完整任务成本和尾延迟目标的执行路径；当工具结果、端点状态或失败反馈改变剩余任务时，只在有限的、可审计的检查点重新决策。模型切换还必须继承结构化状态，并以幂等键、执行账本和检查点阻止重复副作用。

本文把公开产品事实与工程设计分开。标注为“产品事实”的内容来自截至 2026 年 7 月 24 日可访问的官方文档或研究文章；标注为“作者工程推导”的内容是基于这些事实给出的可实现控制面设计，不代表任何厂商已经提供同等能力。

一、入口的一次“难度预测”为何不够

把路由问题写成 route(prompt) -> model，隐含了四个不成立的假设。

第一，它假设任务难度是入口文本的静态属性。实际 Agent 任务常在检索、工具调用或环境观察后才暴露关键分支。一个看似简单的“更新客户地址”，可能在读取账户后发现跨地区数据、权限不足、重复记录或需要人工复核；一个看似复杂的调查任务，也可能因缓存命中和高质量工具结果迅速收敛。IBM Research 的公开文章把这类现象概括为：路由是系统优化问题，任务开始时未必能观察到全部难度，执行期间的工具、检索、合规和基础设施状态会改变后续选择。[^S06]

第二，它假设所有候选模型都可以被统一打分。生产系统中并非如此。某端点可能不在允许地区，某模型版本未获审批，某提供方不能接收该数据等级，某模型不支持当前模态、上下文长度或结构化工具协议。把这些条件写进一个加权分数，等于允许“足够便宜”或“足够快”抵消合规失败。这不是优化，而是越权。

第三，它假设端点状态在任务期间不变。推理端点的排队长度、缓存温度、吞吐、错误率和健康状态会持续变化。Envoy AI Gateway 的推理路由资料明确把 KV Cache 使用、排队请求、端点健康和性能视为实时选点信号；普通轮询无法表达这些状态。[^S11] 同一模型在两个部署上的能力相同，但完整任务的尾延迟和重试概率可能完全不同。

第四，它假设第一次失败只意味着“再试一次”。失败本身包含诊断信息：上下文超限说明当前压缩策略失败；工具返回权限错误说明计划不可执行；端点超时说明基础设施风险上升；低置信验证结果说明当前模型与任务阶段不匹配。继续沿用入口决策，会把新信息丢掉。无条件重放还可能重复创建订单、发送消息或扣款。

二、先区分 Router、Gateway、Load Balancer、Fallback 与 Agent Planner

这些能力经常被同一个产品打包，但职责不同。概念不清会直接导致权限和状态边界混乱。

组件核心职责不应承担的职责
Router根据任务约束、任务状态和端点状态选择模型、提供方、部署或推理配置直接执行业务写工具，绕过合规准入
Gateway统一入口、鉴权、配额、协议转换、策略执行、遥测和审计仅凭网络可达性推断任务语义
Load Balancer在能力等价的健康副本间分配流量，处理容量和可用性决定哪个模型更适合某个业务任务
Fallback主路径超时、错误或不满足预设条件后切换备用路径代替完整的任务状态迁移和副作用治理
Agent Planner分解目标，选择下一项语义动作或工具，并根据观察修订计划持有基础设施凭据，私自改变模型准入策略

官方文档也体现了这种差异。AWS Elastic Load Balancing 的基本对象是健康目标和流量分发；Kong AI Gateway 的 fallback 则在错误、超时或指定状态码出现后重试或转向其他目标。[^S12][^S13] Agent Planner 的典型研究范式如 ReAct，是让推理、动作和观察交替发生，以环境反馈修订下一步行为。[^S15] Router 关注的是“下一阶段在哪个受允许的执行点运行”，Planner 关注的是“下一阶段做什么”。

还要注意同名术语的产品语义可能不同。

**产品事实：Amazon Bedrock Intelligent Prompt Routing。**截至访问日，AWS 用户指南把该能力描述为一个无服务器端点，在同一模型族内的两个模型之间进行请求级选择；自定义 Router 的主要条件是 responseQualityDifference，并指定一个 fallbackModel 作为基准模型。当预测质量差异未达到条件时，文档描述为使用该 fallback 模型。这不是文档所定义的“模型调用失败后，带着任务状态继续执行”的运行时故障转移。[^S01][^S02][^S04]

该产品当前公开限制同样重要：文档称其主要针对英文 Prompt 优化，不能依据某个应用自己的线上表现数据调整决策，并提示专业化场景未必最优。[^S01] 支持页按访问快照列出 Amazon Nova、Anthropic Claude 和 Meta Llama 的若干具体型号，并要求同族路由；但同一官方站点的模型卡与示例存在不一致。因此，支持范围只能作为带日期的文档快照，部署时仍应通过控制台或 ListPromptRouters API 核验账户与区域中的实际可用项。[^S01][^S03][^S05] 这些是 AWS 产品边界，不能外推为所有 Router 的通用限制。

先构造硬约束可行域

三、可执行设计一：硬约束过滤先于软优化

**作者工程推导。**生产 Router 的第一步应是构造可行集合，而不是计算总分。设任务状态为 s，候选端点集合为 E，硬约束谓词为 H(e, s)，则：

F(s) = { e ∈ E | H(e, s) = true }

H 至少应覆盖以下事实：数据驻留与跨境规则；数据分类和提供方边界；允许的模型、版本与区域；输入输出模态；最大上下文和结构化输出能力；所需工具协议；租户隔离；端点健康；当前阶段是否允许执行副作用。延迟上限究竟是硬约束还是软目标，应由业务语义决定：例如实时语音的绝对超时可以是硬门槛，而一般后台任务的延迟通常适合优化。

伪代码如下：

candidates = registry.snapshot()
feasible = filter(candidates, endpoint => hard_policy(task, state, endpoint))

if feasible is empty:
    return fail_closed_or_manual_review(reason_codes)

frontier = pareto_frontier(
    feasible,
    predicted_success,
    expected_remaining_cost,
    predicted_tail_latency
)
return policy_select(frontier, task.sla, task.budget, task.risk)

这里有两个关键纪律。

其一，空集合必须显式失败、切换到获批的替代工作流或进入人工复核，不能选择“违规最少”的候选。路由日志还要记录具体拒绝原因，例如 REGION_DENIED、MODEL_NOT_APPROVED、CONTEXT_TOO_LARGE，以便审计和修正规则。

其二，成本、质量和延迟只在 F(s) 内优化。可以使用可解释规则、约束优化、Pareto 前沿、上下文 Bandit 或学习式 Router；算法不是重点。RouteLLM 展示了基于偏好数据在强弱模型间学习查询级路由，FrugalGPT 展示了级联调用以改善成本—质量折中。[^S08][^S09] 这些研究证明软优化方法具有空间，但并不替代准入控制，也不自动解决多步状态、端点健康和副作用问题。

为什么不能把硬约束与软目标混成一个加权分数？因为任何有限惩罚都可能被另一项足够大的收益抵消；不同量纲的归一化和权重会漂移；策略变更后很难解释某次违规为何“总分更高”；模型或价格更新还会意外改变合规结果。硬约束表达的是“是否允许”，软目标表达的是“允许之后选哪个”，二者属于不同决策层。

再优化软目标

四、完整任务成本会被缓存、队列、错误和工具结果改写

**作者工程推导。**路由时需要预测的不是单次模型调用价格，而是当前检查点之后完成任务的剩余成本：

Expected Remaining Task Cost
= uncached input + cached input/write + output
+ endpoint waiting and SLA penalty
+ expected retries and fallback
+ tools, retrieval and infrastructure
+ context compression and state migration
+ expected failure, compensation and human review

缓存会同时改变计费输入和首 Token 延迟。以 Amazon Bedrock Prompt Caching 的官方说明为例，命中依赖模型支持、缓存检查点和前缀匹配；工具定义、图像或前缀变化都可能让预期命中失效。[^S14] 因此 Router 不能只读取一个全局“缓存命中率”，而要估计当前任务前缀在具体模型、区域和缓存策略下的可复用性。切换模型可能失去已有缓存，迁移成本必须进入决策。

队列和端点健康改变的是尾部行为。较便宜的端点如果正处于排队高峰，可能增加超时、重试和升级概率，最终既更慢也更贵。错误率也不能只作为健康仪表盘上的平均值；应按模型版本、区域、任务段、错误类型和时间窗口分层。一个高频 429 与一个上下文格式错误需要不同处置。

工具结果会改变任务本身。检索可能提供足够证据，使后续可以降级到更轻模型；权限或数据冲突也可能把任务升级为需要更强推理或人工审批的路径。工具还产生不可丢失的外部事实和副作用记录。入口分类器看不到这些信息，因此只能给出初始先验，不能成为全程不可修改的决定。

长任务只在检查点换轨

五、可执行设计二：在状态检查点进行有限次升级

**作者工程推导。**动态路由不等于每个 Token、每个 Agent 步骤都重新选模型。IBM 的文章也指出，逐步路由会增加延迟和运行复杂度，而任务级一次路由开销较低。[^S06] 正确做法是预先定义少量“信息增益高、可安全切换”的检查点。

推荐的决策点包括：任务准入完成后；计划或验收条件首次结构化后；第一个能显著改变任务分支的检索或工具结果返回后；当前端点发生可重试错误、超时或健康恶化后；预算或期限越过阈值后；任何不可逆写操作之前。系统不应在已经提交外部副作用之后仅因模型分数变化而随意重放上一阶段。

每个检查点保存的不是上一模型的全部自然语言轨迹，更不是不可审计的隐藏推理，而是结构化 TaskState：

{
  "task_id": "...",
  "policy_snapshot_id": "...",
  "goal": "...",
  "acceptance_criteria": [],
  "data_class": "...",
  "region": "...",
  "completed_steps": [],
  "verified_facts": [{"ref": "artifact://...", "hash": "..."}],
  "tool_results": [],
  "pending_actions": [],
  "side_effect_ledger": [],
  "budget_used": 0,
  "deadline": "...",
  "route_history": [],
  "context_summary_version": "..."
}

重新路由时，先用最新任务状态重新执行硬过滤，再估计每个可行候选的剩余成功率、迁移成本和尾延迟。只有预期收益超过切换成本与不确定性余量时才切换。控制面还应设置最大切换次数、冷却窗口和迟滞阈值，防止两个端点因短时波动来回震荡。达到上限后，应执行预定义的终止、降级或人工接管策略，而不是无限重试。

一个最小状态机可以写成：

ADMITTED -> RUNNING -> CHECKPOINTED
CHECKPOINTED -> RUNNING        when current route remains valid
CHECKPOINTED -> MIGRATING      when re-route gain exceeds threshold
MIGRATING -> RUNNING           after state validation
RUNNING -> RECONCILING         when side-effect outcome is unknown
RUNNING -> COMPLETED | FAILED | MANUAL_REVIEW

这里的 RECONCILING 很关键。网络超时并不能证明外部写操作失败，可能只是响应丢失。若直接升级模型并重放工具，系统会制造重复订单、重复通知或重复扣款。

重路由前先看副作用

六、模型切换必须带着状态迁移、幂等键和副作用账本

**作者工程推导。**上下文迁移应采用“不可变证据引用 + 有界摘要 + 待办动作”的形式。原始工具结果、文档片段和结构化输出保存在带哈希的对象中；新模型接收必要引用和经过版本化的摘要，而不是无差别转发整段对话。这样既降低上下文与缓存损失，也能在模型、提供方或区域改变时重新执行数据边界检查。

每个可能产生副作用的业务动作必须有稳定的幂等键。键应绑定业务意图，而不是绑定某次模型调用，例如由 task_id + action_type + target_resource + semantic_version 派生。工具网关在执行前查询副作用账本：

  • SUCCEEDED：直接返回已记录结果；
  • IN_FLIGHT：等待或查询外部系统状态；
  • UNKNOWN：进入对账，不盲目重试；
  • FAILED_RETRYABLE：在同一幂等键下按策略重试；
  • FAILED_FINAL：停止并上报。

AWS Builders’ Library 对安全重试的核心要求也是让调用方提供唯一请求标识，使服务能够识别重复意图；AWS Agentic AI Lens 则明确建议在检查点保存工作流状态，并让步骤和外部调用具备幂等性，否则恢复会复制副作用。[^S16][^S17] 这不等于“有了幂等键就获得全局 exactly-once”。外部 API 若不支持幂等，还需要条件写、事务外箱、结果查询、补偿动作或人工对账。

Router 本身不应直接持有业务写权限。它只输出路由决策、配置和升级策略；Runtime 或 Tool Gateway 根据受控凭据执行动作。这样，模型更换不会同时改变权限边界。

一次路由何时够用

七、何时一次路由足够，何时值得检查点重路由

一次入口路由适合这些场景：单轮或短链路；无外部工具和写副作用；所有候选共享相同合规边界；端点状态稳定；上下文较短；失败可以低成本重做；业务只需平均成本和延迟。在这种情况下，规则路由甚至固定模型常比复杂学习策略更稳定、更易审计。

状态检查点重路由适合这些场景：长链 Agent；工具结果决定后续难度；存在跨区域、模型白名单或数据等级差异；端点队列和错误率显著波动；任务有明确预算或期限；失败会引发人工处理或业务损失；执行中包含不可逆动作。动态策略的价值来自“新信息足以改变最优可行路径”，而不是来自动态本身。

因此不能声称动态路由一定优于规则路由。它增加了遥测、状态序列化、迁移验证、策略版本管理和离线评估成本。只有当任务分布、端点状态或失败代价存在足够异质性时，这些复杂度才可能被收益覆盖。上线顺序应是：先建立端点注册表、任务状态和事件账本；再运行可解释规则基线；随后用影子决策和离线回放验证学习策略；最后才允许有限流量自动切换。

在接口层，最小实现应把准入、选择和执行分成三个结果。准入服务返回候选端点及逐项拒绝码；路由服务只对候选集返回 route_id、模型版本、推理配置、策略快照和允许的下一个检查点；执行 Runtime 负责调用模型与工具，并把事件写回任务账本。任何组件都不能用“最终总分”覆盖准入结果。策略更新也必须版本化：一个已开始的任务默认沿用原策略快照，只有经过显式再准入才能切换到新策略，避免同一任务前后使用互相矛盾的地区、模型或权限规则。

控制面还应保存“为什么没有切换”。例如候选模型预测成功率更高，但迁移会丢失缓存、触发上下文重压缩并接近期限，系统可以保留当前路径，同时记录 NO_SWITCH_MIGRATION_COST。这种负决策记录能区分“Router 没工作”与“Router 评估后决定不动”，也是后续离线回放和策略审计的必要证据。

八、生产评测不应只看“路由准确率”

把入口分类标签预测正确率当作 Router 的主指标，会再次把系统问题缩成分类问题。更有意义的指标包括：硬策略违规次数，目标必须为零；可行集合为空的比例及原因；成功任务的完整成本；分任务段的 p95/p99 延迟；升级后成功增益与迁移开销；切换频率和震荡率；端点故障暴露；缓存保留或损失；重复副作用被拦截的次数；进入对账和人工复核的比例。

还要记录策略版本、模型版本、价格与缓存规则快照、端点状态快照和每次过滤原因。否则，模型升级或供应商规则变化后，团队无法解释成本与质量为何漂移，也无法做可信的反事实回放。

结论

生产模型路由不是“在入口猜一次难度，然后选一个模型”。正确的控制面先回答一条路径是否被允许、是否具备执行能力，再在可行集合内比较成功概率、完整任务成本和尾延迟。执行期间，工具结果、缓存、队列、错误和预算会改变剩余任务；系统应只在有限检查点重新决策，并通过结构化状态迁移保留已经验证的事实和未完成动作。

最关键的边界是：合规和能力是硬约束，不进入可补偿的总分；动态升级不是无状态重试，必须继承检查点；模型切换不能重复业务副作用，必须由幂等键、执行账本和对账流程约束。Router 的价值不是总能选到某个“最好模型”，而是持续选择一条被允许、可执行、可恢复、能对最终业务结果负责的路径。

FAQ

路由器和负载均衡器有什么区别？

负载均衡器通常在等价后端间分流；模型路由器还要判断能力、约束、质量和任务状态。

是不是检查点越多越好？

不是。检查点会增加状态管理和切换成本，只应放在状态可序列化且副作用可控制的位置。

能否只按 Token 价格路由？

不能。应看成功任务总成本，并先满足隐私、能力、上下文和工具等硬约束。

参考资料