2026 年 10 月 1 日，Cloudflare 的 Michelle Chen、Alex Reneau 與 Kevin Flansburg 在官方部落格發布了〈Introducing Clef: our open-source decision models, and new RL fine-tuning platform〉。這篇 Cloudflare Clef 發表文把一個問題推到檯面：當 AI Agent 只需要在既定選項間作決定，還需要讓大型語言模型先寫出一段文字嗎？作者給出的答案是 Clef 與 Clef-flash；本文先整理機制與證據，再看它適合放進哪些決策流程。
Cloudflare Clef 的核心：把判斷變成有型別的輸出
Today, we’re releasing two Cloudflare-trained decision models, Clef and Clef-flash,
中文：今天，我們推出兩個由 Cloudflare 訓練的決策模型 Clef 與 Clef-flash。
Cloudflare 發表文
這次發布的實體可以分開核對：Clef 的 Hugging Face 模型卡列出約 27B 參數與 Apache 2.0 授權；Clef-flash 模型卡列出約 9B 參數，也採 Apache 2.0。兩者都能下載權重，Workers AI 文件也列出託管的 Clef 端點、文字與圖片輸入，以及 65,536 token 的上下文上限。這些是可查到的產品狀態；「放進任何代理都更快、更準」則不是模型卡所能直接證明的結論。
Clef 接收一份狀態和一組事先定義的問題，例如「是否緊急」、「交給哪個團隊」、「嚴重程度」。它對每個允許選項回傳分數與機率，程式再依門檻選擇動作。這和讓聊天模型自由生成一份分析報告不同：可用的答案空間先由應用程式畫好，模型負責在其中評分。
為什麼可能更快：少了一段逐字生成
there’s no intermediate text to generate token by token
中文：中間不需要逐字生成文字。
Cloudflare 發表文
原文描述的路徑是：用 Qwen 骨幹讀取輸入，再由專門的 schema head 一次評分有效選項；公開模型卡的架構與檔案清單可見 joint head 與選項 logits，與這個機制一致。Clef 採 Qwen3.8-27B，Clef-flash 採 Qwen3.5-9B。省掉逐字生成，確實能縮短「等文字輸出」這段時間；但端到端延遲還包括影像處理、網路、排隊、前處理與較大模型的計算。
Cloudflare 用網站分類示例稱，Clef 的擷取、渲染與分類花 2.2 秒，同流程的 gpt-oss-120b 花 4.7 秒。這是供應商報告的單一工作流程，模型大小與輸出任務也不同；它能說明可能的部署價值，不能推成所有任務都會快兩倍。
跑分有亮點，也有反例
Cloudflare 把 Clef 放進 Decision Index 0.2.1 的內部測試。公開模型卡的完整表格顯示其中位延遲為 Clef 209.3 毫秒、Clef-flash 38.8 毫秒、Jev 524.1 毫秒；但這些是該次測試的請求延遲，不含你自己系統的網路與排隊條件。原文圖例也把 Cloudflare 的兩個點標成 self-reported，其他開放模型標成 board-validated，提醒讀者資料來源並不完全相同。
同一份表格也有不利於 Clef 的題目：When2Call 準確率 Clef 72.4%、Jev 81.0%；GPQA Diamond 為 48.0% 對 78.3%；BRIGHT 的 nDCG@10 為 45.9 對 47.5。這不代表 Jev 在所有工作都更好，而是「最快」與「最準」都必須附帶測試集、指標和系統條件。四項業務工作流程裡，Cloudflare 表格的 Agent trace observability 主動作分數也由 Jev 領先。
開放權重與微調服務，是兩個不同的承諾
模型卡已提供權重與授權；這讓團隊有機會在自己的環境檢查推論程式、資料流與成本。Cloudflare 的模型卡寫明本機範例曾在單張 H200 上測試，這是重現環境的線索，並不代表每台電腦都能輕鬆執行。開放權重也不自動解決機率校準、資料偏移與錯誤動作的責任歸屬。
另一個容易混淆的地方是微調。原文目前提供的是與 Cloudflare 工程團隊合作的人工協助服務；自行收集資料、微調並重新部署的自助平台被描述為後續規劃。原文的流程圖把 AI Gateway 收集、Workers AI 生成、Containers 評分、Trainer 更新權重和重新部署串起來；這張圖更像產品方向圖，不能當作每個環節都已向所有客戶開放的證明。
我的判讀：真正要量的是錯誤決策的總成本
機率可以排序，未必已校準
模型對「技術支援」給出 0.9，可以拿來排序工單；要把 0.9 解讀成長期十件中九件正確，還需要以自己的標註資料做校準檢查。尤其是資安封鎖、帳戶停權或交易攔截，誤判成本遠高於多花幾百毫秒。比較模型時，除了準確率，還要看錯誤種類、棄權率和人工覆核量。
輸出受約束，決策風險仍在
typed output 讓程式更容易接住結果，也降低自由文字解析造成的錯誤；它沒有保證輸入標籤完整，更不能保證行動本身可逆。若「其他／未知」沒有被設計進選項，模型再有信心也可能只是從錯的菜單裡挑一個。這也是為什麼高風險流程應讓模型先建議、後由明確規則決定何時交人工。
部署位置決定省下的時間能否留下來
一個 9B 模型在特定推論設定下的毫秒數，不能直接外推到跨區域 API、含圖片的長輸入或尖峰併發。把同一批真實任務分別送入現有系統與 Clef，記錄 p50、p95、費用和錯誤處置時間，才知道它省下的是推論時間，還是整條工作流的時間。
我同意原文最有價值的方向：當任務是固定選項的判斷，專門的決策器值得與生成模型分工。我存疑的是把供應商自己的跑分與「更快決策」直接延伸成通用優勢。對團隊來說，下一步是挑一個可回滾的低風險分類節點，用固定的未見過樣本對照原流程，先畫出準確率、棄權率和延遲的取捨，再考慮把輸出接到自動動作。
接著閱讀
左右滑動查看更多推薦
如果你正在評估 Cloudflare Clef，先寫下現有流程最貴的一種錯誤，再決定要量哪個指標；只有當這個錯誤被控制住，速度的改善才有實際價值。