LLM 路由與護欄怎麼做？Jev 與大型語言模型的協作實例

利益與證據披露：PandaNpc 正在開發使用 Jev 的 Agent 決策層。下文分別引用 TypeSafe 官方文件、官方 cookbook，以及我們儲存庫中的真實 Jev 呼叫和合成場景校準。我們的校準使用腳本化假 LLM provider，不能代表真實用戶流量或完整生產鏈路的效能。

LLM 路由可以這樣做：先讓 Jev 判斷請求屬於哪類、風險有多高，再由程式碼決定交給普通函式、專業 LLM，還是人工審閱。 Jev 也可以放在檢索與生成之間篩選證據，或放在 LLM 輸出之後檢查結果。它返回的是封閉選項、評分和概率；開放式回答、程式碼生成與長推理仍由 LLM 完成。TypeSafe 對 coding agents 的說明明確指出，Jev 不能直接替換 Claude Code 或 Codex 背後的聊天模型。

這篇文章用一個客服請求、一條 RAG 問答流水線我們自己的 Agent 校準記錄，解釋兩類究竟在哪裡交接，以及低置信結果為何必須有明確去處。

Jev 能判斷什麼，LLM 繼續負責什麼？

截至 2026 年 9 月 23日，TypeSafe 模型頁列出的穩定模型為 jev-1.13.0。API 接受一個 state 和一組 questions，透過 POST /v1/systemone 返回對應的結構化 answers。jev-latest 當日指向 1.13.0，但別名會隨版本改變；校準過閾值的系統宜固定版本並記錄回應中的實際模型 ID。

Noul 沒有獨立的 confidence 欄位；不能把一個 Noul 概率直接寫成「模型置信度」。Score 也不該拿來計算精確金額。金額、日期比較、配額和權限檢查應留在確定性程式中，官方已列出 Jev 1.13 的這些邊界。

一次呼叫的最小形狀

下面的請求形狀與官方 API 參考一致，示例問題是本文構造的說明性配置，沒有在本文為它做線上實測：

以下 JSON 使用英文客戶訊息；以香港繁體中文來說，客戶會說“訂單重複扣款，請幫我退款。”

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

實際系統還應先用程式碼檢查扣款記錄是否屬於同一訂單、是否允許退款。上例只用於判讀用戶意圖；用戶要求退款不等於退款資格已被證實，更不構成直接執行退款的授權。

用 Jev 做 LLM 路由：三種交接路徑

TypeSafe 官方意圖路由實例把客服請求先交給 Jev 判斷意圖與複雜度，然後由程式碼分流：查訂單狀態走資料庫函式；產品問題與退換貨分別走載入了不同資料的專業 LLM；複雜投訴或低置信結果進入人工隊列。這正是 Jev 與 LLM 最容易理解的協作：前者給出結構化判斷，後者只在需要生成解釋或對話時出場。

落地時可以按下面的順序設計，而不是讓模型自由決定所有動作：

1. 先定義路徑：列清楚普通函式、各專業 LLM、人工審閱能處理的請求，並給 Choice 留 other 或同類兜底選項。
2. 把事實放進 state：用戶原話、帳戶狀態、訂單記錄分別成欄位；不要把來源不明的網頁文字當系統指令。
3. 一次問窄問題：意圖用 Choice，風險或緊急程度用 Score，需要確認的單點事實用 Noul。官方建議同一 state 的多個獨立問題可在同一請求並行評估。
4. 由程式碼作最終路由：先檢查權限和硬規則，再看 Jev 的概率與本業務校準過的閾值；低置信或缺證據的請求走人工或補問。
5. 記錄結果並複查：保存模型版本、問題版本、概率、最終去向和人工糾錯結果，才能判斷閾值是否合適。

圖源：TypeSafe AI《Introducing System One Models & Jev》，2026-09-15。四個工作流由 TypeSafe 自建，指標按工作流等權彙總；評測方法見 TypeSafe workflow evals。

官方這張圖可以幫助理解它為何強調「把多個窄判斷裝進程式工作流」。圖上的縱軸沿用廠商的「accuracy」命名，但其參考答案來自兩個大型模型的預測概率共識，並非經過人工核實的唯一正確答案；成本與指標也取決於這四個工作流及廠商的評測方法，不能換算成「任意場景都能省多少」。

檢索增強生成：Jev 在 LLM 回答前篩證據

