前陣子跟一個在幾十人工程團隊工作的朋友聊天，他們正在評估導入 LLM Gateway——一個放在應用程式和模型供應商之間的中間層，自動把不同的請求分流到不同等級的模型。簡單任務丟給便宜的，複雜任務才送去貴的。
這個思路在企業圈現在非常熱。2026 年，光是 LLM Gateway 這個品類就冒出了至少十幾個產品在搶市場——Bifrost、LiteLLM、Portkey、OpenRouter、Azure AI Foundry Model Router——每一家都在賣同一個故事：「用我們的 routing，你可以省 30-40% 的 AI 成本。」
我完全理解這個需求。幾十個工程師每天都在呼叫 API，月底帳單一攤開，老闆的臉色不會好看。找一個系統化的方式控制成本，是很自然的反應。
但我讀了一圈這些方案的技術文件之後，總覺得有幾個結構性的問題，大家好像都在繞著走。
判斷任務有多難，本身就是一個很難的任務
所有 routing 方案的核心邏輯都一樣，RouteLLM 的作者講得最直白：「每個請求都帶著一個隱含的難度；routing 層估計這個難度然後分配。」
聽起來很合理。但問題來了：誰來估計難度？
如果用規則式路由——按 endpoint 分、按字數分、按客戶等級分——那不是「理解任務」，只是把人的猜測寫成 if-else。你猜對了就省錢，猜錯了就把難題丟給弱模型，然後等著下游出事。
如果用 ML 分類器來判斷難度呢？那你需要一個夠聰明的模型來理解「這個問題有多難」。但判斷問題的難度，本身就是一種高階認知能力——你需要接近能解決這個問題的能力，才能正確評估它有多難。
這不是我的推論，這是心理學上被反覆驗證過的結構：Dunning-Kruger 效應（達克效應）告訴我們，能力不足的個體同時缺乏評估自己能力不足的後設認知。套到 routing 上——如果你的 router 不夠強，它看不出一個問題的深度，就會把它當簡單任務分給便宜模型。而那些被錯誤分流的，恰好是最需要強模型的請求。
所以大多數企業 Gateway 最後退化成什麼？規則式路由。按 endpoint、按 token 數、按用戶等級。這不是「智慧分流」，這是流量管理——跟 CDN 做的事差不多，只是套了一層 AI 的皮。
帳單省了 41%，但沒人算另一筆帳
TrueFoundry 的技術文章裡有一個很有代表性的案例：一個叫 Omar 的平台工程師，花了一整季建了一套 router，成功把公司的 LLM 帳單砍了 41%。
41%。這個數字寫進季度報告，絕對是漂亮的。
但文章自己接著說了一句很關鍵的話：「Omar’s router wasn’t wrong; it was unobserved.」（Omar 的 router 沒有錯，是沒有被觀測。）
另一篇 routing 技術分析也直接點出來：「靜默品質退化是隱性稅——routing 到更便宜的模型，可能以客戶工單的形式在幾天後才浮現，而不是在 dashboard 上。」
這裡有一個成本計算的結構性不對稱：
API 帳單是可見的、即時的、可量化的。每個月的數字清清楚楚，可以做成圖表，可以跟老闆報告「我們省了多少」。
但弱模型產出的問題造成的後續成本——code review 沒抓到的邏輯漏洞、幾週後才浮出來的架構問題、為了修補而多開的 session、因為品質不夠而多做的人工檢查——這些是分散的、延遲的、難以歸因的。你很難把某個 bug 回溯到「三週前那個請求被分給了 Haiku 而不是 Opus」。
所以組織看到的帳面是「我們透過 routing 省了 40% 的 AI 成本」，看不到的是「工程師多花了 30% 的時間在修補和驗證弱模型的產出」。前者有 dashboard，後者沒有。
經濟學家 Charles Goodhart 在 1975 年就講過這件事——後來被稱為 Goodhart’s Law（古德哈特定律）：「當一個指標變成目標，它就不再是好的指標。」 當「AI 成本」變成被優化的 KPI，它就不再是整體效率的好代理了。組織以為自己在優化效率，其實只是在優化一個可見的數字，而那個數字跟真正的效率之間的相關性，正在因為你的優化行為而瓦解。
不只是強弱：你在兩種思維模式之間跳來跳去
上面講的還只是同一家模型的不同等級——Haiku vs Sonnet vs Opus。但有些團隊更進一步，用 Gateway 在不同世代、甚至不同家的模型之間做分流。
這就碰到一個更深的問題：不同模型之間的差異，不只是「能力的強弱」，可能是認知模式的根本不同。
拿最近的例子來說。Fable 5 這個等級的新世代模型，行為模式像管理者——它會全局評估、主動做決策、在你沒給指示的地方自行判斷。而 Opus 4.x 更像工程師——在你給定的範圍內精確執行，不太會越權。
Router 在這兩者之間做分流的時候，它以為自己在做的是「同一件事交給比較厲害或比較不厲害的人」。但實際上，它是在把任務交給用完全不同方式理解這件事的人。
這導致一個很荒謬的場景：你的同一個專案，前半段可能是「工程師」寫的，後半段被交給「管理者」繼續。管理者看了工程師的產出，覺得太保守、沒做全局優化，於是自己做了一堆「改進」。但這些改進的方向，跟使用者原本跟工程師建立的共識完全不同。
或者反過來——管理者做了全局性的架構決策，下一段被交給工程師，工程師看不見那些決策背後的意圖，只在局部做精確的修補。
而且新世代模型的失敗模式是隱性的——它不會報錯或卡住，它會交出一個邏輯自洽、功能完整、但方向偏掉的東西。所以 Router 分流產生的偏差，在交回弱模型繼續開發的時候，弱模型不會察覺那是偏差——它會當成既有決策繼續往上蓋。
技術債不是累積在表面的，是埋進地基裡的。等你發現的時候，通常是以「找不到原因的 bug」或「重構才發現的架構問題」的形式浮出來。到那時候，沒有人會想到要回去查「那天 router 把哪個請求分給了哪個模型」。
組織變小了，但複雜度沒有
很多企業導入 AI 的敘事是這樣的：AI 提高效率 → 需要的人變少 → 組織變精簡 → 管理成本下降。
但這個推論有一個隱藏的前提不成立：管理的對象是人數。
如果管理的真正對象是「行動者的數量」，那結論就要反轉——AI 時代的組織，人變少了，但行動者暴增了。一家 10 人公司，如果每個人指揮 20 個 agent 在跑，這個組織的「行為總量」相當於一家 200 人公司。而且這 200 個行動者比人類員工更難管：它們不會覺得不對勁時來敲你的門，不會累積默契，不會因為做錯事而感到不安，而且 7×24 不間斷地產生決策。
人類組織的管理有一大半其實外包給了社會性——同儕壓力、職業聲譽、常識判斷、午餐時間的閒聊裡順便對齊的認知。這些免費的治理基礎設施，agent 一項都沒有。
所以你省下的是管「人」的 SOP，卻要新建管「agent 行為」的機制——Gateway、trace、evaluation、預算控管、品質閘門。它們不是舊官僚的殘留，是新族群的戶政系統。
而且法律和商業契約只認人。出了事，法院不會傳喚 Opus 出庭，客戶不會接受「是 agent 自己決定的」。組織可以縮小，但責任必須收斂到越來越少的人頭上——10 個人要為 200 個行動者的行為負責。每個人背負的責任密度變高了，而責任密度越高，那個人就越需要可稽核的證據鏈來保護自己。
以前是公司逼你填表，以後是你自己要求系統留下 trace——因為那是你的不在場證明。
真正該路由的不是模型，是注意力
我不是說 Gateway 完全沒用。流量管理、故障轉移（failover）、成本可視化、跨供應商的 API 統一——這些是基礎建設的價值，跟「智慧分流」沒關係，但確實解決了真實的工程問題。
我有意見的，是那個核心敘事：「讓系統自動判斷什麼任務該用什麼模型，就能省錢又不掉品質。」
這個敘事的問題跟我在上一篇文章裡討論的蒸餾迷思是同一個結構——都是想把需要人類判斷的決策，轉換成系統可以自動執行的規則。個人版是「把強模型的判斷力寫成文件給弱模型用」，企業版是「用 router 自動分配任務給便宜模型」。兩條路碰到的天花板一樣：真正需要判斷的那個環節，恰好是最不適合自動化的。
但話說回來，某種程度的自動化確實是必要的——幾十個工程師每天幾千次 API 呼叫，你不可能讓技術主管 一個一個審核「這個請求該用哪個模型」。所以問題不是「要不要自動化」，而是你自動化的是哪一層。
Gateway 真正有價值的部分——故障轉移、統一 API、成本可視化、限流（rate limiting）——這些是 plumbing（底層配接處理），完全該自動化，就像你不會手動管 DNS 一樣。但這些功能很無聊，不好賣。所以廠商把「intelligent routing」（智慧路由）包裝成核心賣點，彷彿系統可以替你判斷什麼任務該用什麼模型。客戶買的不只是產品，是那個敘事：「你不需要自己判斷了，系統會幫你選。」
這裡有一個微妙但重要的區別：企業不是在試圖自動化判斷，是在試圖迴避判斷。
自動化判斷是一個技術問題，可以討論可行性。迴避判斷是一個組織行為問題——買一個工具比訓練團隊理解不同模型的脾性容易得多。採購一個 Gateway 是一個決策，培養三十個工程師的 AI 判斷力是三十個持續的過程。前者有預算單可以簽，後者沒有。
我之前寫過一篇關於「第二注意力」的文章——核心論點是，在 AI 輔助的認知系統裡，有三層：儲存、檢索、以及決定聚焦方向的中央執行系統。前兩層可以也應該外包給工具，但第三層——「決定讓 AI 看什麼、用什麼方式看」——是整個系統裡最不該被自動化的部分。
Gateway 做的事情，正好是試圖自動化這個第三層。在個人場景裡，第三層是「你決定讓 AI 看什麼」；在企業場景裡，是「你決定讓哪個模型做什麼」。兩個都是注意力分配的問題，而注意力分配恰好是人類認知裡最核心、最不可壓縮的功能。
所以如果要找一個務實的方向，可能不是更好的分流演算法，而是更好的職責劃分——把模型選擇的決策權推到離脈絡最近的人手上，Gateway 只負責執行那個選擇和記錄結果。技術主管替自己的領域選模型，系統負責 plumbing。判斷是人的，水管是系統的。
Gateway 作為一個過渡方案是合理的——它讓你在團隊還沒建立 AI 判斷力的時候先跑起來。但如果你把它當終點，就會永遠在用自動化迴避那個你終究要面對的問題：你的人到底懂不懂他們在用的工具。
Gateway 解決的是 底層配接問題，但它卻被當成 評判（judgment）問題的解法在賣。而真正的 評判問題，目前還沒有捷徑。
（話說回來，「省了 41% 然後沒人追蹤品質有沒有掉」這件事，好像不只是 AI 的問題。這大概是所有 成本最佳化 專案的通病——省錢的功勞有人搶，品質劣化的咎責沒人扛。AI 只是讓這個老問題多了一個新的舞台而已。）
參考資訊：
- RouteLLM routing 原則與 cost-quality tradeoff 分析（Digital Applied）
- TrueFoundry, “Intelligent LLM Routing: Cost & Quality-Aware Selection”（TrueFoundry Blog）
- Goodhart’s Law 與 AI alignment 的關係（LessWrong）
- LLM Gateway 市場概覽與比較（FloTorch）
- 從「第二大腦」到「第二注意力」（DOFI Blog）
