我们一直把 LLM 当作解决所有 AI 问题的锤子，哪怕只是简单的决策。Jev 能在毫秒级处理这些决策，成本仅为前者的一小部分。让我们深入了解它的工作原理以及适用场景。
TypeSafe AI 于 2026 年 9 月 15 日发布了 Jev，对于一个既不能对话、也不能写代码、甚至无法生成一段有用文字模型来说，外界的反响异常强烈。
嗯，这种局限性正是其核心所在。
大多数软件不需要另一个聊天机器人。它们需要做出成千上万个小判断，例如：这张工单紧急吗？应该由哪个模型处理这个请求？这条 Shell 命令危险吗？检索到的这段文字是否回答了问题？
团队通常会将每个判断都发送给通用型 LLM。模型逐个 token 地生成答案，应用程序对其进行解析、验证，并在格式错误时重试。这行得通，但对于一个只有五种可能答案的决策来说，这样做既慢又昂贵。
Jev 是专门为这类决策构建的。TypeSafe 将其称为“系统一”（System One）模型：输入非结构化状态，输出带类型的回答和概率。
让我们来剖析这意味着什么，它适合用在哪里，以及在哪些地方营销宣传需要保持克制。
首先，看看 Jev 正在解决的问题
随着工具调用（Tool Calling）和结构化输出（Structured Outputs）的出现，LLM 与软件的集成变得容易多了。
工具调用让模型能够以可预测的格式请求函数。结构化输出让它能够返回符合 Schema 的 JSON。这两者都消除了大量脆弱的解析工作。
但底层模型仍然是生成式的。即使答案只是一个单词 "billing"，它也是按顺序生成 token 的。你需要为输入付费，等待生成过程，而且通常还要为输出支付更高的费用。
现在把这个过程放入 Agent 循环中。
1while not done:2 action = llm(context)3 result = run_tool(action)4 context += result
模型可能会被再次调用以选择工具、评估结果、检测风险、决定任务是否完成，以及选择下一个模型。单次 Agent 运行可能包含许多需要判断但不需要生成文本的调用。
Jev 的目标就是这些调用。
它的赌注很简单：当代码已经知道可能的答案时，语言生成是错误的接口。
Jev 到底是什么
最简短准确的描述是：它是一个语义决策引擎。
你向 Jev 发送两样东西：
- State（状态）：描述当前情况的文本或 JSON。
- Questions（问题）：你希望它针对该状态做出的决策。
每个问题都会预先声明其答案形状。Jev 支持三种原语：
- Choice（选择）：从你定义的列表中选择一个选项，并为每个选项返回概率。
- Score（评分）：将输入放在你定义的有序量表上，例如低、中、高。
- Noul（布尔值）：通过返回其为真的概率来回答是非题。
Noul 是 TypeSafe 对布尔风格原语的命名。这个不寻常的名字并不重要，重要的是输出结果（一个介于 0 和 1 之间、你的代码可以据此行动的数字）。
1{2 "model": "jev-latest",3 "state": "部署失败了两次，客户看到了 500 错误。",4 "questions": {5 "urgent": {6 "type": "noul",7 "instructions": "这需要立即关注吗？"8 },9 "owner": {10 "type": "choice",11 "instructions": "哪个团队应该处理这个问题？",12 "criteria": {13 "engineering": "产品故障和停机",14 "billing": "收费、发票和退款",15 "sales": "定价和新账户"16 }17 }18 }19}
响应中包含一个紧急程度概率和一个针对三个团队的概率分布。没有需要解读的段落，也没有模型可以凭空发明的第四个团队。
你的程序保持控制权：
1if urgent > 0.9 and owner == "engineering":2 page_on_call()3elif confidence < 0.6:4 send_to_human_review()5else:6 add_to_queue(owner)
这就是为什么人们不断称 Jev 为一个智能 Switch 语句。这个说法听起来有些轻视，但它确实捕捉到了设计的精髓。普通代码拥有分支逻辑。模型提供的是普通代码无法可靠计算的模糊判断。
与传统 LLM 的重要区别
传统的 LLM 和 Jev 都可以对支持工单进行分类。但它们得出答案的方式不同，在系统中的适用环节也不同。
TypeSafe 表示，Jev 会并行评估请求中的每一个问题。这改变了你设计工作流的方式。与其问一个问题、等待、再决定下一个问题是什么，不如在一个请求中就同一状态提出所有独立的问题，然后让代码使用它需要的答案。
该公司报告称，端到端延迟在 70 到 500 毫秒之间，每百万输入 token 的价格为 $0.042，输出免费。其头条宣称速度比同类 LLM 工作流快约 200 倍，成本低 400 倍。
这些巨大的倍数来自 TypeSafe 自己的工作流程评估，处于比较的优势端。请将其视为上限，而不是每个应用的承诺。其底层优势依然可信：Jev 避免了长推理轨迹和生成式输出，因为它专为有界决策而设计。
为什么概率很重要
带类型的回答只解决了一半的问题。
假设 Jev 将一张工单路由给 Billing（计费）部门。选定的标签告诉你谁赢了。概率分布则告诉你竞争有多激烈。
1{2 "choice": "billing",3 "probabilities": {4 "billing": 0.52,5 "technical": 0.46,6 "sales": 0.027 },8 "confidence": 0.189}
自动路由这张工单是鲁莽的。Billing 赢了，但险胜。低置信度的答案应触发不同的分支。
这为开发者提供了一个实用的模式：
- 高置信度：当后果较小时，自动执行。
- 中等置信度：请求确认或调用更强的模型。
- 低置信度：将案例转交给人工处理或收集更多信息。
阈值属于代码，在那里它们可以被审查和修改。仪表盘标签可能容忍弱预测。删除数据的命令则需要更高的标准。
TypeSafe 使用“校准决策强化学习”（Reinforcement Learning for Calibrated Decisions, RLCD）来训练 Jev。目标是让置信度反映多次预测中的准确性。如果模型给出一组答案的概率为 90%，那么大约 90% 的这些答案应该是正确的。
关于幻觉的说法需要精确界定
TypeSafe 声称 Jev 不会产生幻觉。这句话只有在狭义定义下才成立。
Jev 不能返回 Schema 之外的选项。如果你定义了 billing、technical 和 sales，响应就不能发明出 legal。它也不能在你的代码期望标签的地方产生格式错误的文本。
但它可能会自信地选择错误的有效选项。
类型安全防止了无效的形状。它并不保证正确的判断。这一区别很重要，因为符合 Schema 的错误仍然可能退错款、错误路由事故，或批准危险的命令。
更安全的说法是：“Jev 不能破坏声明的输出 Schema，但它仍然可能是错的。”
Jev 在 Agent 内部的定位
当 Jev 与 LLM 配合使用而不是取代 LLM 时，效果最好。
LLM 处理需要语言或更深层次推理的工作。它负责规划、写作、解释和使用工具。Jev 处理围绕这些工作的频繁决策。
以下三种放置位置特别具有吸引力。
模型路由
简单的查找不需要与架构评审相同的模型。Jev 可以对请求进行评分，并选择最有可能完成任务且成本最低的模型。
1route = jev.choice(2 state=user_request,3 options={4 "fast": "查找、提取和小型本地编辑",5 "powerful": "架构、歧义和高利害工作",6 },7)89model = fast_model if route == "fast" else powerful_model
路由器不回答请求。它决定哪个模型应该回答。
工具风险门控
在 Agent 运行 Shell 命令之前，Jev 可以将其分类为只读、可逆或破坏性。单独的问题可以检查它是否删除文件、更改 Git 历史、触及生产环境或离开仓库。
高置信度的只读操作可以继续。破坏性或不确定性的操作可以暂停以等待人工批准。LangChain 的 Jev 集成通过在执行前检查工具调用的中间件应用了这一模式。
验证和监督
Agent 可能声称任务已完成，而测试仍在失败。Jev 可以检查状态并回答有界问题：测试通过了吗？Agent 是否在重复相同的动作？输出是否符合策略？这个结果需要审查吗？
当存在硬性测试时，它不会取代硬性测试。它在规则依赖于含义的地方添加了语义检查。
Jev 今天能解决的问题
最佳用例共享三个特性。你可以命名可能的答案，细心的人类可以快速判断输入，并且决策发生的频率足以让延迟或成本变得重要。
支持与运营
- 分类意图、紧急程度、部门、垃圾邮件和客户挫败感。
- 通过几个小检查路由退款和政策例外。
- 在人类阅读之前，根据语义严重程度对日志和事故进行排名。
单个请求可以就同一张工单询问所有这些关于的问题。然后代码将这些答案组合成公司实际的路由策略。
搜索与检索
- 根据检索到的段落是否回答问题来重新排序。
- 检查引用是否支持主张。
- 在将上下文发送给昂贵的 LLM 之前过滤无关的块。
Embeddings 擅长查找语义相关的文本。Jev 可以做出更狭窄的决定：特定段落对于这个问题是否有用。
质量与安全
- 筛查提示词中的越狱或提示注入。
- 根据政策或评分标准检查生成的内容。
- 在执行前标记有风险的代码更改或工具调用。
这些检查应与确定性控制并列。语义分类器适用于模糊风险，而权限、沙箱和测试则强制执行软件可以精确验证的规则。
高容量分类
- 标记文档、研究论文、产品列表或客户消息。
- 将自由文本转换为传统机器学习模型的特征。
- 根据相同的评分标准对整个大型语料库中的每一项进行评分。
这就是每次调用低成本不仅仅是一个基准数字的地方。以前因太昂贵而无法在每一行运行的判断，现在可以移入正常的数据管道。
实时界面
- 从已知的页面元素中选择下一个浏览器动作。
- 在人编写内容时评分语气或清晰度。
- 从结构化的游戏或模拟器状态中选择动作。
Jev 目前仅支持文本，因此这些系统必须先将环境转换为文本或 JSON。它不是在看着屏幕，也不是从像素中进行游戏。
Jev 不适合的场景
一旦答案空间不再已知，Jev 的用处就会降低。
- 它不能撰写回复、总结文档、生成代码或解释其推理过程。
- 它在算术、计数、日期比较或精确字符串操作方面不可靠。将这些操作保留在代码中。
- 当决策需要多个隐藏的推理步骤时，它会遇到困难。将判断拆分为较小的问题或使用推理模型。
- 它不能直接提取未知值。先找到候选值，然后让 Jev 从中选择。
- 无关的上下文会降低准确性。只发送决策所需的状态。
- 封闭权重、早期访问、仅限文本输入以及有限的独立校准数据使得现在完全信任它为时过早。
还有一条更简单的规则：如果确定性代码已经正确解决了问题，那就保留代码。普通的 if 语句比任何模型都快、便宜且易于测试。
如何使用 Jev 而不引入新的故障模式
如果廉价模型的错误导致重试、人工审查或生产事故，它仍然可能很昂贵。衡量整个工作流，而不仅仅是 token 价格。
合理的推出流程如下：
- 选择一个有界、低风险且有明确可能答案的决策。
- 在调用模型之前编写评分标准。定义每个选项中包含的内容。
- 收集带有预期答案的代表性示例，包括模糊和对抗性案例。
- 在当前工作流旁边以影子模式运行 Jev，但不要让它改变行为。
- 绘制准确率与置信度的关系图，并根据你的数据设置阈值。
- 首先自动化最安全的分支，并为不确定案例保留人工或更强的模型。
- 固定或记录模型版本、问题、标准和阈值，以便变更可以在相同的评估集上进行回放。
问题是程序的一部分。像对待代码一样对待它们：进行版本控制、审查，并在模型或评分标准变化时进行测试。
真正的转变
Jev 之所以有趣，不是因为它在写作方面击败了 LLM。它拒绝写作。
它的贡献在于一种塑造得像软件的模型接口：固定的答案类型、显式的不确定性、并行问题和代码控制的分支。
这使得它成为生成式模型的有用伴侣。LLM 产生计划、解释或代码。Jev 路由请求、门控风险动作、检查结果，并决定何时不确定性高到需要升级处理。
即使最终有另一个模型取代 Jev，这个更广泛的理念也很重要。多年来，我们一直要求生成式模型通过文本执行各种智能。许多生产系统不需要更多的文字。它们需要一个小的、快速的判断，普通软件可以安全地使用它。
这就是 Jev 试图建立的类别。
从哪里开始
不要一开始就围绕 Jev 重建你的 Agent。找到一个目前需要缓慢 LLM 调用或经常失效的正则表达式的决策。
给 Jev 最小状态，定义可能的答案，并在当前结果旁边记录其概率。让它证明值得拥有一个分支，然后再将整个工作流交给它。
最有用的心智模型仍然是最简单的一个 → Jev 在普通 if 语句理解值但不理解其含义的地方添加判断。
来源与延伸阅读
- TypeSafe AI: Introducing System One Models and Jev
- LangChain: Building a Harness with Jev
- Flavio Copes: A deep dive into Jev
希望你喜欢这篇文章。
下期再见。
干杯！:)
