Jev 深度使用手册：State 设计、三种原语、置信度阈值与九类失败模式

导读：Jev 是 2026 年 9 月讨论度最高的模型，但它的用法和聊天大模型几乎相反——你不「给它写」，你「向它问」。这份手册不解释它为什么火（原理与热度复盘见站内《不说话的模型，正在接管 Agent 的 80% 决策：Jev 深度拆解》），只解决三件事：它是什么形状的组件、怎么接进代码、哪些坑一定会踩。文中代码是可直接改用的最小骨架，末尾附一页速查表。

0. 30 秒决策卡

该用 Jev	不该用 Jev
分类打标（邮件/工单/论文分箱）	生成文本、写代码、解释推理过程
路由分派（派给谁、走哪档模型）	需要多步骤长链推理的任务
打分排序（严重度、相关性、质量）	需要精确数字：计数、算术、日期比较
是非判断（是否含隐私、是否要求退款）	业务零容忍且没有人工兜底环节
护栏校验（工具调用是否危险）	对抗输入为主、要求当前版本鲁棒
低置信度转人工的中间态	把「模型说有把握」当成「事实正确」

一句话判据：当一个判断的正确答案是「选项 / 等级 / 是-否」而不是「一段话」时，才轮到 Jev。

1. 先把三个概念对齐

1.1 System One 是什么

名字取自卡尼曼《思考，快与慢》：System 1 是快速、直觉、不费劲的判断系统，System 2 是缓慢、刻意的推理。TypeSafe AI 把「软件里高频发生的快判断」单独切出来做成一类模型，Jev 是其中第一个。

发布方：TypeSafe AI（旧金山，2024 年成立）
团队：CEO Diogo Almeida（前 OpenAI 研究员，RLHF / InstructGPT 作者之一），联合创始人 Erik Gafni、Sasha Sheng
时间线：2026-09-15 早期访问 + 公布 4000 万美元种子轮（DCVC 领投，估值约 2 亿美元）；9 月 20 日前后取消候补名单、全面开放
训练：官方称基于 Transformer，训练数据 100% 为合成数据，训练目标为 RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习）——优化的是「说自己有多大把握，这个概率到底靠不靠谱」，而不是「人类更喜欢哪个回答」

⚠️ 口径提醒：官方未公开参数规模、网络结构与技术论文；官网首页的 193.6 倍更快 / 444.6 倍更便宜来自其自建 workflow 评测，TypeSafe 自己在发布文中承认任务由其模型能力团队设计、可能存在偏差，且参考答案取的是 GPT-6 Astra 与 Fable 5.1 的平均值。请当作「数量级参考」，不要当成交付 SLA。

1.2 请求的形状：state + questions → answers

Jev 不复用聊天模型的 messages 对话结构，而是一个三件套：

组成	含义	你的责任
`state`	要评估的内容：一段文本、一个 JSON 对象、或数组	决定喂什么、怎么组织
`questions`	一个有名字的映射，每个问题带类型（Choice / Score / Noul）	决定问什么、怎么措辞
`answers`	按你给的 key 返回的类型化结果（含概率/置信度）	决定怎么用、阈值多少

两个结构性事实，决定了后面所有写法：

一次请求内所有问题共享同一份 state，且并行评估。加问题几乎不增加响应时间，只多花一点输入 token。所以「多问几个，代码里忽略用不到的」通常是划算的。
同请求内的问题彼此独立。A 的答案不会成为 B 的上下文。真正的依赖只能靠发第二次请求解决。

1.3 与 LLM 的分工

维度	生成式 LLM	Jev
输入侧重	非结构化文本，序列化消息	非结构化 state，结构化程序状态
输出	字符串，需解析 + 校验 + 防跑偏	类型安全的结构化值 + 概率 + 置信度
采样	自回归，逐 token 顺序生成	并行，一次查询产出全部答案
成本（官方）	输入 $0.20–$10 / MTok，输出约为输入 5 倍	输入 $0.042 / MTok，输出免费
延迟（官方）	前沿模型端到端 3–329 秒	70–500 毫秒
置信度	即便被要求估计，也普遍过度自信且不稳定	每个 Choice / Score 答案都带校准概率与置信度
典型场景	人机协作：对话、Copilot、编码 Agent	智能 if 语句、大数据 map-reduce、实时应用、全链路校验

工程上的正确姿势不是「二选一」，而是分工：开放生成与长链规划交给大模型，高频结构化判断下沉给决策模型，确定性逻辑留在代码里。

1.4 「零幻觉」到底指什么

官网最醒目的 Zero Hallucinations 常被误读。它指的是：模型不可能跳出你预先定义的类型空间。你规定只能在「猫 / 狗 / 鸟」里选，它绝不会返回「大象」，也不会吐出解析器接不住的文字——所以类型错误率可以是 0%。

但类型正确 ≠ 判断正确。输入明明是猫，它返回「狗 97%」，一个 type error 都没有，业务却全错了。真正需要你兜底的，是判断层面的正确率与你的阈值策略，而不是格式。

