Jev 让「AI 判断」变成了一种可嵌入的低成本能力。
最引人关注的是速度与成本，在 TypeSafe 官方的四个工作流评估中，Jev 实现了约 194 倍加速、约445倍成本优势。
由此可见，Jev让软件以更低的成本、更短的等待时间，在更多环节使用 AI 判断。
本文从 5 个维度一起拆解：
- Jev 是什么？
- 速度和价格会带来哪些工程变化？
- Jev 的训练目标有什么不同？
- 如何使用 Jev 构建 Harness？
- 对产品设计与落地有哪些启发？
一、Jev 是什么？
Jev 是 TypeSafe AI 发布的决策模型，定位是让软件快速做判断。
官方称 Jev 为 System One Model，名字借鉴了《思考，快与慢》中快速、直觉式的“系统一”。
你可以把 Jev 理解成一个能理解自然语言的「智能判断函数」。
它不生成自由文本，而是接收当前状态（State）和范围明确的问题（Questions），返回程序可以使用的结构化判断与概率。
- State：模型需要看到的上下文，可以是文本或结构化数据。
- Questions：需要判断的问题，以及选项、标准或条件。
举个例子：
收到一条客户消息：“订单三天没到，我想退款”，jev可以在一次调用中同时回答以下三类问题：
需要判断的问题与候选答案可以在请求时定义，再由程序组合成处理流程返回结果。
或许有人会说，这不就是分类器吗？
从功能上看，Jev 确实承担分类和评分任务。
更进一步，Jev 希望提供一个可复用的判断接口：开发者可以更换问题、选项和描述，不必为每套标签分别训练模型。
二、速度与价格：让判断进入高频流程
TypeSafe 官方内部评估 Jev 实现了约 194 倍的速度提升和约 445 倍的成本优势。
LangChain 也公开实测对比了不同评估模型：
在这组实验中，Jev 相比 Luna 约快 5.7 倍，费用低约 10%；相比 Sonnet，平均调用费用约低 80 倍。
具体算账，Jev 1.13 的官方价格是每百万输入 token 0.042 美元，输出 token 免费。
假设一次请求的全部输入为 1,000 token，单次模型费用约为 0.000042 美元，100 万次请求仅需 42 美元。
那么，速度和价格会怎样影响工程设计？
主要有三点。
1.评估频率：让更多流程获得反馈
当AI判断费用降低，AI评估判断就可以覆盖更多请求、检查更多维度，更早发现质量变化。
比如客服系统可以持续检查分流是否合适，内容系统可以检查事实依据是否充分。
不过AI评估的前提是这些评估本身有效，否则低成本也会放大错误反馈，因此覆盖率需要与判断质量一起衡量。
2.评估粒度：把复杂判断变得具体
一次调用昂贵时，开发者容易把多个要求塞进一道题。
例如：“判断这封邮件该怎么处理。”
这道题同时包含归属、紧急程度、历史联系、业务规则和行动选择。出错时，很难定位问题。
当判断足够便宜，就可以拆成几个独立条件，再由代码组合。
Jev 也支持在同一份状态上并行评估多道问题，减少重复发送背景的开销。需要依赖前一步答案的问题，仍然要通过流程编排连接。
3.响应性能：缩短流程中的等待
一个 Agent 可能需要连续完成很多步骤。每道判断都等待几秒，累积起来就会影响体验。
更低的判断延迟，可以让分流、筛选和检查更自然地进入在线流程。
但局部调用加速，不会自动带来整项任务同比加速。搜索、工具执行、网络请求和最终生成，仍然可能占据主要时间。
最终需要测量的，是整个任务完成得是否更快、总费用是否更低，以及返工是否更少。
三、训练目标：让概率能够用于决策
Jev 的 CEO Diogo Almeida 曾参与 InstructGPT 研究。
他关注的问题是：当模型主要服务于程序时，应该优化什么？
人阅读 AI 回答，会在意是否清楚、是否有帮助；程序处理模型结果，则需要明确的类型、可执行的条件，以及能够用于制定策略的不确定性信息。
TypeSafe 将自己的训练路线称为 RLCD（ Reinforcement Learning for Calibrated Decisions），面向校准决策的强化学习。
可以从目标上理解几种不同方向：
- RLHF：利用人类反馈优化偏好与有用性。
- RLVR：利用可验证的奖励优化任务表现。
- RLCD：强调判断结果与概率的校准。
这里讨论的是训练目标的侧重，实际训练方法可以组合使用。现有公开资料也还不足以完整还原 RLCD 的技术细节。
其中，“校准”尤其值得理解。
对于一个是或否的问题，如果模型给出 0.9，那么在大量预测值接近 0.9 的案例中，命题为真的比例应当接近 90%。
这是一种统计关系，概率进入程序之后，还需要被转换为具体策略，帮助系统决定下一步。
例如，同样是 0.8，“文档可能相关”可以触发保留；“操作可能安全”则要结合操作后果，决定是否需要进一步检查。
Diogo 在《The Bitterest Lesson》中强调，选择合适的任务，比单纯追求算法或扩展曲线更基础。
一个模型可以把指标优化得很好，却没有解决产品需要解决的问题。
我觉得这也是 Jev 背后更值得讨论的部分：围绕业务实际需要的判断，重新选择接口、训练目标和评估方式。
四、技术架构：AI判断的运行流程设计
技术架构设计可以参考 LangChain 的《Building a Harness with Jev》，展示了 Jev 在 Agent 系统中的位置。
文章介绍了两个经典例子：
- 模型路由：根据用户请求，在候选模型中选择能力足够、成本较低的模型。
- 工具调用检查：在指定工具执行前判断风险，必要时阻止调用。
从这些实践反推技术架构，可以把系统分成五层。
1. 状态与证据层
负责准备判断所需的信息，比如客服工单包括客户邮件、相关交易、历史联系和业务规则。
输入需要与问题对应。判断是否重复联系，需要历史记录；判断能否退款，需要交易和政策。
缺少证据时，模型再快也无法补齐事实。
2. 规划与生成层
负责复杂推理、任务规划、代码或内容生成。
通用大模型仍然承担这些开放任务，Jev 则适合参与其中范围明确的局部判断。
两类能力可以根据任务需要组合使用。
3. 判断与路由层
负责归类、筛选、评分，以及选择下一条处理路径。
比如工单归属、请求复杂度、文档相关性和结果是否需要继续检查。
这些判断有了独立接口，就可以分别评估、调整和替换。
4. 策略与执行层
负责将判断转化为动作。
这一层包含阈值、业务规则、权限限制、工具调用和失败处理。
比如系统判断客户可能需要退款，仍应检查金额、交易状态和授权范围，再决定是否执行或转交审核。
5. 验证与反馈层
负责检查动作是否完成，以及整个流程是否达成目标。
工单是否进入正确队列？工具调用是否成功？回复是否有证据支持？
反馈还应进入后续评估，帮助调整问题定义、阈值和流程。
Jev在Agent系统中的流程架构图如下：
五、项目接入：哪些判断值得自动化？
对于准备接入 Jev 的团队，可以结合业务从如下4点逐步切入：
- 从高频、范围明确的判断开始
工单分流、内容筛选、模型路由和结果评估，都可以成为切入口。
首先需要明确：输入是什么，允许哪些答案，如何评价结果，以及错一次会造成什么影响。
是否切换可以比较规则、专用分类器或 reranker 等方案，综合对比效果、成本和维护负担。
- 为判断准备正确的状态
输入设计决定模型能依据什么作答。
建议区分用户陈述、已验证事实和系统推测，并只提供与当前问题相关的信息。
比如客户说“重复扣款”，是一条需要检查的陈述；交易系统确认两笔扣款，才是可用于执行的事实。
- 用业务数据确定阈值
模型相同，策略调整也会明显影响最终效果。
需要结合具体业务具体损失设置阈值，比如客服系统，漏掉紧急工单和多转交几条普通工单，代价不同；对于检索系统，误删关键证据和多保留无关内容，代价也不同。
- 衡量完整流程的收益
Jev的速度和成本足够吸引人，但产品需要验证系统整体效果。
值得优先关注的指标包括：
- 自动处理覆盖率：多少任务可以直接推进？
- 任务达成率：最终是否完成约定目标？
- 返工与审核负担：是否减少了人的工作？
- 总延迟与总费用：是否包含重试、升级和复核？
- 版本稳定性：模型更新后，阈值与流程是否仍然有效？
六、总结
Jev 虽然尚且处于早期，但它提供了一个清晰的工程方向：将语义判断封装成可以定义、测量、组合和替换的接口。
速度和价格，让这种能力能够出现在更多环节；概率与结构化输出，让代码更容易处理判断结果；规则、权限和反馈，则帮助系统承担实际工作。
“低成本判断”让 AI 能够更多地融入软件内部，参与日常流程。
Agent 系统范式逐渐成型：模型提供语义判断，代码控制流程，业务数据校准阈值，人制定标准、处理例外。
