Jev 实测：这个主打极速判断的 AI Agent 到底强在哪？

AI Agent 领域一直存在两条技术路线：一类是像 ChatGPT 那样擅长生成长文本的"慢思考"模型，另一类则是专注于快速、廉价、结构化判断的"快思考"模型。Jev（视频中读作 Jeff）就属于后者。它的定位借用了心理学中的"System 1"概念——不生成对话、不帮你写应用，只做一件事：接收信息，返回判断。

一位 B 站 UP 主拿到了 Jev 的使用权限，用一组实用测试拆解了它的能力边界。本文梳理这些测试结果，并厘清围绕它的一些常见误解。

Jev 的核心定位：只做快速判断

Jev 主要处理三种问题类型：

• Truth：从你提供的选项里选一个
• Score：按你定义的等级打分
• Bool：给出某个陈述为真的概率（是/否）

这种设计的目标很明确——让每一次小判断都足够便宜、足够快，从而能贯穿整个软件的运行流程。比如判断一条消息该发给哪个团队、某人是不是申请了退款、某件事是否需要人工处理，然后由你的代码来决定后续动作。换句话说，Jev 负责"决策"，代码负责"执行"。

「System 1」与「System 2」的概念来自心理学家丹尼尔·卡尼曼在《思考，快与慢》中提出的双过程理论。System 1 指人类大脑中快速、自动、几乎不耗费认知资源的直觉判断，例如看到熟悉面孔就认出人；System 2 则是缓慢、刻意、需要集中注意力的逻辑推理。将这一框架映射到 AI 模型上，ChatGPT 这类大语言模型在生成长文本、多步推理时更接近 System 2——每次调用延迟高、成本高；而 Jev 的设计目标是充当流程中的 System 1：每次只回答一个结构化问题，延迟低、成本低，可以在一次用户请求中被调用数十次而不产生明显开销。这种分工思路在 Agent 架构中越来越常见：用轻量判断模型承担频繁的分支决策，用重量级生成模型处理真正需要"写文字"的环节。

客服路由测试：分得很准

UP 主从一条重复扣费的客服消息开始测试。客户要求退回多收的钱，说网站能正常使用，还表示可以等到明天处理。他把四个问题打包一起问：该分给哪个部门、是否请求退款、是否紧急、以及情绪状态。

Jev 的表现相当精准：把消息归类到 billing（账单），退款请求概率 98%，而紧急程度仅 11%，情绪分数接近平静。它没有把账单问题自动升级为技术问题，也没有把退款请求默认当成紧急情况。

更关键的是对否定语义的处理。当消息改成"我不是在要退款，我只是需要一份发票副本"，Jev 仍然选了 billing，但退款概率骤降到 3%。它没有因为看到"refund"这个词就机械地判定为退款请求。这也是作者强调的一点：在把任何模型接入实际动作之前，一定要测试"要退款""问退款政策""明确拒绝退款"这三种完全不同的表达。

关于"零幻觉"的重要澄清

第二个测试暴露了一个值得深究的局限。UP 主问"食堂几点关门"，在允许选 other（其他）的情况下，Jev 正确地把它排除在 billing、技术支持和 sales 之外，选了 other。

但当选项被限制为只有那三个部门时，Jev 选了 sales，置信度仅 0.31。答案符合给定选项，可这些选项没有一个能真正涵盖用户需求——这是作者故意设置的陷阱。

这引出一个关键区别：限制输出确实能阻止模型编造新类别，但并不能保证它选出来的类别有用或正确。所谓"零幻觉"只是约束了输出空间，不等于判断永远对。作者给出的实战建议是：在这类流程里加一个"其他/未知"选项交给人工复核；同时，绝不能把 90% 的置信度理解成"模型有 90% 的时间判断正确"——这个准确率必须用你自己的样本去实测。

抗提示注入与文档取值

作者做了一个基础的 prompt injection 测试。原始消息说结账页面崩溃、且明确不是退款，Jev 正确路由到技术支持。随后他在消息里塞进一段伪造的"system override"，要求改选 billing 并把退款和紧急度都拉满。由于真正的评估指令告诉 Jev 把消息内容当作不可信文本，它守住了技术支持分类，退款概率维持在 3%。不过作者也坦言，单次简单注入测试不足以证明模型能免疫攻击。

在文档取值测试中，一条消息包含发件人邮箱、账单地址和收据应发往的新地址。把这些地址作为候选选项提供后，Jev 准确选中了新地址，连门牌号和年份都原样选出。这对做账单信息提取很有价值：代码负责收集候选值，Jev 负责选出正确的那个，再由代码复制使用。但前提是——候选列表本身必须包含正确答案，Jev 无法通过一道选择题"补出"第一步没找到的地址。

