State + Typed Questions → Typed Probabilistic Answers
Jev 接收一个 state，以及一组 Choice / Score / Noul 问题；Choice 与 Score 返回完整概率分布和 confidence，Noul 返回 0–1 概率。多个问题可在一次请求中并行、相互独立地评估。
Deep Research TopicJev · System One2026-09-22 · v2
Jev：从“生成文本”切出一条机器原生的概率决策路径
本专题不把 Jev 当成“更小、更快的 LLM”，而把它当作一种新的软件智能原语来分析：代码拥有控制流，Jev 只负责窄而明确的模糊判断；多个判断并行输出概率，再由代码组合、阈值化、升级或回退。真正要验证的是：这种分层是否能让 Agent / AI 软件同时获得更低时延、更低成本、更稳定的控制边界，而不牺牲端到端正确率。
一、核心结论：Jev 的价值不是“会回答”，而是“能被代码可靠消费”
把已证事实、LRI 技术判断和待验证假设分开。
代码拥有控制流，模型只承担“可编程常识判断”
TypeSafe 明确建议：确定性规则、side effects、workflow 由代码负责；Jev 只插在无法用刚性规则表达、又需要理解非结构化状态的判断点。
最像“神经化的软件原语”，而不是 Agent
传统软件用 bool / enum / number 组成控制流；Jev 在这些基础类型上增加“带概率的语义判断”。它不自己决定下一步，不持有目标，也不负责执行副作用。
最可能改变的是 Agent Control Plane
Planner 仍可由大模型承担，但 tool routing、context selection、memory retention、risk gate、completion check、candidate rerank 等高频小判断可下沉到 Jev；系统从“单大模型串行思考”变成“LLM + 并行 fast judge + deterministic code”。
“结构可靠”不等于“语义可靠”
Jev 可以从机制上避免 schema 外输出，但仍可能在合法选项中选错、错误评分或在分布外状态上高置信出错。生产价值取决于 calibration、OOD 行为和端到端错误传播。
两数量级优势是否可迁移到真实 Agent
官方 workflow eval 给出极强速度/成本优势，但真实 Agent 往往有长上下文、状态构建、网络 RTT、工具执行和多阶段依赖。需要测“系统级收益”，不能只测单 API 调用。
一句话：如果 LLM 是“通用认知 CPU”，Jev 更像“高吞吐概率决策协处理器”。它是否重要，取决于未来 AI 软件里有多少认知步骤能被拆成原子、可类型化、可并行的判断。
二、模型定位：System One 到底切走了 LLM 的哪一部分能力？
不是按参数规模区分，而是按任务形状与输出接口区分。
| 维度 | LLM / Reasoning Model | Jev / System One | LRI 解读 |
|---|---|---|---|
| 主要输出 | 开放式 token/string | Choice / Score / Noul | 从“生成”改为“判断” |
| 控制流 | 模型可在 Agent loop 中决定下一步 | 代码预定义 workflow | 自由度换成可控性 |
| 问题形状 | 可处理开放式、多阶段、长推理 | 原子、窄、明确、可类型化 | 需要主动分解任务 |
| 采样 | token-by-token 串行生成 | 多个 typed outputs 并行评估 | 吞吐优势来自任务形状变化 |
| 不确定性 | 通常需额外 prompting / calibration | 概率分布与 confidence 是一等输出 | 便于风险门控，但仍需域内校准 |
| 适合位置 | Planner、Generator、复杂解释 | Router、Judge、Verifier、Scorer | 更像系统组件而非总控智能体 |
不是“小 LLM”
TypeSafe 明确表示 Jev 不是 chat/code-completion 模型，也不能直接替换 Claude Code、Cursor 或 coding agent 的主模型。
不是 JSON Mode
JSON mode 仍然是字符串模型生成 token 后满足格式约束；Jev 的决策空间本身就是 typed primitive，输出结构是任务定义的一部分。
也不是普通分类器
它试图保留 frontier-model 级“通用语义判断”，而不是为每个 label space 单独训练一个 classifier；这正是最需要独立验证的核心主张。
三、编程模型：真正的创新可能是“把 prompt engineering 变成 workflow engineering”
官方文档反复强调 atomic questions、structured state、并行 fan-out 与 code composition。
离散动作空间
从显式候选集合中选一个，并返回每个候选的概率与 confidence。适合 tool/action/intent/route 的选择。
有序连续判断
给定 rubric levels，返回期望 score、各档概率与 confidence。适合风险、质量、优先级、相关性、严重程度。
概率布尔
对一个命题返回 0–1 值。适合 policy gate、事实检查、是否存在某性质；它没有独立 confidence，因为输出本身就是概率。
原则 1：一问只做一个判断
“这个工具调用是否安全且有用且符合用户意图？”应该拆成多个问题。宽问题把多个因子压成一个不可观察的内部推理；原子问题让系统可以独立调权、做 ablation、审计错误来源。
原则 2：一次问很多独立问题
同一个 state 上的多个问题可以一次 fan-out。这样“多维理解”不一定增加串行 round trip；这与 Agent 里逐步问大模型形成明显差异。
原则 3：组合逻辑留在代码
将 spam_risk、quality、priority 等高层决策由多个概率按显式权重组合。业务策略变化时改 coefficient / threshold，而不是重新写一个巨型 prompt。
原则 4：只提供当前判断需要的 state
TypeSafe 建议避免把所有历史上下文塞进去；结构化 state、明确字段路径、减少无关内容。这实际上把 context engineering 从“越长越好”改成“局部状态最小化”。
LRI 观察：这套方法把 AI 工程重心从“让模型自己推理整个流程”转成“人/代码先定义计算图，再把不可编码的语义节点交给模型”。它牺牲一部分通用性，却获得可观测、可组合、可回放和可测试性。
四、概率与置信度：这是 Jev 能否进入生产的真正支点
confidence 不是装饰字段，而是第二条控制轴。
保留所有候选的相对可能性
Choice/Score 不只返回最终值，还返回完整概率分布。应用可以自定义 entropy、margin、top-2 gap 等指标，而不必接受单一 confidence 定义。
对分布形状的压缩统计
官方 confidence 来自概率分布：分布越集中，confidence 越高。它不是额外的一次“模型自评”，而是由输出分布计算得到。
不同动作使用不同阈值
读操作、可逆动作、不可逆副作用不能共用一个阈值。低风险路径可自动化，高风险路径需要更高置信或二次确认。
官方“calibrated”必须在你的数据上重新验
真正需要画 reliability curve：例如 confidence 0.8 的样本是否真的约 80% 正确？不同 domain、语言、输入长度、类别不平衡、OOD 状态都可能改变校准。
生产判断：最危险的不是“模型不知道”，而是“模型不知道自己不知道”。Jev 的架构价值建立在不确定性可用这一前提上，因此 ECE/Brier/NLL、coverage-risk curve 和 selective accuracy 应成为第一等指标。
五、Agent Runtime 分层：Jev 最可能插入哪些控制面？
从单大模型 Agent 转向异构智能流水线。
Layer 1
Deterministic Code
权限、状态机、事务、预算、side effects、硬规则。能用代码解决的不要交给模型。
Layer 2
Jev Fast Decision Plane
tool routing、candidate ranking、memory/context selection、risk scoring、policy checks、completion signals。
Layer 3
LLM Reasoning Plane
复杂规划、开放式分析、代码生成、长链推理、解释与异常处理。
Layer 4
Escalation / Human
低置信度、高风险、分布外、争议任务进入更强模型、专用 verifier 或人工。
1. Tool Router
从 10–100 个工具/Skill 中选择候选；高置信直接走，低置信回退 Planner。关注高基数 choice 的退化与 255 cardinality 边界。
2. Tool-call Preflight
并行问：是否符合用户意图、参数是否疑似缺失、是否高风险、是否需要确认。代码按风险组合多个概率。
3. Context / Memory Filter
对候选上下文独立评分“当前步骤是否需要”“是否可能影响决定”，减少主 LLM 输入并降低 context rot。
4. Verifier / Completion Gate
在测试、结构化规则之外，补一个语义完成度判断；不能取代 deterministic test，但可以发现“测试绿了、需求没满足”。
5. Cost-quality Cascade
Jev 先判，低置信或高风险才升级 reasoning model；目标指标不是 Jev accuracy，而是 cascade 的 selective accuracy、escalation rate 和总成本。
6. Parallel Evidence Triage
对大量 source / item / event 做 relevance、novelty、risk、entity-match 并行判断，再把少数高价值项交给深度 Agent。
六、技术比较：什么时候 Jev 值得存在？
真正的竞争对手不只是大模型。
| 方案 | 优势 | 弱点 | 适合场景 | Jev 的差异点 |
|---|---|---|---|---|
| 规则 / 状态机 | 确定、便宜、可证明 | 难理解模糊语义 | 硬约束、权限、事务 | 补“规则写不出的常识” |
| 传统分类器 / XGBoost | 便宜、可本地、稳定 | 每任务需数据/训练 | 固定 label、有大量标注 | 主张跨任务 zero/few-shot 通用判断 |
| Embedding + 阈值 | 简单、高吞吐 | 复杂语义边界弱 | 检索、相似度、去重 | 可表达条件与 rubric，而非仅距离 |
| Cross-encoder / reranker | 相关性判断强 | 输出语义较窄 | ranking / relevance | 统一 Choice/Score/Noul 多种判断 |
| 小型 LLM + JSON schema | 通用、生态成熟 | 仍是串行 token 生成 | 结构化提取与轻推理 | 非字符串采样 + 原生概率输出 |
| Frontier LLM / reasoning model | 能力上限高、开放式 | 慢、贵、自由度高 | 复杂规划、生成、异常处理 | 用较低自由度换吞吐和控制 |
关键决策规则：若任务可以用规则解决，优先规则；若是稳定固定分类任务且有训练数据，传统 ML 可能更优；若需要开放式推理，使用 LLM；Jev 最有价值的夹层是“规则写不清、又不值得启动完整 reasoning model”的高频语义判断。
七、官方 Benchmark 应该如何解读？
保留厂商结果，但把测试方法、优势来源与偏差同时展示。
Vendor
70–500 ms
官方公开端到端范围，并说明当前服务位于美国西海岸，发布评测多从当地笔记本运行；网络位置会影响观测。
Vendor
$0.042 / MTok input
官方价格为 $42 / billion input tokens；输出被描述为“too cheap to meter”。价格真实性可观察，但长期可持续性官方也承认需要时间证明。
Workflow Eval
193.6× faster
来自 TypeSafe 自建 workflow eval，官方明确称这可能是现实收益的高端。
Workflow Eval
444.6× cheaper
同一方法学下的成本优势；参考答案来自高端外部模型平均，而非真实人工 ground truth。
值得认可的地方
TypeSafe 主动公开了不少不利 caveat：短输入对 Jev 有利、workflow 由自身能力团队设计可能有 bias、参考答案偏向外部模型、LLM wrapper 会影响比较、真实收益可能小于 headline 数字。方法透明度比只报单一数字更好。
仍不足以回答的问题
缺少广泛第三方基准、真实业务 ground truth、跨语言/长输入/OOD/类别不平衡评测、校准曲线、重复采样稳定性、p95/p99 latency，以及复杂 Agent cascade 的端到端 success rate。
工作流先分解
多个独立问题 + 概率组合，本身就是 Jev 的最佳任务形状；“让一个 LLM 一次性想完”天然承担更多串行生成成本。
比较的是决策，不是生成
放弃字符串生成后，Jev 不需要支付解释、CoT、格式输出的 token 成本。这是合理架构差异，但不能外推到所有 LLM workload。
Reference ≠ Ground Truth
用强模型平均概率当参考可以测“像不像强模型”，但不是业务正确性；真实自动化最终仍需 human labels、outcomes 或可验证结果。
八、失败模式与工程边界
不要只描述“能做什么”，还要明确“怎样会失败”。
合法但错误的答案
类型永远正确不代表语义正确；错误可能更隐蔽，因为系统不再遇到 parse error，而是直接执行错误的合法分支。
Question decomposition bias
系统行为高度依赖人如何拆问题、定义候选、rubric 与权重。遗漏关键维度可能形成“结构化盲区”。
Closed-world option set
Choice 只能在给定选项中选。必须提供 other / none / escalate，或通过低 confidence 检测“选项都不好”。
Distribution shift
校准可能随语言、领域、数据源和时间漂移；固定 threshold 不能永久有效，需要周期重估。
High-cardinality routing
官方披露 Choice cardinality 上限 255；更高候选数需要两阶段 scoring + explicit choice，延迟和误差结构都会变化。
State construction cost
如果为了 Jev 先做昂贵 RAG、序列化大量上下文、跨服务汇聚状态，模型本身 100ms 并不等于系统 100ms。
Probability misuse
概率不是业务风险本身。0.9 的“正确概率”不能直接变成 0.9 的执行安全度；损失函数、动作代价和不可逆性必须由应用层建模。
Observability debt
并行几十个判断后，必须记录 state version、question version、probabilities、threshold、最终 branch，否则失败复盘会比 Agent prompt 更难。
Vendor/API dependency
当前仍是较早期 hosted model；可用性、区域、版本漂移、数据治理和长期价格都应进入部署决策。
九、补全后的实验计划：从“演示快”升级到“证明架构价值”
四个主实验 + 三个横向压力维度，形成可复现 acceptance matrix。
| 实验 | 对照组 | 核心指标 | 关键验收 |
|---|---|---|---|
| E1 Tool Router | 规则 / embedding / 小 LLM / frontier LLM | Top-1、coverage、selective accuracy、P50/P95、$/1k decisions | 在相同错误预算下显著降成本/时延 |
| E2 Context Filter | 全量上下文 / embedding top-k / LLM selector | token reduction、downstream task success、miss rate | 减少上下文但不降低端到端成功率 |
| E3 Semantic Verifier | 无 verifier / LLM judge / deterministic tests | FAR、FRR、Brier、ECE、escape defect | 补足 deterministic tests 发现不了的语义缺陷 |
| E4 Cascade | 全量 frontier LLM | success、escalation rate、latency、cost | 同等 success 下，显著减少 reasoning-model 调用 |
A. Calibration
绘制 reliability diagram、ECE、Brier、NLL、risk-coverage curve；按语言、domain、action risk 分桶。
B. Robustness
模糊输入、缺字段、矛盾 state、对抗提示、OOD、长 state、类别极不平衡、候选相似度高。
C. Runtime
本地到服务 RTT、并发吞吐、P95/P99、批量问题数、state size、question count、版本稳定性。
终局指标：不要追求“Jev 单模型 accuracy 胜过大模型”。真正的成功标准是：在业务可接受错误预算下，异构系统的 端到端成功率 × 吞吐 / 成本 / 尾时延 明显优于单大模型方案。
十、持续洞察计划：未来版本要补什么？
把一次性文章变成可持续专题。
P0 · 独立实测
拿到 API 后优先完成 E1 Tool Router 与 calibration 基线；这是决定是否继续投入的最小实验。
P0 · 第三方证据
持续搜集非 TypeSafe 团队维护的 live benchmark、生产案例、失败报告，防止专题长期停留在 vendor narrative。
P1 · Agent 集成
在实际 Agent runtime 中接入 router / verifier / context filter，记录完整 trace 与 cascade economics。
P1 · 版本追踪
监控 jev-latest / pinned version、API schema、SDK、价格、区域、cardinality、context/state limits 与 release notes。
触发专题升级的信号
出现公开权重/架构论文；独立第三方大规模 benchmark；正式 GA/SLA；主要 Agent framework 原生集成；可复现 calibration 数据；多区域低延迟服务。
触发专题降级的信号
第三方测试显示 calibration 失真；实际 cascade 无系统收益；复杂状态需要大量 prompt engineering；版本漂移导致行为不稳定；传统 ML / 小模型在主要场景全面更优。
十一、证据来源与等级
当前证据以官方一手资料为主，因此专题状态定义为“技术机制已清晰，独立效果验证不足”。
Primary · Product/Research Announcement
Introducing System One Models & Jev
发布时间、RLCD、parallel sampler、70–500ms、价格、workflow eval、cardinality 及官方 caveats。
Primary · DocumentationTypeSafe Introduction
Choice / Score / Noul、并行独立问题、atomic question 与 typed output 的正式语义。
Primary · Architecture GuideHow to build with TypeSafe
代码控制 workflow、原子分解、结构化 state、并行 questions、code composition、confidence routing。
Primary · Confidence SemanticsConfidence
概率分布、confidence 计算语义、风险阈值与生产 gating 建议。
Primary · APIQuick Start / API Contract
POST /v1/systemone、jev-latest、示例响应中的 jev-1.13.0、Python SDK 与 usage fields。
Primary · BoundaryJev with coding agents
官方明确：Jev 不是 coding-agent 主模型，而是嵌入应用/Agent 内的结构化判断组件。
证据边界：目前可以高置信描述“产品接口和官方设计原则”，可以中等置信推导“Agent Runtime 的潜在架构位置”，但不能把官方 workflow eval 当成已独立确认的普适性能结论。下一版的质量提升主要依赖真实 API 实验与第三方证据。