上周我分别写了 Jev 深度解析、OpenJev 生态全景 和 Laya 上手指南，每篇聚焦一个方案。但在研究过程中，我越来越强烈地感觉到一个更大的问题在浮现：
不止 Jev 一家在做「System One 决策模型」——不到十天，社区涌现了至少四条完全不同的技术路线，每条的架构取舍和适用场景截然不同。
更关键的是：这些决策模型和 LLM 不是替代关系，而是互补关系。真正的问题是：如何设计一个架构，让 System 1（决策模型）做它擅长的反射级决策，同时让 System 2（LLM）做它擅长的深度推理，并在两者之间优雅地路由？
本文先横评四大方案的核心区别，再提出一套将决策模型与 LLM 融合的分层混合架构。
四大方案：一张表看全景
在深入细节之前，先用一张总览表建立全局认知：
| 维度 | Jev (TypeSafe) | OpenJev | AnyJev (Nokia) | Laya (Convai) |
|---|---|---|---|---|
| 架构路线 | 自研 RLCD 决策模型 | LLM 微评分 + 软最大 | LLM 隐藏状态 + 线性头 | 双向编码器 + RL 决策头 |
| 运行模式 | 托管 API ($0.042/MTok) | 自托管 + 可插拔后端 | 自托管 LLM + 训练头 | 自托管开源权重 |
| 延迟 (单问题) | 150-276ms | 取决于 LLM 后端 | ~1x LLM forward（~100ms） | 33ms (7.2ms 批量) |
| 参数量 | 未公开 | 依赖后端 LLM | 依赖后端 LLM（1.7B-32B） | 421M / 322M |
| 训练需求 | 无（托管 API） | 无 | L0: 零标签, L2: 100-300 标签 | 需要微调（~4h Kaggle） |
| 类型安全 | choice/score/noul | choice/score/noul | choice/score/noul | choice/score/noul |
| 候选上限 | 无硬限制 | 无硬限制 | ≤26 (字母) / 无上限 (span) | ≤20 (最优) |
| 开源性 | ❌ 闭源 | ✅ 开源 | ✅ Apache 2.0 | ✅ Apache 2.0 |
| 多语言 | 仅英文 | 取决于后端 | 取决于后端 | 100+ 语言自动路由 |
| JevBench 排名 | #1 (74.4) | #11 (66.4) | 未正式参评 (~0.80 acc) | #33 (54.4) |
| 核心差异化 | 即开即用，无需 GPU | 零编码，兼容 Jev API | 零标签可用，渐进式增强 | 速度最快，完全本地化 |
⚠️ 关于 JevBench 排名：这个榜单混合了 52 套系统在 534 个决策上的综合得分（含智能、校准、速度、成本）。排名不完全反映「决策质量」——Laya 在 typed-decisions 基准上的准确率 (0.766) 实际高于 Jev (0.727)，但综合得分低主要是因为零-shot 能力弱（需要微调）和设备成本得分低（自托管 GPU 算成本）。
一、Jev (TypeSafe)：即开即用的托管控件
Jev 是 TypeSafe AI 推出的首个「System One 模型」，9 月 15 日发布。它不自称 LLM，不生成文本——你输入一段「状态」和一组「类型化问题」，它返回结构化的概率答案。
架构核心：Jev 使用名为 RLCD（Reinforcement Learning for Calibrated Decisions）的训练方法。简单来说：对每个候选选项做独立打分（平行采样），用 RL 训练让这些分数逼近真实概率分布，然后归一化输出。不是从文本中「提取」答案——它在 logits 层面就知道哪个选项更可能。
三个原语：
choice：从选项列表中选一个，返回分布 + 置信度score：在序数量表上打分（0-3 级严重程度等）noul：是非判断，返回校准概率 P(true)
优势：零部署、零运维。注册拿 Key，curl 就能调。输出概率经过校准（不是 LLM 那种假装有置信度的 token 模仿），可以直接在代码中设置阈值分支。
局限：闭源，只能走 API。延迟不含网络传输 150ms+，加上 RTT 在大洋洲实测 250-300ms。多语言没公开数据。成本虽然低（$0.042/百万输入 token），但高频场景累积起来不便宜。
二、OpenJev：LLM 微评分 + 软最大
OpenJev 不是一个具体的模型，而是一组用 LLM 模拟 Jev 行为的开源实现合集。目前我看到三个主流实现：
- SiliconLabAI/OpenJev（Node.js）— 三个后端：parallel（对每个选项做单个 logit 微评分→softmax）、oneshot（单次 JSON 结构化调用）、decider（接入 Mapika/decider 真·System One 权重）
- razorback16/openjev — 基于 DiffusionGemma 的决策服务器
- snakerzr/OpenJex — 自托管实现
架构核心：OpenJev 的核心洞察是——你不需要专门训练一个决策模型。把一个普通 LLM 的推理能力「投射」到决策空间就够了。parallel 模式对 K 个选项各发一次 {p}（单个 token 概率请求），然后 softmax 归一化，得到的概率分布和类型化输出可以直接分支。
优势：零训练、零新架构。你已有的 LLM 基础设施直接拿来用。兼容 TypeSafe Jev 的请求形状（POST /v1/systemone）。
局限：速度受限于 LLM 后端。如果用 GPT-4 做后端，一次 choice 决策可能要跑 4-8 次 LLM 调用（每个选项一次）。校准质量取决于后端，不够稳定。
三、AnyJev (Nokia)：LLM 隐藏状态 + 渐进式决策头
AnyJev 是四月中让我最兴奋的方案。它来自 Nokia Applied Research（作者 Jiamu Zhang、Tianze Yang 等），9 月 22 日在 GitHub 开源。
AnyJev 的核心洞察：LLM 在处理输入时，中间层的隐藏状态已经包含了你需要做决策的所有信息——问题是你有没有从中把它读出来。
四级渐进体系：
| 级别 | 需要什么 | 解决了什么 | 成本 |
|---|---|---|---|
| raw | 无 | 直接读 logits（选项颠倒会翻车） | 1 次 prefill |
| L0 | 零标签 | 循环移位消偏 + 先验去偏 → 消除顺序偏差 | K 次 prefill |
| L1 | 100-500 标签 | 温度缩放校准 → 置信度准确可设阈值 | 同上 + 校准 |
| L2 | 100-300 标签 | 闭式解线性头 + 提前退出 → 一次前向传播，比原始 forward 还便宜 | < 1 次 forward |
L0 的惊人效果：用「零标签」把选项顺序颠倒时的翻车率从 23% 降到 7.3%。做法很直观——将选项列表循环 K 次，每次换个顺序问，取平均消偏。不需要任何训练数据。这意味着你可以在零成本下获得「顺序无关」的稳定决策。
L2 的工程艺术：L2 在 LLM 的中间层（约 64% 深度）「提前退出」——截断模型，读该层的隐藏状态，用一个闭式解线性头（closed-form solve）直接映射到决策空间。成本比一次完整 LLM 前向传播还低 30-40%。而且这个线性头是 closed-form solve（矩阵求逆），不需要梯度下降，100-300 个标注就搞定。
效果：Qwen3-4B 在 L2 级别达到 0.786 准确率（超过 Jev 的 0.727），校准误差 0.03-0.05。一个 4B 模型用 64% 的深度跑 L2，效果超过了专门训练的 421M Laya。
四、Laya (Convai)：双向编码器 + RL 决策头
Laya 走了和前三者完全不同的技术路径。它不是基于 LLM（无论是自研还是利用已有 LLM），而是基于双向编码器（ModernBERT-large / mmBERT）。
架构核心：Laya 使用 ModernBERT-large（421M）作为主干编码器，在顶部接一个决策头（2 层 Transformer + option-marker scorer + act/escalate head）。一次前向传播同时评估所有选项——因为双向编码器可以用 attention 看到所有选项之间的相互关系，不需要为每个选项单独打分。
速度的根源：ModernBERT 不是自回归的。它不像 LLM 那样逐个 token 生成输出，而是一次性把整个输入编码完。这就是为什么 Laya 能在 33ms 内完成一次决策（批量模式下 7.2ms/问题），比 Jev 快 6-8 倍。
多语言自动路由：Laya 内置了一个纯 Python 的 Router——按输入文字的 Unicode 脚本自动选择英文模型 / 多语言模型 / typed-decisions 模型。这个 Router 只要 0.1-0.7ms，比一次 forward 的 33ms 几乎可以忽略。
诚实的局限：
- choice 超过 20 个选项时性能骤降（从 0.766 掉到 0.425）→ 需要两级分层
- 零-shot 表现接近随机（~0.35）→ Laya 是需要微调的基础模型，不是即开即用的 API
- 英文模型在非拉丁语系上完全不可用（高棉语准确率 0% 但置信度 95%）→ 必须用自动 Router
五、四种方案的技术路线图
让我用一个直观的方式总结这四条路线的本质差异：
技术路线 ──────────────────────────────────────────────
┌─ 专有决策模型 ─ Jev ──── 闭源 RLCD，托管 API，即开即用
│
├─ LLM 微评分 ── OpenJev ── 用 LLM 当 scoror，零训练成本
│
├─ LLM 隐藏状态 → AnyJev ── 中间层提前退出 + 线性头
│ L0 零标签，L2 省 30%+ forward 成本
│
└─ 双向编码器 ── Laya ───── ModernBERT + RL 头
33ms，完全本地，但需要微调
前三条路线都基于或利用 LLM，但方式完全不同：
- Jev：自研新模型，不是 LLM
- OpenJev：把 LLM 当 scorer 使用
- AnyJev：从 LLM 底层提取决策信号
- Laya：不是 LLM，是专用决策架构
六、混合架构设计：System 1 + System 2 Router
研究完这四个方案，我一直被一个问题驱动：有没有一种方式，让决策模型和 LLM 协同工作，而不是让开发者二选一？
答案是我设计的一套分层混合架构——System 1 + System 2 Router：
┌─────────────────────────────┐
│ Agent / Application │
└──────────┬──────────────────┘
│
▼
┌─────────────────────────────┐
│ Decision Router │
│ │
│ ① 问题类型分类 │
│ ② 复杂度评估 │
│ ③ 置信度门控 │
│ ④ 成本预算 │
└──────┬──────────┬───────────┘
│ │
┌─────────▼──┐ ┌────▼──────────┐
│ System 1 │ │ System 2 │
│ 决策模型 │ │ LLM │
├────────────┤ ├───────────────┤
│ Laya │ │ GPT-4o │
│ 33ms │ │ Claude │
│ $0 │ │ Qwen │
│ 概率输出 │ │ 文本输出 │
└────────────┘ └───────────────┘
Router 的四层决策逻辑
第一层：问题类型分类
不是所有问题都需要 LLM。Router 按问题类型决定走哪条路径：
| 问题类型 | 路由目标 | 典型延迟 | 示例 |
|---|---|---|---|
| 分类/选择（≤20 选项） | Laya (System 1) | 33ms | 路由到哪个部门、内容审核、安全护栏 |
| 分类/选择（>20 选项） | AnyJev L2 / LLM | ~100ms+ | 77 个银行意图分类 |
| 是非判断 | Laya noul | 33ms | 是否欺诈、是否需升级 |
| 序数评分 | Laya score | 33ms | 紧急程度 0-3 |
| 开放生成 | LLM | 500ms+ | 回复客户、写代码、摘要 |
| 多步推理 | LLM + CoT | 1s+ | 需要一步步推理的复杂问题 |
第二层：置信度门控（Critical）
System 1 返回的不只是分类标签——它返回完整的概率分布和校准置信度。
if decision_model.confidence > 0.95:
→ 直接采纳，不回退
elif decision_model.confidence > 0.70:
→ 采纳，但添加「低置信度」标记给下游
else:
→ 升级到 LLM (System 2) 做深度推理
关键区别：LLM 的「置信度」是编的（token 模仿），Laya/AnyJev 的置信度是经过校准的（ECE 0.03-0.08）。这意味着 System 1 的置信度阈值的误报率是可预测的，可以直接写入 SLA。
第三层：成本预算调度
if budget_mode == "cost_optimized":
→ 能走 System 1 都走 System 1
elif budget_mode == "quality_optimized" and confidence < 0.95:
→ 直接走 System 2
elif budget_mode == "balanced" and confidence < 0.85:
→ System 1 判断 + System 2 验证（并行双路径）
第四层：观测反馈（Label Flywheel）
这是 AnyJev 给我最大的启发——决策历史本身就是训练数据。
# 每当 LLM 验证了 System 1 的决策
for state, question, decision, llm_verdict in history:
if decision.confidence < 0.95 and decision.choice != llm_verdict:
# 收集纠正样本
anyjev.observe(question, state, llm_verdict)
# AnyJev L2 头在 30 个新标签后自动重解
随着时间推移，越来越多的「低置信度→LLM 验证」样本反馈回 AnyJev 的训练池，System 1 的覆盖率和置信度持续提高——闭环改进。
具体实现路径
我设计了三种集成模式，从简单到复杂：
模式 A — Laya 前置过滤（最简单）
输入 → Laya 护栏（33ms） → 拦截（恶意/违规）→ 拒绝
→ 放行 → LLM 处理
适用：内容安全、输入护栏、Prompt 注入检测。Laya 的 guardrails 工作流正好匹配——33ms 拦截大部分问题，只有通过了的请求才交给 LLM。
模式 B — AnyJev L0 零成本消偏（零标签）
输入 → LLM → 输出
↑
AnyJev L0（零标签消偏）
适用：用 LLM 做结构化输出（JSON mode）时，L0 消除选项顺序偏差。不需要任何训练数据，只加 K 次循环移位 prefill，翻车率从 23% 降到 7%。
模式 C — 全栈 System 1 + System 2（推荐架构）
┌──────────────────────────┐
│ Agent Gateway │
│ (MCPZERO / 自定义) │
└────────────┬─────────────┘
│
┌────────────▼─────────────┐
│ 1. Laya Router (33ms) │
│ - 内容护栏过滤 │
│ - 问题类型分类 │
│ - 路由：System 1 or 2 │
└────────────┬─────────────┘
│
┌────────────────────┼────────────────────┐
│ System 1 Path │ System 2 Path │
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ Laya choice │ │ AnyJev L2 │ │ LLM (GPT-4o) │
│ (≤20 选项) │ │ (>20 选项) │ │ (开放生成) │
│ 33ms │ │ ~100ms │ │ 500ms+ │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
└───────────────────┼───────────────────┘
▼
┌──────────────────────────┐
│ 置信度门控 & 观测反馈 │
│ - confidence < 0.85 │
│ → LLM 验证 │
│ - 验证结果 → AnyJev 训练池 │
└──────────────────────────┘
实际数据模拟
基于现有基准数据，我对一个典型 Agent 工作负载（1000 次请求，含护栏、路由、分类、开放生成）做了粗略估算：
| 模式 | 仅 LLM | 仅 Laya | 混合架构 (模式 C) |
|---|---|---|---|
| 平均延迟 | ~800ms | 33ms | ~120ms |
| API 成本 | $5.00 | $0 | ~$0.50 |
| GPU 成本 | $0 | ~$0.30 | ~$0.40 |
| 准确率 | ~0.90 | ~0.76 (需微调) | ~0.93 |
| 置信度校准 | ❌ 不可靠 | ✅ ECE 0.08 | ✅ ECE 0.08 |
| 覆盖率 | 100% | ~40% (简单决策) | ~85%+ |
解读：混合架构用 120ms 平均延迟和 $0.90 总成本（约 LLM-only 的 1/5），获得了更优的准确率和校准置信度。这还不是上限——随着 AnyJev L2 头通过反馈持续改进，System 1 的覆盖率和置信度会继续提升。
七、工程启示：决策模型的正确位置
研究完这四条路线，我有三个核心感受：
1. 决策模型不是 LLM 替代品，是 LLM 的「减负器」
Agent 工作负载中，60-80% 的请求是分类/判断/路由类任务——内容审核、部门路由、紧急程度打分、安全护栏检查。这些不需要多步推理，不需要上下文理解，不需要创造力。用 LLM 做这些事就像用喷气式战斗机送外卖——能到，但大材小用。
决策模型的正确位置是在 LLM 前面，拦截并处理那些「反射级」决策。LLM 只处理真正需要它的任务。
2. 置信度校准是 Agent 安全的基础设施
这是我个人最在意的一点。在 MCPZERO 和 ClawGuard 的设计中，我们必须在代码层面上对决策的质量做断言——而不是相信模型输出的文本描述。
未经校准的 LLM 置信度是「听起来自信但数学上不可靠」的。AnyJev 和 Laya 的 ECE（期望校准误差）在 0.03-0.08 之间，这意味着 P(true) = 0.95 在统计意义上确实是 95% 的正确率。你可以直接写：
if decision.probability("fraud") > 0.95:
block() # 只有 5% 误报风险
这在 LLM 的原生输出里是做不到的。
3. AnyJev L0 的「零标签」理念值得行业推广
AnyJev 告诉我一个重要的道理：不需要数据也能提升决策质量。L0 用零标签降低了 23%→7% 的选项顺序颠倒率。这个思路可以推广到很多场景：
- RAG 检索排序中的选项偏见消除
- Benchmark 评估中的顺序偏差校正
- Agent 工具选择的偏好去偏
写在最后
从 9 月 15 日 Jev 发布到今天 9 月 25 日，十天之内，社区涌现了四条完全不同技术路线的 System One 决策方案。这个速度本身就说明了需求的存在——Agent 开发者已经意识到：不是每个决策都需要一次完整的 LLM 推理。
但我认为更大的机会在「融合」——不是选 Laya 还是 Jev，也不是用 LLM 还是决策模型，而是设计一个 Router，让两者在各自擅长的领域工作，用置信度门控保证安全，用观测反馈持续优化。
我在 MCPZERO Gateway 的原型中已经开始测试这种混合架构。初期结果告诉我：用 1/5 的成本和 1/8 的延迟，做到比纯 LLM 方案更高的端到端准确率和安全保障——这个方向值得认真投入。
未来一段时间我会继续深入这个方向。如果你也在研究 Agent 决策架构，欢迎在 GitHub 上讨论和交流。
📌 本系列相关文章：
- 《Jev 深度解析：TypeSafe AI 的 System One 模型》 — Jev 原理分析
- 《OpenJev 生态全景》 — OpenJev 开源生态
- 《Laya 上手完全指南》 — Laya 安装与集成
- 《生产级 Agent 部署架构》 — Docker Compose 全栈方案