决策模型 + LLM 混合架构：Jev、OpenJev、AnyJev、Laya 四大 System One 方案横评与融合设计

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

上周我分别写了 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 全栈方案

AnyJev on AI博士 万戈