前言

先看一个具体的浪费。

你的 agent 要决定"这条 shell 命令能不能直接跑"。为了这一个是非判断，你调了一次前沿大模型：两秒左右返回，几百到上千 token 的账单，外加一段你根本不看的解释性文字。答案其实只有一个字。

Jev 就是冲着这类问题来的。它是 TypeSafe AI 的决策模型，接口只做一件事：你给一份 state 和若干类型化的问题，它并行返回每个问题的概率答案。不写散文，不做推理展示，不在两次调用之间记住任何东西。有人把它概括成一句话——一个没有记忆、没有手、没有嘴的快速裁判。

但真正决定成败的不是 Jev 本身。是这个裁判周围的那套东西：你往 state 里放什么、把问题怎么措辞、选项怎么列、以及拿到概率之后你的代码做什么。这套东西叫 harness。

本文讲清楚三件事：Jev 的接口到底长什么样；一个 harness 由哪几部分组成、常见的六个"座位"是哪些；以及——这是最值钱的部分——它会怎么翻车，包括一个曾经传播量极大、后来被公开评测整个推翻的用法。

一、Jev 是什么：一个不做生成的模型

接口只有三个必填字段

按官方 API 参考，端点是 POST
https://api.typesafe.ai/v1/systemone，请求体就三样东西：

• state：要它判断的全部内容，字符串、对象或数组
• model：模型 ID
• questions：一个 map，key 由你自己起

有一点设计很干净：question 的 key 不会发送给底层模型，也不参与推理。它只是你拿回答案时的索引。你可以把 key 起成 risk、is_safe、same_event，答案就挂在同一个 key 下面。

三种问题原语

官方文档列了三种，可以在同一次请求里混用，并行求值：

Noul — 是/否问题，返回 0 到 1 的概率。

{ "type": "noul",
  "instructions": "两篇文章是否报道了同一件事？",
  "criteria": { "true": "同一事件、同一主体", "false": "不同事件或不同主体" } }

criteria 是可选的，但文档允许你用 true / false 两个子字段分别描述两极的含义。注意一个细节：Noul 的答案不返回 confidence 字段，只有一个 0–1 的概率值。

Choice — 从选项里挑一个，并给出完整分布。返回 choice（概率最高的选项）、probabilities（各选项概率）、confidence。选项上限 255 个，超了得先在代码侧过滤。

Score — 在有序量级上打分，返回概率加权的 score、legend（档位说明）、probabilities、confidence。至少 2 档，最多 10 档。因为它是加权的，分数可以落在两档中间——不要假设你只会拿到整数。

如果你是走 OpenRouter，还会看到第四种原语 Box，用来在图片里框出目标位置。它有个需要记住的限制：Box 不会报告"目标不存在"，所以判断存在性要另外配一个 Noul 问句。

成本结构决定了你该怎么用它

计费方式只有一条：按输入 token 收费，输出 token 免费。

这个结构直接推导出 harness 的第一条设计原则：把问题堆在同一次调用里。同一份 state 配 40 个问句，和配 1 个问句，输入 token 差不了几十个——因为问句本身很短，而输出不花钱。

有一份公开的复现实验给出了实测数据（单次采样，作者自己标注样本很小）：

• 1 个问题：0.53 秒，305 输入 token，$0.0000128
• 4 个问题：0.49 秒，346 输入 token，$0.0000145
• 12 个问题：0.53 秒，449 输入 token，$0.0000189
• 40 个问题：0.52 秒，817 输入 token，$0.0000343

从 1 个问题加到 40 个，延迟几乎没动，成本涨了不到三倍。同一份实验全程 60 次请求、38,931 token，控制台一共花了 $0.0014。

不过这里要打个折：作者明确写了"延迟几乎不随问题数增长"尚未被证明是恒定延迟，因为只有单次采样。更可靠的经验是这样——成本和延迟随问题数几乎不变，但随 state 大小线性增长。所以省钱的杠杆是压 state，不是省问句。

另外，厂商口径的"快 193.6 倍、便宜 444.6 倍"建议直接忽略：那份数据来自厂商自己构造的四个工作流评测，参考基线是前沿模型的平均答案，而且两个系统的输出物根本不同（Jev 输出有界决策，前沿模型输出更多 token）。厂商自己也承认可能存在偏差、公布的数字偏高。

二、harness 是什么：三段式

Jev 永远不行动。它看一眼你给的状态，从你列出的选项里挑一个，然后把一个概率还给你。除此之外的一切都发生在你的代码里。

所以一个 harness 就是三件事：

• 你往 state 里放什么 —— 它看不到的东西，它无法判断
• 你怎么问、怎么建选项 —— 选项是你给的，它只会指
• 你的代码拿到概率之后做什么 —— 这才是真正执行决策的地方

社区把这套东西归纳出九个反复出现的规则，其中五条我认为是硬约束：

规则一：菜单必须由代码构建，Jev 只负责指。 永远不要让它自己发明选项。而且每次动作之后要重建选项列表——否则它会从"昨天的菜单"里挑。

