openJiuwen X-Router自演進模型路由技術首發，昇騰親和，Agent越跑越省，實測減少50+%Token消耗

來源原標題

openJiuwen X-Router自演進模型路由技術首發，昇騰親和，Agent越跑越省，實測減少50+%Token消耗

作者

梦晨

原始標籤

資訊 · 華為

原始連結

https://www.qbitai.com/2026/10/500098.html

摘要原文

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的做法，是把“學習”從“執行”裡拆出來—— 狀態解耦 。這一條是整套架構裡最不起眼、但決定性的設計： 演算法是純函式 ：給定同樣的請求和同樣的狀態快照，必須給出同樣的決策。決策邏輯裡不允許藏著跨請求的記憶，也不允許有隱藏的隨機性。 狀態是可丟棄的提示 ：所有跨請求的記憶——歷史結果、排除項、快取親和、經驗資料——全部外接到獨立的狀態層，演算法每一輪只讀它一眼。 反饋閉環 ：每次呼叫結束後，宿主把結果回報回來：成功還是失敗、用了多久、大概花了多少、這一輪做得好不好。這些反饋寫回狀態層，成為下一輪的輸入。 這三條合起來，產生了一個很實用的性質： 狀態丟了，只是降質為“冷路由”，不會讓請求失敗；而演算法要升級、要換一個新的學習模型，不用動狀態層，也不用動宿主。 從執行時的角度看，這條閉環長這樣：使用者請求進來 → 路由演算法分析請求、判定模型 → 宿主執行、呼叫選中的模型 → 返回使用者； 與此同時，執行結果被送去評估（質量評分、呼叫成本、成敗、時延，可接入後臺評分模型）→ 關聯請求、模型與反饋形成經驗積累 → 演進模組檢索相似經驗、權衡質量與成本 → 應用於下一次決策 。 系統在這裡有一個克制而重要的預設： 樣本不足或優勢不明顯時，保留原判定 ——不為了“演進”而演進。 △反饋驅動的路由自演進——將執行結果轉化為經驗，持續修正後續選模決策 正是這個設計，讓“演進”這條路真正走得通—— 演算法和狀態各自獨立，誰升級都不會拖住對方。 於是就有了兩條互不干擾的演進通路：一條在執行時自我學習，靠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.