Jev / System One：把判断做成软件原语¶
调研快照：2026-09-26。Jev 是 TypeSafe AI 在 2026-09-15 公布、目前 early access 的首个 System One 模型；下面区分官方事实、厂商自述和本 Wiki 的工程判断。
一句话理解¶
生成式 LLM 输出字符串，Jev 接收一段 state 和若干个类型化 question，返回软件可以直接消费的结构化决策。官方把它定位为“决策而不是字符串”，并强调每个结果带概率/置信度；这不是把 LLM 的 JSON mode 换个名字，而是把问题空间限制在预先声明的类型内。
state（工单、文档、页面、trace）
-> typed questions
-> Choice / Score / Noul
-> probability + confidence
-> 代码路由、过滤、升级人工或调用生成模型
三种原语¶
| 原语 | 问题形式 | 输出 | 典型用途 |
|---|---|---|---|
Choice |
从给定选项中选一个 | choice、每个选项概率、confidence | 工单分类、模型路由、工具选择 |
Score |
按有序 rubric 打分 | score、分布、confidence | 风险、相关性、严重性、质量 |
Noul |
某个命题是否成立 | 0 到 1 的 yes/no 概率 | 审核门、jailbreak、是否需要人工 |
官方文档说明三种问题可以在一次 API 调用中混用，并针对同一 state 并行评估。问题应尽量原子化：复杂判断拆成多个独立问题，再由普通代码组合。
它和普通 LLM 有什么不同¶
| 维度 | 生成式 LLM | Jev / System One |
|---|---|---|
| 目标 | 生成对人有用的文本/代码 | 给软件一个受约束的判断 |
| 训练叙事 | RLHF、RLVR、SFT、推理 RL 等组合 | TypeSafe 宣称 RLCD（Reinforcement Learning for Calibrated Decisions） |
| 采样 | 自回归逐 token | TypeSafe 宣称并行采样/一次查询输出多个决策 |
| 输出 | 字符串，需解析和校验 | 预先声明的 Choice/Score/Noul |
| 不确定性 | 常需另问，且可能过度自信 | 每个结果附概率或 confidence；仍需校准验证 |
| 擅长 | 长文、代码、计划、开放式推理 | 路由、分类、评分、守门、筛选、判断是否升级 |
| 不擅长 | - | 写作、算术、长计划、需要新文本的任务 |
“类型安全”只保证输出落在类型和选项空间，不保证语义判断正确；“高 confidence”也不是事实正确性的证明。必须用独立标签、人审和校准曲线验证。
训练与数据：目前能说到哪里¶
TypeSafe 公开了新架构、并行 sampler 和 RLCD 的方向，但截至本快照没有公开 Jev 的参数量、训练 token、完整训练数据清单、权重或本地部署包。不要用社区猜测填这些空白，也不要把“不是 LLM”理解为“没有预训练或没有神经网络”。
官方对比页把 RLHF/RLVR 与 RLCD 的目标区分为“人类偏好/可验证奖励”与“校准决策”，但这是厂商的研究主张，不是已经被独立基准充分复现的结论。官网 workflow evals 使用固定代码工作流、窄问题和外部模型共识标签；其参考模型与任务设计都应在采购前独立复测。
与 Agent Harness 的组合¶
推荐链路¶
事件/用户状态
-> Jev：是否应该自动处理？选择哪个 worker？风险/优先级？
-> 普通代码：阈值、权限、幂等、预算、超时
-> 生成式模型：解释、写作、代码、长计划
-> Jev：检查 trace、引用、风险、是否升级人工
-> 人工批准 / 发布 / 回滚
适合本 Wiki 的落点¶
| FDE 场景 | Jev 问题 | 其他模型/代码职责 |
|---|---|---|
| Agent 路由 | 任务属于 coding、RAG、浏览器还是人工？ | router 执行、LLM 处理开放内容 |
| 工具守门 | 当前 tool call 是否允许、是否需要二次确认？ | policy engine 执行硬权限；不能只依赖模型 |
| RAG 质量 | 文档是否相关、是否需要升级检索？ | embedding、检索、生成答案 |
| 长任务 | 该步骤是否成功、是否重试、是否转人工？ | trace、重试上限、补偿事务 |
| Judge | 输出是否满足 rubric、风险等级是多少？ | 规则 grader、人审、独立生成模型交叉 |
FDE 试点设计¶
- 从一个窄决策开始，例如“support ticket 是否转给人工”，不要先做万能 Agent。
- 建立 300 至 1000 条带人工标签的 holdout，按时间和客户切分，避免同模板泄漏。
- 记录每个问题的概率、confidence、最终动作、人工改判和延迟；绘制 reliability diagram、选择性风险和成本曲线。
- 比较三条基线：规则、生成式模型 JSON、Jev；保持相同 state、阈值、工具和人工策略。
- 只在高置信度区间自动执行，低置信度进入人工或更强模型；阈值按漏放/误报成本而不是默认 0.5 决定。
适用条件：问题边界清晰、选项或 rubric 能预先声明、错误可以被审计和人工接管。
代价：early access 和托管 API 带来可用性、区域、隐私、网络与供应商锁定；还要付出标签、校准和回放工程。
验证方式：比较任务级成本、p95 延迟、覆盖率、选择性准确率、校准误差、人工接管率和越权率；不能只引用官网“更快/更便宜”图表。
不能用 Jev 代替的东西¶
- 不能代替权限系统、审批服务和确定性计算。
- 不能直接生成最终客服回复、代码、合同或长报告。
- 不能因为返回了概率，就跳过数据分布漂移、偏差和对抗样本测试。
- 不能把“zero hallucinations”理解为“zero wrong decisions”；类型正确和事实正确是两件事。
追踪字段¶
| 字段 | 当前记录 |
|---|---|
| Provider / status | TypeSafe AI；early access；托管 API |
| Model | jev-latest（正式环境必须记录实际 model ID） |
| Public recipe | System One、RLCD、并行 sampler；参数/token/权重未公开 |
| API primitives | Choice、Score、Noul；同一 state 可并行多问 |
| 价格/延迟 | 官网公开值会变化；本 Wiki 不把宣传值当采购承诺，每次复核页面和区域 |
| 下一次检查 | 2026-10-26，或模型/价格/API/安全文档有变更时提前检查 |
官方入口¶
- TypeSafe AI 官网
- System One 与 Jev 发布文章
- Jev 官方文档
- Jev Workflow Evals
- Jev 模型说明（独立解释页，需回到 TypeSafe 官方资料核对）