假設一張 support ticket 只有一句「又進不去了」，底下貼了一張錯誤畫面的截圖。對人來說，通常會先看圖：是在登入頁、付款頁，還是連網站都沒打開？接著才知道要問什麼、找誰處理。
我在看 Cloudflare Clef 時，想到的是這種 enterprise agent：它不一定要寫 code，卻可能每天反覆讀 support ticket、看附件、判斷下一步。這些地方如果只需要幾個已知答案，decision model 有沒有機會把流程縮短或者加速整個處理流程？這其實是上一篇談 Jev 的同一個問題，只是這次 Clef 能提供給使用者更多東西。
這篇先看截至 2026 年 10 月 2 日的公開現況，以及我認為值得嘗試的方向。還沒有實測，下面的流程例子也都是假設。
Clef 和 Clef-flash 現在在哪裡
Cloudflare 在 10 月 1 日發表 Clef 與 Clef-flash，兩者都已提供 Workers AI 託管入口。(官方公告)
Clef 是以 Qwen3.8-27B 為基礎做 post-training 的 27B 模型，保留 vision encoder。它讀取 state 與問題 schema，對每個允許的答案輸出機率。公開的權重、joint schema head 與推論程式採 Apache 2.0 授權，可以自行部署；這不等於整套訓練資料與流程都已公開。(Clef model card)
Clef-flash 則以 Qwen3.5-9B 為基礎，是同樣支援多模態、使用相同決策介面的較小型號。官方把它定位在較重視延遲的情境。型號比較小，並不能直接推論它在每個任務都比較差，還是得看實際問題。(Clef-flash model card)
對開發者來說，這裡多了兩條路：先用 hosted API 驗證問題，也可以下載模型，自己決定部署方式。後者當然也把 GPU、服務維運和容量規劃一起帶回來了。
它想加速哪一段工作
先把問題縮小一點。那張截圖現在不需要一篇詳細診斷報告，流程只想知道「問題屬於哪一類」「畫面有沒有足夠線索」「應該送到哪個 queue」。
Clef 的做法，是先讓 Qwen backbone 讀取輸入，再透過專用的 head 對 schema 裡的選項評分。Cloudflare 說明這個 decision step 採 non-autoregressive 方式，不必先逐 token 生成中間文字，再從文字取出答案。(架構說明)
因此，它主要想改善的是這種固定答案範圍的判斷成本。讀取 context 和圖片本身仍然需要計算；如果前面抓資料很慢，換了 decision model 也不會自動解決整個 workflow 的延遲。
介面延續 Jev／System One 的 choice、noul、score：選類別、回答是非機率、依照有序標準給分。這讓原本已經拆好問題的程式有機會沿用結構，但模型換了之後，判斷表現與 threshold 還是要重新驗證，不能只看 request 能不能成功送出。
多了圖片之後可以做什麼
回到那張假設的 support ticket，可以把文字和截圖一起送進去，詢問畫面是否包含登入錯誤、是否需要補充資訊，再從已知類別選一個 routing 結果。這樣就有機會減少先把整張圖描述成長文、再分類的一道步驟。到底少多少延遲、會不會漏掉重要細節，都還需要測。
不過目前 model capability 和 hosted API 要分開看。公開推論程式提供圖片及影片 frame arrays 的輸入方式；Workers AI 目前列出的 schema 則接受最多四張內嵌圖片，不接受遠端圖片 URL，也沒有列出 video 欄位。不能看到模型支援影片，就直接假設託管端點也能照樣呼叫。(本機輸入方式、Workers AI 參數)
另一個可以試的方向是文件前處理。例如附件屬於哪種文件、影像是否可讀、指定欄位有沒有出現在畫面裡，再決定送往哪一條既有流程。精確金額計算仍然交給程式；需要核准的操作，也必須走原本的權限與審核機制。
這裡同樣要把「沒提供資料」做成明確狀態。如果截圖根本沒拍到錯誤訊息，合理的下一步是請人補圖。模型在幾種類別之間猶豫，則可能要交給其他模型或人工。兩種情況都會讓流程暫停，但需要的補救方式不一樣。
接下來可能發展出來的野蠻生長
Cloudflare 已經公布由 FDE 團隊協助 fine-tuning 的服務方向，self-serve 平台則是後續規劃。(服務說明)
順著這個方向，我個人的推測是：企業可能會逐漸把自己常做的判斷，整理成可以反覆評估的 schema 與資料集。例如什麼樣的 support ticket 適合送哪個 queue、哪些附件必須補件。模型選擇或 fine-tuning 才有一個比較明確的目標，而不是先把模型接進 agent，再期待它自己找到用途。
Clef-flash 也讓我想到分段處理的可能：先處理已驗證表現穩定的類別，把其他 case 交給較大型模型或人工。不過，兩個模型可能會犯相似的錯，還要看轉交是否真的改善結果；不能把第二個模型當成自動保險。
我目前會先找一條小流程驗證。除了 accuracy，還要一起看 p95 延遲、漏分與誤分的代價，以及最後有多少案件需要人工處理。自架和 hosted API 也要在各自的實際部署條件下測，不能把公開 benchmark 的數字直接當成上線承諾。
如果這些條件能成立，Clef 可能成為 enterprise agent 裡一個很實際的元件：持續讀取文字和視覺狀態，替流程提供範圍明確的判斷。接下來值得看的，就是它能在哪些工作上穩定省下一段時間，以及省下來的時間有沒有換來更多例外處理。