一顆專門做決定的模型
Agent 工作流程裡，大部分的步驟其實不是「寫一段好文字」，而是「下一個判定」：這張支援票急不急、該路由給哪個團隊、這個 domain 是不是釣魚網站。過去這類判定多半丟給通用 LLM，換來的是非確定性輸出與可觀的延遲。Cloudflare 在 2026 年 10 月 1 日發表 Clef 與 Clef-flash 兩顆決策模型，就是針對這個縫隙：輸出有界、結構化、帶機率的分類結果，而不是自由生成文字。
兩顆模型都部署在 Workers AI 上，並以 Apache 2.0 授權開源到 Hugging Face，可直接本地跑。它們也與 Typesafe AI 的 Jev 系統 API 相容，官方說法是可以直接換掉。對 builder 來說，這意味著你現有的分類呼叫幾乎不用改程式碼就能 A/B 一輪。
數字上快在哪
Cloudflare 內部在威脅情報團隊做了一個示範：給 Clef 一個網址、搭配 Browser Run 抓取並渲染頁面，2.2 秒內完成分類並輸出多個類別機率；同樣流程下 gpt-oss-120b 要 4.7 秒，而且只回兩個分類。接近兩倍的延遲差，在需要即時判定的工作流程裡是實際可用的差別。
官方公布的 benchmark 顯示 Clef 在多項任務（如 BANKING77、CLINC150+OOS）分數領先 Jev，Clef-flash 在延遲上尤其突出——中位數 38.8 毫秒，Jev 則是 524.1 毫秒。硬體規格上也有些差異：Clef 帶視覺編碼器、64k 上下文窗口，比目前只做文字分類的 Jev（32k）多一截。
架構上，Clef 用 Qwen 當骨幹，凍結權重後訓練路由頭與 rank-256 的低秩適配器；推論時只做 prefill pass，直接對合法 schema 選項平行打分，非自迴歸的設計省掉逐 token 生成的成本。訓練目標除了 label-smoothed cross-entropy 和 Brier loss，還加上自家的 RLCD，對相鄰的序數選項給部分分數，以改善機率校準。
RL 微調平台：把線上數據變成訓練素材
這次發表另一個值得注意的部分是新的強化學習服務。Cloudflare 先以 FDE（forward-deployed engineer）團隊提供客製微調，之後會開放自助平台，讓客戶自己擷取數據、微調、再部署回 Cloudflare。底層串起的是既有元件：AI Gateway 自動累積請求數據集、Workers AI 產生 rollout、Containers 當 RL 沙盒做評分與重放，最後用新的 Trainer 更新權重再部署。
這條路徑和我先前寫過的 OpenRouter 把線上流量變成回歸測試的做法 思路相通——真正的槓桿不是模型本身，而是你手上累積多年的帶標籤決策資料。Cloudflare 自己就是最好的客戶：超過十五年的網路數據，足以把通用 Clef 微調成 Trust & Safety 審核、支援工單分流、機器人好壞判定這些專用分類器，代價是犧牲一些通用性能換取特定領域的準確度。
該怎麼評估要不要用
幾個務實的判斷點。如果你的 agent 在熱路徑上頻繁做低風險分類（路由、過濾、觸發條件），把這些從 LLM 拆到決策模型，延遲和成本都會立刻受益，LLM 留給真正需要推理與生成的步驟。API 相容讓試換成本很低，先跑一輪你自己的 eval 再決定。
需要留意的限制：這裡的分數都來自 Cloudflare 自己跑的 benchmark（含 Typesafe 的 eval suite），不同工作負載的表現仍需自己驗證；而自助微調平台還沒上線，目前要先走 FDE 的合作路徑。合理的下一步是到 Hugging Face 拉模型本地測一組你自己的歷史分類案例，看看機率校準在你的資料上是否夠穩。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。