openJiuwen X-Router自演模型路由技术首发，升腾亲和，Agent跑得越省，实测减少50+%Token消耗

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400"> openJiuwen X-Router自演进模型路由技术首发，昇腾亲和，Agent越跑越省，实测减少50+%Token消耗 梦晨 2026-10-02 15:34:15 来源： 量子位 让每一次请求选对模型，让每一次反馈都成为下一次更优、更省的选择 允中 发自 凹非寺 量子位 | 公众号QbitAI 不是所有任务都需要最强的模型。让每一次请求选对模型，让每一次反馈都成为下一次更优、更省的选择。 你有没有想过，你的Agent可能一直在“用力过猛” 先做一个思想实验。 你问AI助手一个再简单不过的问题：“帮我把这句话翻译成英文。” 它调用的，是一个参数量千亿、跑在云端最贵算力上的模型。你问它一个需要通盘推演、写五十行代码、还要自己debug三轮的难题，它调用的还是同一个模型。 这是今天绝大多数AI应用的真实状态： 一个模型包打天下 。 问题还不止于“贵”。真实场景里，一个Agent往往同时握着本地模型、云端模型，以及来自不同厂商的多种服务。当可选模型越来越多，新的麻烦随之出现： 简单任务用昂贵模型，带来不必要的成本； 复杂任务交给轻量模型，效果不稳定； 依赖固定规则做选择，很难跟上业务与模型的持续变化。 用户真正需要的，不是一张需要反复维护的模型路由表，而是让Agent自己完成判断： 这次请求该由谁处理，为什么这样选择，下一次能否做得更好。 问题出在哪？出在我们 把“路由”这件事给忘了 。 从“一个模型包打天下”到“一支模型队伍” 现实世界里的调度智慧，随处可见。 点外卖时，平台不会派最近的骑手去送最远的一单，也不会为了三公里的单子调动整个配送站；医院分诊台不会让所有人直接挂专家号，而是先判断病情轻重，再决定看哪个科室、找哪位医生；快递分拣中心如果想要“送得快”，前提是“分得准”。 它们的共同点是： 手里有一支队伍，并且知道每一项任务该交给队里的谁。 Agent也该如此。 今天的Agent背后，现实已经是一支队伍了：有的模型推理能力强但贵且慢，有的轻快便宜但只能干简单活，有的擅长写代码，有的多模态理解更好。 每个模型各有所长，也各有所短。以PC办公场景为例，删除文件和写PPT，所需的能力显然不同。 问题是： 谁来当这位调度员？ 这就是openJiuwen智能路由要解决的事。 openJiuwen是由华为2012实验室、华为云、终端、计算、算力先遣队等团队联合高校、企业等广大开发者联合构建的开源AI Agent平台。 此次，openJiuwen团队给出的答案是——在Agent与模型之间，增加一层面向请求的智能决策能力，一个专门负责“ 这一轮任务，该用哪个模型、用什么策略 ”的路由引擎。 一句话说清：智能路由在做什么 基于任务复杂度，动态决策与编排群智协同及最优模型选择，实现成本-效果综合最优。 翻译成大白话：看菜下饭，量体裁衣。 简单的问题，用轻快的模型快速回；复杂的问题，调度更强的模型深思考；需要多个模型互相印证的问题，组织多模型协同作战、再统一汇总；而每一次决策的结果，都会变成经验，让下一次的判断更准。 这里的关键词是“ 动态” 。它不是一个开关，不是一份写死的配置表，而是一个会随着任务、用户、负载、成本实时变化的决策系统。 这套系统要有三个属性，缺一个都不成立： 可配置 ——不同业务能带着自己的偏好进来。这一轮要最省，还是这一轮要最快，由业务方说了算，而不是被一套写死的规则绑住； 可演进 ——模型生态是流动的，新模型每个月都在冒出来，老模型在悄悄降价，同一模型迭代一个版本能力分布就可能换个样子。策略必须能跟着一起长； 可观测 ——每一次决策的依据、每一次执行的反馈都要能看见、能回溯。一个说不清“为什么选它”的路由器，用户不敢把它放进生产。 那它到底怎么做到的？ 三层能力，构成一个完整的路由体系 openJiuwen团队把这套体系拆成三层，它们各自解决一个独立的问题： 第一层负责“看得准”，第二层负责“选得对”，第三层负责“越用越好”。 第一层：精准画像——“认识队伍里的每个人” 要做调度，首先得知道每个人擅长什么。 模型的能力不是一张静态标签。说“这个模型代码能力强”不够用——强到什么程度？在什么类型的题目上强？换个领域还强不强？模型还在迭代，能力还在变。 openJiuwen的做法是：基于历史数据， 离线刻画 每个模型的能力画像，并 在线动态刷新 ——当模型版本变动或表现发生变化时，画像的更新时延优于1分钟。 画什么？不只是“代码能力8分、数学能力7分”这种模糊打分，而是精细化的刻画：不同任务类型上的表现、不同难度下的表现、时延和功耗特性、成本量级。 有了精准的画像，路由才有一个可靠的起点—— 决策与执行分离 ，路由层只管判断，具体调用交给宿主，两者互不耦合。 △模型能力画像——每个模型都有一份动态更新的能力档案 第二层：决策——“这一轮，到底交给谁” 画像有了，接下来是真正难的部分： 面对一个具体请求，怎么选？ 先看请求本身。 Agent的任务是多轮的、有状态的，复杂度判断不能只看当前这一句，要看整条轨迹：我们走到哪了，接下来要做什么，前面失败过什么。 openJiuwen把最近的对话窗口连同工具调用进展一起送进判断，并专门做了一处处理—— Agent循环的尾部常被工具输出占满，任务本身会被挤出窗口时，openJiuwen团队特别保留了最近一次用户诉求 ，确保调度员始终知道“雇主想要的是什么”。 再看系统状态。 这是纯算法视角容易漏掉、但对真实收益影响最大的一块： KV缓存亲和 ：这个请求的上下文，跟哪个模型上已有的缓存更“熟”？复用缓存能省下大量重复计算—— 同样的模型，缓存命中与不命中，成本可以差出一截。 实时负载 ：此刻哪个模型更空闲、响应更快？同价位的两个模型，负载不同，时延可能差一倍。 目标可用性 ：某个模型刚超时或被限流，这一轮就不该再往它身上撞。这类信息会写进状态，成为下一次决策的排除项。 换句话说，路由的输入不只是“这个问题的难度”，而是 “这个问题的难度+整个系统此刻的状态” 。 最后才是决策本身。这本质上是一个 多目标优化问题 ：质量够不够、成本值不值、时延等不等得起、上下文和工具支不支持、用户更看重速度还是质量。 openJiuwen的做法是基于候选模型能力、时延功耗、用户偏好等约束，构建启发式优化算法，综合选出最优模型—— 选的是“最优”的那一个，而不是“看起来最强”的那一个。 △动态路由决策——多路信息汇聚后的实时权衡。系统按“请求分析 → 算法判定 → 输出选择 → 宿主调用”的链路工作，模型池每次选其一 第三层：演进——“越用越准，而且要能跟着模型生态一起长” 前两层解决的是“此刻怎么选”。 但如前面所说，一套写完就冻结的策略，三个月后必然过时。所以第三层解决的是： 这套系统能不能自己变聪明。 openJiuwen的做法，是把“学习”从“运行”里拆出来—— 状态解耦 。这一条是整套架构里最不起眼、但决定性的设计： 算法是纯函数