在構建自主 Agent 或多步驟工作流時，工程師最常遭遇的吞吐量瓶頸，往往不是後端業務邏輯，而是架構中的「決策節點」。

我們習慣把一個巨大的對話型 LLM 當成萬能轉轍器：給它一段龐大的 prompt，附帶嚴苛的 JSON Schema 指令，要求它「判斷使用者意圖是否需要退款，若是要退款請輸出 {"action": "refund"}，否則輸出 {"action": "escalate"}」。

這種做法本質上是用重型大砲打蚊子。用每秒生成幾十個 token 的自迴歸（Autoregressive）生成器，去承擔軟體工程裡只需要 1 個 bit 的布林判斷或枚舉選擇，不僅浪費了數千個 input tokens，更帶來了高達數秒的端到端延遲與非確定性的解析崩潰風險。

2026 年 9 月 15 日，前 OpenAI 研究員、InstructGPT 論文共同作者 Diogo Almeida 創辦的 TypeSafe AI 公開 Jev。兩天後，LangChain 發布 Jev harness 整合案例；Sydney Runkle 再於 9 月 18 日整理成完整實作文章：Jev 不是取代負責推理與生成的模型，而是在模型選擇與工具執行前，提供可由程式消費的決策。

9 月 22 日，社群接連梳理了實踐樣貌：@3three_AI 先整理了 20 個面向中文情境的初階案例；同日，老姚進一步彙整發布了涵蓋 60 個公開記錄、59 個去重出處的《Jev 應用圖譜》，將工程界的使用軌跡歸納為 9 大場景模組，並明確標記了從官方教程、開源原型到作者實驗的證據邊界。這些清單的工程價值不在於宣稱「Jev 能做幾十件事」，而在於它們反覆指向同一種可拆出的工作：先把開放式輸入壓成有限的選項、分數或風險訊號，再讓既有程式決定是否執行。

這個案例把原本的架構主張推得更具體：AI Agent 的分水嶺，在於把自迴歸文字生成（System 2）與低延遲、強型別的決策（System 1）拆成不同責任。 Jev 不負責完成任務；它負責回答「接下來該走哪條已知路徑，以及這個判斷有多不確定」。

傳統自迴歸路由的工程代價

在傳統架構中，哪怕我們透過 Structured Outputs、JSON Mode 或 Function Calling 來約束模型，底層的推論機制仍然是一顆 token 接一顆 token 預測。這在軟體整合面上產生了三個根本矛盾：

  1. 推論延遲與計算吞吐量脫節：為了得到一個 true 或 false，模型需要載入完整的注意力快取（KV Cache），並在生成階段耗費數百毫秒甚至數秒。當 Agent 的單次任務需要經歷 10 到 15 個條件判斷分支時，延遲會呈線性堆疊。
  2. 機率校準缺位：生成式 LLM 給出的文字是離散採樣的結果。即便輸出了某個選項，你依然難以得知模型對這個決策的精確信心水準（Confidence Calibration）。工程師只能透過提示詞硬要模型輸出 confidence: 0.8，但這種自評分數往往嚴重過度自信且缺乏統計學上的校準基礎。
  3. 無效上下文的成本膨脹：在複雜工作流中，維護對話歷史與系統提示詞會讓輸入端急遽膨脹。以社群基準測試為例，使用通用程式碼模型做客服意圖分流，單次請求可能吃掉上萬個 input tokens；而實際需要處理的業務狀態，可能只有幾百個位元組。

在架構維度上，傳統生成式模型與專用決策模型存在根本性的分工差異：

  • 運作機制：傳統生成式模型依賴自迴歸逐字解碼（Token-by-token）；專用決策模型則在單次前向傳遞中完成平行評估（Parallel evaluation）。
  • 推論延遲：傳統 LLM 在 TypeSafe 實測中耗時 3 秒至 329 秒（依模型大小與推理鏈長度而定）；專用決策模型公布數據為 70 ms 至 500 ms。
  • 輸出格式：傳統架構輸出自然語言或強制序列化的 JSON 字串；專用模型輸出原生強型別標量與經校準的機率分佈。
  • 失敗模式：傳統模型易發生 JSON 語法截斷、欄位漂移與幻覺；專用模型嚴格約束在已知 schema 內，輸出保證符合型別（但仍需防範語意誤判）。
  • 系統定位：傳統 LLM 定位為 System 2（慢想、深度推理與內容創作）；決策模型定位為 System 1（快思、狀態判定與即時路由）。

上述速度區間來自 TypeSafe 在 2026-09-15 發布的官方比較，不是跨供應商、跨區域的中立 benchmark。它適合用來形成測試假設，不適合直接寫進容量規劃。

