用 Jev（System 1 model）替 agent harness 裡的分類型判斷換上更快更便宜的模型

harness

包在模型外面、負責接請求、派工具、決定何時停止的那層程式。

「harness」原意是馬具，引申為把模型「套上」讓它能拉動實際工作的框架。在 agent 語境下，它包含 agent loop、工具的註冊與呼叫、中間件（middleware）、停止條件等。模型只負責在每一輪回答「接下來做什麼」，harness 負責把回答變成真正的程式動作。影片標題「Building a Harness with Jev」的意思就是：在這層程式裡，把某些判斷交給 Jev 而不是 LLM。

相關術語: agent loop (包含)

出處：第 1 段「回顧大家熟悉的 agent loop」

agent loop

request → LLM → 呼叫工具拿結果 → 回到 LLM，直到 LLM 決定結束並回傳 result 的循環。

這是所有 agent 框架的共同骨架，也叫 tool-calling loop 或 ReAct loop。每一輪 LLM 看到目前的對話與工具結果（observation），輸出一個動作（action）：呼叫某工具，或結束。它強大之處在於步數不固定，模型可以視情況多繞幾圈；弱點是每一輪的「決定」都是 LLM 生成的文字，慢、貴、且不保證格式。

相關術語: LLM (由其驅動)、harness (屬於)

出處：第 1 段「回顧大家熟悉的 agent loop」

LLM

吃一段文字、生成一段文字的模型，是 agent loop 裡負責「決定下一步」的核心。

作者刻意用一句話定性 LLM：「text in, text out」。這不是貶義，而是為了鋪陳：既然它本質上是生成文字，那要讓程式使用它，就必須在它外面加東西。後面出現的所有機制（tool calling、structured outputs、乃至 Jev）都可以理解成對這個「文字進文字出」限制的不同回應方式。

出處：第 1 段「回顧大家熟悉的 agent loop」

tool calling

讓模型以結構化格式（工具名稱＋參數）發出呼叫請求，工具再以結構化資料回傳的機制。

在 tool calling 出現前，開發者得用 prompt 教模型「請用這種格式回答」再自己正則解析，非常脆弱。tool calling 把「工具的 schema」直接交給模型 API，模型的回覆裡會有一個獨立的、已結構化的 tool_call 欄位。投影片的例子：模型送 {"name": "get_order", "args": {"order_id": "A-1042"}}，工具回 {"status": "shipped", "eta": ...}。它對應 agent loop 裡 LLM 與 tools 之間的那條往返邊（見第 1 段）。

相關術語: agent loop (實作其 action 邊)、structured outputs (對照組)

出處：第 2 段「tool calling 與 structured outputs」

structured outputs

把一個輸出型別綁到模型上，讓模型的最終回答是符合 JSON schema 的物件而不是一段文字。

跟 tool calling 不同，structured outputs 管的是 agent loop 的「出口」：任務做完時回傳給程式的 result。投影片範例用 Pydantic 宣告 class Ticket(BaseModel) 有 team 與 urgent 兩個欄位，透過 model.with_structured_output(Ticket) 綁定後，invoke 直接得到 Ticket 實例。底層做法通常是把 JSON schema 傳給模型 API 並在解碼時約束格式。常見誤解是以為它讓模型「更聰明」，其實只是讓輸出「更可解析」。

相關術語: JSON schema (依賴)、tool calling (對照組)

出處：第 2 段「tool calling 與 structured outputs」

JSON schema

用 JSON 描述另一份 JSON 該有哪些欄位、什麼型別的規格。

tool calling 與 structured outputs 底層都靠它：工具的參數格式、輸出物件的形狀，最終都會轉成 JSON schema 傳給模型。像 Pydantic 的 BaseModel 就能自動產出對應的 JSON schema。理解這點就會明白，這兩個 primitive 的「結構」來源是開發者事先宣告的，模型只是被要求「填進這個形狀」。

相關術語: structured outputs (被其使用)

出處：第 2 段「tool calling 與 structured outputs」

primitive

框架提供的、不可再拆的基本能力，其他功能都是用它們組合出來的。

