一次请求只做一次决策：阿里云 AI 网关智能路由如何替大模型应用选模型

作者：张健川（聪言）

模型越多，选择反而越难。阿里云 AI 网关智能路由现已上线：先看哪些模型能把任务做好，再按你关心的方向------综合均衡、成本、速度还是任务适配------做出一次明确的选择；在多轮对话和 Agent 工具链里，它还知道什么时候不该乱动。

做大模型应用的同学大多有这个体感：一开始只接一个模型，后来变成同时管一组。同一套业务里，轻量问答、内容摘要、复杂推理、代码生成、Agent 工具调用可能全都有，而每个模型的能力、价格、延迟、可用状态各不相同。于是一个新的工程问题冒了出来：这一次请求，到底该交给谁？

常见的做法有几种，各有各的难处。全都丢给旗舰模型，效果是稳了，成本和限流压力会一路涨；在应用代码里手写选择逻辑，模型一换、价格一变、运行状态一波动，就得重新发布应用；每次请求都重新判断，Agent 的工具调用链又可能在同一个任务里"中途换脑"，上下文亲和丢了，时延还多了一截。

做智能路由，我们不想再给大家添一层复杂配置，而是把选模型这件事收进 AI 网关：能力足够是前提，优化目标由你来定，最后每次只交给一个模型。 因此，阿里云 AI 网关即将推出智能路由：先看哪些模型能把任务做好，再按你关心的方向------综合均衡、成本、速度还是任务适配------做出一次明确的选择；在多轮对话和 Agent 工具链里，它还知道什么时候不该乱动。

先满足任务，再优化价格、速度与适配度。

一次请求，只做一次决策

一笔合法的 Auto 请求进入网关后，智能路由会按固定顺序走完判断：

识别它是独立请求、普通用户消息，还是工具/模型状态续接。
根据协议、模态、工具能力、上下文容量、授权和可用状态等条件，先排除确定不合格的候选。
理解当前任务与上一任务的关系，以及任务难度和不可缺少的能力。
结合 ModelCard 元数据和平台模型能力参考，形成"足以完成任务"的候选集合。
在这个集合内应用请求方选择的 Profile。
生成唯一的路由决策，把请求交给实际执行模型。

这里有两条边界，我们想先讲清楚。

第一条，任务顾问只负责描述"任务需要什么"，不会直接指定最终模型。协议、能力、成本和运行状态这些事实，仍由网关侧策略统一裁决。顾问暂时不可用时，首个或独立请求可以在满足确定性硬约束的前提下，用本地评分完成受控决策；已经有可信连续性状态的请求，则会优先保守复用原来的执行模型。

第二条，候选评估结果不是 Fallback 顺序。智能路由只负责选出本次主请求的执行模型，不会生成一条自动候选执行链；模型调用失败后的重试和兜底，仍然由独立的 AI Fallback 能力负责。两项能力可以搭配使用，但职责不会混在一起。

想省、想快，还是想更准，你说了算

使用智能路由时，请求方需要显式选择一种模式：

要提醒的是，四种 Profile 都是优化倾向 ，不是理论最优 SLA。cheap 不会为了便宜去选一个能力不够的模型，quality 也不等于保证单次回答的正确率；事实相近时，不同 Profile 选中同一个模型也很正常。

首期我们没有开放自定义权重，主要是不想让每个团队都各自维护一套难以验证的路由公式。Profile 模板由平台统一演进，你只需要表达业务偏好。

Agent 时代，知道什么时候"不重选"同样重要。

三类调用，三种节奏

简单 Model API、多轮聊天和 Agent 调用，看起来都是在"请求模型"，但它们需要的路由节奏完全不同。

独立请求：每次都可以重选

摘要、改写、审核、格式转换这类请求彼此独立，没有可靠的会话证据。网关会把每次请求都当成新的决策单元，让不同任务按各自的需求选模型。

多轮对话：只在该换的时候换

用户接着问"接着说""把第二点展开"时，贸然换模型，上下文缓存可能失效，回答风格也可能漂移。智能路由会先判断当前消息是上下文延续、独立新任务，还是无法确定：

上下文延续或判断不确定时，保守复用上一轮实际执行的模型。
只有识别到高置信的新任务，才在用户消息边界重新决策。
如果新的协议、模态、工具或上下文要求让当前模型不再合格，网关才会突破软亲和重新选择。

Agent 工具链：中途不换脑

