Jev 深度解析：一個不會說話的模型，為什麼能把 agent loop 的成本砍掉 400 倍

中文技術圈這週有兩個頻道同時在講同一個模型：一個問「快 200 倍又便宜 400 倍？」，一個問「AI Agent 真的要大改了嗎？」

被討論的東西叫 Jev，2026 年 9 月 15 日才開放早期存取。它的特別之處不在跑分，而在於它根本不生成文字——你問它問題，它回傳的是帶機率的型別值，設計給程式讀，不是給人讀。

這篇拆三層：它實際怎麼運作、「不會幻覺」這個說法錯在哪、以及怎麼判斷你的系統裡哪些節點該換掉。

---

TL;DR

Jev 是 TypeSafe AI 的 System One Model：輸入非結構化狀態，輸出型別化的機率決策。核心洞見是——agent loop 裡有一大半的模型呼叫根本不需要「說話」，卻付著說話的錢。

它快、它便宜，不是因為模型小，而是因為 LLM 延遲與 output 計價的來源（逐 token 的 generation loop）在它身上不存在。

---

為什麼一個不會說話的模型會紅

先看 agent 實際在做什麼。一個標準的 agent loop：LLM 決定下一步 → 工具執行 → 結果回填 → LLM 再決定。

問題是「決定」這件事。每一次判斷——這個請求該路由到哪個模型、這個 tool call 危不危險、這份檢索結果相不相關、這輪要不要結束——都是一次完整的 LLM 呼叫。而每次呼叫都得經過完整的 generation loop，逐個 token 吐出來，只為了拿到 "yes" 或 "risky" 這種兩三個 token 的答案。

你為了一個布林值，付了一整套自然語言生成的錢和延遲。

創辦人 Diogo Almeida（前 OpenAI，ChatGPT 與 RLHF 的共同建造者）的說法是：「我們手上握著瓶中閃電，卻沒辦法好好用——電腦說的是另一種語言。」LLM 說人話，但呼叫它的是程式；中間那層 parse、retry、驗證格式的膠水，全是為了把人話翻回程式話。

Jev 的做法是把這層翻譯整個拆掉：既然呼叫方是程式，那就直接輸出程式能吃的東西。

---

三個原語：Choice、Score、Noul

Jev 的 API 只有三種問題類型。這個約束是刻意的——所有決策都得先被壓成這三種形狀之一。

Noul（是非）— 回傳 0 到 1 的機率：

{
  "type": "noul",
  "instructions": "這個 shell 指令會不會造成不可逆的破壞？",
  "criteria": {
    "true": "會刪除檔案、改寫歷史或影響生產環境",
    "false": "唯讀或可安全回滾"
  }
}

回應：

{ "type": "noul", "noul": 0.95 }

Choice（單選）— 回傳選中項，外加完整機率分布與信心值：

{
  "type": "choice",
  "choice": "needs_reasoning",
  "probabilities": { "needs_reasoning": 0.88, "simple_lookup": 0.12 },
  "confidence": 0.81
}

單一問題最多 255 個選項。

Score（評分）— 在 2 到 10 級的有序量尺上定位：

{
  "type": "score",
  "score": 1.05,
  "legend": { "0": "不值得讀", "1": "可以參考", "2": "必讀" },
  "probabilities": { "0": 0.0, "1": 0.95, "2": 0.05 },
  "confidence": 0.92
}

注意 score 是 1.05 而不是 1——它是機率加權後的連續值，帶著「有點偏向下一級」的資訊。這在排序的時候很有用，純分類器給不了。

完整請求長這樣，一個 state 配一組 questions：

POST https://api.typesafe.ai/v1/systemone
{
  "model": "jev-latest",
  "state": { "title": "...", "blurb": "...", "source": "..." },
  "questions": {
    "worth_reading": { "type": "score", "instructions": "...", "criteria": [...] },
    "is_ad": { "type": "noul", "instructions": "...", "criteria": {...} },
    "topic": { "type": "choice", "instructions": "...", "criteria": {...} }
  }
}

關鍵細節：多加問題幾乎不增加回應時間。 所有問題在同一次 forward pass 裡平行評分。這徹底改變了成本結構——以往你會精算「這個判斷值不值得多開一次 LLM 呼叫」，現在你可以一口氣問二十個。

---

為什麼快：generation loop 不存在

這是最容易被講錯的一段。「快 200 倍」不是因為 Jev 是個小模型。

自迴歸 LLM 產生 N 個 token 需要 N 次序列化的 forward pass，每一次都要等前一個 token 出來才能算下一個。這個序列依賴是延遲的根源，也是 output token 計價的根源。

Jev 的架構是單次平行 forward pass：它不「產生」答案，而是對 schema 裡所有可能答案同時打分。選項是有限且事先已知的，所以不需要逐步生成——一次算完，取機率分布。