作者把 tool calling 和 structured outputs 稱為兩個 primitive，意思是它們是「加結構」這件事的最小積木，後面所有 agent 功能（路由、判斷、評估）都在這兩塊上面疊。這個用詞也暗示下一步：如果要再加一種新能力，可能需要一種新的 primitive，而不是再多疊一層 prompt。

相關術語: tool calling (一種)、structured outputs (一種)

出處：第 2 段「tool calling 與 structured outputs」

Jev

TypeSafe AI 推出的模型：輸入 state 與 questions，回傳 typed answers 與機率，不生成文字。

投影片上的模型名有 jev-latest（請求時用的別名）與 jev-1.13.0（回應中實際版本）。它的介面完全是結構化的：questions 是一個字典，每題宣告 type 與自然語言 instructions；answers 是同名字典，每題回一個型別化的值。它跟 LLM 的差別不在「更聰明」而在「不同的輸出形式」：LLM 產出 token 序列，Jev 產出決策值。因此它擅長分類、評分、是否判斷，不能寫文章或程式。

相關術語: System 1 model (一種)、LLM (對照組)、TypeSafe AI (由其推出)

出處：第 3 段「Jev 是什麼：System 1 model」

System 1 model

一類專做快速結構化決策、讓軟體能直接使用其輸出的 AI 模型。

這是 TypeSafe AI 文件中的定義：「evaluates a state and questions and returns typed answers and probabilities」。命名借自心理學家 Kahneman 對兩種思維的區分——System 1 是快、便宜、直覺式；System 2 是慢、貴、逐步推理。把它套到模型上：LLM 逐 token 推理、可處理開放式問題，像 System 2；System 1 model 幾乎即時回傳型別化決策、只處理封閉式問題，像 System 1。要注意這是行銷上的類比，不是嚴格的認知科學對應——LLM 並不真的「推理」，只是行為上像。

相關術語: System 2 (相反)、Jev (實例)

出處：第 3 段「Jev 是什麼：System 1 model」

System 2

Kahneman 提出的第二種思維模式：慢、費力、逐步推理，用來處理開放式問題。

在《快思慢想》（Thinking, Fast and Slow）中，System 1 是自動、快速、直覺的（看到 2+2 立刻知道是 4），System 2 是刻意、緩慢、需要注意力的（算 17×24）。作者說 LLM「behave more like System 2」：慢、貴，但能對開放式問題做 step-by-step reasoning。這個對比的用意是替 Jev 定位——不是取代 System 2，而是把那些其實只需要直覺判斷、卻被丟給 System 2 做的事接回來。

相關術語: System 1 model (相反)、LLM (類比)

出處：第 3 段「Jev 是什麼：System 1 model」

state

送給 Jev 的原始情境資料，例如一則客訴訊息，所有 questions 都針對它回答。

在投影片範例中 state 就是一段字串："Hi, I've been trying to connect my Stripe..."。它對應 LLM 世界裡的「prompt 內容」，但語意不同：state 不是指令，只是被判斷的對象；指令寫在每個 question 的 instructions 裡。這種把「資料」與「問題」分開的設計，讓同一個 state 可以同時被問多個問題。

相關術語: question (被其詢問)、Jev (輸入於)

出處：第 3 段「Jev 是什麼：System 1 model」

question

對 state 提出的一個封閉式問題，宣告答案的 type 並用自然語言 instructions 描述判斷標準。

範例中的 question 名為 is_urgent，type 是布林型別，instructions 是「訊息帶有緊急性或時效性」。Jev 回應時用同一個鍵名回傳同型別的值（0.999）。這裡的「型別」是事先宣告的，跟第 2 段 structured outputs 的 JSON schema 角色相似，但差別在於 Jev 不是被「約束」去符合型別，而是天生只能輸出那個型別的值。

相關術語: state (針對)、typed answer (產生)、structured outputs (類比)

出處：第 3 段「Jev 是什麼：System 1 model」

typed answer

Jev 對每個 question 回傳的值：型別跟 question 宣告的一致，並附帶機率或分數。

投影片上 is_urgent 的答案是 0.999，這是一個「這則訊息有緊急性」的機率，而非 true/false 的硬判斷。附帶機率的好處是程式可以自己設門檻（例如 > 0.9 才算緊急），也能把「不確定」當成一種訊號。這是 LLM 用 structured outputs 很難給出的東西——LLM 可以被要求輸出 true/false，但它輸出的「confidence: 0.8」多半是編出來的數字，不是模型內部真實的機率。

