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

让每一次请求选对模型，让每一次反馈都成为下一次更优、更省的选择 不是所有任务都需要最强的模型。让每一次请求选对模型，让每一次反馈都成为下一次更优、更省的选择。 你有没有想过，你的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的做法，是把“学习”从“运行”里拆出来—— 状态解耦 。这一条是整套架构里最不起眼、但决定性的设计： 算法是纯函数 ：给定同样的请求和同样的状态快照，必须给出同样的决策。决策逻辑里不允许藏着跨请求的记忆，也不允许有隐藏的随机性。 状态是可丢弃的提示 ：所有跨请求的记忆——历史结果、排除项、缓存亲和、经验数据——全部外置到独立的状态层，算法每一轮只读它一眼。 反馈闭环 ：每次调用结束后，宿主把结果回报回来：成功还是失败、用了多久、大概花了多少、这一轮做得好不好。这些反馈写回状态层，成为下一轮的输入。 这三条合起来，产生了一个很实用的性质： 状态丢了，只是降质为“冷路由”，不会让请求失败；而算法要升级、要换一个新的学习模型，不用动状态层，也不用动宿主。 从运行时的角度看，这条闭环长这样：用户请求进来 → 路由算法分析请求、判定模型 → 宿主执行、调用选中的模型 → 返回用户； 与此同时，执行结果被送去评估（质量评分、调用成本、成败、时延，可接入后台评分模型）→ 关联请求、模型与反馈形成经验积累 → 演进模块检索相似经验、权衡质量与成本 → 应用于下一次决策 。 系统在这里有一个克制而重要的默认： 样本不足或优势不明显时，保留原判定 ——不为了“演进”而演进。 △反馈驱动的路由自演进——将执行结果转化为经验，持续修正后续选模决策 正是这个设计，让“演进”这条路真正走得通—— 算法和状态各自独立，谁升级都不会拖住对方。 于是就有了两条互不干扰的演进通路：一条在运行时自我学习，靠Contextual Bandit和轻量强化学习从真实反馈里持续抽经验；一条在逻辑上持续迭代，画像更新、算法替换、策略升级都是独立模块。 为什么这件事重要？ 因为它决定了这套路由是“一次性的工程”，还是“能活三年的基础设施”。前者每次模型换代都要重做一遍，后者只需要换掉一个模块。 再进一步：从“选模型”到“编排协同” 三层能力之上，还有一个更大的空间。 一是多模型协同。 多模型协同天然昂贵，所以关键在于 能不能聪明地协同 ：重复的答案不必重复计算，站不住脚的答案及早淘汰，模型之间结论不一致时有机制判断谁更可信。 这类能力，openJiuwen团队已经在 WorkSwarm 的 MoA（多模型协同） 中做了实现，并支持通过路由框架统一接入—— 路由决定“这一轮要不要发动多个模型、发动哪几个”，MoA负责“多个模型的结果怎么收拢成一个”。 一个管派谁上场，一个管场上怎么配合。 △MOA多模型协同——重点不是“多”，而是聚合得聪明 二是策略自编排。 不再局限于“选模型”，而是把模型、Skill/Tool、SubAgent等多种能力放在同一个调度框架下统一编排——某一步交给模型推理，某一步交给工具执行，某一步派个子Agent去查证。 路由的粒度，从“选模型”升级为“编排整个执行策略”。 再加上 策略自闭环优化 ：通过构建反馈Hook点和Fallback机制，验证并总结执行结果和错误根因，让策略能够自行优化——每一次失败都不会被浪费。 关键难点：在四个目标之间走钢丝 讲到这里，有必要单独说说这件事真正的难点。 模型路由最难的，从来不是“能不能选”，而是 如何在成本、时延、质量、上下文/工具兼容性之间做实时权衡 。 把成本压到极致，质量可能就崩了，用户转头就走； 把质量顶到最高，成本会失控，业务方不答应； 一味追求低时延，可能在关键问题上给出草率答案； 只看单次最优，忽略了缓存复用，整体反而更贵。 这是一个典型的 没有标准答案的多目标权衡问题 。理论上没有免费的午餐，实践中也没有一个参数能适配所有场景。 openJiuwen的思路不是去找一个“万能的最优解”，而是 把权衡这件事本身变成一个可配置、可演进、可观测的系统 ：不同业务可以带着自己的偏好进来；决策依据来自真实的执行反馈，而不是纸面上的假设；策略可以随着数据积累持续演进，越用越准。 这套机制落到代码里长什么样？看这张图。 △openJiuwen智能路由整体架构——路由算法（Algorithm）、状态管理（State）、自演进（Evolving）三块解耦，向上对接WorkSwarm/MoA的协同编排，向下对接候选模型池；对外是纯函数接口调用，不产生无状态之外的影响 架构里的 Algorithm 一层，是把“怎么判断”做成可插拔的能力。 目前已经落地的算法包括 x-router ：基于五档复杂度分档的路由算法，支持端云分级、本地能力边界判断、进程内小模型分类器、失败降级永不升级，并用上下文Bandit做经验修正。 同层还有其他路线——比如Rust版本的轻量前瞻路由，走的是高维特征空间质量预测与任务轨迹预测、联合优化的路子，静态编译、无运行时依赖、可直接嵌入宿主进程。 也就是说，x-router是这台引擎里的一个算法模块，而不是引擎本身。 引擎提供的是那套“可配置、可演进、可观测”的骨架；换算法不改骨架，换骨架不动算法。 下面的实测数据，用的就是x-router这条算法通路。 实测：在哪些榜单上，拿到了什么结果 技术讲完了，看效果。 openJiuwen团队想回答两个最直接的问题： 启用智能路由之后，能否减少不必要的模型调用成本？开启自演进之后，路由策略能否随着真实使用持续优化？ 实验设置 团队把x-router接入 WorkSwarm ，使用 PinchBench 全量 147个任务 进行评测，任务覆盖日志分析、数据分析、编码、研究等 11个类别 。 x-router的复杂度分类器采用本地部署的 Qwen3-0.6B ，直接跑在进程内，无需额外启动独立服务。五级模型池配置如下： △五级模型池配置——从SIMPLE到REASONING五档，本地模型与云端模型混合编队 对应的能力分档逻辑是：从 SIMPLE 到 REASONING ，简单任务优先使用轻量模型，复杂任务按需升级能力——查询“HTTP 429是什么含义”走轻量模型，编写数据处理脚本走通用或高能力模型，多文档研究走研究型模型，数学证明与深度推理才交给推理模型。 △五级能力路由——根据任务复杂度匹配合适的模型能力，追求的不是“选更便宜的”，而是“能用轻量模型完成就不必调用强模型，能力不足时才让更强模型接手” 三种运行模式 为保证对比公平，三组实验使用相同的评测模型和评分标准，并统计不同模式下的 PinchBench得分 及 真实模型调用成本 ： 全云基线（All Kimi-K2-Thinking） ：不使用智能路由，所有请求统一交给指定的云端强模型； x-router静态路由 ：启用x-router的复杂度路由，但不开启自演进； x-router Bandit自演进 ：在静态路由基础上开启Bandit自演进，根据相似任务的真实执行结果动态调整路由策略。 结果一：PinchBench——得分几乎持平，成本降44.6% △PinchBench实测结果——横轴为模型调用总成本，纵轴为PinchBench得分；越靠近左上角，代表以更低成本拿到更高任务质量 x-router静态路由 取得 66.3% 的PinchBench得分，总模型调用成本 $8.25 。相比全量调用Kimi-K2-Thinking（ 71.36% 、 $11.11 ），得分下降5.1%，而模型调用成本 降低了25.7% 。 开启Bandit自演进后 ，成本进一步从 $8.25 降至 $6.16 ，较静态路由再降约 25.3% ；与此同时，PinchBench得分 提高4.4% ，达到 70.70% 。 与全云基线相比 ：x-router Bandit自演进模式得分70.70% vs 71.36%，仅低 0.66个百分点 ，几乎持平；而模型调用成本从 $11.11 降至 $6.16 ， 整体降低约44.6% 。 这组对比回答了两个问题：静态路由证明了“按需选模”本身就能砍掉不必要的强模型调用；自演进则证明了—— 反馈闭环带来的不只是省钱，还有质量的回升 。成本降了25.3%的同时得分反升4.4%，这是“越用越准”最直接的证据。 结果二： Terminal-Bench/LLMRouterBench——成功率达Opus的95.2%，成本降51.4% openJiuwen团队还在 Terminal-Bench/LLMRouterBench 上用 Opus4.8/Qwen3.5-122B/Qwen3.5-35B三档位模型池 做了 单轮/多轮路由 测试： cost focused 模式下，降成本 51.4% ，成功率达Opus的 95.2% ； quality focused 模式下，降成本 15.7% ，成功率达Opus的 98.6% 。 △ Terminal-Bench/LLMRouterBench实测结果——横轴为模型调用总成本，纵轴为任务成功率；基于Opus4.8/Qwen3.5-122B/Qwen3.5-35B三档位模型池进行路由 两个榜单、两种偏好设置，指向同一个结论：接近顶配的质量，可以用大约一半的成本拿到。 而且“省多少、让多少质量”是用户自己选的——这正是“可配置”落到数字上的样子。 快速上手 安装 model-router的内核是Rust，Python侧是PyO3扩展。 git clone https://gitcode.com/openJiuwen/model-router.gitcd model-routercargo build pip install maturinmaturin develop 如需使用x-router算法，在已激活的Python虚拟环境中执行： maturin develop –extras x-router 配置 路由的行为由一份TOML描述。最简形态如下： config/edge.tomlalgorithm = “passthrough” [state]backend = “memory”ttl secs = 300max entries = 1024 [targets]models = [“local-default”] 切换到x-router只需改算法名并补上模型池与分类器： algorithm = “x-router” [targets]models = [“model-a”, “model-b”, “model-c”, “model-d”, “model-e”] [x-router.classifier model]model path = “/path/to/qwen3-0.6b”local models = [“model-a”] 调用 装配路由，发起请求，拿到决策后 由宿主自己调用模型 ，再把结果回报回去——这就是前面说的“决策与执行分离”。 import openjiuwenfrom openjiuwen import Feedback, Router router = Router.from config(“config/cloud.toml”) decision = await router.route({ “messages”： [{“role”： “user”, “content”： “hi”}], “session id”： “s1”, “agent id”： “host”,}) 宿主自行调用 decision.selected model id对应的模型 await router.report( Feedback.ok(decision, latency ms=12, session id=“s1”, agent id=“host”)) x-router的调用方式在语义上一致，分类器直接运行在本地进程中： from openjiuwen import x router router = x router.build router(“router.toml”) selection = x router.build request( [{ “role”： “user”, “content”： “Compare Raft and Paxos for a five-node cluster.” }], session id=“s-1”, agent id=“my-agent”,) Router会从 decision.selected model id中返回推荐调用的模型decision = router.route sync(selection) Rust宿主可直接静态链接openjiuwen-runtime： use openjiuwen runtime：：{Feedback, RequestMetadata, RouteHint, RouteRequest, Router}； let router = Router：：from config(“config/edge.toml”)?；let decision = router.route(&req, &RouteHint：：default())?； let mut feedback = Feedback：：ok(req.routing key(), &decision.selected model id, 40)；feedback.route id = decision.route id.clone()；router.report(feedback)； 详细使用说明参考代码仓README。 为什么这件事，现在特别重要 最后聊几句判断。 第一，模型会越来越多，路由会越来越刚需。 今天大家还在讨论“哪个模型最强”，但很快，这个问题会变成“哪个组合最合适”。 因为模型生态正在快速分化：有的往强推理走，有的往轻量端侧走，有的往多模态走，有的专攻代码或某个垂直领域。 没有哪个模型能在所有维度上都赢，这意味着 选择本身，正在成为一种核心能力 。 第二，成本是Agent走向大规模落地的真正门槛。 Agent和聊天机器人最大的区别，是它会长时间、多轮次、多工具地持续工作。 这意味着Token消耗不是线性增长，而是成倍放大。一个在Demo里跑得很漂亮的能力，如果成本压不下来，在真实业务里就跑不起来。 路由不是锦上添花的优化，而是Agent能不能规模化的前置条件。 第三，通用性比单点最优更重要。 团队不打算为某个特定场景做一套定制的最优解。openJiuwen智能路由的目标，是 一套统一的、可嵌入的路由框架 ：同一套内核，通过配置就能实例化出不同的部署形态—— 端侧形态 ：单进程、内存态、零外部依赖，路由与推理同机共处，把决策开销压到可以忽略； 云侧形态 ：状态层外置，决策依据来自全局的模型表现与负载视图； 企业私有化形态 ：在有限的模型清单内做最优搭配，策略与数据都留在本地； 端云混合形态 ：端侧判断简单任务自己消化，复杂任务交给云端——同一套决策逻辑，两侧给出同样的答案。 一套框架，多种形态。 换的是部署拓扑，不换的是那套“看菜下饭”的判断逻辑。 △一套路由框架，多种部署形态 结语：让每一分算力，都用在最该用的地方 回到开头那个思想实验。 openJiuwen团队真正想改变的，不是“用哪个模型”这个具体选择，而是 “选择”这件事本身的发生方式 ——从开发者预先写死的配置，变成一个运行时会思考、会权衡、会学习的系统。 打个比方：过去团队给Agent配的是一位“照着名单发活”的排班员，现在他们想给它配一位 真正的调度员。 这位调度员知道每个人此刻的状态，知道这一单的轻重缓急，知道客户最在意什么，而且每做完一单，他对整支队伍的理解就更深一分。 这正是openJiuwen智能路由想做的事：不是让Agent用更强的模型，而是让Agent用更对的模型。 而x-router只是这台引擎里已经跑通的一条算法通路。 接下来，openJiuwen团队还会推出包括 路由策略强化学习训练 在内的更多自演进能力，让短期经验逐步沉淀为更加稳定的长期路由策略。 相关能力在持续开发和验证中，更多进展敬请关注openJiuwen社区后续发布。 openJiuwen智能路由已开源，欢迎关注openJiuwen开源社区，第一时间上手体验。 相关资源 openJiuwen官网： https://www.openjiuwen.com/ AtomGit： https://atomgit.com/openJiuwen/model-router GitHub： https://github.com/openJiuwen-ai/model-router x-router README： https://atomgit.com/openJiuwen/model-router/blob/main/python/openjiuwen/x router/README.md https://github.com/openJiuwen-ai/model-router/blob/main/python/openjiuwen/x router/README.md x-router示例： https://atomgit.com/openJiuwen/model-router/blob/main/examples/x router cli.py 版权所有，未经授权不得以任何形式转载及使用，违者必究。 华为 梦晨 扫码分享至朋友圈 相关阅读 昇腾云客户2663家，华为云稳居最大国产AI云服务提供商 华为 高通宣布与华为达成新专利授权协议 华为将付18亿美元 华为 高通 荣耀X10发布：旗舰级5G，1899元起 麒麟820全面升级5G体验 华为 荣耀 防患高通效仿华为，苹果10亿美元收购英特尔手机基带！打造5G备胎，加强自主可控 苹果不想再受高通掣肘。 5G 华为 苹果 高通 英伟达含量为零！华为密集模型性能比肩DeepSeek-R1，纯昇腾集群训练 LiveCodeBench达到SOTA水平 华为 盘古大模型 华为自动驾驶2位大将，接管了极氪智能化 极氪密集补强智能化 华为 智能车真high 极氪 热门文章 OpenAI推理之父最新访谈！数学只是多智能体时代的开胃菜 李飞飞创业公司被苏姿丰550亿收购！世界模型最大交易落地 DeepSeek官方开源昇腾基础组件，与昇腾共建高效易用的AI芯片软件生态 OpenAI光速上新GPT-6.1 Sol！一晚上25项更新，都在这里了 DeepSeek知乎独家发文，首次公开V4.1 Agent训练“大本营”DSec 加入我们 寻求报道 商务合作 追踪人工智能新趋势，报道科技行业新突破