flowchart TB
  subgraph LLM["自迴歸 LLM：N 個 token = N 次序列 forward pass"]
    direction LR
    P1[prompt] --> T1[token 1] --> T2[token 2] --> T3[token 3] --> T4["...直到 EOS"]
  end
  subgraph JEV["Jev：所有候選答案同時打分"]
    direction LR
    S[state + questions] --> F[單次平行 forward pass]
    F --> O1["option A: 0.88"]
    F --> O2["option B: 0.12"]
    F --> O3["score: 1.05"]
  end
  LLM -.->|"拿掉生成迴圈"| JEV

所以定價才會變成 input $0.042 / 百萬 token，output 完全免費——沒有 output 這個東西可以收錢。實測延遲落在 70–500ms。

訓練方法叫 RLCD（Reinforcement Learning for Calibrated Decisions），完全使用合成資料。目標函數不是「講得像不像人話」，而是「機率估得準不準」。

---

「數學上不會幻覺」是被誤讀的

網路上到處在寫 Jev「mathematically cannot hallucinate」。這句話有一半是對的，但被理解成了另一半。

它保證的是輸出空間，不是輸出正確性。

Schema 約束確實讓它不可能回傳型別外的東西——你定義了三個選項，它不會發明第四個，不會回傳 malformed JSON，不會突然開始解釋自己。這消滅的是格式類的失敗，而那確實是 LLM structured output 最惱人的一類 bug。

但它照樣會把該選 A 的選成 B。分類錯誤不是幻覺，可是對你的系統來說，後果一模一樣。

更值得警惕的是一個具體的失敗模式：如果你的 schema 裡沒有正確答案，Jev 會自信地選出次好的那個。 它沒有「我不知道」這個出口，除非你自己把它加進選項裡。一個只有 {safe, risky} 兩選的 Noul，遇到「這個指令我看不懂」的情況，只會回一個介於中間的機率——而你拿到的是一個看起來很正常的浮點數。

所以實務上：任何開放式的判斷，選項裡一定要留一個 unknown / needs_escalation，並且對低 confidence 設門檻往上送。

---

Calibration 才是真正該看的指標

比「準確率」更重要的是 calibration：當模型說 0.7 的時候，那一百次裡是不是真的對了七十次？

這件事一般 LLM 做得很差。你叫 GPT 類模型輸出一個 0–1 的信心分數，它會給你一堆 0.85 和 0.9，因為那是訓練語料裡人類寫信心分數的習慣，不是它真實的內部不確定性。那個數字沒有統計意義，你沒辦法拿來設門檻。

Jev 的整個訓練目標就是讓這個數字可用。這才是 confidence 欄位存在的意義——它讓你能寫出這種程式：

const { answers } = await env.AI.run('typesafe/jev', { state, questions });
const risk = answers.is_destructive;

if (risk.noul > 0.9) return block();       // 高信心危險 → 直接擋
if (risk.noul < 0.1) return proceed();     // 高信心安全 → 直接放行
return escalateToLLM(state);               // 灰色地帶 → 才動用大模型

這是一個 三態決策，而不是二元分類。能這樣寫的前提就是機率可信。早期採用者的回饋也指向這點：email 分類服務 Bryo AI 測下來認為 Gemini 準確度略高，但成本是 10–20 倍，而且**「Jev 給的是真實機率」**，這對自動化流程而言比那幾個百分點的準確率更關鍵。

Vercel 則拿它做指令安全審查——原本跑在 GPT-5.6 Luna 上的 safety reviewer 換成 Jev 後，回報快 5–18 倍（p95）且準確度更高。附帶一個能說明市場反應的數字：Jev 上線 24 小時內就有近 13% 的 Vercel AI Gateway 付費團隊在用，成為該平台史上採用最快的模型，比 GPT-5.6 系列發布時還快一倍以上。

不過——所有 40–200x / 40–400x 的數字都是廠商自報，TypeSafe 自己也承認 benchmark 用的 workflow 是內部建構的。 這類數字的正確用法是「值得花一個下午測測看」，不是「可以寫進架構決策文件」。

---

跟你已經在用的東西差在哪

這是最實際的問題。你可能會想：我用 structured output 不就好了？

方案	保證什麼	延遲來源	給不給機率	適合
LLM + JSON mode / structured output	格式合法	仍需逐 token 生成	❌ 沒有可信機率	需要同時產生文字與結構
Constrained decoding（grammar）	格式合法	仍需逐 token 生成	⚠️ logprob 未校準	自架模型、要嚴格文法
微調 BERT 類分類器	型別安全	極快	⚠️ 需自行校準	標籤固定、有標註資料、不常改
Jev	型別安全 + 校準機率	單次 forward pass	✅ 這是設計目標	標籤常改、零標註資料、要機率

