Jev 这几天火得一塌糊涂，各种解读看完还是云里雾里：又是 System One，又是决策模型，还说”零幻觉”——听着像营销词。

我这两天把 TypeSafe 官方文档、创始人发布文和几篇解读翻了一遍。一句话：Jev 想给软件加上一种会理解语义的 if 语句。

它到底想解决什么问题

理解新技术，先想它试图解决什么问题。

我在 Agent 系列里一直用一个”技术选型 Agent”当例子，它干活时有一堆”小判断”：

  • 用户说”帮我选个任务队列”，是要快速出几个候选，还是要深度对比？
  • 检索回来 20 个 README 片段，哪几段值得塞进上下文？
  • Agent 想跑的这条 shell 命令，是只读、可逆，还是会毁掉线上？

这些判断有个共同点：需要看懂语义，但不需要深想。可我过去的做法，全是塞给生成模型，等它写一段带解释的文字，再把标签抠出来。又贵又慢，还偶尔在 JSON 前面来一句”好的，下面是结果”。

说白了这类判断就是 if else：

1
commit 在 main 分支，就触发部署；构建耗时 > 5 分钟，就告警。

可一旦条件变成对自然语言的理解——git push --force 算不算危险操作？这个库”看起来不太活跃”，到底还要不要选？——普通的 if 就写不出来了。

Jev 的答案：

  1. 把当前材料（state）和一组答案类型已定义的问题交给它
  2. 它返回每个问题的答案——是/否概率、备选项，或刻度分数——外加概率分布
  3. 走哪条分支，由你的代码决定

模型负责判断，代码负责执行。

为什么它不是”便宜的小模型”

小模型虽然更快更便宜，但还在沿用 LLM 的生成方式：一个 token 一个 token 往后写，哪怕只想要一个标签，也得先把答案”写”出来。

Jev 直接放弃了自由文本：你提前定义答案空间，它输出概率分布，多个问题并行评估。TypeSafe 为此重做了架构、采样和训练方法。所以它的快和便宜，主要不是”模型做小了”，而是把任务收窄到判断这一件事上，围绕这个目标重做了一整套模型。

System 1 / System 2

TypeSafe 叫它 System One 模型，名字来自卡尼曼《思考，快与慢》：系统 1 是快而直觉的判断（看一眼就知道对方在生气），系统 2 是慢而费力的推理（解复杂数学题）。

过去两年行业全在卷系统 2——Reasoning Model 花更多时间、更多 token 推理。副作用是：我们把大量系统 1 任务也塞给了系统 2 的大脑。判断一句留言是报障还是催更，真需要几千 token 的推理吗？

RLCD：校准决策的强化学习

训练路径也不一样。官方把后训练分成三条：

路径 优化什么 代表
RLHF 人类偏爱的回答 对话模型
RLVR 可程序验证的正确 推理模型
RLCD 校准的决策与概率 Jev

所谓校准：一批被赋 0.8 概率的预测，理想情况下约 80% 是对的。注意是统计意义，单次照样可能错。

官方宣言里有句话我很认同：他们在造 production 用的零件，不是全能上帝（Building prod, not God）——预期未来 99% 的 AI 交互是机器对机器，机器接口比聊天界面更重要。

名字里的赌注：杰文斯悖论

Jev 取自经济学家杰文斯：蒸汽机效率提升后，煤耗不降反升——更廉价的动力创造了新用途。

赌注是智能也走这条曲线：一次判断便宜到忽略不计（每百万输入 token 0.042 美元，输出免费）、快到几十到几百毫秒，软件就会疯狂使用它。过去一个普通的 if，现在可能变成一次 AI 判断；Agent 每走一步，先判断风险、该用哪个工具。

三种原语

类型 问什么 返回什么
Noul 这是真的吗？ 是/否的概率
Choice 哪个选项？ 选项 + 概率分布 + 置信度
Score 刻度上什么位置？ 加权分数 + 各等级概率 + 置信度

拿编码 Agent 的命令护栏举例——执行前先判风险：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
from typesafe_sdk import Choice, Noul, TypeSafeClient

