TypeSafe Jev 與代理模型堆疊的第三層
關鍵要點
- TypeSafe AI 於 2026 年 9 月 18 日發布 Jev——首個基於 Transformer、輸出校準機率而非文字的商業模型——由於使用者預先定義輸出空間,該模型在結構上不可能產生幻覺(TechCrunch)。
- Vercel 將基於 OpenAI Luna 的安全分類器替換為 Jev,運行速度提升 5–18 倍且精度更高;Bryo AI 發現 Gemini 在郵件分類上略更準確,但成本高出 10–20 倍——同一模式下的兩個獨立採用數據點。
- Gartner 現已將「AI Agents and Assistants」單列為一個市場:2025 年 165 億美元、2026 年 292 億美元、2027 年 655 億美元——代理軟體支出到 2027 年接近翻倍,決策層模型正是這一預算的採購對象之一。
- 架構啟示是一個三層模型堆疊——前沿推理層、開放權重通用層、校準決策層——它改變了代理系統路由工作、執行護欄、觀測行為以及驗證 kill-switch 決策的方式。
用 LLM 對代理的每個動作做安全分類,是一種與被保護對象同等昂貴的護欄。Vercel 一直運行 OpenAI 的 ChatGPT Luna 5.6 作為其代理基礎設施的安全分類器——在執行前審查命令——直到本週。在用 Jev 替換它之後,分類器運行速度提升 5–18 倍且精度更高。在 Bryo AI,Gemini 在郵件分類精度上略勝 Jev 一籌,但成本高出 10–20 倍。兩家公司從不同方向得出了同一結論:一大類代理決策根本不需要語言生成,為一個 LLM 產出的、隨即被丟棄的散文式文字付費,是錯誤的成本結構。
Jev 由 TypeSafe AI 於 9 月 18 日發布,是為這一類工作構建的首個商業模型。它基於 Transformer 但不是大型語言模型:它在使用者預先定義的輸出空間上輸出校準機率——該公司稱之為「校準決策」。TypeSafe 聯合創辦人 Diogo Almeida(前 OpenAI 研究員,曾參與 ChatGPT 與 RLHF)向 TechCrunch 闡述了這一論點:「四年來我們極其擅長人類語言,但這對自動化沒有用處,因為電腦說的是另一種語言。」本文描繪一個非語言決策模型如何改變代理架構——模型路由、護欄、可觀測性與 kill-switch 驗證——以及它在生產級 B2B 系統實際運行的模型堆疊中的位置。
Jev 是什麼,哪些仍然未知
先看可驗證的事實。Jev 在使用者定義的輸出空間上產出機率,而非自由文字。其輸出 token 免費,輸入按十億而非百萬計量——這一定價顛覆了 LLM 的成本結構,因為生成是語言模型最昂貴的部分,而 Jev 不做生成。它完全使用合成資料訓練,採用 Almeida 稱為「校準決策強化學習」的技術;發布後需求一度壓垮了 API——該公司在發布後一度喪失了服務使用者的能力。
誠實性標記與宣傳同樣重要。Almeida 對架構諱莫如深,外部觀察者懷疑其構建於某個開放權重 LLM 之上——「不可能幻覺」這一屬性來自受約束的輸出空間,而非任何已公開的架構細節。Vercel 與 Bryo 的對比是開發者自述,而非基準測試評估。Jev 僅限早期存取——它是三個受控發布的 9 月模型之一(與 Anthropic 的 Mythos 5.1 和 Google 的 Fairwind 專屬 Gemini 3.8 Flash Cyber 並列)——因此採用數字建立在受控存取的群體之上。Earendil CTO、開源模型 harness Pi 的創造者 Armin Ronacher 預計,在實用性已經可見的當下,競爭者會跟進:「大概因為 LLM 太便宜且有補貼,你常常還不必發揮創造力。」將 Jev 視為品類驗證,而非確定的供應商選擇。
代理模型堆疊的第三層
生產級代理系統已經在運行兩個行為截然不同的模型層。前沿推理層負責規劃、起草和處理歧義。開放權重通用層——DeepSeek、Qwen、GLM 的發布已將成本壓低的模式——以遠低於前沿的價格執行高流量工具呼叫與校驗。缺失的是第三層,用於既非推理也非語言的工作:代理系統每天數以百萬計的小型分類決策。這條命令是否安全可執行。這條 trace 是否像一次越獄。這個工作負載是否需要昂貴的模型。這個價格偏差是否真實。
把語言模型放在這些決策上,一直只是因為不存在商業替代品。Gartner 九月的預測將代理軟體市場規模定為 2025 年 165 億美元、2026 年 292 億美元、2027 年 655 億美元——到 2027 年接近翻倍——這筆建設的每一美元都讓忽視決策層問題的代價更高,因為每個已部署的代理都會成倍增加護欄檢查、路由呼叫與驗證流程的流量,而這些流量目前預設全部流經 LLM。
三層代理模型堆疊——兩個語言層,以及為其周邊流量定價的非語言決策層:
它如何改變代理架構
當校準決策層成為商業選項,四個架構決策的形態隨之改變。每一項都對應生產級代理系統已有的決策;變化的是成本結構,以及對「營運判斷住在哪裡」的誠實。
模型路由在高頻場景下變得經濟上合理。 據 Ronacher,最被期待的具體用法是預測某個工作負載是否需要特定模型——只有當路由呼叫本身近乎免費時,即時分揀才成為可能。DeepSeek 自動路由事件展示了當操作者無法控制時,供應商側自動路由的代價:靜默的模型替換,在約 45 小時後因使用者施壓而逆轉。廉價的決策層把路由從供應商閘道移到操作者自己的執行時——用你自己的分類器做路由,把備用模型藏在你自己的開關之後,替換風險就從「意外」變成「設計選擇」。
護欄獲得機率契約。 Ronacher 對 Jev 的概括:「它把幻覺問題稍稍轉嫁給使用者」——由操作者聲明閾值。如果一個決策返回 50%,把它當作擲硬幣並轉給人工處理;達到 95%,就執行。這比詢問 LLM「這安全嗎」並從從未校準過的散文式回答中解析置信度,是一份實質性更好的契約。治理檢查清單中顯式審批門控的模式保留下來;變化在於門控檢查本身運行在一個無法虛構「是」的模型上。
可觀測性獲得廉價的監視器。 Almeida 自己的說法:用代理監控代理很昂貴,但用 Jev 來做並不貴——追蹤 LLM 代理 trace 並防範越獄,恰恰是決策層定價所針對的高流量、低歧義分類工作。多數團隊想要卻因「監控 LLM 的成本直逼生產 LLM」而放棄的可觀測性架構,當監視器成本低一個數量級時就變得可行。
Kill-switch 驗證獲得獨立評估器。 依賴 LLM 判斷觸發的 kill switch,會繼承 LLM 的失敗模式。用一個決策層模型評估「這條 trace 是否符合中止標準」,為 kill-switch 層提供了一個足夠便宜、可在每個動作上運行的檢查——經過校準而非憑感覺,且在架構上獨立於被評估的代理。kill-switch-by-design 模式一直要求中止決策獨立於被中止的代理;非語言評估器是這種獨立性的第一個商業基底。
成本算術,直說
這些對比數據點是自述的,因此要謹慎看待——但方向在兩個獨立採用者之間保持一致。Vercel:比基於 Luna 的分類器快 5–18 倍,精度更高。Bryo:Gemini 在商務郵件分類上略更準確,但價格是 10–20 倍。兩個數字背後的結構相同:LLM 把大部分算力花在生成語言上,而分類流水線隨即丟棄這些語言;決策模型則把算力花在判別本身——輸出免費,輸入按十億計量。在生產級代理的流量畫像下——每天數千次護欄檢查、每個請求一次路由呼叫、每步一次 trace 評估——決策層是唯一以「單次呼叫近乎免費」為設計目標的層,而如今代理恰恰從市場上最昂貴的模型那裡租用這一層。
這一切都不會讓決策層變成推理器。它無法起草報價、談判例外或撰寫客戶郵件——前兩層仍然擁有這些工作。主張更為狹窄:圍繞代理語言工作的決策流量,已超出語言模型作為基底的承載能力,而首個為這一流量構建的商業模型已於 2026 年 9 月 18 日發布。
一個具代表性的建構案例
一家中型分銷商在 NetSuite 與 BigCommerce 上運行 24 小時報價代理,此前為每個報價決策向前沿模型付費分類:這個折扣是否在政策內、供應商回覆是否完整、這條 trace 是否需要人工複核。模型路由決策(五決策架構中的第三項)拆分了工作:前沿模型負責起草與談判,執行級的開放權重模型處理目錄與價格查詢,校準決策層分類器運行護欄——命令安全檢查、trace 分類,以及決定每一步由哪一層處理的路由呼叫。分類器的機率輸出讓升級策略顯式化:高於 0.95 的決策自動解決,低於 0.50 的轉人工,中間帶附帶機率排隊複核。每個報價的護欄成本從 LLM 費率降到可以忽略不計,審計軌跡也改善了——每次升級決策現在攜帶一個校準後的數字,而非散文式裁決。
在前沿推理層、開放權重通用層與決策層構成的統一執行時背後,用顯式升級閾值構建三層堆疊,是一次範圍明確的建構,而非研究專案。
申請一次範圍明確的建構。 為期一週的探索。你將獲得系統清單、工作流地圖與固定範圍——無論你是否與我們合作。
相關閱讀
- DeepSeek V4.1-Flash 自動路由:模型替換風險——讓操作者自建決策層值得投入的供應商側路由事件,包括約 45 小時的逆轉
- AI Agent Architecture: Five Decisions That Determine Whether Your Agent Ships——這一堆疊所嵌入的五決策框架;決策層重塑決策 3,模型路由
- AI Agent Observability: What You Can't See Will Hurt You——廉價的決策層監視器終於讓這套可觀測性架構變得經濟
想為您的系統建構這個嗎?
這裡的每份文件都來自真實的生產工作。如果您有目標系統和工作流程想法,我們可以在一週內確定範圍。
申請客製開發為期一週的發掘階段。您會拿到系統清單、工作流程地圖和固定範圍——無論您最終是否與我們合作開發。