跟 structured output 的差別是架構性的：那個方案只是在生成迴圈外面加約束，迴圈本身還在，延遲跟 output 費用一毛都沒省。

跟自己微調小分類器的差別則是營運性的：BERT 路線同樣快、同樣便宜，但你需要標註資料、需要訓練流程、改一個標籤就要重訓一輪。Jev 改判準只是改 instructions 這個字串——這在標籤定義每週都在動的場景（內容分級、風險判定）差別巨大。

社群裡也有人把它連到 DSPy 的 signature 概念：把昂貴的 LLM 呼叫「編譯」成專用的小型 AI function。方向是一致的。

---

三個接進現有 pipeline 的 pattern

Jev 不取代你的主模型，它取代的是主模型正在兼差做的那些瑣碎判斷。

flowchart LR
  REQ[請求進入] --> R{"Jev: 路由<br/>Choice"}
  R -->|simple| SM[小模型 / 直接查表]
  R -->|complex| LM[Frontier LLM]
  LM --> TC[產生 tool call]
  TC --> G{"Jev: 安全閘<br/>Noul"}
  G -->|risky| HUM[要求人工確認]
  G -->|safe| EXE[執行工具]
  EXE --> V{"Jev: 驗證<br/>Score"}
  V -->|不合格| LM
  V -->|合格| OUT[回傳結果]

1. Model Router——進來的請求先讓 Jev 用 Choice 判複雜度，簡單的走便宜模型，複雜的才給 frontier LLM。省下的是整批本來就不該用大模型的呼叫。

2. Safety Gate——在 tool call 執行前用 Noul 判風險。這就是 coding agent 的 auto-accept 模式背後需要的東西：判斷要快到使用者感覺不到，否則不如直接問。Vercel 的用法正是這個。

3. Verifier——工具執行後用 Score 評結果品質，不合格就打回去重跑。這一點特別值得注意，因為它正面回應了 Loop Engineering 裡那個結論：驗證成本決定你能自動化什麼。當驗證的邊際成本趨近於零，原本「驗證比重做還貴」而不得不放棄的迴圈，突然全部變得可行。

這也是為什麼 Jev 對 Harness Engineering 的意義大於對模型能力的意義——它沒讓任何模型變聰明，它讓 harness 能負擔得起更密的檢查點。

---

拿這個站當實例

講抽象的不如看真的。這個站跑在 Cloudflare Workers 上，目前的 Workers AI 用量是：@cf/baai/bge-m3 做嵌入、@cf/qwen/qwen1.5-14b-chat-awq 做 RAG 問答、@cf/baai/bge-reranker-base 重排、@cf/meta/llama-3.1-8b-instruct 在 ingest 時抽 metadata。

把這些呼叫按「生成 vs 決策」重新分類一次，結果很明顯：

現有節點	本質	目前做法	System One 形狀
RAG 問答生成回覆	生成	qwen-14b 串流	不動，這就是要說話的
文章向量化	嵌入	bge-m3	不動
每日挖礦的 A/B/C 分級	決策	LLM 讀標題摘要打分	Score（3 級）
查詢該不該走 RAG	決策	現在沒有，一律走	Noul
事實查證的四種 verdict	決策	LLM 產生判斷	Choice（4 選項）
術語夠不夠「硬核」	決策	LLM 逐詞判斷	Noul
tag 是否重複/同義	決策	LLM 比對	Noul
FAQ 送審是否該過	決策	人工	Noul + 信心門檻

八個節點裡有六個是決策，不是生成。而這六個現在全都在付生成的錢。

更省事的是接法。wrangler.jsonc 裡的 AI binding 已經存在：

"ai": { "binding": "AI", "remote": true }

而 Jev 已經上架 Cloudflare Workers AI，模型 ID 是 typesafe/jev，context window 32k。也就是說不需要新的 API key、不需要新的 SDK、不需要改部署設定：

// 原本：一次 LLM 呼叫換一個布林值
const verdict = await AI.run('@cf/meta/llama-3.1-8b-instruct', {
  messages: [{ role: 'user', content: `這則新聞值得寫嗎？只回 A/B/C：${blurb}` }],
});
// 然後 parse 文字、處理它多嘴解釋的情況、處理它回 "B級" 而不是 "B" 的情況...

// 改成：一次呼叫問五個問題，拿到型別值
const { answers } = await AI.run('typesafe/jev', {
  state: { title, blurb, source },
  questions: {
    worth_writing: {
      type: 'score',
      instructions: '這則內容值得改寫成深度技術文章嗎？',
      criteria: ['不值得', '可當素材', '必讀'],
    },
    is_promo: {
      type: 'noul',
      instructions: '這是產品行銷稿而非技術內容嗎？',
      criteria: { true: '主要在推銷產品', false: '有實質技術內容' },
    },
    topic: {
      type: 'choice',
      instructions: '主題歸類',
      criteria: { agent: null, rag: null, infra: null, model: null, other: null },
    },
  },
});