Jev 的三項決策原語（Decision Primitives）

Jev 的核心設計哲學在於「完全不輸出自由文字」。它接收非結構化的輸入狀態，並直接對開發者定義的一組強型別問題，進行單次前向傳遞的平行計算。

在 TypeSafe AI 的抽象中，所有的控制流決策被凝練為三種基礎原語：

  • Noul：帶有機率值的二元布林判斷。例如「這筆請求是否包含未授權的操作意圖？」模型不會生成字串，而是直接回傳 P(True)（如 0.94）；Noul 沒有另一個獨立的 confidence 欄位。
  • Choice：從預先定義的枚舉集合中挑選最佳解，並輸出完整的機率分佈。例如意圖分類路由，輸出 {"technical_support": 0.73, "billing": 0.25, "general": 0.02}，另外附上描述整體分布集中程度的 confidence。選中項目的機率與 confidence 不是同一個訊號，門檻應分開設定。
  • Score：具備順序級別的評分指標。例如「使用者當前情緒滿意度（1 到 5 分）」，回傳連續 score、對應級別與 confidence。

這種設計使得底層模型可以利用 RLCD（Reinforcement Learning for Calibrated Decisions，校準決策強化學習） 進行特化訓練。模型優化的目標不是產生人類偏好的文字，而是讓 System 1 任務的輸出機率更能反映實際正確率。TypeSafe 目前只公開方法名稱與產品評測摘要；團隊仍需用自己的標記資料量測 Brier Score、Expected Calibration Error 與門檻下的錯誤成本。

System 1 決策模型在 Agent 工作流中的分流 非結構化輸入先由 System 1 產生強型別判斷與機率，再依信心和後果分往受限的確定性程式、System 2 推理或人工審核。INPUT非結構化狀態事件、工具結果、請求SYSTEM 1已知選項的判斷Choice / Score / Noul回傳分佈，不執行動作HIGH CONFIDENCE + ALLOWLIST確定性程式受限的、可驗證路徑OPEN-ENDED WORKSystem 2 生成與推理未知答案或內容合成LOW CONFIDENCE / HIGH CONSEQUENCE人工審核或固定回退不把機率當授權
INPUT非結構化狀態

事件、工具結果、請求

↓
SYSTEM 1已知選項的判斷

只回傳 Choice、Score 或 Noul 的訊號。

↓ 依信心與後果分流
確定性程式

只走 allowlist 的可驗證路徑。

System 2

處理未知答案與內容合成。

人工或回退

低信心或高後果時停止。

圖：System 1 供應語意判斷訊號；真正的 action 仍由後果、政策與可驗證邊界決定。

架構重構：落地雙軌制（Fast/Slow Engine）

把 Jev 類型的模型納入生產環境，並不是要完全揚棄強大的通用大模型，而是建立清晰的責任邊界。

我的立場是：Agent 工作流中需要語意判斷、但答案空間已知的控制節點，應優先交給 System 1；權限與副作用仍由確定性程式碼執行，只有開放式推理與內容產出才交給 System 2。

官方 Python SDK 的介面很直接：一份 state 搭配多個 questions，同一次請求回傳 Choice、Score 與 Noul 的答案。以下示例使用 TypeSafe Quick Start 的實際 client 與回應結構，示範怎麼把機率留在程式控制流裡：

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()  # 從 TYPESAFE_API_KEY 讀取憑證


def decide_next_step(payload: dict[str, object]) -> dict[str, object]:
    response = client.system_one(
        state=payload,
        questions={
            "intent": Choice(
                instructions="Which queue should handle this ticket?",
                criteria={
                    "refund": "Refund or duplicate charge",
                    "technical": "Bug or integration problem",
                    "sales": "Pricing or account question",
                    "spam": "Unsolicited or malicious content",
                },
            ),
            "is_urgent": Noul(
                instructions="This ticket needs immediate attention",
            ),
            "risk": Score(
                instructions="Operational risk if handled automatically",
                criteria=["low", "medium", "high"],
            ),
        },
    )

    intent = response.answers["intent"]
    risk = response.answers["risk"]
    selected_probability = intent.probabilities[intent.choice]

    # 1. 模型給判斷，程式決定後續 action；此處不直接執行副作用
    if intent.choice == "spam" or risk.score >= 1.5:
        return {"action": "quarantine", "route": intent.choice}

    # 2. 選中項目的機率與分布集中度都通過門檻，才進入自動退款規則
    if (
        intent.choice == "refund"
        and selected_probability >= 0.90
        and intent.confidence >= 0.75
    ):
        return {"action": "run_refund_rules", "route": intent.choice}

    # 3. 分布不集中時交給人工；其餘路由才交給 System 2
    if intent.confidence < 0.75:
        return {"action": "human_review", "route": intent.choice}

    return {"action": "reasoning_model", "route": intent.choice}