with TypeSafeClient(model="jev-1.13.0") as client:
    result = client.system_one(
        state="git push --force origin main",
        questions={
            "risk": Choice(
                instructions="这条命令属于哪一级风险？",
                criteria={
                    "read_only": "只读取信息，不改变任何状态",
                    "reversible": "会改动，但可恢复，如写文件、git commit",
                    "irreversible": "不可逆或伤及生产：强推、删数据、改线上配置",
                },
            ),
            "touches_prod": Noul(instructions="这条命令会不会影响线上正在跑的服务？"),
        },
    )

risk = result.answers["risk"]
if risk.confidence < 0.5:
    escalate_to_human()          # 拿不准，找人确认
elif risk.choice == "irreversible":
    escalate_to_human()          # 高置信度的危险命令也不放行
elif risk.choice == "read_only" and risk.confidence > 0.9:
    run(command)                 # 只有又笃定又安全才自动执行

注意两件事：一是 criteria 里写清了每级风险包含什么，只给”安全/危险”两个标签，”改个本地文件”和”删库”就容易混在一起；二是模型给出的只是判断，要不要执行、以什么方式执行，全是代码里的门控逻辑。

Score 返回的是各等级概率的加权平均。比如给”候选库与需求的匹配度”定三级（明显不匹配 / 部分匹配需改造 / 开箱即用），模型给出 0.7、0.3 的分布，分数就是 1.3——落在两级之间，带着点”可能是更高一档”的权重。

真正决定用得好不好的，是这几条”题面功夫”：

  1. 留退路。选项盖不全就加 other / need_more，不留出口它只能硬选。
  2. Score 写情境，不写程度。”部分匹配，核心能力够但缺插件”可对照；”中等匹配”只能让概率摊平。
  3. Noul 的 0.5 不是”中等”。问”这个库维护得活跃吗？”得 0.5，意思是分辨不出。要衡量程度用 Score，要明确是非就写可判定的：”README 里是否写明支持 Python 3.12？”
  4. confidence 不是正确率。它是分布形状的统计量：集中→自信，分散→犹豫。别把它当单次正确概率用。
  5. instructions 写完整，criteria 写边界。ID 只给代码看。官方实测过：同一套评分标准，光秃秃的等级描述置信度 0.54，加上贴切示例升到 0.90——加个不相关的示例则几乎没变化。

几个关键习惯

判断归模型，执行归代码。 最容易踩的坑是把”模型觉得有帮助”当成”现在允许做”。这跟我之前写 Harness 时的原则是同一条边界的两半：能用程序检查的事，别靠模型判断；程序写不成规则的语义判断，也不必动用生成模型。

置信度三段门控。 高→自动执行；中→确认或补数据；低→转人工。阈值取决于答错一次的代价，从保守起步，在自己的数据上画”置信度 vs 准确率”再调。有个影子测试很说明问题：含义不明的 rm -rf 被判”不可逆”的概率 0.56、置信度只有 0.33——正是这个 0.33，让外层代码去找人，而不是轻信标签。

一次问完所有问题。 同一调用里各问题独立并行，多加问题几乎不增加延迟。选型时匹配度、许可证风险、学习成本、要不要自建——一次全问，用不到的答案让代码忽略就是了。官方 cookbook 里 13 个问题打包比串行便宜 12.2 倍、快 10 倍。真正需要第二次调用，只有一种情况：问题在拿到第一个答案之前构造不出来（比如第二轮要细读候选文档，且保留”一个都不选”的权利——第一名只代表”比另两个好”，不代表能用）。

复合评分，权重放代码里。 不问”这个库该不该选”这种大问题，而是各维度分开问再组合：

1
选型得分 = 0.5 × 需求匹配度 + 0.3 × 维护活跃度 + 0.2 × 文档完整度

排序不对味时，改一个系数重跑，不用重写提示词。

从牌堆里挑牌。 Jev 不会写字。想抽取一个值，先用正则或 LLM 捞出候选，再让它挑。直觉说”抽取 X”时，改写成：”这里是 X 的几个候选，是哪一个？”

