Jev vs Agent：在软件中集成决策原语

除非你过去一周一直与世隔绝，否则你一定见过 Jev 来自 @typesafeai。

https://x.com/CompleteSkeptic/status/2099925682726002904

他们将自己的模型描述为：

一类专为软件直接使用的快速、结构化决策而构建的 AI 模型。System One 模型会评估一个
状态并返回带类型的回答和概率。

根据 TypeSafe 的基准测试，Jev 比 LLM 快 20-200 倍，成本低 40-400 倍。

但这为什么重要呢？我们以前也训练过分类器（手机自动更正、Gmail 过滤等），但据 Twitter 上的说法，Jev 有些与众不同。

在本文中，我将教你什么是 Jev，它为何存在，以及如何将其引入你的生产系统。

那么，Jev 到底是什么？

“把 Jev 想象成一个前沿智能函数调用：输入非结构化状态，输出带类型的概率性决策。” - TypeSafe

Jev 暴露了 3 个原语：Choice、Score 和 Noul。

Choice 是一种问题类型，从定义好的集合中选择一个选项（最多 255 个），其答案包括选中的选项、每个选项的概率以及置信度。
Score 针对有序的描述性级别对内容进行评分，其答案包括分数、每个级别的概率以及置信度。
Noul 要求模型评估一个是/否问题，并返回答案为“是”的概率。

以下是一个客户支持用例的示例输入和输出：

json

1// Input
2{
3  "model": "jev-latest",
4  "state": "Hi, I was charged twice for my monthly subscription. Could you refund the extra charge? My account is working fine.",
5  "questions": {
6    "department": {
7      "type": "choice",
8      "instructions": "Which team should handle this message?",
9      "criteria": {
10        "billing": "Charges, payments, subscriptions, and refunds",
11        "technical": "Bugs, errors, and broken features",
12        "account": "Login, passwords, and account access"
13      }
14    },
15    "requests_refund": {
16      "type": "noul",
17      "instructions": "Is the customer explicitly requesting a refund?"
18    },
19    "frustration": {
20      "type": "score",
21      "instructions": "How frustrated does the customer sound?",
22      "criteria": [
23        "Calm: politely describes the issue without expressing frustration",
24        "Frustrated: expresses annoyance or dissatisfaction",
25        "Very frustrated: expresses strong anger or threatens to leave"
26      ]
27    }
28  }
29}
30// Output
31{
32  "model": "jev-1.13.0",
33  "answers": {
34    "department": {
35      "type": "choice",
36      "choice": "billing",
37      "confidence": 1,
38      "probabilities": {
39        "technical": 0,
40        "account": 0,
41        "billing": 1
42      }
43    },
44    "requests_refund": {
45      "type": "noul",
46      "noul": 0.99
47    },
48    "frustration": {
49      "type": "score",
50      "score": 0,
51      "legend": {
52        "0": "Calm: politely describes the issue without expressing frustration",
53        "1": "Frustrated: expresses annoyance or dissatisfaction",
54        "2": "Very frustrated: expresses strong anger or threatens to leave"
55      },
56      "confidence": 1,
57      "probabilities": {
58        "0": 1,
59        "1": 0,
60        "2": 0
61      }
62    }
63  },
64  "usage": {
65    "input_tokens": 442,
66    "output_tokens": 72
67  },
68  "request_id": "playground_12bbfa4198be5ca4de9818a45c0906a2055",
69  "evaluation_time_ms": 163.01120699790772
70}

我建议你去体验一下他们的控制台入门指南，以便更好地理解状态和问题是如何协同工作以生成输出的。

这不就是一个分类器吗？

既是也不是。它更像是一个 LLM 和一个分类器的结合体。

传统分类器擅长处理高吞吐量、固定分类体系的任务。想想 LeNet-5 能够识别图像代表哪个数字。然而，分类器通常是高度专业化且特定于领域的。LLM 擅长生成序列。它们灵活，非常适合运行时定义的开放式任务，但也更慢（相比分类器）、更昂贵且预测性较差。

Jev 是一个“用于分类的基础模型”，结合了 LLM 的自然语言灵活性和分类器的受约束、概率性输出。你可以完成各种各样的任务，而无需训练新模型，同时还能保持跨不同领域（代码、文本、日志、UI 状态、事件等）的专业能力。Jev 还可以并行生成输出，这使其比仅限于顺序生成的 LLM 快得多。

TL;DR：它是一个真正聪明且可泛化的分类器。

Jev 为何存在？

TypeSafe 的首席执行官兼联合创始人 Diogo Almeida 曾在 OpenAI 工作，帮助创建了 RLHF（基于人类反馈的强化学习）和 ChatGPT 产品。RLHF 让我们能够训练 LLM 更好地遵循指令和提示，这与它们的自回归特性相匹配。

随后他离开 OpenAI 创立了 TypeSafe，旨在训练另一类模型以赋能 AI 驱动的软件，而不是 Agent。Jev 使用 RLCD（基于校准决策的强化学习）进行训练，用研究术语来说，就是训练模型非常擅长输出置信度和概率，而不是答案。

TypeSafe 认为软件应该是智能的。Agent 不会自然地融入软件的历史工作方式，而且人在回路（human-in-the-loop）使得既智能又自主的软件难以实现。Jev 是迈向将智能作为软件系统中可组合、可靠原语的一步。

