Jev 是什麼？價格、限制與 Agent 工作流的整合方向

Jev 適合放在 Agent 工作流的判斷層，處理答案空間已知、可以型別化的高頻決策。

典型用途包括模型路由、context 篩選、review 升級判斷與工具執行前的風險分類。這些工作若由 Claude、Codex 等完整生成式模型反覆處理，會消耗額外的模型呼叫與輸入 context；Jev 的低成本、低延遲介面，讓這些判斷有機會移到大型模型呼叫之前。

這個位置也決定了它能省下什麼。若 Jev 只作為 Claude Code 的 MCP 工具，Claude 那一輪通常已經發生；若判斷層位於大型模型之前，才有機會直接減少主 Agent 的呼叫與輸入量。

本文整理截至 2026 年 9 月 18 日可以確認的產品資料與社群實驗，再討論適合放進多 Agent 架構的位置。Jev 在 9 月 15 日才公開 early access，因此目前的社群案例主要是原型與早期實驗，production reliability 仍缺乏足夠資料。

Jev 到底是什麼？

TypeSafe AI 把 Jev 稱為第一個 System One Model。名稱取自 Daniel Kahneman 對 System 1 與 System 2 的區分；在這裡比較適合作為產品設計比喻，不宜直接理解成模型具有相同的心理機制。

更精確的理解是：

Jev 接收一份文字或結構化 state，以及一組事先定義答案空間的問題；輸出可以直接被程式使用的型別化判斷與機率。

官方文件目前定義三種 primitive：

有一個細節很重要：Noul 沒有獨立的 confidence 欄位。Choice 與 Score 的 confidence 是由完整機率分布計算出的摘要；Noul 本身就是「為真的機率」。

同一份 state 可以一次送很多問題。TypeSafe 表示這些問題會彼此獨立、平行評估；增加問題數量對延遲的影響相對小。這是 Jev 和一般自回歸文字生成模型在介面上的核心差異之一。

官方建議把控制流程、可精確計算的規則與 side effect 留在程式碼，模型只處理狹窄的語意判斷。需要多層推理的問題則拆成數個原子問題，再由程式組合。

參考：TypeSafe Introduction、How to build with TypeSafe。

價格、速度與目前限制

截至 2026-09-18，TypeSafe 文件列出的穩定版本是 jev-1.13.0，jev-latest 目前指向它。

以 TypeSafe 直連價格計算，10 億 input tokens 是 US$42。這個數字可以說明成本量級；實際節省幅度仍取決於 prompt 大小、問題數、網路延遲、誤判率與 fallback 次數。

速度也要分清楚來源。TypeSafe 發表文宣稱端到端約 70–500 ms，目前文件則寫「多數 query 約 100 ms」。官方同時說明，公開測試通常從美國西岸的筆電執行，而服務也位於該區，因此台灣實際延遲需要另外量測。本文沒有做台灣端 benchmark。

TypeSafe 首波 workflow eval 宣稱最高約 193.6 倍更快、444.6 倍更便宜。這些數字來自廠商自己的測試，TypeSafe 也公開列出幾個限制：

• 四個 workflow 由自家 model capabilities team 建立，可能存在設計偏差。
• 評估沒有獨立 ground truth；reference labels 取自 GPT-6 Astra 與 Claude Fable 5.1 high-thinking 的平均答案。
• TypeSafe 表示 193.6× / 444.6× 很可能位於真實世界收益的高端。

因此，這些倍率適合作為初步性能資料，不能直接當成一般工作負載的預期值。

參考：Models、Introducing System One Models & Jev、Workflow evals、Vercel AI Gateway。

「零幻覺」的技術含義

TypeSafe 的發表文使用了「can’t hallucinate」與「zero hallucinations」這類說法。官方技術說明中的「0% hallucination」是依 schema matching 保證填入圖表，並非經驗測量出的語意錯誤率。

這項保證的範圍可以簡化成：

答案一定落在事先定義的型別與選項範圍內。

假設 Choice 只允許：

frontend
backend
security

Jev 只會回傳這些選項以及相應機率。它仍可能把 security 問題判成 backend，所以 schema guarantee 和語意正確率是兩件不同的事。