TypeSafe 的 RAG passage cookbook提供了更具體的多模型實例：OpenAI embedding 先召回段落，Jev 對每個「問題＋段落」問四個 Noul——是否相關、是否包含可用於回答的證據、是否反駁問題中的前提、是否試圖給回答模型下指令。程式碼按順序處理四項概率，決定把該段落放進證據區、衝突證據區，或丟棄；最後由 Claude Sonnet 5 寫答案。

這一步解決了一個常見問題：向量相似度高的段落未必可用。它可能只用了相似詞，也可能是一段論壇帖裡夾帶「忽略前文」的提示注入。cookbook 的示例將注入檢查放在路由規則最前面，同時提醒閾值是針對那份語料選的起點，不是所有 RAG 應用的預設值。其演示數字來自 2026-08-27 的 jev-1.12，不能當作當前 jev-1.13.0 的新評測結果。

生成之後還可以做一層核對。TypeSafe 引文核對 cookbook先用程式找引用原文，再用 Jev 判該段是否支持、反駁或沒有提及生成的主張。它能把值得複查的引文挑出來；模型判斷本身仍可能出錯，不能把「通過檢查」寫成事實保證。

我們的 Agent 校準：低置信升級會卡在哪裡？

PandaNpc 儲存庫裡，Jev 客戶端、問題題庫與編排器將 Jev 用在 Agent 的意圖識別、候選修改打分、完成條件核對和提交判斷。客戶端還對超時、429、5xx 做有限重試，對請求預算與過期結果設限；執行權限由編排器和受控工具層掌握，不由 Jev 的一句判斷直接授予。

我們在 2026-09-22 用 jev-1.13.0 對 19 個合成 turn 各跑一次 shadow、一次 enforce，合計 38 次運行，記錄了 165 條真實 Jev 決策。這份內部校準報告及保存的真機回應使用腳本化假 LLM provider，因此這些數據只說明受控場景中的決策表現。它們不能證明真實用戶請求下的整體成功率、節省比例或端到端延遲。

最有價值的發現不是平均速度，而是一個「看似安全」的門檻造成堵塞：在 enforce 的 19 個 turn 裡，有 13 個在 Q2「資訊是否足夠開始修改」處，因為 Noul 概率落入原定的 0.15–0.85 不確定區間而升級；LLM Worker 沒機會執行後續步驟。校準記錄顯示，34 條標註為資訊充分的 Q2 決策中，許多概率在中段。報告建議把複雜的 Q2 拆成更原子的判斷，或調整升級規則；這些是建議，不是已經部署的閾值。

我們的題庫把入口判成 answer_only、inspect、modify 或 out_of_scope；在寫入路徑上，Worker 提出的候選修改先由 Score 排序，最後的內容與改動摘要再經過驗收和提交判斷。這些只是決策點：能否實際讀寫對象，仍由受控執行器按階段發放權限。Jev 無權自己放寬工具白名單，也不能繞過提交前的一致性檢查。

校準數據揭示了另一個取捨。在 shadow 模式裡，Jev 會給出答案和完整分佈，但不改變 Worker 原本的執行路徑；在 enforce 模式裡，答案會影響是否繼續、升級或丟棄。把 shadow 的準確率直接當 enforce 的完成率會看錯系統：Q2 的升級會提前截住任務，令後續候選打分、驗收和提交題目根本沒有機會出現。因此這份報告把每題分佈、升級方向和最終狀態分開讀。

候選修改中有個具體對照：同一 turn 裡，精確修改目標的候選得到 2.94 分，而用整檔案覆蓋的候選得到 0.38 分；高分候選被選中。這個例子只說明該合成情境下評分題區分了兩個方案。反過來，一個證據被截斷的候選得到 2.27 分，不能因為數值看起來「還不錯」就忽略其低置信和截斷標記。我們的程式碼將證據不全單獨標識，避免模型僅憑被保留的前綴作出確定性寫入判斷。

我們還把「選擇哪個候選」和「允許它寫入」拆成兩個不同步驟。候選通過 Jev 打分後，受控執行器只在 ACT/modify 階段開放寫工具；簽發的一次性票據綁定工具呼叫 ID、當前修訂號、目標對象雜湊和參數摘要。候選文字就算誘導模型「忽略限制」，也拿不到越過這幾項檢查的工具權限。這是我們從程式碼級整合得到的經驗：概率判斷決定哪條路值得走，副作用權限則由可複查的程式條件決定。