2. 十分钟跑通第一次调用

2.1 端点与模型名

HTTP 端点：POST https://api.typesafe.ai/v1/systemone
模型字段："model": "jev-latest"（SDK 默认值）
可用模型列表：GET /v1/models；带版本号的 ID（如 jev-1.13.0）无论是否出现在列表里都可直接使用

2.2 curl 版

curl https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "Hi, I have been trying to connect my Stripe account for 3 days and it keeps failing. I am losing sales. Please help ASAP.",
    "questions": {
      "is_urgent": {
        "type": "noul",
        "instructions": "The message conveys urgency or time-sensitivity"
      }
    }
  }'

{
  "model": "jev-1.13.0",
  "answers": {
    "is_urgent": { "type": "noul", "noul": 0.999 }
  },
  "usage": { "...": "..." }
}

0.999 就是「是紧急消息」的概率，直接进你的 if。

2.3 Python SDK 版

pip install typesafe_sdk

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()  # 读取 TYPESAFE_API_KEY

ticket = (
    "Hi, I've been trying to connect my Stripe account for 3 days "
    "and the integration keeps failing. I'm losing sales. Please help ASAP."
)

response = client.system_one(
    state=ticket,
    questions={
        "department": Choice(
            instructions="Which team should handle this",
            criteria={
                "billing": "Payment or subscription issues",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
            },
        ),
        "frustration": Score(
            instructions="How frustrated the customer appears",
            criteria=[
                "Calm, just stating facts",
                "Frustrated but civil",
                "Very angry, strong language",
            ],
        ),
        "is_urgent": Noul(
            instructions="The message conveys urgency or time-sensitivity",
        ),
    },
)

print(response.answers["department"].choice)     # "technical"
print(response.answers["frustration"].score)     # 1.0
print(response.answers["is_urgent"].noul)        # 1.0

读响应：通用入口是 response.answers["<你起的 id>"]；SDK 另外提供 response.choices[...]、response.scores[...]、response.nouls[...] 三个快捷映射，按类型取用更省事。

2.4 版本与别名：调过阈值就必须锁版本

jev-latest 是别名，新版本发布时它会发生漂移——你这边一行代码没改，答案分布和置信度就可能变。官方建议很直接：如果你的置信度阈值是针对某个版本调好的，就固定那个版本号，按自己的节奏升级。

# 生产环境：锁版本
response = client.system_one(model="jev-1.13.0", state=..., questions=...)

同时建议把响应里的 model 字段（回报实际应答的版本化 ID）落进日志，出问题时能回溯是哪版模型给的答案。

3. 三种原语：Choice / Score / Noul

这是 Jev 唯一的「语法」。三个原语回答三种形状的问题，记住这张表就能覆盖 90% 的场景。

原语	回答的问题形状	你要提供的 `criteria`	返回值
Choice	从一组无序选项里选一个	选项 map（键=选项名，值=描述），最多 255 个	`choice`、`probabilities`、`confidence`
Score	落在一条有序谱系上的位置	有序数组，从低到高，2–10 个等级	`score`、`probabilities`、`legend`、`confidence`
Noul	是 / 否	可选的 `true` / `false` 定义	`noul`（0–1 的概率，无 confidence）

选型判据：答案无序 → Choice；答案有序 → Score；答案是是非 → Noul。 如果两种都像，选代码能直接拿来分支的那一个：Choice 直接映射到三个函数分支，Score 映射到一个阈值，Noul 映射到一个 if。

3.1 Choice：路由与分类的主力

请求结构（每个问题三个字段）：

{
  "type": "choice",
  "instructions": "Which team should handle this",
  "criteria": {
    "billing": "Payment or subscription issues",
    "technical": "Bugs or integration problems",
    "sales": "Pricing or account questions"
  }
}

返回结构：

{
  "type": "choice",
  "choice": "technical",
  "probabilities": { "billing": 0.02, "technical": 0.95, "sales": 0.03 },
  "confidence": 0.91
}

要点（都是踩过坑总结的）：

给全量选项，别给候选短名单。选项多花几个 token，但让模型有机会选对；先自己召回再让模型选，等于把召回错误转嫁成判断错误。
加上 other / none of the above 兜底选项。列表可能覆盖不全时，让模型有地方说「都不像」，而不是硬塞进最近的一类。
两个选项容易混，就把描述从字符串升级成对象。自定字段（名字随你起）比长句子更能拉开边界：

"criteria": {
  "return_policy": {
    "what": "问退货规则本身是什么",
    "not_for": "查询某笔退货的进度",
    "examples": ["你们支持 30 天无理由退货吗？"]
  },
  "return_status": {
    "what": "查询某笔具体退货的处理进度",
    "not_for": "询问退货规则",
    "examples": ["我上周寄回的包裹现在到哪了？"]
  }
}

层级分类要逐级链式，不要一把梭。面对深层目录或大分类体系，按层级串多个 Choice，并在每一层做 beam search（保留概率最高的 K 条路径），官方 Hierarchical Classification cookbook 有完整实现。
probabilities 比 choice 信息量更大。选项没选出唯一赢家时，confidence 会掉下来，这本身就是「该转人工」的信号。