相關術語: question (回應)、structured outputs (對照組)

出處：第 3 段「Jev 是什麼：System 1 model」

TypeSafe AI

推出 Jev 與「System 1 model」概念的新創公司。

公司名 TypeSafe（型別安全）本身就點出產品定位：讓模型輸出對程式而言是型別安全的。作者引用的是它的官方文件對 System 1 model 的定義。第 6 段的 LangChain 整合套件與 API key 都以此命名。

相關術語: Jev (推出)

出處：第 3 段「Jev 是什麼：System 1 model」

PII

能直接或間接辨識出特定個人的資料，例如姓名、email、電話、地址。

Personally Identifiable Information。demo 裡的訊息含 dana.ruiz@northwind.co 與 (415) 555-0147，都是典型 PII。「這段文字有沒有 PII」是很典型的 guardrail 判斷：在把使用者輸入送去記錄、送給第三方模型、或回傳給其他人之前，先判斷要不要遮蔽。這種判斷不需要生成任何文字，只需要一個機率，所以是 Jev 這類模型的天然用例。

相關術語: classification task (一種)

出處：第 4 段「Demo：LLM vs Jev 回答 PII 問題」

classification task

答案落在有限選項內（是／否、A／B／C、一個分數）的判斷任務，不需要生成新內容。

作者用「classification or decision style tasks」概括 Jev 擅長的範圍。判斷標準很簡單：如果一個任務的答案空間是事先可以列舉的，它就是分類型；如果需要寫出一段新文字，它就不是。agent 系統裡其實藏著大量分類型任務——該不該呼叫工具、這個請求危不危險、這個回答好不好——只是因為方便，大家習慣通通丟給 LLM。第 3 段說 Jev 只接手「特定任務」，這段把「特定」定義成了「分類型」。

相關術語: Jev (擅長)、LLM (常被其代勞)

出處：第 4 段「Demo：LLM vs Jev 回答 PII 問題」

latency

從送出請求到拿到回答所經過的時間。

demo 的核心對照就是 latency：LLM 約 5 秒、Jev 約 0.1 秒。對 agent 而言 latency 會累加——一個 loop 跑十輪、每輪都要先做一次判斷，5 秒與 0.1 秒的差距就變成 50 秒與 1 秒。這也是為什麼後面談到把判斷步驟放進 agent loop 裡時，速度會成為「能不能開著這個功能」的決定因素。

相關術語: agent loop (在其中累加)

出處：第 4 段「Demo：LLM vs Jev 回答 PII 問題」

choice

從事先列出的選項中挑一個，Jev 回每個選項的機率分佈與一個整體 confidence。

投影片範例：「哪個團隊該處理？」選項 billing / technical / sales，回 0.84 / 0.159 / 0.001。程式端通常取最高者，但也可以看第二名——當前兩名很接近時，可以轉人工或再問 LLM。這是 routing（把請求分派到不同處理者）最直接的工具。

相關術語: question (一種)、confidence (附帶)

出處：第 5 段「Jev 回答的三種問題類型」

score

在一條有刻度的連續量尺上定位，回一個實數與 confidence。

範例：客戶多沮喪？量尺標 Calm、Frustrated、Very angry，回 1.035。它不是三選一，而是連續值，所以能表達「比 frustrated 再多一點」。適合強度、優先度、品質分等本來就是程度問題的判斷；後面談到用 Jev 打 rubric 分數時用的就是這種型別。

相關術語: question (一種)、choice (對照組)

出處：第 5 段「Jev 回答的三種問題類型」

noul

Jev 對是／否問題的型別名稱，回傳「為真」的機率（0 到 1）。

投影片標題寫 Noul，副標「Is this true?」，作者口頭則說 boolean。第 3 段的 is_urgent 與第 4 段的 has_pii 都是這個型別。它回的是機率而非硬 true/false（範例 0.999），所以門檻由程式決定；這讓同一個判斷可以在不同風險情境用不同門檻，例如遮蔽 PII 用 0.5、擋掉危險操作用 0.2。

相關術語: question (一種)、typed answer (回傳)

出處：第 5 段「Jev 回答的三種問題類型」

