決策模型正悄悄取代代理迴圈中的 LLM
Cloudflare 在十月初推出兩款「什麼都不寫」的模型。Clef 與 Clef-flash 會讀取一筆輸入加上一組帶型別的題目，然後為每個允許的答案回傳一個機率值。沒有散文、沒有思維鏈、也不是一次生成一個 token，只有一個結構化的選擇。
這聽起來像是降級，直到你看到數字。在 BANKING77 這個標準的意圖分類基準上，Clef 的 macro-F1 達到 94.20，而開創決策模型這個類別的 Jev 只有 79.74。較小的 9B 版本 Clef-flash 也有 90.93。延遲差距更大：Clef-flash 的中位數回應時間是 38.8 毫秒，Jev 則要 524.1 毫秒。Cloudflare 表示，在十項決策基準中，Clef 有七項勝過 Jev。
兩款模型都以 Apache 2.0 授權在 Hugging Face 上發布，而且都相容於 Jev API，因此已經圍繞 Jev 建構系統的團隊不必重寫整合就能直接切換。Hacker News 上的討論串在一天內就累積了 602 分與超過 200 則留言。
為什麼更小的模型能在更窄的工作上勝出
決策模型與多數開發者慣用的聊天機器人形狀不同。大型語言模型生成開放式文字；決策模型讀取一個狀態與一份允許答案清單，然後為每個答案評分。這個類別由 Typesafe AI 以 Jev 開創，證明了代理路由或分類任務並不需要 400B 的通用模型，它們需要的是有界、便宜、快速的輸出。
Cloudflare 的 Clef 建構於 Qwen3.8-27B 之上，採用僅預填（prefill-only）的架構，平行為各種 schema 選項評分，而非循序生成 token。延遲的差異就出在這裡。通用模型必須一個 token 接一個 token 地吐出答案；決策模型只要讀完問題然後定案。
還有一個值得注意的脈絡視窗差異。Clef 在 64k token 的視窗內接受多模態輸入，涵蓋文字、JSON、影像與影片。Jev 只處理文字，且為 32k。對於需要依據螢幕截圖或 PDF 做路由的代理來說，這可不是小優勢。
社群的第一個質疑，正好切中要害
Hacker News 討論中最有價值的反駁並不是質疑基準數據，而是質疑標籤。一位留言者寫道：「是開放權重，不是開源。」權重採用了寬鬆授權，但訓練資料與流程並未公開，因此無法從零複製這個模型。
對於任何要決定把這東西跑在哪裡的人來說，這個區別很重要。Clef 是以專有的 Qwen 作為起點訓練而成。權重可以免費下載與自行託管，這確實省下實質成本，但它並不像開源軟體那樣可被稽核。供應鏈審查政策嚴格的團隊，應該先讀過授權條款與模型卡，別以為掛上 Apache 2.0 就等於問題解決了。
同一週，Amazon 也把一個放進了你的筆電
Cloudflare 並非孤軍奮戰。AWS 的 Strands Labs 發布了 Strands Decider 2B，這是一款開放決策模型，附有權重與訓練腳本，設計成可在地端執行，並在數十到數百毫秒內回傳附帶信心分數的選擇。Cloudflare 也為 Workers AI 上的決策模型新增了 RL 微調服務。
這個模式就是：讓小模型把一件事做好，並且跑在靠近資料的地方。如果你能用一個 2B 模型在 40 毫秒內判斷某個工具呼叫能不能放行、驗證某個請求是否有依據，或決定要不要升級處理，那麼讓代理的每一步都繞道前沿模型，在成本效益上就開始顯得浪費。
Jev 開創的典範，以及為何花了一年才被接受
Typesafe AI 的 Jev 在推出時提出了一個很容易被忽視的主張：代理請模型做的大部分事情都不是生成，而是分類。把這張工單路由到哪裡、選哪個工具、判斷這個動作是否需要核准。對這些工作而言，一個會寫出整段文字的模型，做了遠比任務所需更多的事。
Jev 證明了這種窄用途做法能在自己的基準上擊敗通用模型。它做不到的，是讓這個類別顯得迫切。單一廠商賣一款決策模型只是個新奇玩意；Cloudflare 推出相容於 Jev API 的 Apache 2.0 版本，情況就不同了，因為現在任何人都能自行託管、檢視授權，並且不必重寫就能替換進來。Amazon 在同一週帶著自家的開放決策模型登場，則把好奇變成了類別。
這個時機正好對上代理實際被建構的方式。第一代代理框架把每一步都導向同一個大型模型，因為那最簡單。當這些系統進入正式環境，路由成本就成了團隊注意到的問題。把迴圈拆成「需要語言的部分交給語言模型、不需要的部分交給決策器」是顯而易見的解法，而要讓它變得可行，得先有一個優秀決策器開源釋出。
微調的角度
Cloudflare 也為 Workers AI 上的決策模型新增了 RL 微調服務，這指出了這個類別的下一步。通用的決策器很有用；針對你自己的路由歷史、你自己的升級規則、你自己對範圍的定義微調過的決策器更有用，因為它學會了對你的業務真正重要的那條界線。
這也正是應該讓團隊提高警覺的部分。微調過的決策器會把你過去的決策編碼進去，包括那些糟糕的決策。如果你的團隊以前會核准本該升級處理的退款，模型就會學到這個模式，並且以人類永遠比不上的速度套用它。校準是一把雙面刃。
這在代理流程中適合放在哪裡
想像一個處理退款的客服代理。在它呼叫退款工具之前，必須有人回答這些問題：這個請求是否在範圍內、客戶的帳戶是否允許、這是否需要真人處理。這些都是有固定答案選項的決策問題。決策模型可以回傳機率，代理再依門檻行動。
成本結構才是重點。把每一個檢查都送去 400B 模型，每次呼叫都要花錢，還會增加數百毫秒的延遲。把這些工作卸載到本地的 2B 或 9B 決策器，就能把前沿模型留給真正需要語言的部分：撰寫回覆、摘要一長串對話、處理模稜兩可的情況。預算與延遲預算都能一起縮小。
但有一個陷阱。決策模型回傳的是機率，而機率有可能以很有自信的方式出錯。如果你用 0.92 的分數自動核准退款，你只是把風險從模型的措辭轉移到你的門檻上。該盯的數字變成校準度，而不是原始準確率。延遲與成本很容易量測；一個校準良好的 0.9 就難多了。
接下來值得觀察什麼
工具鏈已經開始跟上這些模型。llama.cpp 新增了對決策模型的支援，Perplexity 與 Hugging Face 也都朝同一個方向下注。如果這個類別站得住腳，有趣的問題就不再是哪個決策模型在基準上勝出，而是你願意把哪些決策交給一個機率來決定。
對代理開發者來說，實際的做法是審視整個迴圈，找出那些從來不需要流暢文字的步驟。分類、路由、工具選擇與動作前檢查是常見的候選項。在這些步驟上，用固定選項清單換來 40 毫秒的答案，就能取代一次緩慢又昂貴的生成。代理的其他部分則可以繼續使用原本的模型。