规则二：必须给退出选项。 没有"以上都不是"这一项，你就会拿到一个自信的错误答案。实践中可以把退出项写得具体，比如"没有提到任何设备或房间"。

规则三：把它不可能知道的事实喂给它。 它没有记忆，也没有时钟。有开发者报告，同一句问句在补上当天日期之后，答案从 0.35 跳到了 0.94。

规则四：全部塞进一次请求。 并行求值，输出免费。代价是各问题的答案互相看不见——问句之间不能有依赖关系。

规则五：在动手之前先定义"不确定"。 这是最容易被跳过、也最容易出事的一条。

三、六个座位

社区归纳了 Jev 在 harness 里最常坐的六个位置。注意这是分类框架，不是实测结论：

其中几项有具体的社区报告数字（均转述他人自述，未经独立复核，这里只作为量级参考）：选择器用 OCR 文本框当候选项，约每步 $0.003、1.5 秒，打字动作交回给小模型；分诊一次跑 14 项类型化检查，把概率映射成 BLOCK / 安全审查 / 小问题 / 合并，单 PR 成本 $0.00007，关键检查落在 0.35–0.65 就升级；门禁有开发者报告替换掉原方案后快 5–18 倍且更准。

六个座位有一个共同点：每一个都要显式定义"不确定"时走哪条路。是升级给人，还是升级给大模型，还是保守拒绝。没有第四条路——让 Jev 自己硬选一个，就是前面说的"自信的错误答案"。

四、跑通最小 harness

下面是一段骨架代码。它按官方 API 参考编写，我没有执行过（没有可用的 API key），请当作结构参考而不是验证过的实现。真正的重点在阈值那几行。

import os
import requests

API = "https://api.typesafe.ai/v1/systemone"

def ask(state, questions, model="jev-1.13.0"):
    """单次调用，批量提问。model 锁定版本号，不要用 latest。"""
    r = requests.post(
        API,
        headers={"Authorization": f"Bearer {os.environ['TYPESAFE_API_KEY']}",
                 "Content-Type": "application/json"},
        json={"model": model, "state": state, "questions": questions},
        timeout=30,
    )
    r.raise_for_status()
    return r.json()["answers"]

注意 model 那里锁的是具体版本号。文档示例里出现过 jev-1.13.0，OpenRouter 上当前是 typesafe/jev-1.14——模型在快速迭代，只要你的判断依赖阈值，就必须钉死版本，否则某天早上你的门禁行为会悄悄改变。

接下来是门禁本体：

RISK = {
    "type": "choice",
    "instructions": "这条 shell 命令属于哪一类？",
    "criteria": {
        "read_only":     "只读，不改变磁盘或任何远端状态",
        "write_local":   "会修改本地文件或目录",
        "write_remote":  "会影响远端服务、生产数据或他人",
        "destructive":   "不可逆：删除、覆盖、强制推送、清空",
        "none_of_these": "无法归入以上任何一类，或信息不足以判断",
    },
}

def gate(cmd):
    ans = ask(f"待执行命令：{cmd}", {"risk": RISK})["risk"]
    p = ans["probabilities"]

    # 不可逆操作：要求高置信度才拦，宁可多拦
    if p.get("destructive", 0) >= 0.85:
        return "BLOCK"

    # 中间区间和"无法归类"：一律交给人
    if p.get("write_remote", 0) + p.get("destructive", 0) >= 0.35:
        return "ASK_HUMAN"
    if p.get("none_of_these", 0) >= 0.35:
        return "ASK_HUMAN"

    # 放行需要高置信度：默认拒绝，而不是默认放行
    if ans["choice"] == "read_only" and ans["confidence"] >= 0.85:
        return "ALLOW"

    return "ASK_HUMAN"

四个设计点值得单独说：

• none_of_these 是一个真选项，不是一个兜底字符串。 它的概率达到阈值就升级，这是 harness 吸收"我没想到的情况"的唯一通道。
• 默认走向 ASK_HUMAN。 最后一行不是 return "ALLOW"。任何没被前面规则明确接住的情况都落到这里。
• 放行和拦截用不同的门槛。 拦截不可逆操作只要 0.85 就可以动手（宁可错拦），放行却要求 0.85 的 confidence 加明确的 read_only。
• probabilities 里各项不保证加起来是 1。 官方文档说 Choice 的概率是"和为 1 的浮点数"，但独立实测在跨问句场景下记录到 0.02 + 0.97 = 0.99，另一份分析甚至记录到 1.19。不要拿两个问句的概率做加减法，除非你验证过它们在你的场景里是一致的。

五、会翻车的地方

这部分来自一份公开的独立压测。作者把官方记录的失败模式逐项做了实测，九类里只有一类真的翻车——但那一类足以让整套设计失效。

翻车的那一类：让模型自己算数

测试场景：判断一个日期窗口是否超过 30 天，实际差了 42 天。

让 Jev 自己算 42 天是否大于 30 天，返回概率 0.26，判错。代码先算好 days=42 再喂进去，返回 0.99，判对。同一份 state、同一个问题，唯一的区别是算术由谁来做。