這段程式刻意不宣稱「90% 的事件都能自動處理」。能安全直通多少比例，取決於你的資料分布、錯誤成本與門檻校準。真正的架構改變是：昂貴的 System 2 模型只接收需要多步驟推理或語言合成的工作；明確規則與副作用仍由程式碼掌握。

不買 Jev 也能驗證「不生成文字」的推論路徑

Avi Chawla 在 2026-09-20 的〈Build Your Own Jev (100% Local)〉把這個想法收斂成一個可在本機檢驗的實驗：不要求一般 decoder 寫出 JSON，而是讓它在 prompt 的下一個位置對固定標籤評分。SGLang 的 /v1/score 文件明列 query、items、label_token_ids 與 apply_softmax；回傳的 scores 依指定 token ID 的順序排列。這讓團隊可以用既有 checkpoint 驗證「答案空間固定時，停止生成是否真的改善自己的延遲與解析失敗率」。

這條本機路徑的核心不是讓模型讀出 billing、technical、account 三個字，而是把語意完整寫進 prompt，然後只讀下一個位置的三個標籤 token，例如 A、B、C。取出三個 logits 後，只在這個候選集合內做 softmax，得到的數字回答的是「在這三個候選中，模型偏好哪個」，不是「模型有多少機率真的正確」。若沒有 OTHER 或 ESCALATE，softmax 仍會把 100% 的質量硬分給錯誤集合；若標籤在實際 chat template 與前置空白下不是單一 token，則比較已不再是同一個輸出位置。

local_scoring_gate:
  choices: [refund, technical, account, escalate]
  label_validation: exact-rendered-prompt, one-token-per-label
  accept_when: top_probability ≥ calibrated_threshold and margin_to_second ≥ calibrated_margin
  otherwise: human_review
  never_authorizes: refunds, deletion, permission_changes

這是很有價值的 control experiment，卻不是 Jev 的替代宣稱。TypeSafe 說明 Jev 會平行輸出機率，並以其訓練與 workflow eval 做產品主張；它也承認公開的速度與成本數字是特定測試設定的結果。官方說明與本機 API 可共同支持的結論只有：停止自迴歸解碼能改變推論路徑。是否有可用的校準、較低 P95，或可接受的錯誤成本，仍要在自己的標記資料、完整 prompt、硬體與併發量上量測。

固定選項評分如何略過文字生成完整 prompt 經一次 prefill 取得下一個位置的 logits，系統只讀取固定標籤、在候選集合內正規化，最後回傳選項與分佈，而非生成 JSON 或句子。01 · PROMPT語意與候選A = refund · B = tech02 · PREFILL一次前向傳遞停在 answer position03 · LABEL + SOFTMAX固定候選中正規化每個標籤都須一 token04 · PROGRAM OUTPUTchoice + 分佈不是 JSON 或句子
01完整 prompt

語意留在 prompt；候選對應短標籤。

↓
02一次 prefill

模型產生下一個位置的 vocabulary logits。

↓
03讀固定標籤

驗證 A、B、C、ESCALATE 各自是一 token。

↓
04restricted softmax

只在宣告的候選中換算分佈，再交給程式。

圖：local scoring 的省略不是少寫 JSON，而是根本不進入自迴歸 decode loop。

LangChain 把 Jev 放進 Agent loop 的兩個位置

Sydney Runkle 在 2026-09-18 的文章沒有把 Jev 包裝成另一個聊天模型，而是把它接到 Agent harness 的 middleware。LangChain 的整合先用 TypeSafeClassifier 暴露 state + questions → answers，再提供兩個實驗性 middleware：模型路由與工具風險閘門。

模型路由：先選能力級距，再開始整個 run

簡單查詢、資料擷取與局部修改，不需要和架構決策、高風險變更使用同一個推理模型。LangChain 的 Jev harness 範例讓 ModelRouterMiddleware 先檢查最新的使用者訊息，從預先定義的模型集合中選一個，並在整個 run 期間沿用該選擇：

from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import (
    ModelChoice,
    ModelRouterMiddleware,
)