if (answers.worth_writing.score > 1.5 && answers.worth_writing.confidence > 0.8) {
  // 高信心「必讀」
}

差別不只是省錢。右邊那段沒有 parse、沒有 retry、沒有「模型又多講了一句廢話」的防禦性程式碼，而且多問的兩個問題幾乎不花額外時間。

---

什麼時候不該用

這是決定要不要導入的實際判準：

情境	用 Jev？	原因
分類、路由、評分、風險判定	✅	正中設計目標
需要機率來設門檻	✅	calibration 是核心賣點
同一份輸入要問多個獨立問題	✅	平行評分幾乎免費
要產生任何人類要讀的文字	❌	它不會說話
要摘要、翻譯、改寫	❌	同上
決策前需要先查資料 / 呼叫工具	❌	單次 forward pass，不能 chain、不能反問
選項超過 255 個	❌	硬上限
需要解釋「為什麼這樣判」	❌	只有機率，沒有理由
標籤固定、已有大量標註資料	⚠️	微調小模型可能更划算
輸入超過 32k token	⚠️	Cloudflare 上的 context 上限

最後那個「不能解釋理由」值得單獨強調。如果你的場景需要對使用者交代判斷依據（內容審核申訴、風控拒絕原因），Jev 給你 0.93 這個數字，但給不了任何說明。這種時候合理的架構是 Jev 先篩，被擋下來的少數案例再交給 LLM 生成解釋——反正那只佔流量的幾個百分點。

另外提醒兩個營運面的現實。第一是可用性：9/15 發布時是 waitlist 限量存取，但需求太猛，9/20–21 已取消候補名單全面開放（console.typesafe.ai 註冊送 $5 額度，約 1.2 億 token），所以現在要測不用等。第二是穩定性：發布當週 API 被打爆過一輪，429（限流）跟 529（過載）需要你自己做指數退避——官方 SDK 有內建，但直接打 Workers AI 的話得自己處理。

---

整體來說

這個模型叫 Jev，取自經濟學家 William Stanley Jevons——Jevons paradox：當資源的使用效率提高、單位成本下降，總消耗量不會減少，反而會暴增。

這個命名是整篇文章最誠實的部分。如果決策成本真的掉 400 倍，結果不會是你的帳單少 400 倍。結果是你會在每個 agent loop 裡塞進二十個以前捨不得問的問題：每一步都驗證、每一個 tool call 都過安全閘、每一份檢索結果都評分、每一輪都判斷要不要繼續。

這其實回到那個老問題——模型不是不夠聰明，是缺乏引導。而引導的密度一直被成本卡著。Jev 沒有讓任何模型變聰明，它只是把「多問一個問題」的邊際成本壓到接近零。

所以「AI Agent 要不要大改」的答案大概是：架構不會變，但檢查點的密度會變。以前你只在關鍵節點插驗證，因為每個驗證都是一次 LLM 呼叫；現在你可以在每一步都插。

值得現在就做的事，也就一件：把你系統裡所有 LLM 呼叫列出來，標記哪些其實只是要一個型別值。那份清單的長度，會比你預期的長。

---

參考資料

如果想更深入了解本文提到的技術與架構，建議進一步閱讀以下官方文件與延伸文章。

部分內容因篇幅限制不會完整展開，內文也會適度使用超連結，方便讀者延伸閱讀。

• TypeSafe AI API Reference — Choice / Score / Noul 的完整請求與回應格式
• Jev (typesafe) — Cloudflare Workers AI — 模型 ID、binding 用法與 context 限制
• Jev (AI model) — Wikipedia — RLCD 訓練方法、公司背景與命名由來
• What Is Jev? A Guide to TypeSafe AI’s System One Model — LangChain — Model Router 與 Safety Gate 的 middleware 實作
• A new kind of AI model from a ChatGPT inventor is thrilling developers — TechCrunch — Vercel、Bryo AI 的實際採用數據
• TypeSafe AI’s Jev offers an alternative to LLMs — Tom’s Hardware — benchmark 數字與其保留空間
• AINews: Jev, a “System One Model” — Latent Space — 社群討論與 DSPy signature 的類比
• Spring AI and TypeSafe Jev — Spring Blog — JVM 生態的整合方式
• TypeSafe (Jev) — Pydantic Docs — Python 型別化整合
• 影片討論：Gary：爆紅新模型 Jev 解析、Harry EP155：席捲 AI 圈的 Jev 到底在紅什麼
• 站內延伸：Loop Engineering、Harness Engineering