问一个再简单不过的问题。
「帮我把这句话翻成英文。」
AI 助手转身叫来一个参数上千亿的模型。
它还跑在最贵的算力上。
它很贵。
同一时间，另一个用户让它写五十行代码。
还得自己 debug 三轮。
它叫来的，还是同一个模型。
这就是今天很多 AI 应用的真实状态。
一个模型包打天下。
问题不只是贵。
真实场景里，一个智能体手里往往同时握着本地模型和云端模型。
还有好几家厂商的服务。
可选的东西一多，麻烦就来了。
简单任务用昂贵模型，成本白白流走。
复杂任务交给轻量模型，效果又不稳。
靠固定规则去挑，业务一变就得推倒重来。
用户真正想要的，不是一张天天要维护的模型路由表。
他们想要智能体自己判断。
这一轮该交给谁，为什么这么选，下次能不能更准。
问题出在哪儿。
出在我们把「路由」这件事给忘了。
手里其实早就是一支队伍
现实世界里的调度智慧，随处可见。
点外卖时，平台不会派最近的骑手去送最远的一单。
医院分诊台不会让所有人直接挂专家号。
它先看病情轻重，再决定去哪个科室。
快递分拣中心想要送得快，前提是分得准。
它们的共同点是手里有一支队伍。
而且知道哪一单该交给队里的谁。
智能体也该如此。
它背后的模型，现实已经是一支队伍了。
队伍很大。
有的推理强，但贵且慢。
有的轻快便宜，只能干简单活。
有的擅长写代码。
有的多模态理解更好。
以办公场景为例，删文件和做演示所需的能力，显然不是一回事。
问题是，谁来当这位调度员。
openJiuwen 给出的答案是在智能体和模型之间加一层能力。
这层能力面向请求，专门负责这一轮该用哪个模型。
openJiuwen 是华为 2012 实验室和华为云等团队联合构建的。
它是一个开源 AI 智能体平台，高校与广大开发者都参与了共建。
这一层叫智能路由。
它本质是一台路由引擎。
一句话说清它在做什么。
按任务复杂度动态决策，选出成本与效果综合最优的模型。
说白了就一句。
翻成大白话，就是看菜下饭。
简单问题交给轻快模型快速回。
复杂问题调度更强的模型深思考。
需要多方印证的问题，就组织多个模型协同作战，再统一汇总。
每一次决策的结果都会变成经验。
它让下一次判断更准。
关键词是「动态」。
它不是一个开关。
也不是一份写死的配置表。
而是一套会随任务和负载实时变化、跟着成本走的决策系统。
这套系统要同时满足三个属性。
可配置。不同业务能带着自己的偏好进来，这一轮要最省还是要最快，业务方自己说了算。
可演进。模型生态是流动的，新模型每个月都在冒出来，老模型在悄悄降价，策略得跟着一起长。
可观测。每一次决策的依据、每一次执行的反馈都要能看见，也能回溯。
一个说不清「为什么选它」的路由器，没人敢放进生产。
三层能力，各管一段
openJiuwen 把这套体系拆成三层。
第一层负责看得准。
第二层负责选得对。
第三层负责越用越好。
要做调度，先得知道每个人擅长什么。
模型的能力不是一张静态标签。
说「这个模型代码能力强」并不够用。
强到什么程度，在哪类题上强，换个领域还灵不灵，这些都要清楚。
openJiuwen 的做法是离线刻画每个模型的能力画像。
然后在线动态刷新。
模型版本一变，或者表现出现波动，画像的更新时延优于一分钟。
画的不只是模糊打分。
不同任务类型上的表现，不同难度下的发挥，这些都要画。
还有时延功耗和成本量级。
有了精准画像，路由才有可靠的起点。
决策与执行在这里是分开的。
路由层只管判断。
具体调用交给宿主，两者互不耦合。
第二层要解决的是最难的：面对一个具体请求，到底交给谁。
先看请求本身。
智能体的任务是多轮且有状态的。
复杂度不能只看当前这一句。
它要看整条轨迹。
走到哪了，接下来要做什么，前面失败过什么。
团队还专门做了一处处理。
智能体循环的尾部常被工具输出占满。
任务本身快被挤出窗口时，系统会特意保留最近一次用户诉求。
再看系统状态。
这是纯算法视角容易漏掉、却对真实收益影响最大的一块。
上下文缓存亲和。这个请求的上下文跟哪个模型上已有的缓存更熟，复用它能省下大量重复计算。
实时负载。此刻哪个模型更空闲，响应更快。
同价位的两个模型负载不同，时延可能差一倍。
目标可用性。某个模型刚超时或刚被限流，这一轮就不该再往它身上撞。
换句话说，路由的输入不只是问题的难度。
它还包括整个系统此刻的状态。
最后才是决策本身。
它本质上是一个多目标优化问题。
质量够不够，成本值不值，时延等不等得起，上下文和工具支不支持。
团队的做法是构建启发式优化算法，综合选出最优模型。
选的是「最优」的那一个。
而不是「看起来最强」的那一个。
第三层解决的是：这套系统能不能自己变聪明。
一套写完就冻结的策略，三个月后必然过时。
openJiuwen 把「学习」从「运行」里拆了出来。
算法是纯函数。
给定同样的请求和同样的状态快照，必须给出同样的决策。
决策逻辑里不允许藏着跨请求的记忆。
状态是可丢弃的提示。
所有跨请求的记忆全部外置到独立的状态层。
算法每一轮只读它一眼。
反馈闭环。每次调用结束后，宿主把结果回报回来：成功还是失败，用了多久，大概花了多少。
这些反馈写回状态层，成为下一轮的输入。
三条合起来，产生了一个很实用的性质。
状态丢了，只是降质为「冷路由」。
它不会让请求失败。
算法要升级，也不用动状态层，更不用动宿主。
系统在这里有一个克制而重要的默认。
样本不足或优势不明显时，保留原判定。
不为了演进而演进。
从「选模型」再往前一步
三层能力之上，还有更大的空间。
一是多模型协同。
当一个问题确实很难，单模型不足以给出可信答案。
此时路由层可以调度多个模型各答一份。
再经过语义去重和质量筛选。
接着做冲突消解与压缩整理。
最终聚合成一个更高质量的答案。
多模型协同天然昂贵，关键在能不能聪明地协同。
重复的答案不必重复计算。
站不住脚的答案及早淘汰。
模型之间结论不一致时，还要有机制判断谁更可信。
这类能力已经在同团队的 WorkSwarm 多模型协同里做了实现。
它也支持通过路由框架统一接入。
一个管派谁上场。
一个管场上怎么配合。
二是策略自编排。
路由的粒度不再局限于选模型。
它会把模型和技能，还有工具与子智能体放进同一个调度框架。
某一步交给模型推理，某一步交给工具执行，某一步派个子智能体去查证。
再叠加策略自闭环优化。
通过反馈钩子和降级机制，验证并总结执行结果与错误根因，让策略自行优化。
每一次失败都不会被浪费。
讲到这里，有必要单独说说真正的难点。
模型路由最难的，从来不是能不能选。
难的是如何在成本、时延和质量之间走钢丝。
还得兼顾上下文与工具的兼容性。
把成本压到极致，质量可能就崩了。
客户转头就走。
把质量顶到最高，成本会失控。
业务方不答应。
一味追求低时延，可能在关键问题上给出草率答案。
只看单次最优，忽略了缓存复用，整体反而更贵。
这是一个典型的没有标准答案的多目标权衡。
理论上没有免费的午餐。
实践中也没有一个参数能适配所有场景。
所以团队不去找万能的最优解。
他们把权衡本身变成一套系统。
可配置，可演进，也可观测。
决策依据来自真实的执行反馈，而不是纸面上的假设。
实测：省了多少，质量掉了多少
技术讲完，看效果。
团队想回答两个最直接的问题。
启用智能路由之后，能不能减少不必要的模型调用成本。
开启自演进之后，策略能不能随着真实使用持续优化。
实验把 x-router 接入 WorkSwarm。
评测集含 147 个任务，覆盖日志分析和数据分析，还有编码与研究等十一个类别。
复杂度分类器用的是本地部署的一个小模型。
它直接跑在进程内，不需要额外起服务。
模型池按五档配置。
对应的能力分档逻辑很清楚。
从最简单到最复杂，简单任务优先用轻量模型，复杂任务按需升级。
查一句「某个报错是什么含义」走轻量模型。
编写数据处理脚本走通用或高能力模型。
多文档研究走研究型模型。
数学证明与深度推理才交给推理模型。
难度不一样。
为保证公平，三组实验用的评测模型和评分标准完全相同。
全云基线不使用智能路由。
所有请求统一交给指定的云端强模型。
静态路由开启复杂度路由，但不开启自演进。
自演进在上一步基础上打开多臂老虎机。
它根据相似任务的真实执行结果动态调整策略。
结果一出来，得分几乎持平。
成本降了 44.6%。
静态路由拿到 66.3% 的得分。
总调用成本 8.25 美元。
全云基线是 71.36% 和 11.11 美元。
得分只低了 5.1 个百分点，成本却降了 25.7%。
打开自演进之后，成本进一步从 8.25 美元降到 6.16 美元。
比静态路由再降约四分之一。
与此同时，得分反而回升 4.4%，来到 70.70%。
与全云基线相比，得分只差 0.66 个百分点。
几乎持平。
成本却整体降低约 44.6%。
数字不会说谎。
这组对比回答了两个问题。
静态路由证明，按需选模本身就能砍掉不必要的强模型调用。
自演进则证明，反馈闭环带来的不只是省钱。
还有质量的回升。
成本降了四分之一，得分反升 4.4%。
这就是「越用越准」最直接的证据。
第二个榜单上的结果同样明显。
团队在终端任务评测集上用三档位的模型池做了单轮和多轮路由测试。
偏向成本的模式下，成本降低 51.4%，成功率达到旗舰模型的 95.2%。
偏向质量的模式下，成本降低 15.7%，成功率提升到 98.6%。
两个榜单、两种偏好，指向同一个结论。
接近顶配的质量，可以用大约一半的成本拿到。
而且省多少、让多少质量，是用户自己选的。
这正是「可配置」落在数字上的样子。
再说三个判断。
第一，模型会越来越多，路由会越来越刚需。
今天大家还在讨论哪个模型最强。
很快这个问题会变成哪个组合最合适。
模型生态正在快速分化。
有的往强推理走，有的往轻量端侧走，有的专攻某个垂直领域。
没有哪个模型能在所有维度上都赢。
这意味着选择本身正在成为一种核心能力。
第二，成本是智能体走向大规模落地的真正门槛。
智能体和聊天机器人最大的区别，在于它会长时间持续工作。
它还要多轮次、多工具地跑。
这意味着消耗不是线性增长，而是成倍放大。
一个在演示里跑得很漂亮的能力，如果成本压不下来，在真实业务里就跑不起来。
路由不是锦上添花的优化。
它是智能体能不能规模化的前置条件。
第三，通用性比单点最优更重要。
团队不打算为某个场景做一套定制的最优解。
他们想要的是一套统一且可嵌入的路由框架。
同一套内核，通过配置就能实例化出不同形态。
端侧形态单进程运行，靠内存态存储，零外部依赖。
决策开销压到可以忽略。
云侧形态把状态层外置，决策依据来自全局的模型表现与负载视图。
企业私有化形态在有限的模型清单内做最优搭配，策略与数据都留在本地。
端云混合形态由端侧判断简单任务自己消化，复杂任务交给云端。
换的是部署拓扑。
不换的是那套看菜下饭的判断逻辑。
回到开头那个思想实验。
openJiuwen 想改变的，不是用哪个模型这个具体选择。
它想改的是选择这件事本身的发生方式。
过去团队给智能体配的是一位照着名单发活的排班员。
现在他们想给它配一位真正的调度员。
这位调度员知道每个人此刻的状态。
它也知道这一单的轻重缓急。
每做完一单，它对整支队伍的理解就更深一分。
一句话，不是让智能体用更强的模型，而是让它用更对的模型。
与其每次都请出最强的旗舰，不如按任务难度挑一档。
与其盯着参数表上的数字，不如先看它能不能稳定交货。
顺着这条路往下走，同类工具只会越来越多。
想找别的选择，可以去排行榜按用途翻一翻。
想让它真正帮上忙，不妨先从AI编程这类高频场景试起。
至于日常办公和内容生产要用到的搭配，AI工具那一类目里也有现成的清单。
这套东西已经开源，装好就能上手。
上手说明也都写在仓库里。
等每个需求都能自动找到最合适的那双手，省下的就不只是账单。