confidence

Jev 對「這一題自己判得準不準」的整體評估，跟各選項的機率是兩回事。

choice 範例裡 billing 已經拿到 0.84，但 confidence 只有 0.596；score 範例 confidence 0.842。可以這樣理解：機率分佈回答「哪個對」，confidence 回答「我該不該相信這個分佈」。實務上這是一個很好用的分流訊號——confidence 低就把這筆交給更貴的 LLM 或人工，高就直接採用。這是 LLM 用 structured outputs 給不出的東西：LLM 被要求填一個 confidence 欄位時，那個數字是「生成」的，不是模型內部的量測。

相關術語: typed answer (附屬於)、choice (見於)

出處：第 5 段「Jev 回答的三種問題類型」

parallel questions

一次送一個 state 與多個 questions，Jev 同時算出所有答案而非逐題順序回答。

作者強調這是跟 LLM「sequential reasoning」的又一個對比。原因在架構：Jev 對 state 編碼一次後，每個 question 是獨立的輸出，互不依賴；LLM 要回答多題得在一段文字中依序寫出，後題必須等前題的 token 生成完。實際效果是：問一題與問十題的延遲差不多，所以設計 harness 時可以放心一次多問幾個判斷（該走哪個模型？危險嗎？緊急嗎？），不必為每題付一次 latency。

相關術語: state (共用)、latency (不隨題數增加)

出處：第 5 段「Jev 回答的三種問題類型」

langchain-typesafe

把 Jev 包成 LangChain 元件的 Python 套件，用 uv pip install langchain-typesafe 安裝。

LangChain 的整合套件慣例是 langchain-<供應商>，每個供應商一個獨立套件，主套件不必跟著升版。這個套件提供 TypeSafeClassifier 以及三種問題型別的類別（投影片上示範了 Noul）。因為它遵守 LangChain 的 Runnable 介面（有 invoke），所以能直接放進 LangGraph 節點或當 middleware 用。

相關術語: TypeSafeClassifier (提供)、TypeSafe AI (整合)

出處：第 6 段「在 LangChain 裡用 Jev」

TypeSafeClassifier

langchain-typesafe 提供的類別，invoke 一個含 state 與 questions 的字典，回傳各題的 typed answers。

名字叫 classifier 而不是 model 或 chat，是刻意的：它提醒使用者這不是拿來對話的東西，而是拿來做分類判斷的。用法：classifier = TypeSafeClassifier()；response = classifier.invoke({"state": ..., "questions": {...}})；response.nouls["is_urgent"].noul 取值。API key 從環境變數 TYPESAFE_API_KEY 讀取。它跟 LangChain 裡的 chat model 一樣有 invoke，所以能塞進任何接受 Runnable 的位置。

相關術語: Jev (封裝)、langchain-typesafe (屬於)

出處：第 6 段「在 LangChain 裡用 Jev」

middleware hook

在 agent loop 的固定時點（例如 LLM 呼叫前後、工具執行前後）插入的一段攔截邏輯。

投影片右下角寫「Call it anywhere: a node, a tool, or a middleware hook」。node 是 LangGraph 流程圖上的一個步驟；tool 是 agent 可以主動呼叫的工具；middleware hook 則是不需要 LLM 決定、每一輪都會自動經過的攔截點。三者對應第 1 段 agent loop 的不同位置。Jev 特別適合放在 middleware：因為它 0.1 秒就回，每一輪都跑也不會拖慢 loop；如果換成 LLM 來做同樣的攔截，每輪多五秒，使用者很快就會把它關掉。

相關術語: agent loop (掛在其上)、harness (屬於)

出處：第 6 段「在 LangChain 裡用 Jev」

model routing

依每個請求的複雜度或性質，決定把它送給哪一個模型（快便宜或強昂貴）。

動機是成本與速度：最強的模型每一次呼叫都貴且慢，但 agent 做的事有八成是簡單的。routing 這一步本身如果用 LLM 做，等於為了省一次 LLM 呼叫先多花一次 LLM 呼叫，划不來；用 Jev 的 choice 問題（選項：fast / powerful）幾乎不花時間。作者說 LangChain 內部 coding agent 正在做這件事。放在 agent loop 裡，它是 request 進入 LLM 之前的一個節點。