这并不是一个全新的想法，研究人员在 2017 年就发现强大的预测准确性并不意味着可靠的置信度估计（因此 LLM 在这里并不是完美的解决方案）。

为什么选择 RLCD 而不是 RLHF？

RLHF 的问题在于，人类想要的并不总是客观正确的。仅仅因为我们在某种格式下偏好某个答案，并不会使模型变得更智能，只会让它更好用。

这还会引入模式崩溃（mode collapse），RLHF 使 LLM 收敛到单一答案，尽管有时多个轨迹可能都是“正确”的。

“对于个人来说有吸引力的输出，未必足够可靠以实现无人值守的自动化。人类偏好和机器可信度是不同的优化目标。”

通过 Jev 文档展示的模式崩溃

Jev 并非为了构建 Agent 而生

与你时间线上看到的相反，Jev 作为一个独立的 Agent 表现并不好。我们尝试过构建它的版本，无论是仅使用 Jev 还是 LLM + Jev。

https://x.com/kylejeong/status/2100622054945095934

老实说，Jev Agent 确实能做出很酷的演示。有很多演示利用 Jev 以闪电般的速度执行 Agent 任务。但即使是最棒的演示，也尚未准备好部署到生产环境。

像 Jev 这样的模型是为 AI 驱动的软件设计的，它可以帮助你在确定性代码中做出组合决策。如果没有推理或生成能力，将其用作独立 Agent 纯属无知。

AI 驱动的软件

与其让 Jev 成为独立的计算机使用 Agent，不如将其用于客户支持路由、发票处理、安全警报和分诊，或者作为 Agent 监控器。

数据说话

他们的第一个模型 Jev 1.13.0 的输入成本为 $42/btok（即 $0.042/mtok），输出 token 免费。作为参考，Fable 5.1 的输入成本为 $10/mtok，即 $10,000 / Btok。典型的企业工作负载输入输出 token 比例为 3:1 或 4:1，因此 Fable 的成本约为 ~$20,000/Btok（假设输出为 $50/mtok）。

上下文窗口为每个请求 64k tokens，其中状态 + 最长的问题必须适应 32k tokens。

然而，在他们的内部基准测试中，他们在准确率/成本和准确率/速度方面超越了 OpenAI、Anthropic 和 Deepseek（通过 Fireworks 进行推理）的所有模型。

准确率/成本

废话少说，如何使用它？

你现在应该对 Jev 有了足够的了解，无论目前正在做什么，都能想到几个用例。（如果没有，这里有一份 TypeSafe 推荐的用例列表）。

与其限制你对如何使用它的创造力，我将向你展示我们如何将 Jev 改造进我们的框架 Stagehand。

在过去两年里，Stagehand 已发展成为一个供 AI 和 Agent 控制远程浏览器的框架。在 Agent 变得足够强大之前，我们创建了 AI 原语 Act（执行动作）、Extract（提取结构化数据）和 Observe（发现页面上的潜在动作），以帮助开发者编写自愈脚本来自动化 Web 操作。

Stagehand A/E/O 让你可以使用自然语言构建自动化流程，而不是使用 Playwright（或其他遗留框架）并手动解析 DOM 来提供动作中的选择器。

typescript

1// Playwright
2await page.click('button[type="submit"]');
3
4// Stagehand
5stagehand.act("click the submit button")

这在首次编写脚本时很有帮助（开发速度更快），但对于脚本维护尤其有用。如果网站发生变化且 DOM 选择器更新，Playwright 脚本必须重写以匹配新页面。Stagehand 在运行时选择选择器和动作，具有“自愈”能力。

你可以大概猜到我们要说什么了。Jev 非常适合这些原语。我们最初使用 LLM（给定页面外观和目标上下文）来决定做什么。使用 Jev，我们可以使用 Choice 来决定与哪些选择器交互。

让我们具体谈谈 Act 的流程。通常，我们会使用混合无障碍树（a11y-tree）向 LLM 提供页面的简洁表示。使用 Jev，我们首先将无障碍树中的节点标记为可交互（即使是富文本编辑器）或不可交互。

当 stagehand.act 被调用时：

Jev 将指令分类为一个动作（如 click、fill 或 scroll）
Stagehand 解析参数并为该动作构建候选列表（包括附近的页面上下文）
Jev 回答“哪个候选最佳”和“是否有候选匹配”，接受阈值为 0.7
如果候选动作被接受，则 Stagehand 处理执行
如果动作未被接受，则 Stagehand 回退到 LLM

Act 流程

在早期测试中，Act 的中位延迟从 1.97 秒降至 0.46 秒，大约快了 4.3 倍（或节省了 77% 的时间）。查看完整的 PR 堆栈。

在计算机使用场景中，Jev 只是拼图的一部分，而非独立解决方案。我们现在能够构建更多 Agent 可以使用的确定性软件工具。

何时使用 Jev

在现实世界中普及 AI

Jev 能构建生产级的计算机使用 Agent 吗？不能。它是拼图中有用的一块吗？我认为是的。

感觉有很多在 Jev 出现之前说不通的想法现在变得合理了。我看到人们构建了即时搜索、智能复制粘贴，以及其他简单但极其有用的工具。

AI 不应局限于聊天界面的某种形式，无论是同步还是异步。借助像 Jev 这样的模型，我们可以构建无需聊天输入框就能整合预测模型的软件。尽管分类器已经存在很久，但它们从未显得如此有用。也许我们需要做的只是激发灵感。

-> Kyle