我們一直把 LLM 當成萬用錘子，用來解決所有 AI 問題，甚至只是簡單的決策。Jev 能在毫秒內處理這些決策，成本卻只有冰山一角。讓我們來了解它的運作原理以及適用場景。
TypeSafe AI 於 2026 年 9 月 15 日發布了 Jev，對於一個無法進行對話、撰寫程式碼或生成任何有用段落的模型來說，市場反應異常熱烈。
嗯，這種限制正是重點所在。
大多數軟體不需要另一個聊天機器人。它需要做出成千上萬個微小的判斷，例如：這張工單緊急嗎？哪個模型應該處理這個請求？這條 Shell 指令危險嗎？檢索到的這段文字是否回答了問題？
團隊通常會將每個判斷都交給通用型 LLM。模型一次生成一個 token，應用程式解析它、驗證它，並在格式錯誤時重試。這行得通，但對於只有五種可能答案的決策來說，既慢又貴。
Jev 專為這些決策而生。TypeSafe 稱之為「系統一」（System One）模型：輸入非結構化狀態，輸出帶類型的確切答案與機率。
讓我們拆解這意味著什麼、它適合哪裡，以及行銷話術中哪些部分需要保持克制。
首先，Jev 正在解決的問題
隨著工具調用（Tool Calling）和結構化輸出（Structured Outputs）的出現，LLM 變得更容易整合到軟體中。
工具調用讓模型能以可預測的格式請求執行函式。結構化輸出讓它能回傳符合 Schema 的 JSON。這兩者都消除了大量脆弱的解析邏輯。
但底層模型仍然是生成式的。即使答案只是一個單字 "billing"，它也是依序產生 token。你需要支付輸入費用，等待生成完成，而且通常輸出的費用更高。
現在把這個過程放入 Agent 迴圈中。
1while not done:2 action = llm(context)3 result = run_tool(action)4 context += result
模型可能需要再次被呼叫來選擇工具、評估結果、偵測風險、決定任務是否完成，以及選擇下一個模型。單次 Agent 執行可能包含許多需要判斷但不需要生成文字的呼叫。
Jev 的目標就是這些呼叫。
它的賭注很簡單：當程式碼已經知道可能的答案時，語言生成是錯誤的介面。
Jev 究竟是什麼
最精簡且準確的描述是：語義決策引擎。
你發送給 Jev 兩樣東西：
- 狀態（State）：描述當前情況的文字或 JSON。
- 問題（Questions）：你希望它針對該狀態做出的決策。
每個問題都會預先宣告其答案格式。Jev 支援三種基本原語：
- Choice（選擇）：從你定義的清單中選出一個選項，並回傳每個選項的機率。
- Score（評分）：將輸入放在你定義的有序量表上，例如低、中、高。
- Noul：回答是非題，回傳該陳述為真的機率。
Noul 是 TypeSafe 對布林風格原語的命名。這個不尋常的名字不重要，重要的是輸出結果（一個介於 0 和 1 之間、你的程式碼可以據以行動的數字）。
1{2 "model": "jev-latest",3 "state": "部署失敗兩次，客戶看到 500 錯誤。",4 "questions": {5 "urgent": {6 "type": "noul",7 "instructions": "這需要立即關注嗎？"8 },9 "owner": {10 "type": "choice",11 "instructions": "哪個團隊應該處理這件事？",12 "criteria": {13 "engineering": "產品故障與停機",14 "billing": "收費、發票與退款",15 "sales": "定價與新帳戶"16 }17 }18 }19}
回應中包含緊急程度的機率，以及三個團隊的概率分佈。沒有需要解讀的段落，也沒有模型可以憑空捏造的第四個團隊。
你的程式碼掌握控制權：
1if urgent > 0.9 and owner == "engineering":2 page_on_call()3elif confidence < 0.6:4 send_to_human_review()5else:6 add_to_queue(owner)
這就是為什麼人們持續稱 Jev 為「智慧 Switch 語句」。這個說法聽起來有些輕視，但它捕捉到了設計中有用的部分。普通程式碼擁有分支邏輯。模型提供普通程式碼無法可靠計算的模糊判斷。
與 LLM 的重要區別
傳統 LLM 和 Jev 都能對支援工單進行分類。它們得出答案的方式不同，在系統中的適用環節也不同。
TypeSafe 表示 Jev 會平行評估請求中的每個問題。這改變了你設計工作流的方式。與其問一個問題、等待、再決定下一個問題是什麼，你可以在單一請求中針對同一狀態詢問所有獨立問題，並讓程式碼使用它需要的答案。
該公司報告端到端延遲介於 70 到 500 毫秒之間，每百萬輸入 token 的價格為 $0.042，輸出免費。其主打宣傳聲稱比可比擬的 LLM 工作流快約 200 倍，便宜約 400 倍。
這些巨大的倍數來自 TypeSafe 自己的工作流評估，處於比較的有利端。請將其視為上限，而非每個應用的承諾。其底層優勢仍然可信，因為 Jev 避免了長推理鏈和生成輸出，它是為有限決策而設計的。
為什麼機率很重要
帶類型的答案只解決了一半的問題。
假設 Jev 將一張工單路由到 billing（帳務）。選定的標籤告訴你誰贏了。機率分佈告訴你比賽有多接近。
1{2 "choice": "billing",3 "probabilities": {4 "billing": 0.52,5 "technical": 0.46,6 "sales": 0.027 },8 "confidence": 0.189}
自動路由這張工單是不負責任的。Billing 贏了，但險勝。低信心的答案應該觸發不同的分支。
這為開發者提供了一個實用模式：
- 高信心：當後果較小時，自動執行。
- 中等信心：請求確認或呼叫更強大的模型。
- 低信心：將案例轉交人工處理或收集更多資訊。
閾值屬於程式碼的一部分，在那裡可以被審查和修改。儀表板標籤可能容忍弱預測。刪除資料的指令則需要更高的標準。
TypeSafe 使用「校準決策強化學習」（Reinforcement Learning for Calibrated Decisions, RLCD）來訓練 Jev。目標是让信心反映跨多個預測的準確率。如果模型給出一組答案的機率為 90%，那麼大約 90% 的那些答案應該是正確的。
幻覺主張需要精確表述
TypeSafe 說 Jev 不會產生幻覺。這句話只有在狹義定義下才成立。
Jev 不能回傳 Schema 之外的選項。如果你定義了 billing、technical 和 sales，回應不能憑空創造 legal。它也不能在你的程式碼預期標籤的地方產生格式錯誤的文字。
但它可能會自信地選擇錯誤的有效選項。
類型安全防止無效格式。它不保證正確判斷。這個區別很重要，因為符合 Schema 的錯誤仍然可能退錯款給客戶、錯誤路由事故，或批准危險指令。
更安全的一句話是：「Jev 不能破壞宣告的輸出 Schema，但它仍然可能是錯的。」
Jev 在 Agent 內部的位置
當 Jev 與 LLM 搭配使用而不是取代 LLM 時，效果最好。
LLM 處理需要語言或更深層次推理的工作。它規劃、撰寫、解釋和使用工具。Jev 處理圍繞這些工作的頻繁決策。
有三種放置位置特別有吸引力。
模型路由
簡單的查詢不需要與架構審查相同的模型。Jev 可以對請求進行評分，並選擇最有可能完成任務且成本最低的模型。
1route = jev.choice(2 state=user_request,3 options={4 "fast": "查詢、提取和小規模本地編輯",5 "powerful": "架構、歧義和高風險工作",6 },7)89model = fast_model if route == "fast" else powerful_model
路由器不回答請求。它決定哪個模型應該回答。
工具風險門控
在 Agent 執行 Shell 指令之前，Jev 可以將其分類為唯讀、可逆或破壞性。單獨的問題可以檢查它是否刪除檔案、更改 Git 歷史記錄、觸及生產環境或離開儲存庫。
高信心的唯讀操作可以繼續。破壞性或不确定操作可以暫停以等待人工批准。LangChain 的 Jev 整合透過在中間件層級檢查工具呼叫來應用此模式。
驗證與監督
Agent 可能在測試仍失敗時宣稱任務已完成。Jev 可以檢查狀態並回答有限制的問題：測試通過了嗎？Agent 是否在重複相同動作？輸出是否符合政策？這個結果是否需要審查？
當存在硬性測試時，它不會取代硬性測試。它在規則依賴意義的地方添加了語義檢查。
Jev 今天能解決的問題
最佳用例共享三個特性。你可以命名可能的答案，細心的人可以快速判斷輸入，而且決策發生的頻率足以讓延遲或成本成為考量因素。
支援與營運
- 分類意圖、緊急程度、部門、垃圾郵件和客戶挫折感。
- 透過幾個小檢查路由退款和政策例外。
- 在人工閱讀之前，根據語義嚴重性對日誌和事故進行排名。
單一請求可以針對同一張工單詢問所有這些問題。然後程式碼將答案結合到公司的實際路由政策中。
搜尋與檢索
- 根據檢索到的段落是否回答查詢來重新排序。
- 檢查引用是否支持主張。
- 在將上下文發送給昂貴的 LLM 之前過濾無關區塊。
Embeddings 非常擅長尋找語義相關的文字。Jev 可以做更窄的決策：特定段落對此問題是否有用。
品質與安全
- 篩查提示詞中的越獄（jailbreaks）或提示注入。
- 根據政策或評分標準檢查生成內容。
- 在執行前標記風險代碼變更或工具呼叫。
這些檢查應與確定性控制並存。語義分類器對模糊風險很有用，而權限、沙盒和測試則強制執行軟體可以精確驗證的規則。
高容量分類
- 標記文件、研究論文、產品列表或客戶訊息。
- 將自由文字轉換為傳統機器學習模型的特徵。
- 針對大型語料庫中的每個項目，使用相同的評分標準進行打分。
這就是每次呼叫的低成本不僅僅是基準數字的地方。以前因太昂貴而無法在每一行數據上執行的判斷，現在可以移入正常數據管道。
即時介面
- 從已知的頁面元素中選擇下一個瀏覽器動作。
- 在人們寫作時評分語氣或清晰度。
- 從結構化的遊戲或模擬器狀態中選擇動作。
Jev 目前僅支援文字，因此這些系統必須先將環境轉換為文字或 JSON。它不是在查看螢幕或從像素進行遊戲。
Jev 不適合的選擇
一旦答案空間不再已知，Jev 的效用就會降低。
- 它不能撰寫回應、摘要文件、生成程式碼或解釋其推理。
- 對於算術、計數、日期比較或精確字串操作不可靠。請將這些操作保留在程式碼中。
- 當決策需要幾個隱藏的推理步驟時，它會掙扎。將判斷拆分為較小的問題或使用推理模型。
- 它不能直接提取未知值。先找到候選值，然後讓 Jev 從中選擇。
- 無關上下文可能會降低準確率。只發送決策所需的狀態。
- 閉源權重、早期存取、僅文字輸入和有限的獨立校準數據，使其尚不足以讓人盲目信任。
還有一條更簡單的規則：如果確定性程式碼已經正確解決問題，請保留程式碼。普通的 if 語句比任何模型都快、便宜且易於測試。
如何使用 Jev 而不創造新的失敗模式
如果錯誤導致重試、人工審查或生產事故，便宜的模型仍然可能很昂貴。衡量整個工作流，而不僅僅是 token 價格。
合理的推出看起來像這樣：
- 選擇一個邊界明確、低風險且有清晰可能答案的決策。
- 在呼叫模型之前寫好評分標準。定義每個選項包含的內容。
- 收集具有預期答案的代表性範例，包括模糊和對抗性案例。
- 在影子模式下運行 Jev，與當前工作流並行，但不讓它改變行為。
- 繪製準確率與信心的關係圖，並根據你的數據設定閾值。
- 首先自動化最安全的分支，並為不確定的案例保留人工或更強大的模型。
- 固定或記錄模型版本、問題、標準和閾值，以便變更可以在相同的評估集上重播。
問題是程式的一部分。像對待程式碼一樣對待它們：進行版本控制、審查，並在模型或評分標準變更時進行測試。
真正的轉變
Jev 之所以有趣，不是因為它在寫作上擊敗了 LLM。它拒絕寫作。
它的貢獻是一種形狀像軟體的模型介面：固定的答案類型、顯式的不確定性、平行問題和程式碼控制的分支。
這使它成為生成模型的有用伴侶。LLM 產生計劃、解釋或程式碼。Jev 路由請求、門控風險動作、檢查結果，並決定何時不確定性高到需要升級處理。
即使最終另一個模型取代了 Jev，這個更廣泛的想法仍然重要。我們花了多年時間要求生成模型透過文字執行各種智能。許多生產系統不需要更多的文字。它們需要一個小型、快速的判斷，讓普通軟體可以安全地使用。
這就是 Jev 試圖建立的類別。
從何處開始
不要一開始就圍繞 Jev 重建你的 Agent。找到一個目前需要緩慢 LLM 呼叫或不斷出錯的正規表達式的決策。
給 Jev 最小狀態，定義可能的答案，並在其概率旁邊記錄當前結果。讓它證明自己值得擁有一個分支，然後你再將整個工作流交給它。
最有用的心智模型仍然是最簡單的那個 → Jev 在普通 if 語句理解值但不理解其含義的地方添加判斷。
來源與延伸閱讀
- TypeSafe AI: Introducing System One Models and Jev
- LangChain: Building a Harness with Jev
- Flavio Copes: A deep dive into Jev
希望你喜歡這篇文章。
下次見。
乾杯！ :)