3.2 Score：打分与排序

请求结构：criteria 是有序数组，从低到高；数组下标就是等级编号，从 0 开始。

{
  "type": "score",
  "instructions": "How severe is this bug",
  "criteria": [
    "外观或体验瑕疵，功能正常",
    "功能损坏，但存在绕过办法",
    "功能完全不可用，且无绕过办法"
  ]
}

返回结构：

{
  "type": "score",
  "score": 1.43,
  "probabilities": { "0": 0.0, "1": 0.57, "2": 0.43 },
  "legend": { "0": "外观或体验瑕疵…", "1": "功能损坏，但存在绕过办法", "2": "功能完全不可用…" },
  "confidence": 0.35
}

score 的计算方式值得记住：各等级编号 × 其概率，再求和（0×0.0 + 1×0.57 + 2×0.43 = 1.43）。它是一个概率加权均值，可以落在两个等级之间；confidence 低说明概率被摊平了。

看一组官方示例，直观感受不同输入如何变化：

输入	`score`	`confidence`
设置页导出按钮错位了几个像素	0.0	1.0
PDF 导出点了没反应，但还能导 CSV 自己转	1.0	1.0
PDF 导出一直转圈；有人说 CSV 还行，有人说也不行	1.11	0.84
导出按钮让 Safari 的设置页崩了，Chrome 正常	1.43	0.35
全组人今早都登不上，每次都 500	2.0	1.0

要点：

描述「情形」，不要描述「程度」。写「功能损坏但有绕过办法」，不要写「中等严重」。同一个 bug 报告，只给数字等级时模型会把它摊到 0 和 1 之间；给具体情形描述则稳定落在 0.0、置信度 1.0。
一个 Score 只测一个维度。描述里出现「准时、聪明又有经验」是在同时测三件事，高一项低一项的样本无处安放，置信度必然掉。拆成三个 Score，在代码里加权合成。
每个等级是被独立评估的。模型看不到等级编号，也不知道相邻等级是什么，所以「比上一级更严重」这种表述对它没有意义，描述里写数字也没用。
等级数量以「你能描述清楚」为限，3 个就很好，最多 10 个。别为了精细塞进你区分不开的等级。
顶端的罕见极端情形单独设一级。情感量表如果只到「非常愤怒」，那么辱骂和威胁会被挤在同一个高位；加一级「辱骂/威胁」，代码才分得开。
不要用 score 反推精确数值。它的等级数值校准很弱，score=1.43 不代表「43% 的客户没有绕过办法」，也不适合在两档之间插值还原真实数字。用它过阈值、做排序没问题，做算术不行。
不同分布可能给出同一个 score。1.0 可能是全部概率压在等级 1，也可能是 0 和 2 各一半。要区分这两种情况，必须同时读 probabilities 和 confidence。

3.3 Noul：一个是非问题，一个概率

请求结构：

{
  "type": "noul",
  "instructions": "Does the customer explicitly request a refund or credit?",
  "criteria": {
    "true": { "what": "明确要求退款或账户抵扣", "examples": ["请把重复扣的钱退给我"] },
    "false": { "what": "没有要求退款", "not_for": "只是投诉或询问账单，未要求补偿" }
  }
}

criteria 是可选的。多数问题光靠 instructions 就够，边界微妙时再补 true / false 的描述——官方建议两种写法都拿自己的数据测一遍，留效果好的那个。

返回结构：

{ "type": "noul", "noul": 0.93 }

要点：

一个 Noul 只问一个是非。「客户既生气又要求退款吗？」是两个条件，模型要在一次判断里同时权衡，数值含义会变淡。拆成两个 Noul，用代码组合。
措辞要让「高值 = 是」。问「消息里是否含个人信息」而不是「消息里是否不含个人信息」——后者会让下游代码读反。
把边界写清楚。「这位候选人有没有任何 Python 经验」里的「任何」消除了中间地带，是个好问法；模糊时就用 criteria 补上什么算 yes、什么算 no。
Noul 的值是「命题为真的概率」，不是「程度」。想表达「Python 熟练度」，应该用带等级的 Score；用 Noul 问「是否精通」，中间值只能说明「不确定」或「一般般」，两种情况混在一起，且候选之间的间距也不是你定的。
Noul 没有 confidence。因为只有是与非两个结果，概率本身就完整描述了分布，不需要再压缩成置信度。用法就是按风险挑阈值把它切成布尔：假阳（误唤人、误退款）代价高就抬高阈值；漏掉真阳（漏掉安全问题）代价高就压低阈值；中间地带交给人。

3.4 送分题：要不要用 `criteria` 写死枚举

一个高频误区：用 Noul 去问「严重度是不是高」，然后自己把 0–1 切成「0.3–0.7 算中等」。模型看不到你的分档，也就没有任何输出是针对这些分档判断的。真要分档，就用 Score 把每一档写出来，让模型逐档对齐。

4. State 设计：把上下文喂对