TypeSafe 對 Jev 1.13 也公開列出不少 failure modes：

• 容易照字面理解，隱含條件與複雜否定較不可靠。
• 不適合算術、計數與精確數值工作。
• 日期排序、時間差等應交給程式計算。
• 多層 indirection 會降低準確度。
• state 裡有大量無關內容時會發生 context rot。
• adversarial content 可能影響判斷。
• 文字生成需要其他模型處理。

因此，typed output 提供的是輸出介面與答案空間的可靠性；語意正確率仍需透過 evaluation、threshold 與 fallback 管理。

參考：Jev 1.13 jaggedness。

實際怎麼用？

直接呼叫 TypeSafe API 時，request 的形狀很單純：

{
  "model": "jev-latest",
  "state": {
    "task": "Fix the flaky checkout test and update any affected code.",
    "changed_files": ["checkout.test.ts", "checkout.ts"],
    "tests": "1 previously flaky test now passes 20/20 runs"
  },
  "questions": {
    "task_type": {
      "type": "choice",
      "instructions": "What is the primary kind of work?",
      "criteria": {
        "small_change": "Narrow, well-scoped modification",
        "implementation": "New or substantially changed behavior",
        "debugging": "Diagnosing or fixing an observed failure",
        "research": "Primarily gathering or analyzing information"
      }
    },
    "needs_human": {
      "type": "noul",
      "instructions": "Does this task currently require a product or requirement decision from a human?"
    },
    "regression_risk": {
      "type": "score",
      "instructions": "How risky is this change for unrelated behavior?",
      "criteria": [
        "Very low risk",
        "Low risk",
        "Moderate risk",
        "High risk"
      ]
    }
  }
}

程式再依輸出採取動作：

if (needsHuman.noul > 0.8) {
  return askHuman();
}

if (
  taskType.choice === "small_change" &&
  taskType.confidence > 0.9 &&
  regressionRisk.score < 1.5
) {
  return dispatch("cheap-worker");
}

return dispatch("strong-worker");

這裡的 0.8、0.9、1.5 都是示意值。TypeSafe 文件建議依風險與自己的標記資料校準 threshold，跨 domain 直接沿用同一組門檻缺乏可靠依據。

Vercel AI SDK 7 也已提供 experimental evaluate API，透過 AI Gateway 使用 typesafe-ai/jev；在 Vercel 的介面裡，Noul 對應的是 boolean question。

參考：TypeSafe Quick start、Confidence、Vercel Jev announcement。

哪些方向真的可能降低 Agent 用量？

判斷整合價值時，關鍵在於 Jev 插在哪一層。

前三項和降低 Claude / Codex 日常 quota 的關聯最直接。

1. Model router：在 Agent 被叫之前選模型

社群的 jev-router 示範了一種具體作法：在 Claude Code / Codex 前放 loopback proxy，每個新的 user turn 先讓 Jev 選 abstract tier，再映射到實際模型。

這種做法利用 router 本身有限的答案空間：

fast
balanced
strong
long

因此可以把 routing 從強模型 turn 移到低成本的 bounded decision。

評估時應特別追蹤 wrong downgrade rate。單看平均花費下降沒有意義；若省下 30% 強模型呼叫，卻讓 5% 任務因錯誤降級而重做，實際收益可能消失。

2. Context gate：在大型模型看到資料前先篩選

大型 Agent 常需要先讀大量檔案、log、搜尋結果與 handoff，才能判斷哪些資料相關。這部分的成本主要表現在 input tokens 與 context pollution。

Jev 可以放在 retrieval 之後處理 bounded judgment：

ripgrep / BM25 / index
          ↓
   候選 passages
          ↓
         Jev
 relevance / injection / contradiction
          ↓
   通過的少量 context
          ↓
    Claude / Codex

TypeSafe 官方有 RAG passage classification、semantic find、citation check 與 LLM guardrail cookbooks。社群的 jev-mcp 則把相近模式包成 claim verification、content screening 與 semantic ranking 三個 MCP tools。

