Jev on AI博士万戈

OpenJev 生态全景解析：当社区用 151M 参数在浏览器里复刻 Jev 的「System One」范式

admin@yesmiracle.net (万戈) — Mon, 21 Sep 2026 00:00:00 +0000

如果你看了上一篇 Jev 的深度解析，应该已经理解了 TypeSafe AI 为什么放弃文本生成——并行采样、RLCD 训练、数学保证的类型安全——这些让 Jev 在结构化决策任务上比 LLM 快 200 倍、便宜 400 倍。

然后有趣的事情发生了。

Jev 发布不到一周，开源社区里至少涌现出 8 个独立项目，试图用不同的技术路线复刻 Jev 的「System One」范式。 有人用 ModernBERT + GLiClass 搭了个 151M 参数的纯编码器决策引擎，在公开 Benchmark 上宣称超越了 Jev 本身。有人往浏览器里灌了个 Qwen3-0.6B，让任何人免费在本地 GPU 上对比直接 Logit 读取和逐 token 生成的差距。还有人用 Google 的 DiffusionGemma 做并行决策，单步推理达成 90.8% 的 Jev 一致率。

这不是开源社区在「山寨」一个 API。这是在用不同的技术栈验证同一个洞见：「AI 不需要会说话，会判断就够了。」

这篇文章系统地梳理 OpenJev 生态——从技术路线、性能数据到工程启示。

1. 全景图：八个项目，三条技术路线

OpenJev 不是一个项目，而是一个快速扩散的生态系统。我按底层技术路线把它们分为三类：

分类	项目	核心模型	参数	路线
编码器路线	OpenJev Verdict 1.4	ModernBERT-base + GLiClass	151M	双向编码器 + 分类头
	openJev-verdict-2.0	ModernBERT-base + 双通道	149.6M	编码器 + 双校准通道
	Laya（参考）	ModernBERT-large	421M	更大的编码器基线
扩散路线	JoshuaSP/open-jev	DiffusionGemma 26B-A4B	26B	扩散去噪 + Logit 约束
	razorback16/openjev	DiffusionGemma 26B-A4B	26B	同上的决策服务封装
LLM 路线	SemIf (workszop/openjev)	Qwen3-0.6B (GGUF)	0.6B	Browser WebGPU + Logit 读取
	zhihz/openjev	Qwen3-4B-Instruct	4B	本地 MLX 推理
	TheoLeeCJ/openjev	多种开放模型	可变	LLM 分类头读取
商业	openjev.sh	N/A	N/A	付费代理 + $JEV 代币

三条路线的哲学完全不同。下面逐一拆解。

2. 编码器路线：OpenJev Verdict——151M 的纯判断引擎

架构

Verdict 是当前最「认真」的 OpenJev 项目。它不是把 LLM 拿来改 Prompt，而是从零用编码器搭了一个纯判断模型。

核心组件：

ModernBERT-base（149.6M 参数）：Answer.AI 和 LightOn 联合研发的高效编码器，支持 8192 token 上下文，原生 unpadding，训练效率比旧版 BERT 高 4 倍
GLiClass 分类头：bi-encoder 架构，将文档和候选标签联合编码后计算相似度
RLCD 风格训练：用 Brier Score 等校准指标做优化信号

推理过程是非自回归的：输入文档 + 候选标签列表 → ModernBERT 单次前向传播 → 分类头计算所有候选的 Logit → Softmax 归一化 → 直接输出概率分布。整个过程 20–35 毫秒完成。

Verdict 1.4 的修复故事

V1.0 有几个低级但关键的工程缺陷：

Calibrator 没加载：推理引擎在独立运行时忘了加载 calibrator.json，实际上在用未校准的 temperature 1.0 瞎蒙
候选标签格式不匹配：GLiClass 基座来自自然语言推理（NLI），期望标签写成假设句（“It is {description}"），但引擎直接送裸名词短语
上下文窗口过大：训练数据的上下文平均 71 tokens，推理时却允许 1024，导致分布外漂移