4.1 用对象，别用一坨字符串

最简单可以传纯字符串，但只要内容不止一件事，就用 JSON 对象——每一部分都有名字，关系清楚。把 state 想成「你递给一群专家审阅的材料」：

state = {
    "ticket": { "message": "...", "sender": {...}, "links": [...] },
    "customer": { "plan": "pro", "open_orders": [...] },
    "policy": { "sensitive_credentials": ["password", "security code", "API key"] },
}

注意：这整块是一个 state，即使里面同时包含会话、订单和政策——当判断需要跨这些部分比较时，就该放在一起。

4.2 在 `instructions` 里用反引号路径点名

state 是对象时，问题要指明「看哪一部分」。用「键路径 + 反引号」写进指令，模型就知道该判断哪个字段：

{
  "type": "noul",
  "instructions": {
    "question": "消息是否在索取敏感凭证？",
    "compare": ["`ticket.message`", "`policy.sensitive_credentials`"],
    "focus": "只找「要求对方交出凭证本身」的情形"
  }
}

instructions 可以是字符串、对象或数组。把问题放一个字段、把要引用的数据放其他字段，再用反引号按名引用——这套「结构化指令」在需要模型对照多份材料时明显更稳。

4.3 只喂该喂的：无关细节是干扰项

官方明确说过：state 越长、无关内容越多，准确率越低。无关细节既是干扰，也让「哪部分导致答错」变得不可归因。

先检索、过滤、裁剪，再进 state；
无法预先过滤时，可以加一个 Noul 先做相关性判定；
别把整篇文档 + 全部数据库记录一股脑倒进去，指望它自己找。

4.4 内容与问题分离

state 放事实、材料、规则；questions 放判断。把「退款请求」和「退款政策」都放进 state，然后分别问「客户是否要求退款」「政策是否支持退款」——两个独立问题 + 代码合成，比问一句「该不该退」可靠得多。

4.5 数据与语言

官方承诺不用客户请求/响应训练模型，企业版可谈零数据保留（ZDR）；
Jev 不按客户微调，所有领域适配都通过 state + instructions/criteria 完成，同一套权重服务所有账户；
英文是主要训练语言、目前效果最好；CJK 等语言可用但不等同，中文负载上线前必须用你自己的数据实测，并特别关注置信度。

5. 置信度与阈值：把不确定性交还给代码

5.1 四个数字别搞混

字段	出现在	含义	怎么用
`probabilities`	Choice / Score	完整概率分布（求和为 1）	需要分布本身时（如按概率排序、beam search）
`confidence`	Choice / Score	把分布形状压成 0–1 的一个数	做阈值门控，最省事
`score`	Score	等级编号的概率加权均值	排序、过阈值；不要当精确数值
`noul`	Noul	命题为真的概率（无 confidence）	切成布尔

confidence 是从 probabilities 派生的统计量：分布越集中越高。Choice 的低置信度通常意味着「没有哪个选项明显胜出」；Score 的低置信度通常意味着「等级描述重叠、或这题在测多个维度、或 state 信息不足」。

5.2 三档路由：起步就用这个骨架

c = response.answers["department"].confidence

if c >= 0.9:
    auto_route(...)          # 直接自动执行
elif c >= 0.6:
    flag_for_review(...)     # 复核 / 追问用户 / 补数据
else:
    route_to_human(...)      # 转人工，或换更强模型

5.3 阈值不是「一个数」，而是随风险变化的一族数

同一个系统里，不同动作的阈值应该不同：

只读操作（打标签、排序）阈值可以低；
破坏性 / 有成本的操作（发退款、发消息、删数据、动线上配置）阈值要高得多；
0.5 是底线，confidence 低于它基本等于「模型自己都在摇摆」，不该有任何自动动作。

5.4 阈值必须用你自己的数据标定

这是整份手册里最容易被忽视、代价也最大的一条。

第三方中文实测（虎嗅，50 条中文电商客服问题）暴露了典型的阈值抖动：人工标注认为某条消息的严重度下限应是 2.00，Jev 给出 1.99——数值只差 0.01，但如果你的业务规则写的是「达到 2.00 才转人工」，1.99 和 2.00 在程序里就是两个世界。15 次重复测试中，有 3 道题在通过与失分之间反复横跳。

结论：模型返回一个精确到小数点后的数字，并不会自动让业务规则变可靠。上线前请做三件事：

用你真实的历史数据（不是示例）跑一遍，看概率分布落在哪里；
把阈值定在分布的空档处，而不是贴着某个样本的边界值；
对临界样本做重复调用，测出抖动幅度，据此留出安全带（例如把 2.00 的门槛改成 1.90，或把临界带整段转人工）。

5.5 两个常见反模式

到处都设 confidence 阈值：如果你只是想在若干选项里挑最好的那个，直接取 choice（等价于取概率最高项）即可，不需要再设阈值。只有当你确实要用概率做统计计算时，才去读 probabilities。
把中间值当「程度」：Noul 的 0.5 不代表「中等严重」，只代表「模型也拿不准」。要程度，用 Score。