router = ModelRouterMiddleware(
    choices={
        "fast": ModelChoice(
            model="openai:luna",
            criteria="Direct lookups, extraction, and localized changes.",
        ),
        "powerful": ModelChoice(
            model="openai:sol",
            criteria="Architecture and high-stakes decisions.",
        ),
    },
    instructions="Choose the least costly model that can complete the task.",
)

agent = create_agent("openai:gpt-5.6-luna", middleware=[router])

這個切入點的重要性在於「先選一次」：若每一步都重新路由，省下的模型成本可能被重複分類延遲吃掉，run 內也容易因能力與行為風格切換而漂移。路由結果的機率仍保留在 Agent state，團隊可以追蹤低信心案例，而不是只留下最後選了哪個模型。

工具風險閘門：在副作用發生前多一道判斷

第二個位置是 tool call 與真正執行之間。AutoModeMiddleware 可以針對指定工具檢查即將發生的呼叫，風險不符合策略時先擋住，而不是等 shell、瀏覽器或交易工具已經產生副作用才補救：

from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import AutoModeMiddleware

guardrail = AutoModeMiddleware(tools=["bash"])
agent = create_agent(
    "openai:gpt-5.6-luna",
    middleware=[guardrail],
)

這個 pattern 適合把「明顯低風險可自動執行、模糊或高風險要停下」寫成 harness 政策。不過分類器不是授權系統。真正不可逆的動作仍需要 sandbox、最小權限、allowlist、交易邊界與人工核准；否則一次高信心誤判就可能直接變成事故。

型別安全只解決介面，不解決真實性

Jev 可以保證答案落在預先定義的型別與選項內，但不能保證語意判斷一定正確。TypeSafe 官方 skill也明確區分兩件事：typed output 保證介面，不保證真相；Choice 與 Score 的 confidence 描述分布集中程度，不等於整個工作流可以安全自動化。

所以生產環境至少要另外保留四個控制面：

  1. 離線評估集：用真實流量中的正常、邊界與攻擊案例，分別量測每個問題的誤判率與校準曲線。
  2. 按後果設門檻：客服佇列分錯可以重派，刪除資料或付款分錯不能用同一個 confidence threshold。
  3. 服務失敗回退：timeout、rate limit 或供應商中斷時，明確選擇 fail closed、固定規則、System 2 或人工，不讓例外默默繞過政策。
  4. 完整觀測：記錄 state 版本、question 版本、模型版本、原始機率、最終分支與後續結果，才能知道門檻是否仍適用。
從模型分佈到 action 的控制邊界模型分佈要先通過完整候選集合與單 token 標籤檢查，再經標記資料校準的門檻；任一失敗交由人工或回退，通過後仍由確定性政策決定是否允許 action。否否是MODEL SIGNAL候選分佈不是授權每個標籤一 token 且有ESCALATE？經標記資料校準的機率與margin 通過？DETERMINISTIC POLICY程式決定 action權限與副作用另行檢查SAFE FALLBACK人工審核、固定規則或 System 2
1模型只給分佈

分數是訊號，不是 action 的授權。

↓
2檢查候選集合

每個標籤一 token，並保留 ESCALATE。

↓
3檢查校準門檻

用標記資料驗證 probability 與 margin。

↓
4確定性政策再決定 action

權限、allowlist 與人工核准不交給模型。

任何一步失敗：人工審核、固定回退或 System 2。

圖：校準能協助選擇下一步；它不會取代授權、最小權限或不可逆動作的人工核准。

傑文斯悖論（Jevons Paradox）的軟體預言

TypeSafe AI 將這款模型命名為「Jev」，致敬的是 19 世紀經濟學家威廉·斯坦利·傑文斯提出的傑文斯悖論——提高資源使用效率通常會增加、而不是減少該資源的總體消耗。

在傳統認知中，軟體工程師不敢在每一行程式碼、每一個單元測試、每一個日誌行注入 AI，因為「LLM 太貴、太慢、不可控」。

但當決策模型把單次推論壓到 TypeSafe 公布的 70 至 500 毫秒區間、把輸出限制為強型別判斷與機率分布後，工程師呼叫 AI 決策的頻率不會維持在原來的低水準，而是可能增加數個數量級。這是廠商目前的產品與評測主張，仍需要用自己的區域、輸入長度與併發量驗證：

  • 過去你只在使用者按下「送出」時呼叫一次 AI；未來你可以在使用者打字的每一次停頓、背景佇列的每一個重試輪迴，全量運行決策模型。
  • 過去 CI 只能跑靜態 Lint；未來每次 Git commit 都可以掛載一個 Jev 節點即時計算語義相容性與風險指數。

哪些場景該換成 System 1？10 種決策形狀的落地邊界