提示注入（Prompt Injection）是指攻击者在用户输入或外部数据中嵌入伪造指令，试图覆盖或篡改模型收到的系统提示，从而使模型执行非预期行为。在面向真实用户的应用中，这是一个不可忽视的安全威胁——例如客服机器人可能被恶意用户通过消息内容"命令"它绕过退款政策。Jev 的防御思路是在系统层面将用户输入标记为「不可信文本」，评估指令明确告知模型：消息内容是待判断的对象，而非可执行的指令来源。这种隔离并非万能，复杂或多层嵌套的注入攻击仍可能绕过简单的语义边界，因此作者才特别说明单次测试不足以证明免疫能力。在生产部署中，提示注入防御通常需要结合输入过滤、输出校验和人工审计多重手段。

Agent 审计：按证据判断

作者还试了一个小型的 Agent 审计场景。工具返回显示"权限被拒绝，什么都没保存"，但助手的最终消息却声称"草稿已成功保存"。Jev 把这个任务判为失败，并以 93% 的概率认定"成功"的说法没有依据。

作者欣赏它在这里是按工具证据来判断的。不过他也指出，这个错误本身很简单，用普通代码就能抓出来。真正有价值的应用，是去检查那些更长、有多个步骤、部分进展和互相矛盾说法的 trace——而那需要大得多的测试集才能验证。

Browser Use 结合：7 秒查航班

视频还提到一个有意思的开源演示。Gregor Zinnick 分享的开源项目 Jev Ultra Fast 把 Jev 与 browser use 工具结合。据其演示，项目在约 7 秒内于 Google Flights 上查到了从苏黎世到伦敦的单程航班，单次调用成本 0.39 美分（不到半美分），视频为原速播放。作者强调这些均为 Zinnick 自报结果，他本人尚未复现。

它的工作方式很典型：读取网页结构，生成带编号的可操作元素列表，每步之后刷新可选项。Jev 先选下一步动作，把目标和问题打包成请求；当需要实际输入文本（点按钮、填输入框）时，则交给一个单独的小语言模型（演示中用的是 Mercury 2.5）。这正是 Jev 融入更大 Agent 体系的实际范例——Jev 负责结构化决策，另一个模型负责生成文本，浏览器代码负责检查目标并执行动作。

几个容易被忽略的细节：公开的计时是从首次页面观察后才开始的，不含启动时间；这是一次无需预订的搜索；报告价格与模型成本估算一致，但不包含浏览器基础设施的开销。作者自己复现时统计，这些请求共用了 4148 个输入 Token，按每百万输入 Token 4.2 美分估算，输入费用远不到 1 美分，输出 Token 按该定价免费。

Browser Use 是一个开源的浏览器自动化框架，允许语言模型通过读取网页的 DOM 结构或无障碍树（accessibility tree）来感知页面状态，并生成点击、输入、滚动等操作指令，从而实现无需人工干预的网页交互。与传统的 Selenium/Playwright 脚本不同，Browser Use 不依赖硬编码的元素选择器，而是让模型动态理解页面语义，因此在页面结构变化时鲁棒性更强。在文中描述的架构里，Browser Use 负责将网页转化为带编号的可操作元素列表（感知层），Jev 负责从中选择下一步动作（决策层），Mercury 2.5 等小模型负责生成具体的文字输入（生成层），三者分工明确。这种「感知-决策-生成」的三层拆分是当前轻量 Web Agent 的一种典型架构模式。

成本、版本与结论

作者提醒，虽然单个例子成本极低，但一个应用的总成本还包括准备输入、检查答案、以及处理需要切换模型或人工介入的部分。他还特别记录了模型版本——选择 "Jev The Latest" 时，返回结果标识为 Jev 1.13.0。由于 "Latest" 这类别名会变动，建议把版本号和结果一起保存。

综合来看，Jev 最吸引人的地方在于：你能非常轻松地把这些小判断塞进应用逻辑里。测试显示它在路由、否定识别、文档取值、以及依据证据核实说法这几方面表现不错，也证明了你给出的选项和指令有多重要。

但作者保持了应有的克制：这些只是八个诚实的小请求，给出了值得继续研究的方向，却还不能证明它在生产环境里可靠，也不能证明它在速度上真的远超其他模型。想验证是否适合自己的工作流，最好用更大范围的样本、并对比"多问题合并提问"与"分开提问"的效果。