Jev 集成到智能体：速度、成本与最佳实践

01 核心论断

先给结论。以下九条中，第 4、8 条是对主流宣传最直接的校正，也是本报告最有决策价值的部分。

02 范式判定：Jev 是什么，不是什么

名字取自卡尼曼《思考，快与慢》的"系统一"，以及杰文斯悖论——智能成本每降一个数量级，就会解锁数量级更多的场景。

2.1 一句话定义

Jev 接收一段非结构化 state（字符串 / JSON 对象 / 文本数组）和一组类型化问题，在一次请求中并行评估全部问题，返回类型安全的答案 + 概率分布 + 置信度。官方把它称作"前沿智能的函数调用"：非结构化状态进，带概率的类型化决策出。

2.2 三种原语

原语设计上刻意保持"一个知识丰富的人几秒钟内能做的直觉判断"。需要多因素权衡的问题，官方明确要求拆成多个原子问题、再用代码加权组合。

2.3 它不是什么

2.4 关键规格（生产必读）

来源：docs.typesafe.ai/models（2026-09-17 复核）、CSDN 技术整理（2026-09-20）、llm24 聚合（2026-09-18）。

03 机制：为什么快，为什么便宜

三条机制，每条都能推出一个具体的工程动作。理解机制而不是背倍数，才能判断自己的场景吃不吃得到这份收益。

3.1 机制一：跳过自回归，一次前向并行出全部答案

传统 LLM 即便只需要输出一个 "A"，也要为解释答案逐 token 生成；Jev 直接对隐状态打分，单 token logits 完成决策，并用 KV-Cache 广播把多个候选 / 多个问题的评估并行化为一次批处理前向。复杂度从 O(tokens × layers) 的解码循环降到 O(1) 的 logits 投影。

3.2 机制二：问题之间彼此独立，不产生上下文腐化

同一次请求中的所有问题针对同一个 state 并行、独立评估：增删问题不影响其他问题的结果，不存在 context-rot。这与"把所有条件写进一个大 prompt 让模型在思维链里权衡"形成鲜明对比——后者的问题会互相污染。

3.3 机制三：RLCD 把概率训练成"认知诚实"的信号

第三条后训练路线。RLHF 优化"人类偏好的文本"（会奖励谄媚与听起来自信的幻觉），RLVR 优化"可验证的正确性"，RLCD 优化决策 + 校准概率：被赋予 0.8 概率的结果，应在约 80% 的情况下发生。

为什么这是自动化的入场券：一个 95% 准确率但不说自己何时落在那 5% 里的模型，无法被自动化。LLM 即使被要求输出置信度，也往往过度自信且不一致。

3.4 RLCD 的另一面：为什么"校准"比"准确"更值钱

官方评测（Workflow Evals）的方法值得单独说：假设存在一个用代码表达的正确计算图，把任务分解为程序化规则 + 若干独立原子问题，由 GPT-6 Astra 与 Claude Fable 5.1（均开最高思考档）对每题作答取平均作为参照标签。

结论有两条：① 每个模型用工作流方式都比用大 prompt 更准确、更便宜、更快——"结构总是更好"；② Jev 位于帕累托前沿，在相近智能水平下速度 / 成本领先约两个数量级。

官方自己也标注了偏差（"Nuance"小节，值得称道）：193.6× / 444.6× 属于真实世界收益的偏高端；工作流由其模型能力团队编写；参照答案取两家平均可能低估 Jev 与 DeepSeek；速度 / 成本声明无法证明没有补贴。

04 四种集成模式与决策树

官方给出 4 个 pattern，社区实践把它们落到了四类场景。这张表把官方意图与社区实测并排列出——右侧"实证状态"列是本节的价值所在。

05 模式一：动态动作空间（工具 / 元素选择）

这是目前证据最扎实、也最能代表"Jev 该被怎么用"的一类。两个项目几乎同时独立做出同样的设计，而且都完整公开了原始测量文件。

5.1 机制：把"可选动作"变成编号候选集

传统 Agent 让模型生成一个动作（选择器、坐标、JSON）。Jev 路线反过来——先由 Harness 扫描当前状态，把真实存在且可交互的候选整理成编号表，再让模型从编号里选。

[1] button    Change ticket type · Round trip
[2] combobox  Where from?        · San Francisco
[3] combobox  Where to?          · empty
[4] textbox   Departure          · empty
...

