决策模型

步骤 1四种原语，其中三种就是控制流。

TypeSafe 把 Jev 称为「System One」模型：它不写文字，只针对一段内容回答带类型的问题。一个请求包含一个 state（即内容）和一组 questions，每个问题以你自取的名字为键，类型是四种之一。在 Hacker News 上，一个自称公司 CEO 的账号把其中三种分别对应到它们所替代的语句——这是把整个产品装进脑子里最好用的方式：

• noul 就是 if。取自 Bernoulli（伯努利）：一个条件，答案是它成立的概率。
• choice 就是 match。选项和每个选项的描述由你提供，最多 255 个；你拿回每个选项的概率。
• score 就是排序键。你提供一组有序的档位描述，2 到 10 档；你拿回各档上的分布，以及按概率加权后在这把梯子上的位置。
• box 是例外。它在 Jev 1.14 中加入（截至 2026 年 10 月仅限预览版），用来在图像里定位一个区域。TypeSafe 自己也说，这是它第一个「并非纯粹为智能 if 语句而设计」的类型。

注意模型从不决定的东西：标签。每个选项、每个档位、每个条件，都是你在调用时写下的文字。没有训练过程，没有固定的分类体系：改一个分支，就是改一个字符串。下面是官方文档的快速上手示例，删减到两个问题：

# POST https://api.typesafe.ai/v1/systemone  (Jev quick start, trimmed to two questions)
{
  "state": "Our API integration started returning 500 errors on every request about 20 minutes ago, and we can't process any customer orders until this is fixed.",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this",
      "criteria": {
        "billing": "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales": "Pricing or account questions"
      }
    },
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

# response (docs example; values can change between Jev releases)
"department": { "type": "choice", "choice": "technical", "confidence": 1.0,
                "probabilities": { "technical": 1.0, "billing": 0.0, "sales": 0.0 } },
"is_urgent":  { "type": "noul", "noul": 0.99 }

像代码那样去读这个响应：department 是 match 的一个分支，is_urgent 是一个 if 的输入。模型填上的是两个条件，接下来发生什么，仍然由你决定。

步骤 2类型安全不是新东西，分布才是。

发布时最响亮的说法，是 Jev 不可能给出格式错误的答案——这没错：答案永远是你的某个标签，或者一个落在范围内的数字。但 TypeSafe 自己的发布文章也把那个 0% 类型错误率标注为「并非实测」——它由 schema 保证，而这恰恰是受约束解码早已为任何开启结构化输出的 LLM 提供的保证。发布讨论串里反复出现的那条反驳是对的：它不会吐出类型非法的值，却照样可能吐出一个完全错误的合法值。

受约束的 LLM 不会交给你的，是每次调用都附带的、针对你那组标签的一等公民级概率分布。这才是真正的产品：一个分支如今可以有三种结局——执行、询问、升级——由概率质量的分布形态来决定。文档里有两个细节值得留意：

• confidence 不是第二意见。它是 probabilities 的确定性函数；对 choice 而言是 (n·p_max − 1)/(n − 1)，只看得到排第一的选项。对两者同时设阈值，等于对同一个东西设了两次阈值。
• noul 根本不返回 confidence 字段。概率就是全部答案；接近 0.5 的值，就是模型在说它拿不准。如果你想要一个余量，文档建议用 abs(p − 0.5) × 2。

「已校准」是厂商的说法，而截至 2026 年 10 月，还没有任何分布内的校准数据公开。唯一公开的数字来自一项超出本来用途的学术测试——让 Jev 给另一个模型的答案打分：ECE 0.133，AUROC 0.666，而一个经过训练的校准器是 0.868。所以阈值是你的活儿，要用你自己的标注数据来定——方法见不确定性与校准，操作流程见决策模型阈值。

步骤 3它的短板，恰好是代码的长项。

TypeSafe 为 Jev 1.13 发布的「锯齿性」（jaggedness）页面（最近审阅于 2026 年 10 月 2 日）列出了它会失手的地方。几乎每一条，都是普通程序能做得完美无缺的事。

• 计数与算术。「Jev 不是计算器」——它「认的是答案的形状，而不是在逐个清点」。计数、求和、比较，都放进代码里。
• 日期与时间。它「把日期当文本读，而不是当有序的量」。在代码里解析日期、比较日期，只问模型这个比较结果意味着什么。
• 间接引用。双重否定、「属性的属性」式的问题。在代码里把查找做完，让问题直指那一个要紧的字段。
• 庞大而嘈杂的 state。无关细节越堆越多，准确率就越往下掉。先过滤；只发送问题真正需要的部分。
• 选项顺序。choice「偏向排在最前面的选项」。在代码里打乱选项顺序，检查答案是否保持不变。
• 对抗性 state。state 就是数据，模型并不会把它当作敌意内容看待。HiddenLayer 演示了一则注入到页面里的广告劫持了浏览器智能体的结账决策；另一项研究发现，注入文本会挪动概率，却很少翻转排第一的答案（在自适应攻击下，攻击成功率从 1.8% 升到 3.5%）。不管哪种，这都是提示词注入，防线在模型之外。

由此得出设计规则：代码负责计算，模型负责判断。问题发出之前，凡是能确定性完成的计数、日期比较、查找和过滤都已经做完，剩下的只是规则难以刻画的判断——这条消息是不是带着火气，这段文字有没有用，这条命令有没有风险。一个仍然包含算术的问题，是调用方的 bug。

步骤 4它在智能体里的位置，以及如今还有谁在卖。

既然它替换的是分支，决策模型就该待在智能体的分支点上，而绝不进入负责规划与写作的那个循环：

• 路由。交给哪个处理器、哪个队列、哪个模型——就是模型路由里那条静态 switch，只是附上了概率，让余量小的请求可以走昂贵的那条路。
• 工具调用守卫。LangChain 的实验性 AutoModeMiddleware 借助 Jev 标记有风险的待执行工具调用（比如 bash），并在执行前将其拦下。
• 上下文过滤。GPT-Researcher v3.7.0（2026 年 9 月 26 日）对每段抓取来的文字按其对问题的有用程度打分，只保留有帮助的那些——并且在没有密钥或 Jev 调用失败时，回退到 BM25 关键词排序。这个回退，正是值得照抄的模式。
• 轨迹检查。针对智能体轨迹中某一步提出是非题：工具结果是否回答了请求，回复是否遵守了策略。把它们用来筛选需要人工复核的样本，而不是当作评分器——上面那个超出本来用途的测试，正是这种用法。

Jev 于 2026 年 9 月 15 日发布，不到三周就成了一个品类。Cloudflare 发布了开放权重的 Clef（10 月 1 日），称其「完全兼容 Jev API」；Perplexity 发布了同样开放权重的 pplx-decider-v1-27b；OpenAI 的 Decisions API 提供 predicate、choice 和 score 三种类型，于 10 月 6 日进入公开测试。有意思的分歧在请求形态上：Jev 的 state 加带键的 questions 正在成为别人照搬的事实标准，而 OpenAI 选择了由具名问题组成的数组，以及自己的一套术语。在这个形态外面包一层薄薄的适配器，换供应商就始终只是改一下配置。正面对比把这四家并排摆在了一起。

延伸阅读：可观测性讲怎么记录决策，护栏讲工具调用守卫放在哪里，小模型与本地模型讲微调这条替代路线。