V1.4 修复后，Standard 难度准确率从 62.5% → 69.4%（+6.9%），Hard 难度校准误差从 0.298 → 0.118（-60.4%）。这是一个很好的案例：即使架构对了，粗心的推理工程也能毁掉一切。

Verdict 2.0：151M 击败 421M

Verdict 2.0 在 LocalLLaMA/typed-decisions 这个企业级决策 Benchmark（2000 条金融/安全/客服/Agent Trace 数据）上交出了令人侧目的成绩：

模型	参数量	Top-1 准确率	Brier Loss	ECE	延迟
Verdict 2.0	149.6M	77.10%	0.0636	1.44%	~20-25ms
Laya	421.3M	76.60%	0.0660	—	~31ms
TypeSafe Jev 1.13	~150M	72.70%	0.1480	14.4%	~140ms
TF-IDF + LR	0	66.10%	0.1520	2.07%	~8ms
Verdict 1.0 基线	149.6M	26.10%	0.5851	42.09%	~35ms

几个值得注意的点：

Verdict 2.0 的准确率（77.10%）超过了 Jev 本身（72.70%）。但要注意：Benchmark 数据集是 LocalLLaMA/typed-decisions，不是 Jev 的 workflow evals。TypeSafe 明确拒绝在公开 Benchmark 上评测，所以这不是 apples-to-apples 对比。
TF-IDF + Logistic Regression 拿到 66.10%，说明这个数据集里相当一部分决策可以通过简单词频特征解决。Verdict 2.0 多出的 11% 来自需要深层语义判断的边界样本。
Verdict 2.0 的双通道校准（Correctness Head + Distribution Channel）把 ECE 降到了 1.44%，这是数学上比 Jev 更好的校准度。Jev 的文档里承认 ECE 约 14.4%。

但是：Verdict 2.0 目前只支持最多 25 个候选选项（24 + 1 弃权槽），而 Jev 支持 255。Verdict 的上下文窗口也受限于 ModernBERT 的 8192 token 位置编码。

编码器路线的根本局限

编码器方案的优势是快且便宜——一次前向传播决定所有事情。但它的上限也很清楚：

没有推理能力：遇到需要多步推导的决策（「如果 A 且 B 则 C」），编码器要依赖训练数据中的模式覆盖
不支持开放式输出：只能从预定义的候选中选择，不能动态生成新选项
语言能力受限：相比在数十亿 token 上训练的 LLM，编码器的语言理解有限
候选数量上限：25 vs Jev 的 255，差距明显

但如果结构化决策是它唯一的任务，这些局限可能根本不成问题。

3. 扩散路线：DiffusionGemma 做并行决策

JoshuaSP/open-jev 走了一条完全不同的路：用 Google 的 DiffusionGemma 26B-A4B（一种非自回归扩散语言模型）来做并行决策。

为什么用扩散模型？

DiffusionGemma 不是逐 token 生成文本，而是从一个随机噪声向量开始，通过多步去噪直接「涌现」出完整输出。这意味着它能在单步去噪后就读取 Logit 做出决策，而不需要走完整个扩散序列。

对比 Jev 的并行采样与 DiffusionGemma 的扩散采样：

	Jev	DiffusionGemma (1-step)
采样策略	专用并行架构	扩散去噪 + Logit 约束
单次决策速度	70-500ms	~150ms（含 H100 推理）
一致性	数学保证（原始 Jev）	90.8%（复刻 337 题）
类型安全	架构保证	约束解码保证
模型来源	私有训练	开放权重 26B

实测结果

项目作者在 20 个 Jev 公开用例的 337 个问题上做了对比：

Workflow	原始 1-step	分组 1-step	分组 2-step	原始 Jev
Agent 跟踪	78.8%	78.8%	80.8%	78.8%
客服	91.3%	82.6%	84.8%	89.1%
发票处理	92.8%	92.2%	94.0%	97.0%
安全事件	69.2%	73.1%	73.1%	80.8%
全部	88.4%	86.1%	87.8%	90.8%