state 只放需要的。 材料越臃肿准确率越低（官方也承认会 context rot）。分类一个库，别把它整个 issue 区都塞进去。能用代码算的别问模型：star 数、许可证条款、版本号比较，程序算又快又准。

它会在哪里翻车

官方每个版本发一页”参差性”（jaggedness），坦白列短板。这点先给个好评。重点几条：

  • 数学、计数、日期：统统不可靠。要日期就让它抽月份/日/年（带”未说明”选项），代码里构造真日期再比较
  • 字面化解读：它回答你写下的问题，不是你心里想的问题。盯着错答案想解释”我其实想问的是……”时，那句话就是缺失的半条指令
  • 间接推断：双重否定、连环跳转都掉准确率。直接指向 state 相关部分
  • 对抗性内容：操纵性文本能移动答案，上线前拿恶意输入测一轮
  • 类型正确 ≠ 业务正确：”零幻觉”指输出永远符合你的 Schema（官方说是结构性保证），不是业务判断零错误。返回值永远合法，照样可能选错
  • 问法一变，分布不保证对齐：同一个问题用 Noul 问、用二选一 Choice 问，官方实测能差一个数量级（0.22 vs 0.01 的 yes）。阈值别跨问法搬运
  • 中文要自测：官方写明英语是主训练语言，CJK 能处理但准确率不等

另外，模型、问题、criteria、阈值是一个整体——加个选项、改句描述都可能改变系统行为，当代码变更来测。

我会怎么用

最想先试的是命令护栏（上面那个例子）：影子模式阶段根本不放行，出错代价低，收益直观。其次是上下文分诊（Noul 过滤检索片段）和意图分流（把选型 Agent 的”快选 / 深比 / 转人工”从生成模型挪过来）。

起步流程不求快：

  1. 现有行为不动，Jev 在旁边影子跑，只记录答案
  2. 收几十条真实输入，标注预期答案，复盘错在哪
  3. 改问题、改 criteria、调阈值
  4. 只自动化低风险路径，拿不准的继续给人或更强的模型

对照组留三个：现有规则、要求短结构化输出的生成模型、Jev。生成模型只让它返回标签，别逼它写一大段解释再拿这个证明 Jev 更省。账也要算全：局部选对不一定抵消多一次网络调用，只有”模型怎么选、程序怎么执行、最后有没有做对”连起来记录，才知道值不值。

冷静看宣传数字

首页”快 193.6 倍、便宜 444.6 倍”来自官方 workflow evals，他们自己写明这属于现实收益里偏高端的情形；参考答案取的是两个顶级模型的平均，被比的 LLM 走的还是官方结构化封装。当上限看，不当承诺用。

再记几条：端到端 70–500ms 测自美国西海岸，跨洋要叠延迟；限流官方明说早期会动态调整；Jev 不可微调，领域适配全靠 state 和 criteria 写清楚；调过阈值就固定版本号别用 jev-latest，别名随发版漂移。

最后

LLM 是会推理、会写字的系统 2 大脑；Agent 是围绕它搭的餐厅；Jev 这类决策模型，是塞在各角落的快速判断件——领位员、品控闸门。不写菜单、不做大菜，但每个动作便宜到可以随便用。

智能不一定都要做得又大又重。拆轻、拆快、拆便宜，塞进每一个原本写不好的 if else——这是今年我看到最有意思的一条岔路。

它会不会成为 Agent 常见组件，还要更多实际结果说话。但在结论出来前，我们已经可以反问自己的系统：

流程里的每一步，到底在判断什么？该谁做——生成模型、决策模型，还是固定代码？

这个问题问一遍，通常比接入任何新模型都有收获。

基于 2026 年 9 月下旬官方资料整理：发布文、System One、AI Primer、Models、Jev 1.13 参差性。Jev 仍在早期，价格、限流、能力均可能变化，接入前请以最新文档和自己的测试为准。

AILLMAgent

站内搜索

没有找到内容！