Agent 執行工具之前，先把這次請求和事先列好的選項交給決策模型，取回每個選項的機率，再由程式決定執行、擋下或問人。這篇說明我們怎麼設計這道關卡、20 筆測試的結果，以及要選託管服務、開源權重還是自己讀 logit。
本系列第 5 篇｜這篇回答：該不該用決策模型替工具呼叫守門，以及要選託管、開源權重還是自己讀 logit？
Agent 為什麼需要先問再做
工具呼叫在執行前，應該先在固定的幾個選項上得到機率，再由程式決定怎麼做；決策模型負責給機率，不負責改寫政策。
Agent 會刪檔案、送網路請求、讀設定，有些動作無法復原。決策模型適合在執行前做這種判斷，因為它一次前向計算就停，不生成文字，也沒有回答需要解析（定義與原理見第 1、2 篇）。
我們的決策模型用戶端把守門拆成兩題。action 是 choice，四個選項各有定義：allow 是安全可逆、或政策已明確允許的本機讀取；deny 是違反常設政策，例如破壞性刪除、外洩密鑰、未授權存取；escalate 是邊界情況或高影響，要由人或政策負責人判斷；ask_user 是缺少同意或意圖不明，先問使用者。high_risk 是 noul，問執行後是否可能造成資料遺失、對外副作用、憑證外洩或不可逆改變。呼叫失敗時，回落成 action 為 escalate、high_risk 為 true。
可以把它想成門口放著四張印好的單子，守衛只能蓋其中一張，不能當場另寫規定。
預設是 shadow 模式，只記錄、不攔截；改成 enforce 需要兩個明確開關，出錯一律 fail closed（當成不放行）。工具輸入預設只送本機端點，檔案內容先截到 2,000 字，shadow 記錄只留 200 字。還有一點容易忽略：「是不是 loopback」不等於「資料有沒有留在本機」，本機上轉發到另一台機器的連接埠，一律當成遠端處理。
規則先行，模型只能收緊
常設規則先給底線，決策模型只能把判決改得更嚴，不能放寬。
嚴格度由低到高是 allow、escalate 與 ask_user（同一層）、deny；合併時取兩者中較嚴格的那個，high_risk 也不得低於規則給的值。這條規則來自一次程式審查：早期草稿允許模型把 escalate 放寬成 allow，審查時改掉了。
規則底線是相鄰 token 的正規表示式，加上線性的 token 掃描，任一命中就 deny，所有比對都是線性時間。它經過連續六輪程式審查，處理過截斷盲點、ReDoS、可被填充繞過與解析差異。即使如此，它仍是盡力而為的黑名單，不是安全邊界。
個資欄位只能加、不能刪
同一套「只能收緊」的原則也用在個資欄位稽核：決策模型投的是第二票，只能新增疑似欄位，不能移除。在 2026-10-11 的合成測資難組（欄位名稱經過偽裝）中，決策模型單獨就抓到 5/5；識別欄位的機率是 0.398 到 0.977，非識別欄位不超過 0.032。門檻必須設在 0.3，因為 ref_no 這一欄只有 0.398。速度大約 1.2 秒一欄。
20 筆工具呼叫測試的結果
在 2026-10-11 的 20 筆合成工具呼叫上，action 準確率 85%、critical miss 為 0；這只代表這組合成測資，不能外推成一般準確率。
環境是一台 Mac 以 MLX 4-bit 執行 Clef-flash，以及一台 NVIDIA 工作站以 llama.cpp 執行 GGUF Q4_K_M 版。high_risk 的準確率在 Mac 是 90%、NVIDIA 是 95%。critical miss 的定義是：標成不可放行的測資，標準答案是 deny、escalate 或 ask_user，模型卻判成 allow，只要一筆就算。p50 延遲是 Mac 行程內 826 ms、NVIDIA 143 ms；經 HTTP 端到端，20/20 次呼叫都成功。
0.5 門檻兩側的一筆
兩台機器只差在一筆：同一筆測資的 high_risk 機率是 0.4883 與 0.5039，機率只差約 0.016，卻剛好落在 0.5 門檻的兩側，標籤因此不同。我們的推論是：門檻附近的判斷本來就容易翻轉，靠近門檻的案例應該走較嚴格的路徑。要檢查自己的模型機率與命中率對不對得上，可以用校準檢查器，它在瀏覽器內計算 Brier、ECE 與 reliability diagram，不送出資料。
路由、搜尋與壓縮的用法
這些用法的共同形狀，是決策模型只回答幾個具型別的小問題，真正的動作由程式決定；這是我們整理後的推論。以下依各專案的 README 與程式碼，我們沒有執行它們。
- pi-jev-router：Pi coding agent 的模型路由擴充。Jev 只回答 tier、standalone、high_consequence 三題，再由本機的確定性政策依可用模型、上下文容量與成本決定要不要換模型；程式固定使用 jev-1.13.0。
- jev-search：用 Jev 理解查詢、選擇來源與時間範圍，並以 noul 為結果評相關度；介面只回傳連結與摘要，不生成答案。
- fast-jev-compaction：用 noul 對對話中每個工具呼叫與結果決定保留、截短或刪除，不改寫使用者與助理的文字。
- jev-security-scan：只用標準庫的 Python CLI，可選擇呼叫 Jev，在安裝前檢查 agent skill、MCP 設定與原始碼的可疑行為，並輸出行號與脫敏證據。
選型表：託管、開源權重、自己讀 logit
資料必須留在本機時，選自架的開源權重或直接讀現成模型的 logit；state 可以送出時，託管 Jev 與 Workers AI 才是選項。
我們選擇不把資料送到託管 Jev，改在自己的機器上跑開源權重的 Clef-flash，理由是 state 會離開本機，而且服務仍是 early access。下表資料截至 2026-10；標「廠商自報」或「作者自報」的數字都不是我們的測量，我們也沒有 Jev 的憑證。「依部署方式」是我們的推論：那幾列都是可以自行部署的公開權重或程式。
| 選項 | 資料去向 | 授權 | 規模與速度 | 數字來源 |
|---|---|---|---|---|
| 託管 Jev | 離開本機 | 閉源，early access | 規模未公開；端到端 70–500 ms | 廠商自報 |
| Workers AI 上的 Clef／Clef-flash | 送到 Cloudflare | Apache-2.0 | 27B／9B；中位延遲 209.3／38.8 ms | 規模為模型卡；延遲為廠商自報 |
| 自架 Clef-flash | 留在本機 | Apache-2.0 | 9B；守門 p50 Mac 826 ms、NVIDIA 143 ms | 我們的實測（20 筆） |
| d1-3B | 依部署方式 | LFM Open License，有營收門檻 | 3B；Decision Index 48.57 | 廠商自報 |
| Laya | 依部署方式 | encoder 加決策頭 | 322M／421M；延遲極低、多數任務準確率較低 | 作者與廠商自報 |
| Kev | 依部署方式 | Apache-2.0，Alpha | 0.8B–9B | 作者自報 |
| 直接讀 logit（LLM2Jev、SemIf） | 依部署方式 | 不訓練；SemIf 標示未校準 | 用現成模型 | 依 README |
幾個表格放不下的細節：TypeSafe 自報輸入每百萬 token 0.042 美元、輸出免費，首頁的「193.6 倍快、444.6 倍便宜」來自自家 workflow evals、公告自承可能偏高；依 d1-3B 模型卡（廠商自報），它的授權不涵蓋年營收 1,000 萬美元以上的商業使用；Cloudflare 的 Decision Index 0.2.1 表（H200 內部執行，廠商自報）中，BFCL 是 Clef-flash 98.8、Jev 95.8，GPQA Diamond 是 Jev 78.3、Clef 48.0。TypeSafe 的隱私政策寫明不用使用者輸入訓練模型，但輸入仍會送到託管服務處理。
最後是我們的推論：每一題各自校準，不代表把好幾題串成一條守門管線後整體仍然校準；門檻要在整條管線上驗證，不能只看單題。