相關術語: choice (以其實作)、agent loop (位於其入口)

出處：第 7 段「用例：model routing 與 auto mode」

auto mode

LangChain 提供的 middleware：讓 agent 自動執行工具而不逐一問人，但用分類器判斷每個 tool call 是否有風險，有就擋掉。

「auto」的意思是不用每個動作都請使用者按確認。要做到這點就需要一個看門人：每個 tool call 發出後、執行前，先判斷「危不危險」。作者的親身故事說明了這個看門人的速度就是 auto mode 能不能開著的關鍵——用 LLM 判斷太慢，她把它關了；換 Jev 後開回來。範例：會刪資料庫或刪重要檔案的呼叫會被分類為 risky 並在 runtime 被擋。在 agent loop 圖上，它掛在 LLM → tools 的 action 邊上。

相關術語: middleware hook (一種)、noul (以其實作)、tool calling (攔截)

出處：第 7 段「用例：model routing 與 auto mode」

coding agent

以 agent loop 驅動、能讀寫檔案、執行指令來完成程式任務的 agent。

作者兩個用例都以 LangChain 內部的 coding agent 為例，因為它同時具備兩個特徵：任務複雜度差異極大（改一個字 vs 重構模組），所以需要 routing；工具有真實破壞力（刪檔、跑指令），所以需要 auto mode 的攔截。它也是對 latency 最敏感的一類 agent——使用者盯著終端機等，每一輪多五秒都很明顯。

相關術語: agent loop (實例)、auto mode (使用)

出處：第 7 段「用例：model routing 與 auto mode」

online evals

對 agent 在真實流量中產生的每一條 trace 即時或準即時地打分，而不是只在開發階段跑固定測試集。

跟 offline evals（開發時用固定資料集跑分）相對。online 的難點是量大：每一條真實對話都要評，人工不可能，用 LLM 評則成本隨流量線性成長。所以 online evals 對 judge 的速度與成本極度敏感，這正是 Jev 的優勢所在。「trace」指一次 agent 執行從 request 到 result 的完整紀錄。

相關術語: LLM-as-a-judge (常用方法)、rubric (依據)

出處：第 8 段「用例：Jev 當 online evals 的 judge」

rubric

把「好回答」拆成幾條可獨立判斷的準則，每條分開打分。

投影片範例：Correct（符合參考答案）、Grounded（有引用來源）、Complete（列出所有條件）。拆成多條的好處是可診斷——總分 0.67 本身沒意義，但看到 complete 0.11 就知道問題出在漏條件。對 Jev 而言，每條 rubric 就是一個 question（score 或 noul），instructions 寫判斷準則，多條一次平行回答。

相關術語: score (以其實作)、parallel questions (利用)

出處：第 8 段「用例：Jev 當 online evals 的 judge」

LLM-as-a-judge

用一個 LLM 讀 agent 的回答並依 rubric 打分，取代人工評分。

這是目前最常見的自動評估方式，能處理 code 式 evaluator 做不到的語意判斷。缺點有二：貴（每筆 eval 一次完整 LLM 呼叫，還常要 chain-of-thought）與不穩（同輸入不同次打分會漂移，因為分數是生成的）。作者把 Jev-as-a-judge 定位為它的「演進」而非取代：開放式、需要解釋理由的評估仍需 LLM；但沿著固定 rubric 打分這種封閉判斷，Jev 更快、更便宜、也更一致。

相關術語: Jev (被其演進)、online evals (用於)

出處：第 8 段「用例：Jev 當 online evals 的 judge」

code-style evaluator

用確定性程式（字串比對、正則、格式檢查、跑測試）判斷回答對不對的評估方式。

它快、免費、完全一致，但只能檢查「形式」——回答裡有沒有某個關鍵字、JSON 合不合法、單元測試過不過。它判斷不了「這個回答有沒有依據」「有沒有漏條件」這類語意問題。作者的框架是三層：code-style evaluator（便宜但淺）→ Jev（便宜且能做語意分類）→ LLM-as-a-judge（貴、能做開放式評價）。Jev 填補的是中間那一層。

相關術語: LLM-as-a-judge (相反)、Jev (被其補足)

出處：第 8 段「用例：Jev 當 online evals 的 judge」