分组 2-step 推理比原始方法快 4.85 倍、便宜 79%，正确判断只少了 2 个（337 题中从 298 → 296）。

关键发现：所有 408/408 输出都是有效的 typed answer，零格式错误。通过约束解码直接在 Logit 层拦截非法 token，格式合法性同样可以数学保证。

扩散路线的成本估算：$0.0361/千文档（H100 上），与 Jev 的 $0.042/M tokens 定价在不同维度上。

路线的意义

DiffusionGemma 方案证明了非自回归语言模型天然适合 System One 范式。扩散模型不需要逐 token 解码，可以在任意去噪步骤后读取已稳定的 Logit。这意味着：

如果你需要更高的判断质量，就多走几步去噪
如果你只需要快速决策，就 1-step 截断
同一个模型可以同时提供 System One 和传统的 System 2 生成能力

4. LLM 路线：SemIf——浏览器里的 Logit 读取实验

SemIf（原名 OpenJev，由 workszop 开发）是这个生态里最出圈的项目。它登上 Hacker News 首页拿到 556 票，245 条讨论。

核心思想

在浏览器加载一个 Qwen3-0.6B 的 GGUF 量化版本（~639MB），然后用两种方式比较同一个模型做决策：

Direct Readout：从模型的最后一层 Logit 中直接读取候选标签的归一化概率——单 token 读取，不生成任何额外文本
Generation：让模型自回归地生成一个 JSON 格式的概率分布——完全标准的 LLM 调用

结果一目了然：

指标	Direct Readout	Generation
延迟（RTX 3090）	0.704 s	3-5x 更慢
格式错误率	0%（数学保证）	需解析 JSON
是否需要 LLM 生成	❌ 单 token 读取	✅ 完整解码
是否需 GPU	是（WebGPU）	是（WebGPU）

SemIf 的页面设计了非常直观的交互：左边是 Direct Readout 的条形图显示每个选项的概率，右边是 Generation 的输出和计时。你可以自己添加/删除选项，实时体验差距。

关键发现：不是模型的问题，是范式的问题

SemIf 最深刻的洞察是：同一个模型（Qwen3-0.6B），通过 Direct Readout 和 Generation 输出的概率分布可以完全不同。因为生成路径需要模型「自我报告」概率——模型需要先想好答案，再把它写成 JSON——这个过程引入了额外的偏差和格式压力。

Direct Readout 则绕过所有中间表示，直接从最后一层的语义表示中读取该 token 的 Logit。它更快，而且不可能格式错误。

「这实际上是对 Jev 核心论点的直接证明：如果你只需要判断，不要生成文本。即使是非常小的模型（0.6B），直接读取 Logit 也能在结构化任务上给出有用的分布。」

5. 中文路线：zhihz/openjev

zhihz/openjev 是中文社区的直接回应。基于 Qwen3-4B-Instruct，用 MLX 在 Apple Silicon 上运行，支持中文和英文输入。

核心差异：

真正的双语：英文 + 简体中文，Prompt 和候选标签均支持
本地运行：Apple M3 + 16GB 内存即可
Web 界面：内置 UI 支持编辑示例、多问题并发、JSON 导出

但作者也诚实标注了当前的局限：

后端是 Qwen3-4B 的通用指令模型，不是专门训练的决策模型
问题目前是顺序执行的（共享上下文编码的并行化尚未实现）
没有宣称比直接调用 LLM 有精度或速度优势

这意味着 zhihz/openjev 更像一个工程演示——展示如何将 LLM 的输出约束为决策接口——而不是一个真正的「复刻」。

6. Benchmark 乱局：谁真的超越了 Jev？

OpenJev 生态里最热门的叙事是「Verdict 2.0 以 151M 参数超越 Jev」。但这个说法需要仔细拆解。

