Agent 工作流里的快速决策： Laya vs TypeSafe Jev

英文原文：Fast Decisions in Agent Workflows: Laya vs TypeSafe Jev（JevLab）。本文为独立、非官方评测视角，与 TypeSafe 、Convai Innovations 均无隶属或背书关系。

一句话结论： 用 70B 级自回归大模型去做简单的 Agent 路由，越来越不划算。Convai Innovations 开源的 Laya（ 421M ModernBERT-large ）正在挑战 TypeSafe 托管的 Jev。公开数字里，Laya 大约 快 7.8 倍（ 32.8 ms vs 236–276 ms ），温度校准后 ECE 更紧（ 0.081 vs 0.246 ），多语言覆盖更广，自托管软件成本可视为 $0 。但在真正上线的 Agent 流水线里，裸准确率只是一半故事——置信度阈值 + fail-closed handoff （不足则移交），才决定错误路由会不会真的被执行。

1. 「突破」之争，以及 System 1 决策引擎

2026 年 9 月初，TypeSafe 推出专有引擎 Jev （例如 jev-1.13.0），把非自回归决策原语包装成 AI 工作流的新范式：不再生成变长文本，而是直接给出确定的 choice 和 confidence。

随后，Convai Innovations 创始人 Nandha Kishor M 发了一篇传播很广的技术复盘（大意是：我一年前就在做非自回归决策模型，然后某前沿实验室管这叫「突破」）。同期开源了 Laya：Apache-2.0 ，权重在 Hugging Face （convaiinnovations/laya）。

这背后是 Agent 工程的一次分叉：

- System 1：快、非生成式分类 / 决策

• System 2：慢、自回归推理```

用户请求进来
│
[System 1：快速决策引擎]
(Laya 本地 ~33ms / Jev 托管 API)
│
置信度 >= 阈值？
/ \
是 否
│ │
自动采纳路由 Fail-closed 移交
(专职工具) (人工 / 兜底)
```如果只是为了在五个工具里选一个，就拉起 GPT-4 / Claude 级别模型，常见代价是几百毫秒到数秒、吃掉 token ，还容易在 JSON / schema 上翻车。决策引擎的做法是：不做文本解码，一次前向传播直接出类别 log-probability 。

2. 头对头数字（先说清楚前提）

Convai 发布的多维对比，是把 Laya 和 第三方已公开的 TypeSafe Jev 数字放在一起（例如 AbdelStark 、nlbzard 等相关评测材料）。这有方向性参考价值，但 不等于 同一网络、同一运行时条件下的字节级对照实验。

指标 |
TypeSafe Jev （ 1.13.0 公开） |
Laya （ Convai ） |
差异 |

P50 延迟（单题） |
236–276 ms （托管 API ） |
32.8 ms （本地 T4 ） |
约 7.8× 更快 |

批处理（ 50 题） |
N/A （并发常受限） |
7.2 ms / 题（合计 337 ms ） |
本地吞吐优势 |

校准（平均 ECE ） |
0.246 |
0.081 （温度 refit ） |
约 3× 更紧 |

许可 / 价格 |
闭源 API （约 $0.042 / 1M tokens ） | Apache 2.0 （自托管软件 $0 ） |
开源 |
|

多语言 |
未明确 / 偏英语 |
51 语中约 45 语可用 |
覆盖更广 |

隐私边界 |
出站到公网端点 |
可本地 / 气隙 |
零出站 |

公开集准确率（据报道）

- typed-decisions（ 2000 次）：Laya 0.766 vs Jev 0.727（+3.9%）； Laya 甚至高于估计的 teacher 上限（~0.735 ）

- AG News（ 4 类）：0.950 vs 0.910（+4.0%）

- DAIR Emotion（ 6 类）：0.595 vs 0.480（+11.5%）

Laya 在若干工作流式 held-out 任务上的表现（多 checkpoint ）

- 钓鱼检测：0.940–0.993

- 邮件垃圾分类：0.958–0.993

- 主题分类：0.930–0.953

- Guardrail / Jailbreak：0.708–0.762

- RAG 段落相关性：0.625–0.657

- 10 路客服分流：0.502–0.522

3. 为什么 Laya 能到 ~33 ms：ModernBERT + 校准训练