6. 四个必须掌握的模式

6.1 Speculative fan-out：一次问完所有可能的问题

既然同请求内的问题是并行评估的，那就把代码可能用到的每个问题都塞进同一次调用，包括那些只在某些分支才有意义的问题，事后由代码决定用哪几个。

例子：工单分诊同时问「派给哪个团队」「退货原因」「物流问题」「客户诉求」「语气」。如果 department 判成 returns，就看 return_reason；判成 shipping 就看 shipping_issue；其余答案直接忽略。

官方 Parallel questions cookbook 给了一组硬数据：把 13 个问题合并成一次调用，比拆成 13 次调用便宜 11.5 倍、快 9.6 倍，且答案不变。

6.2 Composite scoring：拆分 + 归一化 + 加权

复杂判断的正确解法不是写一句更复杂的问句，而是拆成一维一问题，再在代码里合成：

# 1) 归一化：把不同长度的量表拉到 0–1
def norm(ans, criteria_len):
    return ans.score / (criteria_len - 1)      # 4 档量表返回 0–3，3 档返回 0–2

priority = (
    0.6 * norm(response.answers["severity"], 3)        # 严重度
  + 0.3 * norm(response.answers["frustration"], 3)     # 客户愤怒度
  + 0.1 * norm(response.answers["report_quality"], 4)  # 报告可用信息量
)

三个好处：权重写在代码里可读可审；改权重不用重写提示词；每一维的细微差别都被保留，而不是被压成一个模糊总分。当合成结果和团队的实际判断不一致时，你调的是权重，而不是玄学地改措辞。

6.3 什么时候才需要第二次请求

同请求内问题互相独立，所以不能拿 A 的答案当 B 的上下文。只有下面三种情况，第二次请求才是真需求：

需要用第一个答案去取更多数据才能构造 state（例如先用 Choice 排出候选技能，再抓取前三名的全文重新判断）；
需要用第一个答案决定 state 由什么构成；
需要用第一个答案决定下一个问题的选项集（层级分类）。

除此之外——包括「下一问依赖上一问」的直觉——都应该合并到第一次请求里，让代码忽略不需要的答案。两次请求是例外，不是常态。

6.4 把算术、计数、日期交给代码

这一条来自官方失败模式文档，务必记住：Jev 不是计算器。

计数不可靠：数词里的字符数、某个词在段落里出现几次、长列表有几项——它识别的是「答案的形状」而不是真的在数，而且错得随对象变长而变多；
数值表示很弱：问颜色用「红/蓝/绿」比用 hex/RGB 好得多，后者它无法可靠判断两个值是否接近；判断高级语言比判断汇编、二进制编码可靠；
日期按文本读：比较两个日期先后、算间隔、判断是否落在某个窗口内都不可靠，混合格式与相对日期更糟；
不要用 Score 的期望值反推精确数字。

正确姿势：能枚举的枚举（日期拆成「月/日/年」三个 Choice，并加一个「未提及」选项，代码再拼成真实日期并接管排序与算差）；能正则/解析的用代码；模型只负责「这到底算不算一个判断」。分工原则：提取是判断，算术是代码。

7. 生产级实战配方

7.1 配方一：客服工单分诊

结构：一次请求，多种原语混用；代码负责路由、加权与转人工。

questions = {
    "topic": Choice(                     # 主分类
        instructions={"question": "Which team should handle `ticket.message`?",
                      "focus": "Classify the customer's primary request."},
        criteria={
            "billing": {"what": "扣费、发票、退款、订阅",
                        "not_for": "物流查询或账号访问",
                        "examples": ["我被扣了两次", "我的退款在哪"]},
            "orders":  {"what": "订单状态、配送、取消、退货",
                        "not_for": "扣费或账号访问",
                        "examples": ["我的订单到哪了"]},
            "account": {"what": "登录、资料、权限、安全",
                        "not_for": "扣费或订单查询",
                        "examples": ["重置密码", "我登不上去"]},
        },
    ),
    "requests_credentials": Noul(
        instructions={"question": "消息是否要求对方交出敏感凭证？",
                      "compare": ["`ticket.message`", "`policy.sensitive_credentials`"]},
    ),
    "refund_requested": Noul(
        instructions={"question": "客户是否明确要求退款或抵扣？",
                      "focus": "必须是明确的补偿诉求，而不只是抱怨账单"},
    ),
    "frustration": Score(
        instructions={"question": "客户表现出的愤怒程度？",
                      "inspect": "`ticket.message`"},
        criteria=[{"what": "平静陈述事实"},
                  {"what": "不满但克制"},
                  {"what": "强烈愤怒或威胁流失"}],
    ),
}

resp = client.system_one(state=state, questions=questions)
a = resp.answers

# 1) 不确定就升级，而不是猜
if a["topic"].confidence < 0.75 or a["requests_credentials"].noul >= 0.7:
    return route_to_human_review(ticket)

# 2) 让代码决定哪个「备用问题」的答案有意义
if a["topic"].choice == "billing":
    return route_to_billing(ticket, refund=a["refund_requested"].noul >= 0.7)