明面宣称	实际限制
Verdict 2.0 准确率 77.10% > Jev 72.70%	Benchmark 数据集 `LocalLLaMA/typed-decisions` 不是 Jev 的评估集
Verdict 2.0 ECE 1.44% « Jev 14.4%	Jev 的 ECE 来自其官方 jaggedness 文档，但 Jev 也在持续改进
Verdict 2.0 延迟 ~25ms < Jev ~140ms	Jev 的 140ms 包含网络传输，Verdict 的 25ms 仅是本地推理
Verdict 2.0 训练成本 $0（消费级 GPU 8.8 小时）	Jev 的 RLCD 训练成本未公开

TypeSafe AI 有一个明确的哲学立场：「不发布公开 Benchmark 成绩，也不鼓励社区用公开 Benchmark 对比。」 他们甚至写了一篇博客叫 Antibenchmaxxing，论述为什么以 Benchmark 为中心会扭曲研究。

所以「超越了 Jev」这个说法在工程上有趣，但在科学上几乎是不可验证的——除非有人拿到同一个私有评估集，或者 TypeSafe 开放他们的 Workflow Eval 集。

7. 三条路线的工程对比

维度	编码器路线（Verdict）	扩散路线（DiffusionGemma）	LLM 路线（SemIf/zhihz）
架构	纯编码器（非自回归）	扩散语言模型	自回归 LLM + Logit 读取
参数	149.6M	26B (A4B)	0.6B-4B
推理速度	~20-35ms	~150ms	~700ms-2s
GPU 需求	任意 GPU（6GB VRAM）	H100 80GB	RTX 3090 / M3
类型安全	数学保证	约束解码保证	约束解码保证
候选上限	~25	灵活	灵活
校准	专用双通道	未专门校准	原始 Logit 未校准
训练	需 RLCD 风格训练	无需（零样本）	无需（零样本）
语言	英文	英文	中英双语
可部署性	生产就绪	实验性	演示/教育

没有一条路线在所有维度上领先。选择取决于你的约束条件：

如果你要在生产环境中做高频率决策（>100 QPS）、GPU 有限、只需要英文 → Verdict 路线最务实
如果你需要零训练成本、最高判断质量、有 H100 资源 → DiffusionGemma 路线值得试
如果你要快速验证概念、做双语或教育演示 → SemIf/zhihz 路线最佳

8. 工程启示：为什么 OpenJev 生态会爆炸？

Jev 发布不到一周就出现 8 个复刻项目，这个速度本身就值得思考。

洞见一：「决策」是比「生成」更容易复制的接口

LLM 的「生成」能力依赖大规模预训练数据、RLHF 对齐、数万张 GPU。Jev 的核心创新是接口层面的——不是模型更强了，而是模型被迫输出的东西更少了。一旦理解了「单次 Logit 读取」这个 trick，任何 LLM 或编码器都可以装上这个接口。

SemIf 用 0.6B 模型证明了这一点。Verdict 用 151M 的编码器论证了「专用胜过通用」。

洞见二：TypeSafe 真正的护城河可能是 RLCD 训练数据

Verdict 2.0 的 Benchmark 成绩虽然惊艳，但它依赖的是 LocalLLaMA/typed-decisions——一个 2000 条的企业决策数据集。Jev 背后是 TypeSafe 自研的合成数据 pipeline，他们明确定义自己为「primarily a data research lab」。

数据，而不是架构，可能是这个领域真正的护城河。

洞见三：Agent 基础设施正在吃掉这些能力

OpenJev 生态快速膨胀的原因之一是 agent 开发者的直接需求。我在上一篇中提到 Jev 对路由层、护栏、验证的影响——OpenJev 项目正在把这些能力从 API 调用变成可部署的本地服务。

Verdict 2.0 明确列出了 MCP 工具选择、实时 Agent 护栏、高频率状态循环等场景。这不是巧合，这是 agent 基础设施在寻找自己的「条件判断函数」。

9. 总结：未来是属于 System One 的，但不会只有 Jev

Jev 的开创性贡献不是它的模型——而是它定义的接口。

这个接口——State + Questions → Typed Answers with Probabilities——可能会成为 AI 领域的 REST API：一个足够通用的契约，让不同技术栈在不同硬件上实现同一个承诺。

