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”ttlsecs = 300maxentries = 1024 [targets]models = [“local-default”] 切換到x-router只需改算法名並補上模型池與分類器： algorithm = “x-router” [targets]models = [“model-a”, “model-b”, “model-c”, “model-d”, “model-e”] [x-router.

classifiermodel]modelpath = “/path/to/qwen3-0.6b”localmodels = [“model-a”] 調用 裝配路由，發起請求，拿到決策後由宿主自己調用模型，再把結果回報回去——這就是前面說的“決策與執行分離”。import openjiuwenfrom openjiuwen import Feedback, Router router = Router.fromconfig(“config/cloud.toml”) decision = await router.

route({ “messages”： [{“role”： “user”, “content”： “hi”}], “sessionid”： “s1”, “agentid”： “host”,}) 宿主自行調用 decision.selectedmodelid對應的模型 await router.report( Feedback.

ok(decision, latencyms=12, sessionid=“s1”, agentid=“host”)) x-router的調用方式在語義上一致，分類器直接運行在本地進程中： from openjiuwen import xrouter router = xrouter.buildrouter(“router.toml”) selection = xrouter.buildrequest( [{ “role”： “user”, “content”： “Compare Raft and Paxos for a five-node cluster.

” }], sessionid=“s-1”, agentid=“my-agent”,) Router會從 decision.selectedmodelid中返回推薦調用的模型decision = router.routesync(selection) Rust宿主可直接靜態鏈接openjiuwen-runtime： use openjiuwenruntime：：{Feedback, RequestMetadata, RouteHint, RouteRequest, Router}； let router = Router：：fromconfig(“config/edge.toml”)?

；let decision = router.route(&req, &RouteHint：：default())?； let mut feedback = Feedback：：ok(req.routingkey(), &decision.selectedmodelid, 40)；feedback.routeid = decision.routeid.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/xrouter/README.md https://github.com/openJiuwen-ai/model-router/blob/main/python/openjiuwen/xrouter/README.md x-router示例： https://atomgit.

com/openJiuwen/model-router/blob/main/examples/xroutercli.py 版權所有，未經授權不得以任何形式轉載及使用，違者必究。