if a["topic"].choice == "account":
    return route_to_account_support(ticket)

# 3) 分数高但模型没把握时，不要自动升级
priority = "high" if (a["frustration"].confidence >= 0.7
                      and a["frustration"].score >= 1.5) else "normal"
return route_to_orders(ticket, priority=priority)

注意最后一段：frustration 不只看分数，还看了 confidence——分数高但模型没把握时，不该自动升级。

7.2 配方二：Agent 工具调用安全护栏

Agent 最大的信任问题是：它可能被坏指令（用户的、或注入的）说服去做你不想要的动作。编码类 Harness 早就在这么干了——在工具执行前分类一次，但这个能力长期锁在闭源 Harness 内部。

有了廉价的高性能分类器，你可以把同一模式复制到所有 Agent 上。LangChain 提供了现成中间件：

from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import AutoModeMiddleware

guardrail = AutoModeMiddleware(tools=["bash"])
agent = create_agent("openai:gpt-5.6-luna", middleware=[guardrail])

它在 bash 之类的工具真正执行前先问一次 Jev，危险调用直接拦截。相比「完全信任模型不发疯」和「每一步都弹窗确认」两个极端，这是一个可量化、可审计的中间态——而且单次判断的延迟是毫秒级、成本是厘级。

7.3 配方三：模型路由（投入产出比最高的改造）

最简单的查询不必动用最贵的模型。让 Jev 在任务入口做一次复杂度判断，再决定走哪档：

from langchain_typesafe.experimental.middleware import ModelChoice, ModelRouterMiddleware

router = ModelRouterMiddleware(
    choices={
        "fast":     ModelChoice(model="openai:luna",
                                criteria="Direct lookups, extraction, and localized changes."),
        "powerful": ModelChoice(model="openai:sol",
                                criteria="Architecture and high-stakes decisions."),
    },
    instructions="Choose the least costly model that can complete the task.",
)
agent = create_agent("openai:gpt-5.6-luna", middleware=[router])

路由器只看最新一条用户消息，并把选中的模型用于整轮；概率与置信度会留在 agent state 里，可审计。「80% 简单任务走便宜路径、20% 难任务走高端路径」第一次变成可实施的策略，而不是口号。

7.4 配方四：上下文压缩（是「过滤」，不是「总结」）

长会话的常规做法是让模型写摘要，代价是丢细节、且要生成（慢、贵）。换成决策模型的思路是：用 Score 给历史里每一次工具调用打相关性分，低分直接丢弃、高分原样保留——保留原文，不做改写。

站内拆解文引用的实测数据：约 1 秒把近 100 万 token 的会话压到 8.6 万 token，且关键细节不丢。这是「便宜的高频判断」最能立刻见效的地方之一。

7.5 顺带一提：让编码 Agent 少写错代码

官方提供了 TypeSafe agent skill（供 Claude Code、Codex 等使用），把三种原语、架构模式与最佳实践一次性喂给编码 Agent，并附了几条值得抄走的纪律：

先和 Agent 把方案聊清楚，确认计划再动手；
把问题定义和阈值常量集中放在一个文件里——这是人类最该 review 的部分；
Agent 不擅长写问题（questions），预期要人工协同编辑；
不要照单全收它的断言，要求它验证假设。

8. 九类失败模式与避坑清单

以下前九条来自官方 jev-1.13 jaggedness 文档（即官方主动披露的「棱角」），第十条来自第三方实测。

#	失败模式	表现	正确做法
1	字面理解	它回答你写的问题，不是你想的。限定词、否定、隐含条件都按字面读	把确切条件写进 `instructions`，边界情况写进 `criteria`。「你心里那句解释」就是指令缺的另一半
2	计数不可靠	数字符数、数词频、数列表项都不准，且随对象变长错得更多	能正则/解析数出来的，交给代码；要「按条件计数」，就逐个候选问一次再自己加总
3	数值表示弱	用 hex/RGB 判颜色、用汇编/二进制判语言，明显变差	代码先换算，再传「命名」或「分桶」给模型；模型只判断「这个颜色读起来像不像警告」
4	拿 Score 当计算器	想在两个等级间插值反推精确数字	Score 只用于过阈值或排序，精确数值回代码算
5	日期时间比较	哪个在前、差几天、是否在窗口内，都不可靠；混合格式更糟	拆成 Choice 逐字段提取（月/日/年，含「未提及」），代码拼装并接管一切运算
6	多跳与双重否定	需要多层推理或绕弯的指令，准确率下降	写得尽可能直白；必要时拆成两个字面问题，在代码里组合
7	长 state 里的无关细节	越长的无关内容越是干扰，且错误难以归因	先在代码里检索过滤，只发问题需要的字段；必要时用 Noul 先做相关性判定
8	对抗性内容	state 里注入的指令、刻意误导的框架、「自证分类」的文本，都能推动答案	在 `criteria` 里显式说明；上线前做充分对抗测试，当前版本尤其要谨慎
9	指令与 criteria 打架 / 结构不变性	比如 Noul 里 `true` 表示「否」会变差；也别假设 `P(是) = 1 − P(非)`、别假设 Choice 与 Noul 版本可互换	让 criteria 成为指令的自然延伸；措辞直接表达你要的意思；Noul 上标定的阈值不要搬到 Choice 上
10	阈值抖动（第三方实测）	1.99 与 2.00 之差让结果横跳，重复测试同一题会反复过关/失分	阈值定在分布空档处；临界样本重复调用测抖动；临界带整段转人工

