Cloudflare 在 AI Gateway 中推出 Auto Router 公開測試功能，開發者把模型名稱設為 cloudflare/auto，系統就會針對每一次請求自動挑選模型。InfoQ 於 2026 年 10 月 26 日由 Steef-Jan Wiggers 報導此事，點出這類產品的核心難題：團隊過去多半只能在成本與品質之間選一個固定模型，但真實應用的請求難度差異很大，昂貴模型用於簡單查詢造成浪費，便宜模型用於高風險操作則可能帶來更高的修正成本。Auto Router 試圖把「選模型」從靜態設定變成逐次判斷，而判斷依據不只是任務類型，還包含請求的複雜度、模糊程度、利害程度，以及對前文脈絡的依賴。
路由的運作方式與評分維度
Auto Router 的路由分成兩個階段。第一階段由 AI Gateway 建立候選模型池，先過濾掉無法處理該請求格式的模型，再套用憑證、計費設定、存取控制與支出上限等條件。也就是說，不是所有可用模型都會進入評分，而是先依團隊既有的治理規則縮小範圍。第二階段則在 Workers AI 上執行一個多頭分類模型，運行於 Cloudflare 的邊緣 GPU；這個模型會輸出 14 種任務類別的概率，並針對四個維度給予 1 到 5 分的評分，分別是複雜度、模糊性、利害程度，以及對較早對話內容的依賴程度。
分類結果會進入一個評分矩陣，與基準測試結果結合，Cloudflare 公布的公式是 utility = expected quality - adaptive cost penalty，也就是預期品質減去隨情境調整的成本懲罰。候選模型會依其在該任務類別上的強項，以及處理較困難工作時可望帶來的品質增益來評分；工作越困難，價格在評分中的權重越低。這樣的設計意味著 Auto Router 並非單純比價，而是先判斷請求需要多少能力，再決定成本應該佔多大比重。
值得注意的是，分類器只讀取最近幾輪對話，且文字上限為 8 KiB。這讓判斷更便宜、更快速，也避免把整段長對話塞進分類模型，但同時產生一個實務上的關鍵限制：早期對話中出現的重要背景，可能在後續短指令中被稀釋。
基準數字與風險分類的實務爭議
Cloudflare 公布了一組基準結果，涵蓋 97 個任務、每個模型三個樣本，並進行 10,000 次 bootstrap 重抽樣。結果顯示，大約三分之一的支出可以換來十個百分點的可靠性提升。這個數字的意義在於，路由的價值不只是在帳單上省錢，而是讓團隊判斷自己願意用多少成本換取多少穩定度。一位從事代理式工程（agentic engineering）的技術長 Jacques B 在 Cloudflare 的 LinkedIn 討論中指出，如果便宜模型產生的結果還需要有人再花一小時修正，那省下的費用其實很有限；Cloudflare 公布的數字正好把這種隱形成本放回檯面。
不過，最尖銳的回應來自風險分類。曾參與銀行與醫療平台開發的技術主管 Igor Pyrin 指出，利害程度是從偏好近期輪次的精簡檢視來評分。在長時間的代理工作階段中，使用者可能一開始就說「這是客戶退款」，之後只補一句「繼續執行」。若系統只根據最後那句話判斷，短指令可能讓底層動作的風險等級被默默調低。他建議由應用程式自行維護一個跨輪次的風險標籤，用來決定該請求是否可以使用 cloudflare/auto；真正承諾動作的那一輪，往往在對話中看起來最便宜、最不需要高階模型，但實際上卻是風險最高的一刻。
這個問題並非文件瑕疵，而是逐次路由的結構性挑戰。請求的語意風險經常分散在整段對話中，最後一輪只負責確認；若分類器只看到最後幾輪，就可能低估動作的後果。對需要稽核或合規的場景而言，這種低估比多花一點模型費用更難處理。
可稽核性、候選池與基準重現
Cloudflare 在文件中補充了兩項有助於事後檢查的機制。回應會帶上 cf-aig-routed-model 與 cf-aig-routing-reason，後者的值包括 cost_optimal_within_pool、pinned_by_turn 等，讓團隊能在請求結束後確認實際選了哪個模型、以及路由原因。候選池也可以透過 cf-aig-allowed-models 與 cf-aig-allowed-providers 這兩個標頭，按單次請求限制可用模型與供應商；不過這樣做不能儲存成可重複使用的路由設定檔，這正是 Adam Natad 在發布討論串中提出的需求。
另一個需要留意的地方是預設池與基準表格之間的落差。目前預設池列出 Claude Opus 5、Sonnet 5、Fable 5，以及 GPT-5.6 Luna、Sol、Terra 與 Grok 4.5；但基準表格中的兩個基線 Opus 5.5 與 GPT-6 Sol 位於 opt-in 清單，只能透過前述標頭觸及。Cloudflare 表示候選池「可能隨時間改變」，因此這可能是池子漂移而非刻意設計。對於想重現基準數字的團隊來說，應先確認自己的 gateway 實際會選到哪些模型，否則基準與實際行為可能對不上。
Session 處理也會影響成本。若請求沒有帶 session ID，同一段對話中的請求可能落到不同模型，因而無法重用提示快取。Cloudflare 為此套用切換懲罰，且懲罰會隨脈絡長度增加；原因是新模型可能得重新處理推理 token，而這些 token 是以輸出價格計費。換句話說，路由本身也會產生狀態切換的成本，逐次選擇最適模型不一定等於整體最省。
社群質疑與目前限制
在 Reddit 討論中，使用者 reachjalil 直接反對自動路由的前提，認為這類系統「最終會讓你花更多錢、換到更少的智慧」，並主張若結果重要，使用能力足夠的模型反而更便宜。另一位使用者 yangqi 則回應，計算單位應該是任務，而不是單次請求。reachjalil 後續的論點則觸及 Cloudflare 也承認的一點：分類本身對大型模型而言比較容易，而路由權重會過時，尤其在模型不斷變化的情況下。報導指出，路由權重來自基準測試結果，新模型必須手動加入評分矩陣，這表示自動路由的自動化範圍僅限於推論當下，模型清單與評分基礎仍需要人工維護。
目前 Auto Router 在測試期間免費，之後的定價尚未公布。它不支援 WebSockets，僅支援 Chat Completions 與 Responses API。Cloudflare 也把 cloudflare/auto-best 列在發展藍圖中，這個模式會使用相同的分類器與候選池，但選擇預期品質最高的模型，不做成本取捨。
整體來看，Auto Router 把模型選擇拆解成任務分類、四維評分、成本懲罰與候選池治理，讓每次請求都能被獨立判斷，也提供事後稽核的路由原因。它的限制同樣清楚：只讀取近期輪次與有限文字，可能低估長對話中的累積風險；没有 session ID 時，快取與模型切換會增加成本；候選池與基準模型可能不一致；路由權重仍需人工更新。對團隊而言，真正的問題不是「自動路由能不能省錢」，而是能否把風險標籤、對話狀態與可稽核性一起納入設計，否則省下的單次費用，可能在下一次修正或合規檢查時付回去。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。