关键在 jev-ultrafast 的"投机目标头"设计：一次请求同时问 operation（CLICK / TYPE_TEXT / SELECT / SCROLL / WAIT / DONE / BLOCKED）和三个投机性的 target 头（click_target / type_text_target / select_target）。如果操作是 CLICK，就只有 click_target 能执行——两个决策，一次网络往返。每个 target 头只包含与之兼容的元素，从机制上杜绝了"点错类型的元素"。

5.2 实证 A：browser-use/jev-ultrafast（MIT，2026-09-16）

由 browser-use 创始人 Gregor Zunic 亲自接线。任务：在 Google Flights 上搜苏黎世 → 伦敦单程机票，含真实文本生成与加载等待。

更值得看的是对照实验：六次交替运行、相同模型与设置，两版均 3/3 通过。中位任务时间 9.450s → 7.092s（−25%），中位浏览器协议调用 1,092 → 101。

来源：仓库 docs/flights-measurement.json、docs/full-speed-measurement.json、docs/performance.md（2026-09-17）。同政策还跑出 Wikipedia 任务 2.798s、本地酒店搜索筛选 1.896s。

5.3 实证 B：APUS-AI-Lab/fast-browser-use（MIT，2026-09-19）

没有 API key、也不能接受数据出境场景下的答案：把它搬到本地。APUS 基于公开文档反推出"跳过自回归解码、隐状态直接打分"的核心逻辑，用 Qwen3.5-9B 复现了单 token logits 决策 + KV-Cache 广播 + 并发批量评估。

测量环境：NVIDIA RTX PRO 6000 Blackwell（96GB VRAM，Linux），PyTorch 2.14.0 + Flash Linear Attention，100% 本地推理。单次决策 79ms，与 Jev 官方 70–500ms 区间对齐。在 M2 Pro 消费级笔记本上跑同样的维基百科任务，中位耗时约 18s——无 GPU 也能用，只是慢一档。全程零云端调用、零 API 费用、数据不出本机。

06 模式二：投机扇出 + 置信度门控

语音场景把 Jev 的能力边界推到了最有趣的地方——它可以在用户还没说完的时候就行动。

6.1 打破"等一句话结束"的串行假设

传统语音智能体的链路是：等一句话说完 → ASR 定稿 → LLM 推理 → 执行。Gradium 团队的测试把中间那一步换成了"对每个部分转写持续判断"，于是链路变成：部分转写 → Jev 判断 → 若已足够明确则提前触发工具调用。

moritzkremb/jev-voice-browser 把这个思路做成了完整实现，而且工程细节非常值得抄：

一次请求问 9–11 个问题（全部并行）

策略层：阈值不是常数，是按风险分级的门控表

0. is_correction ≥ 0.6 且无新指令  → 撤销上一个动作
1. is_command    < 0.5             → 忽略
2. intent.confidence < 0.55        → 等待
3. complete < 0.6 且未静音 900ms    → 等待
4. 自由文本类意图额外静音 600ms      → 防止 "search for alan" 截断
5. 目标需 confidence ≥ 0.45 且 top-p ≥ 0.35，否则弹编号浮层让人选（无模型调用）
6. destructive ≥ 0.5               → 必须口头 "confirm"

来源：仓库 README 与 test/integration/（2026-09-21）。整个 16 条语音命令的 demo 花费约 $0.01。

6.2 官方的置信度门控范式（可直接套用）

action = response.answers["intent"]

if action.confidence < 0.6:
    route_to_support_agent(account_id)          # 通用地板
elif action.choice == "check_balance":
    show_balance(account_id)                    # 低风险：0.6 够用
elif action.choice == "approve_transfer":
    if action.confidence > 0.85:
        approve_transfer(account_id)            # 高风险 + 高置信：自动执行
    else:
        ask_user_to_confirm(...)                # 高风险 + 中置信：先确认
else:
    route_to_support_agent(account_id)

来源：docs.typesafe.ai/patterns/confidence-routing（语音银行示例）。要点：先设一个通用地板（0.6）兜住"模型真的不确定"，再按后果严重性给每类动作单独设阈值。

6.3 复合评分：把权重留在代码里

官方的简历筛选示例展示了"原子打分 + 代码加权"的形态——四个维度各自 Score，归一化到 0–1 后按不同岗位套不同权重：

py      = answers["python_depth"].score   / 4
lead    = answers["team_leadership"].score / 4
arch    = answers["system_design"].score  / 4
general = answers["generalist"].score     / 4

ic_score = 0.40*py + 0.10*lead + 0.40*arch + 0.10*general   # 高级 IC
em_score = 0.15*py + 0.40*lead + 0.20*arch + 0.25*general   # 工程经理