另外两条场景级提醒：

它不支持生成。想靠链式 Choice 拼出文本「不是不能用，是又慢又差」。需要写东西，请用生成式模型。
中文要自测。第三方中文实测里，Jev 在「便宜小模型组」排第二、在强模型组排最后，完整准确率约 64%–65.2%；但延迟与成本是全场最优（平均每题约 0.73–0.75 秒，50 题合计约 0.002 美元）。选它的理由应该是「够快够便宜且给得出可信概率」，而不是「最准」。

9. 成本、延迟与版本管理

9.1 价格与额度

项目	数值
输入	$0.042 / 百万 token（$42 / 十亿 token）
输出	免费（无 token 生成，低到不值得计量）
新用户额度	注册即得 $5；按输入价折算 ≈ 1.19 亿输入 token
折算	若每次决策消耗 1000 输入 token，$5 约支撑 11.9 万次决策

官方在发布文中罕见地自己承认：「我们无法证明它没有补贴，需要长期来证明定价的可持续性（我们预期它会继续下降，而不是上升）。」——所以现在按它做容量规划时，建议按当前价上浮留余量。

9.2 延迟与上下文预算

端到端延迟：70–500 毫秒；
64k 预算：state + 本次请求所有问题之和；
32k 预算：state + 最长的单个问题。

这两条预算就是「为什么建议一次问多个问题」的量化依据：问题越多，单个问题的预算越紧张，但整体仍很宽松；真要塞进超长 state，就得靠第 4 节的裁剪功夫。

9.3 速率限制与错误处理

限制维度：每秒 token 数与每分钟请求数；任一超限返回 429 Too Many Requests；
官方 SDK 默认自带指数退避重试，并遵守响应头里的 retry-after；
直连 HTTP 的话，遇到 429 或 529 Overloaded 请不要立即重试，用指数退避。

9.4 版本管理清单

[ ] 生产环境固定版本 ID（如 jev-1.13.0），不要用会漂移的 jev-latest；
[ ] 把响应里的 model 字段写入日志，保留「哪版模型给了这个答案」的追溯链；
[ ] 版本升级时，用同一批回归样本重跑一遍，对比准确率与置信度分布，再决定是否调整阈值；
[ ] 问题定义与阈值常量集中在一个文件，方便 review 与回归。

10. 该不该用：审计清单与迁移路线

10.1 现有 LLM 调用审计法

拿你现在的 Agent 代码，把每一次 LLM 调用逐个标记：

输出是「从预定义选项里挑一个 / 给一个等级 / 回答是-否」→ 划入选择题，考虑下沉到 Jev；
输出是「生成全新文字 / 代码 / 解释」→ 留在生成类。

你会发现相当高比例的调用其实是选择题。站内那篇拆解文给过一个可执行的判断框架：典型 Agent 内循环里，真正需要「生成一段文字」的动作可能只有 20%。

10.2 建议的迁移顺序

先做护栏：在危险工具调用前加一层分类——风险最低、收益立竿见影、出错的代价只是「拦了一次无害操作」；
再做路由：让廉价判断决定「这件事值不值得动用最贵的模型」，投入产出比最高；
最后做重活：批量分类、打标、评分、上下文过滤——这类要先用真实数据标定阈值，跑稳了再扩量。

10.3 什么场景别用

需要开放式生成（写作、代码、解释）；
需要多步长链推理；
需要精确数字：计数、算术、日期运算；
业务对错误零容忍且没有人工复核环节；
输入以对抗性内容为主，且要求当前版本鲁棒；
中文等非英语负载未经自测。

还有一条底线：高置信度只代表模型自己的把握，不代表事实正确，更不代表动作真的执行成功。 文件是否写入、消息是否发出、退款是否到账——必须由代码单独确认，不能拿 confidence=0.99 当执行回执。

11. 小结

Jev 的价值主张不是「替代大模型」，而是把 Agent 循环里被浪费掉的那部分算力收回来。它把「智能 if 语句」做成了一个可依赖的组件——类型安全、带校准概率、毫秒级、白菜价，然后交由工程去组合。

但它的使用方式也确实和聊天模型不一样，这份手册的核心可以压缩成六句话：

问封闭问题：答案必须是选项、等级或是否；
喂干净的 state：用对象组织、用路径点名、把无关细节删掉；
一次问完：所有可能用到的判断塞进同一次调用，代码里再挑；
拆分再合成：一维一问题，归一化后加权，权重写在代码里；
让置信度决定谁来接手：高自动、中转复核、低转人工，阈值按风险分级并用真实数据标定；
算术、计数、日期留给代码，模型只做判断。