當推論延遲從秒級縮短到數百毫秒、成本降至自迴歸生成式模型的小數點後幾位時，最關鍵的架構問題變成：哪些工作該交給 System 1，哪些必須留在 System 2？

TypeSafe AI 在官方的 Use Case Map 中，將軟體工程常見的語意判定依輸出結構歸納為十種「決策形狀（Decision Shapes）」。這十種形狀在系統設計上大致對應兩大應用範式：

1. 通用驗證與防禦閘門（Universal Verification & Guardrails）

在傳統 Agent harness 中，對 LLM 的輸入提示、輸出回應與 tool call 進行驗證，往往也是呼叫另一個 LLM。這意味著防禦層的成本與延遲甚至超過了被保護的業務本身。

在 System 1 視角下，防禦層不需要生成任何解釋文字，只需要強型別的判定：

  • Detection（存在檢測）：以布林機率判定單一屬性是否存在，例如偵測 Prompt Injection、敏感資料洩漏、合約關鍵條款缺漏或客服退款意圖。
  • Scoring（階梯評分）：在固定量表上輸出順序等級，例如評估生成回答的引用支撐度（Citation Support）、工具呼叫風險指數，或客服對話的負面情緒嚴重度。
  • Verification（工件核驗）：驗證先前步驟的執行工件是否違反特定策略，若失敗則直接在程式層阻斷並重試，不將無效狀態傳遞至下游。

2. 語意巨量處理與特徵萃取（Semantic Map-Reduce & Feature Extraction）

過去企業難以對數百萬筆客服對話、日誌追蹤或即時網路串流做全量深度語意分析，核心阻力在於自迴歸模型的 Token 計價與慢速吞吐。

System 1 決策模型能夠作為巨量非結構化資料到關聯式/向量資料庫之間的「特徵降維器」：

  • Classification & Routing（分類與路由）：在預先定義的類別集合中給出機率分佈，決定下一段程式碼路徑（如工單派發、模型階梯路由、工單嚴重度升級）。
  • ML Feature Extraction（機器學習特徵萃取）：從自由文字（如業務拜訪紀錄、事故復盤）中即時萃取購買意願、流失風險或詐欺訊號，輸出標準化的機率標量，直接作為下游傳統預測模型（如 XGBoost、風控評分卡）的特徵輸入。

這四種決策形狀在輸出合約與工程特性上有清晰的分工：

  • Detection（存在檢測）
    • 輸出合約：單一屬性之 P(True)。
    • 傳統 System 2 痛點：容易因 Prompt 幻覺輸出非預期 JSON，多輪重試拉高延遲。
    • System 1 架構優勢：單次前向傳遞，輸出真值校準機率，無語法截斷風險。
  • Scoring（階梯評分）
    • 輸出合約：順序評級與連續 Score。
    • 傳統 System 2 痛點：LLM 自評分數過度集中且缺乏統計校準基礎。
    • System 1 架構優勢：經 RLCD 特化訓練，評分具備排序單調性與可靠信心水準。
  • Routing（分類與路由）
    • 輸出合約：枚舉機率分佈與整體 Confidence。
    • 傳統 System 2 痛點：輸出格式漂移、逐字生成延遲拖垮整體 Agent loop。
    • System 1 架構優勢：強型別枚舉，毫秒級決定下游代碼分支。
  • Verification（工件核驗）
    • 輸出合約：規則核驗矩陣（通過 / 違規標籤）。
    • 傳統 System 2 痛點：核驗成本甚至高於主任務，無法在生產流量全量運行。
    • System 1 架構優勢：輕量化常駐於 harness 與 CI 管道中，實時阻斷無效狀態。

Jev 應用圖譜：60 個公開案例、9 大場景與三階證據邊界

如果只看社群上的片段展示，很容易把 Jev 誤判為「又一個做展示用的玩具模型」。但若拉高視角，檢視截至 2026 年 9 月 20 日已公開的實踐，會發現工程界正在把原本由 Chatbot 粗糙處理的各類控制節點，系統化地遷移到 System 1。

老姚在《Jev 應用圖譜》中，將 60 條公開記錄（涵蓋 59 個去重出處）收斂為 9 大場景模組。所有案例無論表面功能為何，底層架構均嚴格遵循同一個「三步解耦模型」：

  1. 01 · 輸入材料（Context）：提供非結構化狀態、DOM 快照、程式差異、工單內容與預先定義的候選集合。
  2. 02 · Jev 判斷（Engine）：在單次前向傳遞中平行回答多個強型別問題，輸出 Choices、Scores 或 Nouls，以及校準後的機率分佈。
  3. 03 · 推進流程（Action）：由外部確定性程式碼接收結構化結果，觸發下游代碼分支、阻斷高風險動作，或在信心不足時轉入人工入口。