OpenJev 生态已经证明了三条独立的技术路线都可以收敛到这个接口上。未来 12 个月，我们很可能会看到：

编码器路线向更大上下文和更多候选发展（ModernBERT-large, 更长位置编码）
扩散路线通过更多去噪步获得更好的校准
LLM 路线作为「回退方案」——同一个模型同时提供 System One（Logit 读取）和 System 2（生成）能力
Agent 框架原生集成 System One 接口作为标准组件

这个领域正在发生的事情，不只是 Jev 被复刻——而是整个 AI 行业在重新思考：当模型不需要「说话」时，我们能省下多少成本、快多少？

答案可能是「两个数量级」。那个未来值得我们去建。

关于作者：万戈（Chengqi），AI Infra 工程师，前华为/万翼，现构建 MCPZERO（Agent 工具协议）、ClawGuard（Agent 行为安全）和 NanoRuntime（轻量级 Agent Runtime）。

TypeSafe AI Jev 深度解析：放弃文本生成的「System One 模型」凭什么这么火？

admin@yesmiracle.net (万戈) — Mon, 21 Sep 2026 00:00:00 +0000

如果你这几天刷 AI 新闻，一定看到了这个名字：Jev。

TypeSafe AI 在 9 月 15 日发布了它，然后整个圈子炸了——不是因为它又一个「超越 GPT」的 Benchmark 跑分，而是因为它从根本上重新定义了一个 AI 模型应该输出什么。

Jev 不能聊天。不能写代码。没有推理链。你给它一段客户投诉，问三个问题：这是紧急吗？该转哪个部门？客户情绪多差？它并行回答所有问题，70–500 毫秒内返回带概率的结构化结果，你的代码直接分支——不需要解析 JSON、不需要重试、不需要 Schema 验证。

这不是又一个更小更快的 GPT。Jev 的架构、训练目标、采样策略全部不同。TypeSafe 称之为 System One 模型，我认为这是 2026 年最有意思的 AI 发布之一。

这篇文章从架构原理、训练方法、实际能力到基础设施影响，帮你全面拆解。

1. 什么是 System One 模型

名字来自丹尼尔·卡尼曼的《思考，快与慢》：System 1 是快而直觉的，System 2 是慢而深思的。传统 LLM 是 System 2——逐 token 自回归生成文本。Jev 是 System 1——读一段状态（state），输出一个判断，单次并行前向传播完成。

维度	LLM (System 2)	Jev (System One)
训练信号	RLHF — 优化人类偏好	RLCD — 优化校准决策
输出	生成文本（字符串）	带概率的 typed 结构化值
采样	顺序逐 token	并行，所有输出一次完成
速度	3–329 秒（前沿模型）	70–500 ms
成本	$0.20–$10 / M 输入 tokens，输出约 5x 更贵	$0.042 / M 输入 tokens，输出免费
类型安全	需解析+验证，仍可能幻觉格式	数学上保证类型正确
置信度	过度自信且不一致	校准的：高置信度 = 高准确率
典型用例	聊天、代码生成、推理链	分类、路由、评分、验证

TypeSafe 在 workflow evals 上的数据是：比前沿 LLM 快 193.6 倍，便宜 444.6 倍。他们发布的 Pareto 图显示 Jev 在结构化决策任务上处于完全独立的曲线——任何价位的 LLM 都无法在速度+准确率组合上匹配。

2. 架构核心：并行采样

最根本的架构差异是并行采样。

传统 LLM 逐 token 生成：token N+1 依赖 token 0..N。要输出一个结构化决策（比如从 5 个选项中分类并给出概率），模型必须先产出一长串描述答案的 token——每一个 token 都是潜在的幻觉点。

Jev 反过来。给定一个 state 和一组 questions，它在单次前向传播中并行评估每个问题。输出是固定形状的 typed 结构：

Noul：一个 [0, 1] 浮点数，代表「是」的概率
Choice：选中选项 + 所有选项的概率分布 + 置信度
Score：概率加权得分 + 每级概率 + 置信度