附录：一页速查表

项目	结论
端点	`POST /v1/systemone`
模型	试用 `jev-latest`；生产锁 `jev-1.13.0`
三个原语	Choice（无序选项，≤255）/ Score（有序等级，2–10）/ Noul（是否）
返回	Choice: `choice`+`probabilities`+`confidence`；Score: `score`+`probabilities`+`legend`+`confidence`；Noul: `noul`（无 confidence）
成本	输入 $0.042/MTok，输出免费；$5 ≈ 1.19 亿输入 token
延迟	70–500 ms
上下文	64k = state + 全部问题；32k = state + 最长单问
限流	429 / 529 → 指数退避（SDK 自动重试）
三档路由	≥0.9 自动；0.6–0.9 复核；<0.6 转人工（按风险调整）
一次问几个	全部。加问题几乎不加延迟，只多花输入 token
什么时候发第二次请求	仅当要取更多数据 / 决定 state 构成 / 决定下一问选项
交给代码的事	计数、算术、日期比较、数值换算、最终执行确认
别指望它	生成文本、多步推理、精确数值、对抗鲁棒

信源

TypeSafe AI 官方文档：Introduction / State / Primitives（Choice、Score、Noul）/ Confidence / Speculative fan-out / Composite scoring / How to build / Models / API reference / Agent skill / Jev 1.13 jaggedness — https://docs.typesafe.ai/
TypeSafe AI 发布文《Introducing System One Models & Jev》（Diogo Almeida，2026-09-15）：https://typesafe.ai/blog/introducing-system-one-models-and-jev
维基百科 Jev (AI model)：https://en.wikipedia.org/wiki/Jev_(AI_model)
LangChain《What Is Jev? A Guide to TypeSafe AI's System One Model》：https://www.langchain.com/blog/building-a-harness-with-jev
站内：《不说话的模型，正在接管 Agent 的 80% 决策：Jev 深度拆解》（含第三方中文实测、浏览器/邮件/上下文压缩落地数据与开源复现生态）
站内资讯：《TypeSafe AI Releases Jev》《A new kind of AI model from a ChatGPT inventor is thrilling developers》《APUS 开源国内首批 Jev 跨平台复现》

口径声明：本文所有性能与价格数字均标注来源口径。193.6 倍 / 444.6 倍为 TypeSafe 官方自测结果（其自认可能偏乐观）；中文准确率 64%–65.2% 为第三方实测。官方未公开参数规模、网络结构与技术论文，长期定价可持续性亦未经独立验证。

Jev 深度使用手册：State 设计、三种原语、置信度阈值与九类失败模式

Jev 深度使用手册：State 设计、三种原语、置信度阈值与九类失败模式

0. 30 秒决策卡

1. 先把三个概念对齐

1.1 System One 是什么

1.2 请求的形状：state + questions → answers

1.3 与 LLM 的分工

1.4 「零幻觉」到底指什么

2. 十分钟跑通第一次调用

2.1 端点与模型名

2.2 curl 版

2.3 Python SDK 版

2.4 版本与别名：调过阈值就必须锁版本

3. 三种原语：Choice / Score / Noul

3.1 Choice：路由与分类的主力

3.2 Score：打分与排序

3.3 Noul：一个是非问题，一个概率

3.4 送分题：要不要用 criteria 写死枚举

4. State 设计：把上下文喂对

4.1 用对象，别用一坨字符串

4.2 在 instructions 里用反引号路径点名

4.3 只喂该喂的：无关细节是干扰项

4.4 内容与问题分离

4.5 数据与语言

5. 置信度与阈值：把不确定性交还给代码

5.1 四个数字别搞混

5.2 三档路由：起步就用这个骨架

5.3 阈值不是「一个数」，而是随风险变化的一族数

5.4 阈值必须用你自己的数据标定

5.5 两个常见反模式

6. 四个必须掌握的模式

6.1 Speculative fan-out：一次问完所有可能的问题

6.2 Composite scoring：拆分 + 归一化 + 加权

6.3 什么时候才需要第二次请求

6.4 把算术、计数、日期交给代码

7. 生产级实战配方

7.1 配方一：客服工单分诊

7.2 配方二：Agent 工具调用安全护栏

7.3 配方三：模型路由（投入产出比最高的改造）

7.4 配方四：上下文压缩（是「过滤」，不是「总结」）

7.5 顺带一提：让编码 Agent 少写错代码

8. 九类失败模式与避坑清单

9. 成本、延迟与版本管理

9.1 价格与额度

9.2 延迟与上下文预算

9.3 速率限制与错误处理

9.4 版本管理清单

10. 该不该用：审计清单与迁移路线

10.1 现有 LLM 调用审计法

10.2 建议的迁移顺序

10.3 什么场景别用

11. 小结

附录：一页速查表

信源

读者留言

相关阅读

3.4 送分题：要不要用 `criteria` 写死枚举

4.2 在 `instructions` 里用反引号路径点名