失敗路徑同樣要設計。客戶端只有在超時、網絡錯誤、429 或 5xx 時有限重試；取消後或超出 turn 截止時間的回答直接丟棄。若 Jev 在 enforce 模式不可用，未獲降級授權時不能繼續；獲准走 llm_only 時，執行器鎖定唯讀。如果分支已經發生修改才失去 Jev，編排器把整輪標為失敗，而不是讓後續 LLM 在缺少決策層的情況下補做寫入。這些路徑對用戶體驗有代價，卻使「模型暫時不可用」不會悄悄變成「寫權限照舊」。

校準報告還區分了「低置信升級」和「拒絕執行」。例如一次正確的 discard 如果置信沒有達到統一的 0.85 門檻，會被記為需要用戶輸入；這並不等於錯誤放行。報告據此建議把提交和丟棄的門檻拆開，不過目前仍是建議。寫工作流時必須分清錯誤放行、錯誤拒絕與待審三種結果，否則同一組數據會導出錯誤的閾值結論。

這個案例告訴我們，Jev 與 LLM 的配合不能只畫成「Jev 先判斷，LLM 再幹活」。每個判斷都要問：不確定區間有多寬？是否會讓後續處理器永遠接不到任務？若輸入證據被截斷，能否明確升級而非猜測？在我們的實現裡，state 構建器會記錄 evidence_truncated，並讓呼叫方把缺證據路徑視作不確定；計數、排序等確定性計算先在程式碼裡完成，不交給 Jev 猜。官方 Jev 1.13 已知限制也建議把計數和算術留在程式碼中。

LLM 護欄應該放在哪兒？

TypeSafe 的 LLM guardrails cookbook把 Jev 放在 LLM 的輸入與輸出兩側。它用一組 Noul 識別不同風險，用 Score 衡量嚴重程度，再由程式碼根據策略決定放行、人工覆核、阻止或轉交支援。輸出也要檢查，因為普通輸入仍可能得到不合適的生成結果。

這類護欄的邊界同樣清楚：Jev 可以按預先寫好的問題檢查內容，但不是萬能安全證明。官方限制文件明確提到惡意內容可能影響判斷，要求寫清 criteria 並測試邊界。我們的合成樣本中曾做 16 次針對候選參數的注入探針，記錄到 0 次排序翻轉；樣本太小，不能推出「抗提示注入已解決」。真正決定工具能做什麼的，仍是程式碼裡的允許列表、階段門禁和提交前檢查。

什麼時候適合用，什麼時候不要用？

適合 Jev 的是：候選集合已知、問題可以拆成幾個短判斷、軟件需要概率來決定自動處理或升級人工。例如客服路由、RAG 段落篩選、Agent 候選動作評分、生成結果中的引文核對。若任務要求寫一封回信、改一段程式碼或解釋複雜推理過程，就由 LLM 接手。若任務是精確算錢、比較日期或檢查存取控制，程式應直接計算。模型頁還說明 Jev 只接受文字，英語是當前表現最好的訓練語言；中文場景需要用自己的數據評測，不能照搬英文 cookbook 的閾值。

如果想觀察真實 Agent 如何處理權限與工具呼叫，可以先看 PandaNpc Agent；關於編碼 Agent 的邊界和使用場景，也可參考 Claude Code 與 Codex 對比。

讀者可用一個很小的驗證集起步：準備「明顯可以自動處理」「明顯應拒絕」「語義模糊」「包含惡意指令」四類樣本；先確定人工標註，再記錄 Jev 各題概率與路由結果。成功判據不是每條都自動通過，而是自動處理路徑的錯誤率與人工升級量都落在你能接受的範圍內。若模糊樣本大量卡在同一題，先檢查題目是否混入多個判斷、state 是否太長或閾值是否按本地數據校準。

常見問題 (FAQ)

Jev 能替換 Claude Code、Codex 或聊天模型嗎？ 不能。TypeSafe 將它定位為軟件內的結構化決策模型；聊天、寫作和程式碼生成仍需 LLM。

返回類型固定，是不是就不會犯錯？ 不是。固定類型減少解析和越界輸出問題，但分類、評分與事實判斷依舊可能出錯。低置信與高風險路徑應保留人工覆核。

同一請求能問幾個問題？ 可以把共享同一 state 的多個獨立 Choice、Score、Noul 放在一次請求中。題目各自求值，複雜判斷仍應拆開，再由程式碼組合。

中文能用嗎？ 官方稱支援包括中日韓文字在內的自然語言，但英語準確度目前最好。中文工作負載需要單獨驗證和校準。