因为输出形状在请求时就固定了，类型错误在数学上不可能发生。不存在幻觉出畸形 JSON 键或错误闭合括号的 token。

这对 agent 基础设施的意义巨大：你的代码不需要解析、验证、重试或 Schema 强制。response.answers["department"].choice 永远是 criteria 集合中的有效字符串。这是 AI 最接近「永远正确工作的函数调用」的一次。

3. RLCD：真正的训练秘密

TypeSafe 最重要的创新可能不是架构，而是 RLCD（Reinforcement Learning for Calibrated Decisions）。

每个主要 LLM 实验室都用某种 RLHF：训练一个基于人类偏好的奖励模型，然后最大化这个奖励。创始人 Diogo Almeida 说得直白：「生成人类标注者更喜欢的文本」对自动化来说是错误的优化目标。

RLVR（Reinforcement Learning with Verifiable Rewards）用程序化可验证的奖励信号部分解决了数学和代码的问题。但大多数现实世界的判断任务不适合这种形状——结果就是「尖峰智能」：在可验证 Benchmark 上表现好，在细微决策上不稳定。

RLCD 优化的是校准度（calibration）：模型输出的概率应该匹配真实结果频率。当 Jev 说一个工单有 85% 概率属于「技术」类别时，在所有这样的判断中，大约 85% 应该确实是技术类。校准曲线（ECE、可靠性图）直接衡量这个指标，RLCD 直接优化它。

这和「让模型产出一条推理链然后希望结论正确」有本质区别。Jev 不推理——它判断。训练数据是 TypeSafe 自己合成的（他们自称为「主要是数据研究实验室」），RLCD 过程在 System One 任务上迭代改进校准度。

4. 三个原语：Noul, Choice, Score

TypeSafe 恰好暴露三种问题类型，每种对应一种基本的决策形状：

Noul（是否型）

最简单的原语。问一个二值问题，返回概率 [0, 1]。

用途：内容审核、护栏触发、相关性过滤、大规模二值分类。

Choice（N 选一）

从最多 255 个候选中选一个，返回完整概率分布 + 置信度。

{
  "department": {
    "type": "choice",
    "choice": "technical",
    "confidence": 0.78,
    "probabilities": {
      "technical": 0.85,
      "sales": 0.0,
      "billing": 0.15
    }
  }
}

用途：意图路由、工单分类、模型选择、链接选择（Wikiracing demo 每步从 ~100 个链接中选）。

Score（评分型）

在一组有序级别（2–10 级）上返回概率加权连续分数。

{
  "frustration": {
    "type": "score",
    "score": 1.0,
    "confidence": 1.0,
    "probabilities": { "0": 0.0, "1": 1.0, "2": 0.0 }
  }
}

用途：情感评分、质量评级、严重程度评估、复合评分（多个原子分数后在代码中组合）。

5. 置信度契约

Confidence 是 Jev 最被低估的杀手特性。

Choice 答案不仅返回选了什么，还返回模型对这个选择有多确定。置信度从概率分布计算：0.0（均匀分布——模型完全没把握）到 1.0（所有概率质量集中在一个选项）。

这开启了一种 TypeSafe 称为 confidence-gated routing 的模式：你的代码检查 if answer.confidence > 0.8: 自动处理; else: 升级到人类或昂贵 LLM。不需要 Prompt 工程。不需要「你确定吗？」重试。模型在不确定时就告诉你。

对 agent 基础设施来说，这是变革性的。当前的 agent 循环浪费大量计算在确定性的重试逻辑、确认 Prompt 和解析重试周期上。置信度门控架构在推理层面消除了大部分这种开销。

6. 两个 Demo：Doom 和 Wikiracing

Doom：10 次/秒的实时决策

Jev 通过评估游戏状态（敌人位置、血量、弹药、附近道具）来玩 Doom，以约 10 次查询/秒的速度选择动作。成本：约 $7/小时。模型不在像素上运行——游戏状态被预解析为结构化文本——但延迟预算符合实时游戏要求。