ModernBERT-large （ 421M ）

编码器路线（ FlashAttention-2 、RoPE 、unpadding 、更大上下文）并行处理 token ，避开自回归路由的 O(N) 解码循环。

面向校准的训练（ RLCD 一类思路）

经典分类器容易只优化 top-1 ，越训越「自信过头」。Laya 方向更强调 proper scoring （如 Brier 、log-loss ），让概率更适合当 策略输入，而不只是榜单装饰。

多 checkpoint + preload```
from laya import Router

router = Router(preload=True)

decision = router.route({
"task": "Review pull request #104 for potential race conditions",
"context": "diff --git a/worker.go b/worker.go..."
})
```混合语言场景下，如果每次动态加载权重，冷启动惩罚很大（ Convai 提到约 7.4 秒）。预加载后，跨语言流量下的单次延迟会平稳很多。

4. 真正决定能不能上线的部分：ECE + fail-closed

在 Agent 里，校准往往比裸准确率更重要。

- 预测 code_search，置信度 0.98 → 自动采纳通常合理

• 预测 code_search，置信度 0.52 → 基本是在猜；正确策略是 fail-closed handoff（人工复核，或追问澄清）```

ECE （越低越好）

Laya （出厂原始）： ~0.466
Jev （公开数字）： ~0.246
Laya-Multi （ refit ）： ~0.106
Laya （温度 refit ）： ~0.081
```未校准模型可以说「我 95% 确定」，但在它经常错的样本上，真实错误率可能接近 40%。温度 / 域内 refit 不是边角料——它决定阈值有没有物理意义。

5. JevLab 的视角：量的是 handoff 边界

我们的工作假设是：

没有阈值的准确率是幻觉。上线后，策略生死线是 handoff 边界。

两条反复强调的 caveat：

- 第三方表格 ≠ 受控对照。 更可信的是：同一批 prompt 、同一网络/运行时假设、钉死的模型版本。

- 歧义才是生产税。

- 「找到解析 auth token 的位置，并改测试去 mock 它」→ 多意图（code_search + test_runner）

- 「这个函数干什么？」却没贴代码 → 信息不足

无约束路由器仍会吐出一个「看起来很自信」的标签，然后把下游状态搞脏。阈值的意义，是把「我在猜」变成 handoff，而不是变成一次错误工具调用。

概念上的评测切分：

- 清晰验证 / 测试集：看 auto-adopt 率，以及被自动采纳决策里的错误率

- 对抗 / 歧义挑战集：置信度会不会塌下来，让例如 t = 0.80 的阈值干净触发 handoff

6. 怎么选：生产决策矩阵

更适合 Laya ，如果你需要：

- 本地 P50 大约 <50 ms

- 气隙 / 数据不出域

- 已有 GPU （ T4 / L4 一类）且愿意运维

- 多语言输入常见

更适合 TypeSafe Jev ，如果你需要：

- 无服务器、几乎零 GPU 运维

- 纯 TypeScript / Edge 友好接入

• 量小或突发，API 费用比常驻 GPU 更划算```

必须零出站 / 气隙？
/ \
是 否
│ │
选 LAYA 有 GPU 吗？
/ \
是 否
│ │
要 <50ms ？ 选 JEV
/ \ （托管）
是 否
│ │
LAYA 两边都评一遍
```7. 我们接下来做什么

Laya 这类可上线的开源决策模型，强化了一个判断：System 1 路由是基础设施，不是演示。

JevLab 正在评估把 Laya 基线加进公开 Lab ，让开发者可以：

- 在 同一套 Agent 路由任务上对比引擎

- 扫置信度阈值，观察 auto-adopt vs handoff 权衡

- 导出由这些曲线塑造的 TypeScript 向路由策略

在正式 measured report 发布前，请把公开站点当成 非官方阈值实验室 / Preview：适合用「策略空间」思考问题，不等于每一张图都已是发版门禁。

原文与 Lab： https://jevlab.dev/blog/laya-vs-jev · https://jevlab.dev

独立非官方项目。与 TypeSafe AI 、Convai Innovations 无隶属、背书或维护关系。文中基准数字除非另有说明，均来自已公开的第三方 / 厂商材料。