為了讓工程團隊快速對照自身業務，這 9 個場景模組依技術性質被收斂為三大應用叢集，逐一拆解其判斷責任與外部程式邊界：

第一叢集：實體對齊、檢索過濾與文檔工程

01 · GEO 與營銷（2 條案例）
  • 代表開源：usenotra/notra、replynodes/jev-web-analyzer
  • Jev 承擔的判斷：AI 回答中是否實質提及目標品牌；官網 Markdown 內容在產品定義、目標受眾與價值主張上的清晰度。
  • 外部程式接續動作：記錄提及分佈與引用 URL；生成多維表達診斷報告供人工優化，不直接連動外部 SEO 排名。
02 · 知識檢索與證據核驗（9 條案例）
  • 代表專案：superagents-lab/jev-search、MarissaFamularo/citation-verifier、jexp/neo4jev
  • Jev 承擔的判斷：檢索結果語義重排；RAG 證據前置過濾；引用句是否實質支持相鄰論斷；Neo4j 知識圖譜下一跳選擇。
  • 外部程式接續動作：剔除無效檢索；高亮矛盾引文並轉交人工覆核；程式碼獨立核對引文在原文中是否存在。
03 · 文檔與數據工程（9 條案例）
  • 代表專案：mattn/sqlite-jev、AkashPriyadarshii/jev-curate、TypeSafe 條款 cookbook
  • Jev 承擔的判斷：GDPR 條款多維平行標註；資訊抽取後逐欄位一致性校驗；分類樹逐層走訪；訓練語料品質評分。
  • 外部程式接續動作：觸發更強模型修正抽取錯誤；過濾 Parquet/JSONL 訓練資料集；在 SQL 函數內即時過濾資料行。

第二叢集：業務風控、Agent 守護與受控自動化

04 · 業務分流與風控（7 條案例）
  • 代表專案：TypeSafe 理賠 cookbook、Vercel 工單分流、LangGraph 郵件發票路由
  • Jev 承擔的判斷：車險理賠要件符合度；公司 SIC 行業分類；發票、採購單與合同四方交叉驗證；客服承諾兌現審計。
  • 外部程式接續動作：疑點分流至人工審核佇列；自動路由至財務或工單系統；未履約承諾發出風控告警。
05 · Agent 編排與安全（9 條案例）
  • 代表專案：LangChain AutoMode、noelzappy/tripwire、AshutoshVJTI/progressgate
  • Jev 承擔的判斷：工具呼叫前危險操作評估；生成回答出廠檢驗；Agent 探索是否陷入重複無效假設。
  • 外部程式接續動作：阻斷高危 Bash 執行；攔截違規生成內容；提示重規劃或強制終止失控的 Agent run。
06 · 瀏覽器與設備自動化（7 條案例）
  • 代表專案：browser-use/jev-ultrafast、droidrun、kitze/unclutter、HA-Jev
  • Jev 承擔的判斷：依當前已索引 DOM 選擇點擊或導航目標；Android 介面動作選擇；網頁干擾元素判定。
  • 外部程式接續動作：外部瀏覽器驅動執行點擊；隱藏干擾 DOM；智慧家居感測器觸發狀態切換。

第三叢集：研發維運、多媒體審核與基準評測

07 · 開發與維運（7 條案例）
  • 代表專案：sufianetaouil/every、frostney/clean-code-review、Vicente-MD/jev-resilience
  • Jev 承擔的判斷：依自然語言找函數；PR 差異多維品質檢查；Git 提交說明與實際改動一致性；HTTP 200 業務錯誤識別。
  • 外部程式接續動作：排列候選程式碼片段；生成結構化 review 反饋；標記未說明的代碼變更；觸發告警與重試。
08 · 內容與媒體審核（7 條案例）
  • 代表專案：Every 21 項寫作模式檢查、valentynkit/jev-skip、santos-sanz/jev-audio-beeper
  • Jev 承擔的判斷：字幕軌贊助廣告區間識別；影片轉錄逐句審查；語音詞級時間戳髒話檢測；文章 AI 味特徵比對。
  • 外部程式接續動作：播放器跳過片頭贊助；ffmpeg 精確消音插入提示音；Discord 社群違規發言標記。