要直接節省這一輪 input quota，filter 必須發生在 frontier model 讀到 context 之前。若 Claude 已經讀完全部資料，再叫 MCP 排序，主要收益會落在後續處理品質，而非當前輸入成本。

3. Completion / review gate：只把不確定案例升級

雙 Agent review 很容易形成固定成本：

worker
  ↓
strong reviewer
  ↓
worker fixes
  ↓
strong reviewer again

Jev Review MCP 把 focused diff 交給 Jev，取得 correctness、complexity、tests、security 等結構化訊號，再由原本的 coding agent 決定怎麼改。

比較合理的 production 版本可以再加一層 deterministic verification：

tests / typecheck / static analysis
              ↓
             Jev
 scope / risk / missing-test signals
              ↓
      confident + low risk
        ↙             ↘
    finish        strong reviewer

Jev 在這裡的角色是決定哪些案例需要額外的強模型 review。程式正確性仍應以測試、型別系統、靜態分析與必要的人工審查驗證。

4. Tool gate：提供風險訊號

Jev 可以判斷一個 tool call 是否看起來是 read-only、destructive、ambiguous，或涉及外部 side effect。模型輸出可以成為權限系統的語意訊號之一。

實際授權仍應由 deterministic policy 控制身份、資源範圍、allowlist、transaction boundary 與不可逆操作的確認。

適合的流程是：

semantic judgment → code policy → execute / ask / block

這樣可以利用模型判斷的彈性，同時把最終 side effect 留在可稽核的程式規則中。

5. Browser / computer use：把微操作從大型模型迴圈移出去

Browser Use 的 Jev Ultrafast 是目前很直觀的實驗：Jev 從動態 action space 中選 operation 與 DOM element，只有需要 TYPE_TEXT 時才叫另一個小型文字模型生成欄位內容。

這顯示部分 browser step 可以改寫成 bounded choice，減少每一步重新呼叫完整生成模型的需求。

目前仍應把它看成 demo / prototype。頁面變動、登入流程、長任務規劃、視覺資訊與 adversarial content 都會增加難度。Jev 1.13 目前只接受文字輸入，也不能直接看 screenshot。

6. Semantic lint：高頻自然語言規則檢查

Patrick Desjardins 的實驗把 370 條 Markdown coding rules 接到 VS Code / Cursor 存檔流程，先依檔案 glob 篩規則，再讓 Jev 判斷新增 diff 是否違規；被標記的案例才繼續做 severity 與 hunk 定位。

這類 semantic lint 介於 static analyzer 與完整 LLM review 之間，適合處理具有語意模糊性、答案空間又明確的規則。

能用 parser、type system、AST rule、regex 或測試精確判定的規則，使用 deterministic tool 會有更好的可重現性與可稽核性。Jev 的價值集中在靜態規則難以表達的語意區域。

參考：370-rule experiment。

MCP 整合與主 Agent quota

MCP 很適合快速接入 Jev，但節省哪一層成本取決於呼叫順序。

若架構是：

Claude / Codex
      ↓
決定要不要叫 Jev
      ↓
    Jev MCP
      ↓
主 Agent 繼續

主 Agent 的這一輪已經發生。這種模式比較可能省下額外 reviewer、classifier 或 security judge。

若希望直接降低主 Agent quota，Jev 應位於 routing 層：

user / event
     ↓
Jev + deterministic policy
     ↓
 ┌───────────────┬────────────────┐
 cheap worker   strong worker   no LLM

同一原則也適用於其他 gate：

• routing 發生在大型模型呼叫前；
• context filtering 發生在 context 被送進大型模型前；
• completion gate 發生在強 reviewer 呼叫前。

這種設計把一部分語意判斷從 Agent loop 移到一般軟體控制流，讓大型模型集中處理生成、整合與複雜推理。

放進 Straw Boss：先 shadow，再授權

以 Straw Boss 這種 coordinator / worker 架構為例，Jev 適合加入 coordinator 周圍的 decision layer。工作分解、跨 workspace 契約、模糊需求處理與人類協商仍由生成式／推理模型負責。

                 ┌────────────────────┐
                 │ coordinator / LLM  │
                 └─────────▲──────────┘
                           │ uncertain / hard
                           │
                 ┌─────────┴──────────┐
                 │ Jev decision layer │
                 │ route / filter / gate │
                 └─────────▲──────────┘
                           │
                 deterministic policy

