🔍 本文基于 TypeSafe AI 官方文档、LiteLLM 与 LangChain 官方博客，以及 jev-mcp 等社区实现的公开资料整理而成，文末列出参考来源。
跑一个长任务的编码 Agent，其实在做大量「一眼就能判断」的小决定：刚刚那个 read_file 的结果对当前问题还有用吗？这一步该上顶配模型还是用便宜的？这个补丁碰了生产配置，要不要先停下来问人？这些判断都很小，小到不值得写一条手写规则，但又确实需要一个判断。现在的做法很粗暴：全都交给那个生成式模型，于是每一个小决定都要付一次完整调用，上下文被反复重读，延迟一层层叠上去。
TypeSafe AI 在 2026 年 9 月 15 日发布的 Jev，盯的就是这块空地。它不是更强的生成模型，而是一个只输出类型化决策、不生成任何文本的分类模型。
一、System One 不是「小号 LLM」
Jev 的定位叫 System One model，名字借自卡尼曼的《思考，快与慢》。它的接口形态和 LLM 完全不同：你给它一个 state（任何脏文本、JSON 或字符串数组），再给它一组带类型的问题，它把结果一次性还给你。
问题只有三种原语：
| 原语 | 问什么 | 返回什么 |
|---|---|---|
choice | 从最多 255 个标签里选一个 | 命中的 key、每个选项的概率、置信度 |
score | 在 2 到 10 级的评分表上打分 | 小数分数加完整分布 |
noul | 一句是非判断是否成立 | 0 到 1 的概率 |
有三个工程细节值得单独拎出来。
第一，一次请求里的所有问题并行评估。官方文档明确说，加更多问题几乎不改变响应时间，成本只增加问题本身那点 token。这意味着你可以顺手多问几个「投机性」问题，反正判断结果便宜，用不用由代码决定。
第二，输出自带校准过的置信度。TypeSafe 用自研的 RLCD（Reinforcement Learning for Calibrated Decisions）训练，概率是对着真实结果优化的。但官方文档同时给了一句很克制的提醒：校准是成组统计上的性质，它不保证某一条具体回答是对的。这句话后面还会再出现，因为它决定了你能把 Jev 放在什么位置。
第三，它不写回复、不生成代码、不解释理由。这一点在工程上比听起来重要得多。因为不生成理由，也就不存在「模型嘴上说没问题但实际有问题」这种解析陷阱；你的代码拿到的是一个可以直接分支的值，而不是一段需要再解析的 JSON 字符串。
性能数字方面，官方给的区间是 70 到 500 毫秒延迟，输入 token 价格 $0.25 到 $0.42 每百万，输出免费。首页那个「快 193.6 倍、便宜 444.6 倍」的对比数据是针对 System One 类任务的特定工作流，不要直接套到自己的场景上。
二、MCP 接入：三条现实路径
很多人的第一反应是把 Jev 当成编码 Agent 的模型换掉。官方文档在 Jev with coding agents 这一页里直接把这个念头掐灭了：不存在 model: "jev-latest" 这样的设置能把 Claude Code、Codex、Cursor 变成 Jev 驱动的 Agent，因为两者解决的问题不同，Jev 不会流式输出文本、不会调工具、不会改文件。
真正可行的做法是反过来：Agent 照常写代码，Jev 扮演它代码里的判断层。围绕这个思路，社区两天之内长出了三种形态的接入方式。
形态一：stdio MCP 工具包
代表是 burnigtm/jev-mcp，一个本地 stdio MCP server，Cursor 和 Codex 都能直接挂。它暴露九个工具，设计上有一点很聪明：jev_step 把「路由下一步」和「在准备好的候选调用里挑一个」合并成一次请求，于是宿主少花一轮 MCP 往返，也就少花一轮宿主模型 turn。原来的 jev_coding_loop 和 jev_tool_route 仍然保留。
Codex 的注册方式是一行命令：
codex mcp add jev --env TYPESAFE_API_KEY=ts_... \
-- node /absolute/path/to/jev-mcp/dist/index.js
它的边界写得相当坦白：prepared-call router 最多接受 32 个候选，空列表或全不合法就地返回、零 Jev 消耗；state 加问题要能在约 64000 token 的预算里放下；rank 最多 5000 个候选、每次上游调用最多 250 个选项，超出就走多轮归约。还有一条最容易踩的：Jev 从不发明参数，也不执行工具，它只能读到经过清洗的候选描述和参数形状，真正执行的调用由宿主本地校验后执行。
形态二：宿主钩子，而不是让 Agent 自己决定要不要调用
Brainwires/jev-mcp 这个实现走得更远，它同时提供 MCP server 和一个可嵌入的库，外加一个 Claude Code 插件的 hooks 层，把判断挂在 harness 的边界上：工具调用之前、拿到结果之后。
这个选择背后是一条值得记住的原则。如果判断只作为一个 MCP 工具存在，那么是否需要判断这件事就变成了 Agent 自己的自由裁量，而 Agent 完全可能不调用它。可是「提交代码前必须检查风险」这种要求，本身就不该是一个可选项。所以真正需要强制执行的检查，应该写成 harness 里的函数调用，而不是一个 Agent 可以选择跳过的工具。
形态三：代理式，工具名和 schema 原样透传
jev-playwright-mcp 是给官方 Playwright MCP 套一个代理，任何编码 Agent 连上去，看到的工具名、schema 和原生版本完全一致，只在中间悄悄插了一层判断。加上去的延迟是每次带注解的响应 100 到 600 毫秒，相同内容走内容哈希缓存，几乎零开销。
这种方式最容易被接受，因为它不改变任何既有配置和提示词，等于是给已有工作流加了个旁路。
另外还有两类值得一提：jevai.org 提供的远程 MCP 用 Streamable HTTP，文档里专门提醒必须走 https://www 前缀，因为 http 和裸域会重定向，而很多 MCP 客户端会把 POST 变成 GET，最后收到 405；以及 codex-jev-compaction 这种以 Codex 插件形式分发的实现，把判断彻底藏进插件里。
三、上下文压缩：逐条保留原文，不做有损摘要
上下文压缩是 Jev 目前最有说服力的落点，也是它和「让 LLM 总结一下历史」最本质的区别。
先看问题本身。长任务里堆积最多的是工具输出，其中大部分在后面的对话里已经不再有用。让 LLM 写一段摘要来替换它们，看起来合理，但摘要是有损重写：一个精确的约束、一个路径、一个错误号，很可能就在重写里消失了，而且消失得无影无踪。
LiteLLM 在 9 月 18 日发布的集成给了另一种做法。它把 typesafe 作为一个 guardrail 挂进 proxy，模式设为 pre_call，在调用你的模型之前先跑一遍压缩：
guardrails:
- guardrail_name: jev-compaction
litellm_params:
guardrail: typesafe
mode: pre_call
api_key: os.environ/TYPESAFE_API_KEY
optional_params:
relevance_threshold: 0.2
它对每一组已完成的工具交换问 Jev 一个简单问题：机器人还需要这个结果来回答用户最新的问题吗？默认 keep 概率低于 0.2 的工具结果会被替换成一句固定说明：
[Tool result removed by TypeSafe compaction: judged no longer relevant to the current task]
被保留的结果原样不动。tool call 及其 id 保留，所以对话结构对模型来说仍然是完整的；system 和 user 消息不变；最后一条 assistant 消息以及它所属的工具交换受到保护。这套逻辑同时兼容 Chat Completions、Anthropic Messages 和 Responses API，判断由 Jev 做，答案由你自己的模型写。
codex-jev-compaction 把同一思路做得更保守，它的六条规则几乎可以当成一个模板：
- 先固定，再推断。所有叙述和指令类 block、最近的证据、显式 pin、带路径的普通文本、已知未完成的标记，一律保留。一个工具调用和它的结果是不可分割的整体。
- 收紧候选。只有来自已知只读操作、且结果经过验证的完整一对一配对才有资格被删。未知工具、写操作、不完整的配对全部留下。允许的工具名只有
read、read_file、search、list、inspect、fetch。 - 把证据完整交给 Jev。每个
noul问题问的是「这一对是否应该保留」，工具结果不做省略或删节。 - 保留不确定性。只有当校验后的 keep 概率低于 0.2 时才丢弃，等于或高于 0.2 就保留。文档里那句话写得很好：一个概率不是无关性的证明。
- 原子应用。每一批必须返回所有被请求的概率，且都是 [0,1] 内的有限数。任何失败都会放弃这一批所有拟议的删除。
- 决策可审计。返回保留的原文、逐条 id 的决策和内容体积测量。Markdown 输出用字面围栏代码块，而不是生成的摘要。
把这两套实现放在一起看，会发现它们共同承认了一个事实：选择本身就是有损的，分类器也会错。所以原始输入要作为权威档案留着，压缩产出的东西是「带决策记录的交接包」，不是「我帮你总结好了」。
我的判断是，这条路线的价值不在于省了多少 token，而在于把不可验证的改写换成了可审计的删除决策。摘要式压缩最让人不安的地方是，你无法审查它删掉了什么；而逐条判定留下了一条可以逐项复核的痕迹。
四、模型分级路由：把「该花多少钱」变成可编程的判断
第二个落点是模型分级路由，这也是目前社区实现最密集的方向。
pi-jev-model-router 的做法很有代表性：每个 prompt 在开跑之前，Jev 回答四个原子问题。
task_kind choice: plan / implement / debug / refactor / review / research / explain / operate / write / chat
complexity score: trivial → architectural
capability_deserved score: minimal → maximum（忽略价格）
needs_deep_reasoning noul: yes/no 概率
然后由代码把这些答案组合成一个需求分：
demand = 0.55 * complexity + 0.45 * capability
demand = max(demand, kind_floor) # planning / review 不允许走便宜档
再依次过 confidence guard、budget guard、availability guard、cache guard，最后才切模型和推理强度。
这个设计里有一句分工原则值得抄下来：Jev 判断任务，代码掌握预算。任务判断是关于语义的纯解读，改预算上限不该让判断失效，所以两者必须分开，不能把「钱够不够」塞进给模型的 state 里。
Claude Code 上的 jev-model-router mod 是同一思路的另一套取舍，它问三个问题：tier（机械的本地工作 / 普通工程 / 困难或高风险）、effort（四档评分）、risky（是否碰生产、钱、凭证或不可回滚的状态）。然后用了两条不对称的置信度门槛：
- 想多花钱（换更大模型、更多推理），门槛
minUpgradeConfidence默认 0.3； - 想少花钱，门槛
minDowngradeConfidence默认 0.6； risky超过 0.7，直接走 deep tier 加真实推理，不参与门槛讨论。
我特别喜欢这个不对称设计，因为它承认了错误的代价不对等：判断失误导致多花一点钱，只是浪费；判断失误导致任务交给了一个太小的模型，是任务失败。而且它还有一条更狠的兜底：如果一个后端根本不报告置信度，那这个请求只能往上调，不能往下调。用不可测量的直觉去省钱，本身就是坏交易。
prompt cache 这个坑，比模型价格更贵
上面的讨论都建立在「换模型的收益大于成本」这个隐含前提上，但现实里有一个经常被忽略的反向成本：切换模型会丢弃 provider 的 prompt cache。
缓存是按模型隔离的，缓存读取大约只按输入价的 10% 计费。所以一次模型切换的等效代价，是把整个上下文按新模型的全价重读一遍；再切回来，还要再付一次。按文档里的估算，50k 上下文在 Sonnet 上切一次大约 $0.10，200k 大约 $0.45。
这就解释了两个看起来反直觉的设计：
- cache-aware 门控：先估算这次切换造成的缓存未命中成本（
contextTokens × 新模型 input 价减去缓存价），超过maxPenaltyUsd就直接拒绝切换。 - dead-band 防抖：需求分要超过当前档位区间（约为
tier ± 0.5）一个deadband之后才考虑换档，免得 prompt 在边界上反复横跳，每跳一次都重付一遍上下文。但跨档幅度足够大的「大跳跃」仍然放行，因为那是真正的能力变化，不是边际调整。
顺带一提，同档位内的专家模型替换（比如从通用模型换到代码特化模型）也算一次模型切换，代价一样要算。
选档本身也能自动化
pi-jev-router 走了更彻底的一步：它用 Jev 分类出任务类型，然后过滤整个模型目录，在质量、成本、延迟上算一条 Pareto 前沿，再取 knee point（离「最便宜」和「最贵」两点连线最远的那个点）。这样做不需要给三个维度配权重，模型目录一变，选择就跟着变。
不过这里要泼一盆冷水：它公开的基准只有五个任务，作者自己也标注了「分类开销未计入，五个任务不足以得出普遍节省率」。这类路由的收益高度依赖你的任务分布，先在自己的负载上量一遍，再决定要不要上。
五、置信度到底该怎么用
Jev 真正区别于普通分类器的地方是输出里那个置信度，它把你原本的单轴决策变成了双轴：既要看选了什么，也要看有多确定。官方文档里两个例子把用法讲得很清楚。
第一个是语音银行。意图识别的置信度低于 0.6，一律转人工；查余额这种低风险动作，0.6 就够了；但「批准转账」这种高风险动作，必须高于 0.85 才允许自动执行，否则要显式跟用户确认一次。同一套模型输出，不同的动作类型配不同的阈值。
第二个是客服工单路由。先分类 intent，再结合复杂度决定去向：一个意图直接交给确定性代码，完全不过 LLM；两个意图交给不同领域的专家模型，各自带不同上下文；投诉类还要额外看一次复杂度评分，太复杂或者置信度低就转人工。昂贵的资源只被真正需要它的请求触发。
三条不能忘的边界
把置信度用起来之前，有三条边界必须记住，它们都写在实现方的文档里。
校准不保证单条正确。 TypeSafe 自己的措辞是：校准是在一组预测上衡量的性质，它不保证某一条具体答案是对的。所以别把 0.95 读成「这条有 95% 概率正确」，它更像是一种可用于设定阈值的稳定刻度。
置信度衡量的是确定性，不是事实真值。 jev-mcp 的实现文档里专门写了这一句。模型非常确定地相信一个错误的事实，置信度一样会很高。
上下文不完整时不允许多 auto。 同样的文档里有一条硬约束：不完整的上下文永远不能得出 auto 这个动作，遇到这种情况要缩小输入重新提交，拿一个完整判断。换句话说，「信息不够」不能被执行成「风险不高」。
顺带说一句，判断结果里的 action 只有三个值：auto、review、escalate。三种状态的语义边界清楚，比让模型自由输出一段「建议谨慎处理」的文本要好接得多。
六、落地前值得先算清楚的几笔账
分类开销本身要计入。 路由和判断都是要花钱花时间的。上面提到的路由器就明确标注了「分类开销未计入」。如果你每个 turn 都多打一次判断请求，省的可能是大模型的 token，花掉的是小模型的钱加一点延迟，净收益要在自己的流量上量。
再挂一个 MCP server 是有代价的。 agent 的工具税是个老问题，5 到 15 个 MCP server、上百个工具全量塞进上下文，能吃掉几万 token。Jev 的 MCP 工具定义同样占位置。现在主流客户端都在往「延迟加载、按需检索工具 schema」的方向走，新加的 Jev server 最好也纳入同一套按需加载策略，而不是常驻。
算术和日期计算留给宿主代码。 实现文档写得很直白：算术和日期计算属于宿主代码，不要问分类模型。判断模型的价值在于模糊判断，不在于精确计算。
训练数据是纯合成的。 这是社区讨论里的共识，也决定了它的强项和盲区。合成数据能覆盖得很整齐，但真实业务分布的长尾要靠自己的评估集去补。官方文档提到的使用建议也印证了这一点：问题要问得原子化，如果一个判断需要多因素加权推理，就把它拆成几个独立问题，让代码用明确的系数去组合。这样优先级一变，改的是代码里的一个系数，而不是重写一段提示词。
闭源、托管、无自托管方案。 Jev 只提供托管 API，没有开放权重，也没有 VPC 选项。但发布两天内社区就出现了六个复现：Laya 用 ModernBERT-large 编码器加两层 transformer、SemIf 用 Qwen3.5 主干接一个小的三分类 NLI 头、Bespoke Nimble 是 Qwen3.5-9B 的 LoRA 微调、还有能在笔记本上跑的 Kev-0.5B。在作者的评估集上，Bespoke Nimble 把基础 Qwen 从 66% 提到 90%，Jev 是 93%。如果你有数据不能外发的约束，这是现实的起点，但要自己承担校准质量的验证工作。
这个品类还没有标准基准。 这是目前最该保持怀疑的地方：大量演示在比速度，而不是比质量，而分类质量恰恰是这个品类能不能用的唯一关键。选型时最好带着自己的标注集去比。
七、小结
Jev 带来的真正变化，不是多了一个模型可以选，而是给编码 Agent 补上了一层原本缺位的结构：把那些太小、不值得写规则、又太大、舍不得浪费一次前沿模型调用的小判断，变成了可以独立部署、独立计量、独立回退的模块。
对独立开发者来说，这件事的含义很直接。今天的 GitHub 榜单上，拿走最多 star 的已经不是「又一个 agent 框架」，而是 agent 的配套层：技能包、方法论、沙箱、可观测性。判断层是这条线上还很空的一个位置。当决策模型便宜到 70 毫秒、百万 token 几毛钱，给 Agent 加一个 if 这件事，第一次有了不需要动用前沿模型的选项。
接下来的看点有两个。一是这类模型会不会走向本地与私有部署，毕竟现在的复现已经能在笔记本上跑了。二是校准质量能不能被标准化度量出来，因为在这之前，所有关于「快 400 倍、便宜 400 倍」的数字，都还只是故事的一半。
参考来源
- TypeSafe AI 官方文档：Introduction 、System One 、Jev with coding agents 、Patterns 、Confidence-gated routing 、Intent routing
- LiteLLM 官方博客：Reduce agent context with TypeSafe Jev and LiteLLM
- LangChain 官方博客：Building a Harness with Jev
- 社区实现：burnigtm/jev-mcp 、Wang-auspicious/codex-jev-compaction 、jev-playwright-mcp 、Brainwires/jev-mcp 、pi-jev-model-router
- Latent.Space AINews：Here are 6 Clones of Jev in 2 days