09 · 交互與能力評測（3 條案例）
  • 代表專案：Doom 遊戲動作循環、LLM Chess 合法步選優、nekuda-ai/WindTunnel
  • Jev 承擔的判斷：結構化遊戲狀態下一步選擇；國際象棋合法棋步評估；WebMCP 結構化工具呼叫基準對抗。
  • 外部程式接續動作：遊戲引擎執行動作；棋盤程式驗證走步有效性；定量比較 DOM 模式與工具模式的吞吐量。

三階證據邊界：區分演示、原型與生產可用

在閱讀這 60 個公開案例時，軟體架構師最常犯的錯誤，是把「有人在 GitHub 上開源」直接等同於「這是一套能在企業級生產環境穩定運行的解法」。

依照老姚的證據口徑分析，這 60 條記錄跨越了三個截然不同的可信度層次：

  1. 官方記錄（27 條，45%）：來自 TypeSafe AI、Vercel 與 LangChain 的一手教學、cookbook 或受控評測。
    • 證據價值：證明 API 介面合約、原語呼叫機制與單元可行性。
    • 工程邊界：官方身份無法直接證明該解法已在大規模客戶生產中穩定部署，亦不能推論真實商業 ROI。
  2. 開發者開源專案（30 條，50%）：來自獨立工程師發布在 GitHub 上的實作倉庫。
    • 證據價值：證明 System 1 能嵌入真實技術棧（如 SQLite、Hono、Browser Use、Home Assistant、Discord Bot）。
    • 工程邊界：許多專案仍屬於 POC、dry-run 或特定環境的錄製回放（例如 Jev Resilience 默認故障放行、Commit Miner 無法替代完整資安稽核、航空訂票展示停在結帳前）。
  3. 作者實驗（3 條，5%）：如 Every Mike Taylor 的 37 篇寫作檢查、Maxim Saplin 的 80 局西洋棋評測，以及 WindTunnel 網頁任務測試。
    • 證據價值：提供了明確的樣本範圍、組件分工與統計數據。
    • 工程邊界：作者自評指標不等於獨立第三方的客觀復現；特定語料上的特徵匹配度，不能直接外推為跨語言、跨領域的通用判準。

4 條高槓桿業務遷移線與先測指標

與其盲目複製這 60 個展示，更具工程價值的做法是提取其中的高槓桿決策範式，對照自己的業務工作流進行漸進遷移。以下四個方向具備最高重用價值，但必須以相應的「先測指標（Pre-flight Metrics）」作為准入標準：

                    [ 業務工作流中待遷移的決策節點 ]
                                   │
         ┌─────────────────────────┼─────────────────────────┐
         ▼                         ▼                         ▼
   【實體與意圖】            【檢索與信源】            【內容與表達】
   · 品牌提及判定            · 證據支撐度審校          · 官網表達診斷
   · 同名實體對齊            · 不相關片段過濾          · 文本結構完整性
   · 商業意圖分類            · 錯引漏引防禦            · 寫作模式質檢
         │                         │                         │
         ▼                         ▼                         ▼
   [ 先測指標 ]              [ 先測指標 ]              [ 先測指標 ]
   · 提及精確率/召回率       · 錯引檢出率              · 人工評審一致性
   · 同名實體誤合併率        · 有效證據誤刪率          · 檢查項漏檢率
   · 標籤跨批一致性          · 檢索相關性改善幅        · 人工返工比例
  1. 品牌提及與實體歸一（GEO 與公關監測）
    • 架構模式：將目標品牌、同義詞、產品名與生成式 AI 的回答配對，先以 Noul 判定是否存在實質提及，再以 Choice 進行同名實體消歧義；引用 URL 與出現位置由正則或字串索引獨立處理。
    • 先測指標：提及識別精確率（Precision）、召回率（Recall）、同名實體誤合併率。
  2. 信源篩選與引用審校（RAG 與研報工作流）
    • 架構模式：將搜索策略、候選段落篩選、論斷支持度與原文真實存在性拆為獨立環節。Jev 只負責判斷「檢索片段是否實質支持該論述」，引文是否被竄改或捏造則交由字串核對工具。
    • 先測指標：相關性打分準確率、錯引檢出率、有效證據誤刪率（False Negative）。
  3. 商業意圖與問句特徵（線索路由與 CRM）
    • 架構模式：沿分類樹層級走訪，從自由對話中標註行業、場景、預算範圍、競品比較與採購意向，輸出標準化標量特徵，直接對接既有規則庫或傳統計量模型。
    • 先測指標：標籤分類一致性（跨時間/跨批次穩定度）、歧義率、特徵與最終付費轉化的相關係數。
  4. 官網表達與內容質檢（Landing Page 與行銷工件）
    • 架構模式：將產品定義清晰度、目標受眾痛點、價值主張獨特性、信任證據與行動指引拆為互斥的評估項。由 Jev 平行評分，人工只審查低分項目，避免主觀總分造成的溝通摩擦。
    • 先測指標：人工評審一致性（Inter-annotator Agreement）、漏檢率、修改後文章的真實轉換數據。