同一批打分，换权重就是换岗位标准——不需要重跑模型，也不需要改 prompt。这是"判断原子化"最实际的回报：优先级调整从重写提示词变成了改一行系数。

07 模式三：校验器、裁判与模型路由

"Verify Everything"——用便宜的判断去给昂贵的输出把关。这一类在社区里花样最多，也最容易高估收益。

7.1 三类玩法

7.2 实测数据

7.3 一个被低估的用法：给 Agent 轨迹做可观测性审查

官方四个公开工作流里有一个是 Agent 轨迹可观测性审查。这恰好对应真实痛点：Agent 跑了几百步之后，你无法人工回看每一条轨迹。而 Jev 的输入侧定价让"全量审查"在经济上第一次成立——审查 1 万条轨迹、每条 20 个原子判断，输入按 4k tokens 计，成本约 10000 × 4000 / 1e6 × 0.042 ≈ $1.68。

这是纯建模估算，不是实测值。它的意义在于说明数量级：同样的全量审查用前沿 LLM 做，成本会高两个数量级，因而根本不会被做。这就是杰文斯悖论在 Agent 工程里的具体形态——便宜到某个阈值以下，原本"不值得做"的事变得值得做。

08 模式四（反面）：上下文压缩为什么失败了

这一章专门留给一个失败的案例。它比任何成功案例都更能说明边界在哪，而且失败原因是可以推广的通用律。

8.1 它原本想解决什么

普通上下文压缩让模型把前面的对话重写成短摘要，痛点是：文件路径、精确报错、限制条件、已经试过的失败方案，都可能在改写时消失。fast-jev-compaction 换了个思路——不写摘要，只做选择题：把每个 tool_use 与对应的 tool_result 配成一组，让 Jev 分别回答两个问题：这个调用还要保留吗？它的结果还要原样保留吗？

默认阈值 0.5，最近 6 条消息与第一条消息默认不动。演示里压缩几乎瞬时完成，保留下来的内容一字不改——这是它最吸引人的地方。

8.2 回放测试的打击

GitHub issue #26 给出了一组真实会话回放：2 个项目、16 段 Claude Code 会话，在上下文达到 12 万 token 时触发压缩，共让 Jev 评估 256 个非固定工具调用。

8.3 根因：Jev 只能判断它能看见的东西

8.4 更有分量的批评：压缩不是筛选

Theo（t3.gg）看过演示后写了措辞很重的长评，核心区分是：整理任务状态 ≠ 逐条过滤工具记录。六条意见里五条直接关系到使用效果，其中两条尤其值得记：

• 局部判断会丢掉关系。模型做摘要时会利用整段对话，重新整理当前目标、已确认事实、失败路径和下一步动作。逐项决定保留 / 删除则可能保住一条"看起来有用"的记录，却丢掉它与前后步骤的关系。
• 删 token 不一定省钱。提示词缓存依赖历史前缀不变——删掉中间的 2，后面的 3、4、5、6 都可能需要重写缓存。Theo 自己的账单里 cache write 曾超过总模型开销的 60%。频繁改写历史，可能拿更贵的缓存写入去换更小的上下文。

另有开发者给出更激进的对比：Jev 删掉了 98.7% 的上下文，但在复杂会话里丢了 7 个关键测试与边界事实中的 6 个。Agent 忘掉之前为什么失败，很容易重新走一遍老路（Theo 称之为 stupid loops）。

09 速度与成本全景校准

本章回答"到底能快多少、省多少"。结论是：倍数取决于你把测量边界画在哪里——从 1.33× 到 518× 都有人报，而且都是诚实的数字。

9.1 成本：为什么是"输入侧主导"

传统 LLM 的输出单价约为输入的 5 倍，而 Agent 的每一轮决策都要为"把答案写出来"付输出费——哪怕最终只需要一个枚举值。Jev 的输出是 logits 投影，不是 token 序列，因而输出免费。

9.2 一个可以直接套用的估算式

# Jev：只算输入
jev_cost   = (state_tokens + Σ question_tokens) / 1e6 × 0.042

# LLM：输入 + 输出（输出单价通常 ≈ 输入的 5 倍）
llm_cost   = in_tokens / 1e6 × P_in  +  out_tokens / 1e6 × P_out

# 真实可得的端到端收益 —— 别忘了这一项
real_gain  = 1 + (model_layer_speedup − 1) × decision_share_of_end_to_end