一次用户任务可能引发多轮模型请求、工具调用和工具结果回传。智能路由会在任务开始时做一次决策，让后续的工具续接保持同一个实际执行模型；标准协议中已有的工具和模型状态关联信息，会被用来恢复正确的执行关系。

所以，Agent 不会因为一次工具结果回传就重新走一遍完整路由，也不会仅凭短期的成本或健康波动，在同一个任务里切换模型。这样既省下额外时延，也尽量保住了上下文与缓存亲和。

当然，连续性能力不会假装自己有无限记忆。当客户端压缩了上下文、丢失了协议因果信息，或者只提供无法区分会话的普通请求时，保证会相应退化；网关不会把同一消费身份下的所有请求强行拼成一个会话。

平台模型与自有模型，共用一套清晰的选择边界。

候选池：可以开箱即用，也可以完全自己定

你可以从已有模型服务里挑最多 5 个自定义候选，也可以直接开启平台内置的经济、标准和旗舰模型档位；两类候选还能混在同一次决策里参与比较。

每个候选背后都有一张 ModelCard，提供结构化的事实：支持的协议、输入输出模态、工具与推理能力、上下文容量，以及用于路由比较的 Credit。智能路由不会靠模糊的模型名称去猜能力，也不会用低成本去抵消缺失的硬能力。

平台内置模型用稳定档位承载，后续物理模型演进，不需要你重新接入每一个新模型；自定义模型继续用你已有的服务和凭据，归属关系不变。

有一点要特别说明：ModelCard Credit 是路由偏好尺度，不是账单价格。 你可以按自己的合同价或内部成本口径来维护 Credit；实际的模型费用，仍由对应模型服务和产品计费规则独立结算。这样一来，auto/cheap 比较的是同一候选池里你自己的成本标准，而不是被强行套上平台统一报价。

一次抖动，不至于换模型

智能路由会持续观察候选的可用状态和延迟表现。明确不可用的候选，会在新的安全决策边界被排除；达到有效样本门槛后，延迟和健康信号会进入 fast 及其他 Profile 的本地评分。

样本不足时，系统不会因为一两个偶发请求就把某个模型判成"最快"或"最差"；已经进入同一 Agent 工具链的强续接，也不会仅仅因为瞬时的软信号就换模型。如果原模型已经违反了确定性硬边界，网关会按明确的失败语义处理，业务级兜底仍然交给独立的 Fallback 策略。

接入很简单，不需要新 SDK

在控制台创建或更新 Model API 时，选择"智能路由"后端场景，配置自定义候选、按需开启平台内置模型，发布后就能用。调用侧不需要接任何额外的路由 SDK，只要把 model 改成显式模式，例如：

json 复制代码

{
  "model": "auto/balanced",
  "messages": [
    {"role": "user", "content": "请总结这份材料并列出三个行动项"}
  ]
}

如果请求里继续填写具体的模型名称，智能路由会完全旁路，原有业务行为不变。裸 auto 不会被猜成某个默认策略------调用方必须明确写出 auto/balanced、auto/cheap、auto/fast 或 auto/quality。

智能路由 Model API 会强制启用消费者鉴权，用可信身份隔离不同租户的连续性状态；同一消费者下的多个会话，仍由协议因果信息区分，消费身份本身不会被当成会话 ID。路由状态只保存有界的任务摘要和必要的关联信息，不持久化完整 Prompt、完整历史或凭据；有界摘要仍按敏感业务内容保护，不进入普通 Trace 和日志。

几条边界

首期面向支持该能力的 AI 网关 Model API，MultiTenantServerless 多租网关暂不开放。
智能路由只接管显式 auto/<profile> 请求，具体模型请求保持原链路。
一次决策只产生一个主执行模型，不自动生成重试或 Fallback 候选链。
四种 Profile 表示优化倾向，不承诺每次命中理论上全局最便宜、最快或最强的模型。
连续性依赖当前请求可观察到的标准协议证据；上下文压缩或因果信息丢失时，能力会保守退化，而不是跨会话猜测。

写在最后

多模型时代，真正贵的不只是 Token，还有散落在每个应用里的选择逻辑、持续调参和故障风险。

我们希望智能路由把这些工作收进一个清晰的入口：让独立任务拥有选择空间，让多轮会话保持必要的稳定，让 Agent 工具链不再重复判断；先保证能力充分，再按你的业务偏好，选更省、更快或更合适的模型。

智能路由功能已经在 AI 网关专享实例率先上线，登录阿里云搜索"AI 网关"即可体验。