第一階段可以採 shadow mode：Jev 只記錄自己的判斷，不改變實際派工。

每筆任務至少記：

• 原 coordinator 選的 worker / model / effort；
• Jev 的 Choice / Score / Noul 輸出；
• 使用的 Jev version；
• confidence 或 noul probability；
• 實際 input tokens 與 latency；
• 任務最後是否成功、是否重做；
• 是否需要人工升級；
• 若 routing 不同，哪個選擇事後看來較合理。

評估指標可以包括：

• strong-model call reduction；
• input-token reduction；
• wrong downgrade rate；
• escalation / fallback rate；
• p50 / p95 routing latency；
• 按 confidence bucket 計算的實際 accuracy；
• 整體 task success / rework rate。

等自己的資料顯示某一類 high-confidence decision 足夠穩定，再逐步讓它生效。TypeSafe 也建議在自己的 workload 上校準 threshold；若 tuned threshold 依賴特定模型版本，應 pin version，避免 jev-latest 更新後改變決策分布。

另一種解釋：泛用 classifier / evaluator

從軟體使用方式看，Jev 很接近高泛用性的 classifier / evaluator：輸入 state，輸出封閉選項或分數。TypeSafe 宣稱它使用新的 model architecture、parallel sampler 與 Reinforcement Learning for Calibrated Decisions（RLCD），但目前公開資料還不足以讓外界獨立重建，也無法判定每一項技術對效果的貢獻。

TypeSafe 的主要 workflow benchmark 仍是內部建立的 evaluation，reference 來自其他模型的平均判斷。Jev 剛公開數日，獨立、跨 domain、長期 production 資料也很有限。

目前較穩健的結論是：

Jev 已經展示了一個低成本、低延遲、答案空間封閉、帶機率的語意判斷介面。它和小型 LLM、constrained decoding、專用 classifier 或開源模型之間的長期優劣，仍需更多獨立 benchmark 與 production telemetry 才能判斷。

對 Agent 架構而言，可以先吸收其中一個設計觀念：具有語意模糊性但答案空間封閉的判斷，可以獨立成低成本 decision layer。

目前最值得做的三個實驗

若目標是提高多 Agent 生產力，同時降低 Claude / Codex 的日常使用量，可以先做三個實驗：

1. Model-routing shadow mode：量測 Jev 是否能辨識適合使用較便宜模型的工作，同時追蹤 wrong downgrade rate。
2. Pre-context relevance gate：對搜尋結果、檔案、log、handoff 做 relevance / injection 判斷，再送進大型模型。
3. Pre-review completion gate：deterministic tests 先跑，Jev 再判斷是否需要升級到強 reviewer。

這三個實驗共同驗證一個可量化的命題：

在封閉、重複、高頻的語意判斷上，Jev 能否以足夠低的誤判率，減少大型模型的呼叫與 context 使用量。

若 telemetry 支持這個命題，就逐步擴大授權；若收益不足，保留原本的 deterministic code 或 LLM。這樣能直接用自己的 workload 判斷價值，不必依賴廠商宣稱的倍數。

參考資料

官方資料

• TypeSafe AI，〈Introducing System One Models & Jev〉
• TypeSafe AI，Introduction
• TypeSafe AI，Quick start
• TypeSafe AI，Models
• TypeSafe AI，Confidence
• TypeSafe AI，How to build with TypeSafe
• TypeSafe AI，Jev 1.13 jaggedness
• TypeSafe AI，Workflow evals
• Vercel，〈TypeSafe AI’s Jev now available on AI Gateway〉
• Vercel AI Gateway，Jev model page

社群實驗

• gargpratyush，jev-router
• jkudish，jev-mcp
• NiazMorshed2007，jev-review
• Browser Use，jev-ultrafast
• Patrick Desjardins，〈Typesafe AI Jev Running 370 Text Rules under 2 seconds〉