團隊落地的三個即時切入案例

如果你的團隊打算在一週內看到驗證成果，不要試圖建構全自動系統，而是挑選以下三個最安全的起手式：

案例 1：內容與資訊分流

  • Jev 應回答的有限問題：這則素材是忽略、略讀、保存或立刻成題嗎？這個標題是否需要人工重寫？
  • 不該交給 Jev 的責任：決定事實是否正確、直接發布文章。
  • 一週內要量測的結果：入選率、人工採用率、漏掉的重要素材、每篇的人工篩選時間。

案例 2：工單或線索路由

  • Jev 應回答的有限問題：應送往退款、技術、銷售、垃圾訊息，還是人工佇列？
  • 不該交給 Jev 的責任：退款、承諾補償、修改帳務或回覆客戶。
  • 一週內要量測的結果：路由正確率、重派率、低信心比例、首回應時間。

案例 3：Agent 下一步動作選擇

  • Jev 應回答的有限問題：目前狀態下應點哪個已觀測到的控制項、呼叫哪個工具、還是停止？
  • 不該交給 Jev 的責任：產生任意 selector／shell 指令、略過權限、宣告任務成功。
  • 一週內要量測的結果：完成率、無效動作數、人工接管率、獨立驗收失敗率。

第一個案例刻意把「文章好不好」縮成排序輔助。原貼文轉述的 61 項貼文診斷、約 1 秒與約 0.0004 美元，是 Rob Hallam 的案例數字；公開內容沒有足以重現的資料集與方法，因此只能把它當成待驗證的成本／延遲假說，不能當成「高分必定傳播」的保證。真正可用的起點是讓模型把 100 則素材排成四級，編輯只看 save 與 pitch；再以人工最後採用的結果回填，檢驗它是否真的少掉無效閱讀。

第二個案例最容易被誤做成全自動客服。更安全的做法是只讓分類改變佇列與優先級，保留回覆內容、退款資格與帳務寫入給既有的規則、業務系統與人員。這正符合 TypeSafe 對「非結構化 state 輸入、型別化機率決策輸出」的定位；它降低的是分流成本，不是取消業務責任。官方 Use Case Map也將 classification、routing 與 verification 分成不同決策形狀，實作時不要拿同一個 confidence 門檻處理所有後果。

第三個案例有最具體的開源參考。browser-use/jev-ultrafast讓 Jev 從當前已索引的 DOM 控制項選擇操作與目標，只有需要輸入文字時才交給另一個小型生成模型；它也在執行前重新檢查目標與頁面新鮮度，並在完成後由獨立檢查器驗證結果。該專案報告的 Google Flights 7.073 秒展示與三組配對比較，僅適用於其公開的單一工作、瀏覽器設定與少量重複，不是通用 browser-agent benchmark。它仍給出一條正確的設計原則：模型只能在當下已觀測、可驗證的動作集合中選擇；完成與安全要由模型外的檢查決定。

團隊在架構設計上的下一步

如果你正在為團隊的 Agent 系統規劃下一代架構，不要等到系統被延遲拖垮才回頭重構。現在就可以採取以下三個行動：

  1. 盤點 Agent 工作流中的決策節點：審視系統內的所有 prompt，挑出那些「輸出只需從清單二選一、多選一，或只需要評估門檻」的節點。
  2. 制定強型別原語合約：停止在 prompt 裡編寫冗長防禦規則要求模型輸出特定 JSON，改用枚舉、布林等資料結構定義控制邊界。
  3. 建立 System 1 / System 2 的降級與回退閥門：分開設定選中項目機率與 confidence 的門檻，並用離線資料校準。任一訊號不符合該動作的安全要求時，才啟動慢速模型或引導人工介入。

先不要急著替換整條 Agent loop。挑一個目前由 LLM 回傳固定枚舉的節點，保留既有路徑做對照，記錄一週的正確率、P95 延遲、單次成本與人工接管率。只有在品質門檻不退步、錯誤案例可追蹤，而且回退路徑真的可用時，再把相同模式擴到模型路由或工具風險閘門。

延伸閱讀

延伸閱讀：Jeeves 能自架判斷服務，但 17 秒尾端延遲必須先過驗收，以 Story 缺漏檢查拆解可自架的推理決策模型、拒答與延遲驗收。