这条经验很硬：凡是日期比较、差值计算、计数，全部在代码里算完再喂进去。 作者在结论里把这条单独写了出来——日期/算术推理应该在代码里做，不要交给模型。

不过要补一句公道话：0.26 在 0.5 阈值下仍然判为"否"，所以这个结果并不支持"所有阈值下都会误判"的说法。风险在于你的阈值如果是 0.2，它就正好翻过去了。

其余几项（都通过了，但别当成保证）

同一份压测里：数 17 个项返回 0.99，16 和 18 都返回 0.01；双重否定返回 0.93；把信号塞进 120 句填充噪声里类别判定不变（1.0）；state 里埋的注入样本返回 0.01。

最后一项要特别小心——作者明确警告，抗注入表现比文档描述的要好，但这不应被视为安全保证。你自己的生产环境该有的防御一样都不能省。

三类设计层面的坑

置信度不等于正确。 官方 Score 文档的原话是 confidence "describes the model's answer, not a guarantee that the answer is right"。它描述的是模型对自身答案的确信程度，不是答案正确的概率。高置信度的错误答案完全可能出现——类型合法但语义错误，比如该判 fraud 却返回了 billing。所以"零幻觉"这种说法是站不住的。

上下文上限不等于有效上下文。 文档写明的是 262,144 token，但超过约 32,000 字节文本就会进入"更慢且更不准"的长上下文模式。上限是能塞进去多少，不是每个决策都有那么多有效信息。

版本会漂移。 前面提过：官方文档示例是 jev-1.13.0，OpenRouter 上当前是 jev-1.14。用 latest 这类别名意味着你的阈值会在某次发版后开始漂移。

六、一个被审计翻掉的座位

这一节讲一个已经失败的用法，因为它比任何成功案例都更有教育意义。

压缩（compaction） 曾经是 Jev 传播量最大的用法：给历史里的每次工具调用打分，丢掉不相关的，把上下文压下来。有转帖称某次会话从接近 100 万 token 降到了 86K。

数字很漂亮，传播很广，然后有人在公开的 Nous compaction 评测上把它审计了一遍。结论是：那套"学到的打分规则"实质上只有一条——删掉工具调用；而且它会递减退化，因为它只能删掉已经不在的东西。

同一次对照的数字：保留 115K token vs 55K token，召回 76% vs 79%——保留更少 token 的那一方召回反而更低。在相同预算下，Jev 排序与最简单的"最近优先"打成平手，77.8 对 77.8。

更彻底的一击来自另一个人的复现：他把 Jev 换成"永远回答 0"的模型，插件结果完全相同。

还有一笔被忽略的账：过滤历史会导致 prompt cache 失效。省下来的 token，可能又贴在缓存未命中上还回去了。

这里要说明的是，评测方自己也把结论落在"这是那个策略的问题，不是 Jev 的问题"。

但对我们写 harness 的人来说，从这件事里能拿走的方法论只有一条，而且是全文最重要的一条：

必须对着一个笨基线做对照。

具体做法很朴素：把 Jev 换成一个恒定的答案、换成一个抛硬币，再跑一遍。如果结果没变化，那 Jev 在这个位置上没有产生任何价值，你的 harness 只是在为它付钱。

这条规则比六个座位、九条军规都值钱。因为它是唯一能告诉你"这个座位到底该不该存在"的方法。前面那些通过了的压测项——计数、噪声、注入——也都是对照出来的，不是感觉出来的。

七、上线前的检查清单

接口层

• model 锁的是具体版本号，不是 latest 别名
• 问句批量合并进同一次调用（输出免费，问句几乎不加成本）
• state 体积做过压缩——成本随它线性增长，不随问句增长
• 处理了 429 / 529 的指数退避

选项层

• 选项列表由代码构建，模型不参与发明
• 每次动作后重建选项，不复用旧菜单
• Choice 的选项数不超过 255，超出的先在代码侧过滤
• 存在一个真实的"以上都不是"选项，且它的高概率会触发升级
• 模型不可能知道的事实（当天日期、外部 ID、计算结果）已由代码注入

决策层

• 默认路径是拒绝/升级，不是放行
• 不确定区间有明确定义，且升级到一个真实存在的下游
• 高风险动作和放行动作使用不同的门槛
• 日期、差值、计数全部在代码里算，不进模型
• 没有拿两个独立问句的概率做加减

验证层

• 已经用"恒答基线"对照过每一个座位
• 用真实标注样本量过 Brier 分数或校准曲线，而不只看 accuracy
• 读过一遍官方记录的九类失败模式，确认哪几类会落到你的场景里
• 清楚 confidence 不是正确率，有兜底的人工复核路径

最后一条建议和目标无关，和方法有关：先挑一个座位做，做完做对照，再决定要不要第二个。 六个座位一次上齐，最后你无法判断是哪一个在起作用——这正是压缩那个座位踩过的坑。

本文所有厂商自测数据（193.6 倍、444.6 倍、90% 准确率等）均未作为事实引用；独立测量数据已注明来源与样本限制；社区转述的他人自述数字均标注为"有人报告"。