decision_share 是你必须自己测的那个数。browser-use 实测为 53%（3,720ms / 7,073ms）——所以即便模型层快 25 倍，端到端也只能拿到 −25%。在测量之前，任何"10 倍提速"的承诺都是无意义的。

9.3 便宜到某个阈值以下，会解锁原本不做的事

这是杰文斯悖论在 Agent 工程里的具体形态，也是 Jev 命名由来。三个已经在社区出现的例子：

• 全量轨迹审查：1 万条 Agent 轨迹 × 20 个原子判断 × 4k tokens ≈ $1.68（建模值）——原本因成本根本不会被做。
• 实时游戏 / 机器人闭环：Doom 演示每秒约 10 次决策，成本约 $7/小时。贵，但在"可接受"的量级内。
• 大数据 map-reduce：输入便宜 + 输出免费 + 可大规模并行，把 PB 级数据变成特征和洞察在经济上第一次成立。

反过来说：如果你的场景每秒只做几次判断、且判断本身不是瓶颈，那么这份"便宜"换不来任何结构性变化——你只是省了一点钱。

10 失败模式与适用边界

TypeSafe 单独维护了一页 jaggedness（锯齿）说明，列出 jev-1.13 的九项已知弱点，最后复核日期 2026-09-17。厂商主动公开失败模式这件事本身就值得称道——而且这份清单实质上是一份使用说明书。

10.1 反模式清单

11 开源生态地图与本地化路线

Jev 本身完全闭源——无权重、无自托管、官方从未承诺开源。但社区在一周内就把这条路铺开了。

11.1 项目速查表

11.2 接入渠道与价格（2026-09-18 前后）

来源：llm24.net / llmpricing.dev 聚合（2026-09-18～20）。价格会随渠道调整；生产前请以官方文档与账单为准。

12 落地检查清单

把前十一章压缩成可勾选的动作。按"先测量、后接入"排序——跳过第 1 步直接接入，是本项目观察到的最主要失败方式。

12.1 接入前（必做）

12.2 接入时（设计要点）

12.3 接入后（护栏）

12.4 成熟度阶梯

13 结论与参考来源

13.1 判断（以下为观点，不是共识）

13.2 参考来源（按证据类型分组）

一手官方文档

• TypeSafe AI 官方文档 docs.typesafe.ai —— 规格 / 原语 / 置信度 / Patterns（fan-out、confidence-routing、composite-scoring、intent-routing）
• docs.typesafe.ai/model-jaggedness/jev-1.13 —— 九项失败模式，最后复核 2026-09-17
• docs.typesafe.ai/introduction/machine-learning-primer —— RLCD 与 RLHF / RLVR 的路线对比
• 官方博客 Introducing System One Models & Jev（2026-09-15）；Workflow Evals 评测站 evals.typesafe.ai

开源项目（含原始测量文件）

• github.com/browser-use/jev-ultrafast —— MIT；docs/flights-measurement.json、docs/full-speed-measurement.json、docs/performance.md
• github.com/APUS-AI-Lab/fast-browser-use —— MIT；README 含五场景性能表与 RTX PRO 6000 实测
• github.com/moritzkremb/jev-voice-browser —— README 含完整策略阈值表；test/integration/ 34 例
• github.com/tamaratran/fast-jev-compaction —— issue #26 为关键反证据
• github.com/bespokelabsai/nimble（Apache 2.0）、github.com/vinnylarouge/jevlike（MIT）、github.com/typesafe-ai/system-one-adapter-python

第三方实测与评测

• Every · Mike Taylor（2026-09-15）—— 目前唯一公开的独立第三方测试：777 判断 <0.7s、约 1/4 美分；缺陷检出 6/7 vs 7/7；0.35s vs 8.83s
• Hacker News 讨论（2026-09-17，89 分）—— 含计时边界质疑、封閉性顾虑、遥测指控（未经独立核实）
• llm24.net / llmpricing.dev —— 多渠道价格聚合

中文报道与访谈（二手，用于线索发现与交叉印证）

• 科技日报 / 央广网 / 新浪（2026-09-20）—— APUS 复现报道
• 网易《独家｜撬开 Jev 黑箱，对话全球首批复现者》—— APUS AI 首席科学家张旭博士访谈，含 79ms 数据来源
• 量子位《输出 token 永久免费！Jev 爆火后，开源版也跟着火了》—— Nimble 一致率数据、社区案例转述
• 知乎 RTE 开发者日报（2026-09-21）—— Gradium 语音智能体、jev-voice-browser 案例