核心洞察：没有 LLM 能以商品化定价维持每秒 10 次结构化决策。这不仅是速度和成本问题，更是架构问题——Jev 的并行评估让它在同一前向传播中处理多个决策，而 LLM 必须为每个动作生成一串 token。

Wikiracing：无需解析的路由

从一篇 Wikipedia 文章出发，只用超链接导航到目标页面。每一步需要从数百个链接中选一个。Jev 评估每个链接的相关性并选一个。

关键洞察：Jev 永远不会幻觉出不存在的链接——这是 LLM 在高基数选择中常见的失败模式。利用 Choice 的 255 选项限制和更大候选集的 2 阶段评分，模型始终用更少的步数到达目标。

7. 已知缺陷：Jev 不能做什么

TypeSafe 发布了一份相当坦诚的 「jaggedness」文档。以下是真实限制：

字面阅读：Jev 回答你写的问题，不是你想问的。否定、隐含条件、作用域词都按字面理解。如果指令说「客户既生气又要求退款」而只有一个条件满足，Jev 可能基于部分重叠回答。规避：分解为独立问题。
不能数学和计数：Jev 不能可靠计数。在 8 个项目的列表中问「几个是水果」会失败。规避：每个项目一个 Noul，在代码中求和。
不能比较日期和时间：日期被视为文本，不是有序量。混合格式和时区边界特别不稳定。规避：用 Choice 提取组件，在代码中比较。TypeSafe 提供了一个日期提取 cookbook。
不支持间接推理：双重否定或属性之属性会降低准确率。规避：写最直接的问题。
对大状态敏感：准确率随着与决策无关的内容增多而下降。规避：代码中先检索和过滤相关字段。
不处理图像：目前仅文本输入。Doom demo 将游戏状态预解析为结构化文本。
语言偏差：英语是主要训练语言，准确率最好。中日韩及其他语言「效果不那么好」。

这些不是致命伤——它们是不同范式的边界。LLM 在这些方面也会失败，但失败的信号被流畅的文本掩盖了。Jev 的失败是透明的（低置信度、错误概率），因而更容易管理。

8. 对 Agent 基础设施的影响

对于正在构建 agent 基础设施的人（包括 MCPZERO 和 NanoRuntime 的我们），Jev 改变了几个关键子系统的计算：

路由层：不再用单个 LLM 调用来决定意图。部署 Jev 作为预路由器——70–500ms、$0.042/Mtok、零解析开销、置信度门控升级到更强模型。这是我所见过最干净的「分类器 → 专家」架构。

护栏：Jev 比现有护栏模型更快更便宜。每个检查一个 Noul 问题（检测到劫持？泄露了 PII？违反策略？）在同一调用中运行，增加可忽略的延迟。

验证：用 Jev 评分任何其他 LLM 的输出。「这个答案引用了证据吗？评分 0–2。」「这个推理链逻辑一致吗？Noul。」以生成式调用 1/400 的成本，你可以验证生产中的每个 LLM 输出。

Agent 行为 Map-Reduce：100 倍更便宜意味着你可以对 agent 会话的每一步进行分类、评分和特征提取——构建支持类似 ClawGuard 的可观测性和安全工具所需的行为数据集。

9. 更大的图景：Jevons Paradox

TypeSafe 将模型命名为 Jev 是为了纪念 William Stanley Jevons——他观察到煤的使用效率提高导致了更多的煤消费，而不是更少——因为更便宜的能源解锁了新用例。Jevons Paradox 是团队明确的赌注：当 AI 判断便宜 400 倍时，软件自动化的决策数量会爆发式增长，而不是收缩。

如果这个假设成立，未来不是一个巨大的聊天模型运行一切。它是一个分层架构：Jev 类模型在边缘做快速、廉价、校准的决策；更强的 LLM 保留给深度推理、创意生成和人类交互；中间的代码控制流程。

这是一个值得为之构建的未来。

Jev on AI博士 万戈