摘要：Jev 把模型路由、工具风险判断和结果验证，从生成式 LLM 的主循环中拆出来，变成类型明确、带概率的快速决策。本文用四张架构与流程图、两段代码，讲清它应该放在哪里、怎样设阈值，以及哪些工作仍要留给代码、强模型和人。

一个 Agent 要完成任务，通常会反复回答几类问题：这条请求该交给哪个模型？下一条命令能不能执行？工具返回的结果是否满足要求？现在可以结束了吗？

不少系统把这些问题都交给同一个大模型。即使答案只有「允许」或「拒绝」，模型仍要读取上下文、逐个生成 token，再由应用解析结果。单次调用看不出什么，放进循环后，几十次小判断会一起抬高延迟、成本和失败概率，还会让每个分支都依赖一次不完全稳定的文本生成。

2026 年 9 月 15 日，TypeSafe AI 发布首个 System One 模型 Jev。

这里的 System One（系统一）借用了《思考，快与慢》所推广的认知框架：「系统一」快速、直觉，几乎不需要有意识的努力；「系统二」较慢、审慎，用于需要集中注意和多步分析的问题。二者是描述思考方式的概念划分，并非大脑中两套彼此独立的物理系统。TypeSafe 用「系统一」强调 Jev 的快速判断定位。

Jev 不生成回复、解释或代码，只接收一段状态和一组预先定义的问题，再返回类型明确的答案与概率。

Jev 更像一块可编程的「语义判断器」。代码擅长判断 amount > 100，却难以直接判断「投诉是否紧急」「shell 命令是否危险」。Jev 补上后一类判断，最终执行权仍留在代码中。

Jev 对 Agent 最有价值的用法，是成为生成式模型周围的控制层：先分流，执行前门控，执行后验证。

一、Agent 循环里，很多调用根本不需要生成

先看一条常见的 Agent 执行链：

  1. 读取用户任务，选择模型和工具；
  2. 生成计划或下一步动作；
  3. 判断动作风险，决定是否需要审批；
  4. 调用工具，读取返回结果；
  5. 判断任务是否完成，或继续下一轮。

第二步需要生成内容。其余步骤多是有限判断：选哪个模型、动作是否危险、任务是否完成。即使要求主 LLM 输出 JSON，底层仍要自回归生成，应用还是为一个小判断承担完整调用成本。

选型规则可以归结为三问：能精确计算的交给代码；已有成熟数据和固定标签的，可训练传统分类器；答案能枚举、却需要理解自然语言语义的，才是 Jev 的目标区间。规划、解释和内容生成仍属于 LLM。

如何在代码、传统分类器、Jev 和生成式 LLM 之间选型

图 1｜先看是否需要生成，再看问题能否精确计算、能否枚举答案。Jev 的位置是「有限答案 + 语义判断」。

采用 Jev 的前提是：答案可以预先列出，却无法用确定性代码稳定算出。 需要开放回答时，任务仍应交给生成式模型。

二、Jev 的接口：状态进，概率化决策出

对应到工程里，Jev 把这种「快速判断」收窄为一个明确接口：

非结构化状态进，预定义类型的概率化决策出。

一次请求包含两部分：

  • state：当前情况，可以是文本、JSON 对象或文本数组；
  • questions：要对这段状态作出的判断，以及每个判断允许返回什么。

这份约束在调用前就已确定。应用不必从一段解释里提取标签，也不必处理模型临时发明的新类别；拿到概率后，可以直接进入阈值、回退和审计逻辑。

Jev 提供三种基础问题：

↔ 左右滑动查看完整表格
类型适合回答返回内容
Choice「这条请求属于哪个部门？」被选选项、每个选项的概率、整体置信度
Score「这次操作的风险有多高？」连续分数、各等级概率、整体置信度
Noul「这条消息是否要求退款？」命题为真的概率，范围为 0 到 1

Noul 是 TypeSafe 对真假判断的命名，没有单独的 confidence 字段；Choice 和 Score 的 confidence 由完整概率分布计算。Choice 在两个选项间接近五五开时，置信度通常较低。

Jev 请求中 state、Choice、Score 和 Noul 的数据流

图 2｜一份 `state` 可以支撑多个独立问题并行评估。模型返回概率化结果，阈值、分支和升级路径仍由代码管理。

LangChain 用 TypeSafeClassifier 封装了这一接口。下面判断线上故障是否需要立即处理：

from langchain_typesafe import Noul, TypeSafeClassifier  

classifier = TypeSafeClassifier()  

response = classifier.invoke(  
    state=(  
        "The deploy failed twice and customers are seeing 500s. "  
        "Can someone look now?"  
    ),  
    questions={  
        "urgent": Noul(  
            instructions="Does this need attention right now?"  
        )  
    },  
)  

urgent_probability = response.nouls["urgent"].noul  

if urgent_probability > 0.9:  
    page_on_call_engineer()  
else:  
    add_to_incident_queue()

模型只提供「紧急」的概率。0.9 是业务阈值，不是 Jev 内置的安全线，必须在团队自己的故障样本上校准；通知、升级和审计仍由应用处理。完整 Agent 会围绕开放目标持续工作，Jev 每次只回答有限问题，然后停止。

三、把 Jev 放进 Harness 的三个位置

Harness（Agent 运行框架）连接模型、工具、上下文、权限和执行循环。Jev 适合嵌入三个窄而高频的控制点。

Jev 在 Agent Harness 中的三个控制点

图 3｜Jev 负责语义判断；普通代码负责确定性规则和流程控制；生成式 LLM 继续承担规划与生成。本文根据 TypeSafe 与 LangChain 公开资料整理绘制。

1. 请求进入时：选择模型和处理路径

查订单可直接访问数据库，局部修改可交给便宜模型，架构评审才需要强模型。Jev 根据语义难度、任务类型和风险路由；低置信度请求升级给强模型或人工。这样，强模型只处理真正需要规划和推理的请求，路由错误也有明确的回退路径。

2. 工具执行前：评估动作风险

确定性规则先检查权限、路径和禁止项，Jev 再判断命令组合是否可能删数据、改 Git 历史或触碰生产环境。LangChain 的实验性 AutoModeMiddleware 就在工具执行前检查危险动作。多个风险可以分别提问，再由代码采取「任一高风险即升级」或加权策略。语义门控只是第二道筛网，不能取代沙箱和权限系统。

3. 工具返回后：补上语义验证

退出码和测试结果由代码判断；「回答是否覆盖要求」「证据是否支持结论」「Agent 是否重复动作」则可交给 Jev。Harness 再决定继续、换模型、人工复核或结束。这里的关键是把「完成」拆成可检查命题，而不是让模型笼统评价整体质量。Jev 只补语义条件，不覆盖硬测试。

三个控制点连起来后，一轮 Agent 循环可以写成下面的伪代码：

广告媒流（小程序）-AI生图
route = jev.choose(request, [direct_lookup, fast_model, strong_model, human])  

if route.confidence < ROUTE_THRESHOLD:  
    return send_to_human(request)  

proposal = selected_model(route).plan_next_action(request, state)  

hard_checks = policy_engine.check(proposal)  
risk = jev.score(proposal, [read_only, reversible, destructive])  

if hard_checks.denied or risk > ACTION_THRESHOLD:  
    return request_approval(proposal)  

result = run_tool_in_sandbox(proposal)  
tests = deterministic_tests(result)  
semantic_check = jev.verify(result, completion_criteria)  

return finish() if tests.pass and semantic_check > DONE_THRESHOLD else continue_loop()

Jev 没有最终权限：代码决定阈值，策略引擎可直接拒绝，工具仍在沙箱运行，高风险动作仍需人批准。即使 Jev 服务不可用，Harness 也应走预设的保守回退，而不是默认放行。

四、四条工程原则，比接入 SDK 更重要

独立问题一次问完

一次请求可以并行判断工单部门、紧急程度、退款意图和信息完整度。TypeSafe 称之为 speculative fan-out（推测式展开）：共享长文本只传一次，新增判断主要增加问题本身的 token。只有后一个问题依赖前一个答案时，才拆成多次请求；否则串行调用只会重复传输状态并累加延迟。

一个问题只包含一个判断

「分析工单并决定最佳处理方式」混合了部门、风险、情绪和权限，出错后难以定位。应把判断拆开，再由代码按可审阅的业务权重组合。这样既能分别评测每个问题，也能看见是哪项概率推动了最终分支；调整权重并回放测试，无需重写一大段 prompt。

阈值随风险变化

置信度表达模型在候选答案间是否犹豫，不能证明当前答案正确；校准衡量的是一组预测。低风险只读操作可用较低阈值，发邮件、改数据库或删文件需要更高阈值和执行前确认。实践中可设置「自动执行、升级复核、直接拒绝」三个区间。阈值应来自真实数据上的准确率与错误代价，而不是照抄示例。

能用代码算清的，继续用代码

计数、金额、日期、权限白名单和测试结果都应由代码处理。Jev 1.13 的官方「jaggedness」页面也承认，它不擅长算术、计数、日期比较和数值精度。把硬规则写成代码，才能得到可复现的单元测试、清晰日志和稳定拒绝行为。模型判断意义，代码计算事实。

五、怎样理解「快 200 倍、便宜 400 倍」

截至 2026 年 9 月 19 日，TypeSafe 官方模型页列出的稳定版本是 jev-1.13.0：每百万输入 token 0.042 美元，输出 token 免费；每次请求总预算为 64k token，同时要求 state 加单个最长问题不超过 32k token。输入目前只支持文本。

TypeSafe 报告其端到端延迟约为 70–500 毫秒。在自建 workflow evals 中，官网使用了 193.6 倍速度和 444.6 倍成本优势的数字。官方同时说明，这两个倍数处在真实收益的高位区间，评测任务也由公司自己的模型能力团队成员制作，可能存在偏差。

这些数字只适用于答案空间有限的工作流任务：参考概率来自强外部模型的平均预测，不是传统分类测试中的唯一标准答案；任务由厂商团队制作，而且接口主动放弃了长推理和文本生成。因此不能外推到写作、编程或开放推理，也不能直接当成某个生产系统的成本承诺。

一个更容易复查的例子来自官方 parallel questions cookbook。测试把一篇 53,777 字符的 GDPR 文本和 13 个问题交给 Jev 1.12，重复运行 5 次：

↔ 左右滑动查看完整表格
方式调用次数平均成本总耗时应怎样理解
一次提交 13 个问题10.000497 美元0.27 秒长文档只传一次
13 次单问题调用130.006090 美元2.71 秒每次重复传入长文档

这组测试中，批量方式便宜 12.2 倍、快 10 倍。13 次调用若并发，延迟差会缩小，但重复输入成本仍在。它证明的是共享长状态时批量独立问题更划算，不代表所有工作流都有固定 10 倍收益。

六、类型安全解决不了判断错误

TypeSafe 称 Jev 「不会幻觉」。严格说，这只表示答案空间定义后，模型不会返回 schema 之外的类型。

部门若只有 billing、technical 和 sales，Jev 不会生成 legal 或一段散文，却可能把技术故障错分给 billing。

类型安全保证输出形状，概率校准描述一组预测，当前答案是否正确仍要靠测试。

官方文档列出的已知薄弱点还包括：

  • 它按字面理解问题，隐含条件、双重否定和多跳关系会降低准确率；
  • 无关信息过多时，长状态会干扰判断，应先检索和过滤；
  • 对抗性文本可能推动答案偏移，不能把 state 默认当成可信输入；
  • Score 适合排序和过阈值，不适合把 1.4 解释成精确物理量；
  • 它不能可靠生成、总结或解释，需要开放文本时应调用生成式模型；
  • 英语是主要训练语言，中文等 CJK 文字虽然可处理，仍需用自己的数据验证。

在 Agent 中还要区分可信规则与不可信观察：权限政策由代码保存，网页、邮件和工具返回值只能作为 state。必要时先检索、截断和去除无关内容，再让 Jev 判断，避免外部文本借提示注入影响门控结果。

Jev 目前处于 early access（早期访问），权重未开放，独立校准研究也有限。接入前还要评估服务稳定性、数据边界和供应商依赖。它是需要本地评测的新组件，不是开箱即用的安全裁判。

七、七步把 Jev 接进现有 Agent

第一步，选择频繁、有限、低风险的判断，如模型路由、工单分流或只读工具检查。

第二步，为每个选项写清包含项和排除项，并保留「其他」或「信息不足」。

第三步，建立标注集，覆盖正常、模糊、边界、中文和恶意诱导样本。

第四步，运行 shadow mode（影子模式），只记录答案、概率、延迟和结果，不改变真实行为。

第五步，分析准确率与概率或置信度的关系，为自动执行、强模型和人工处理划定区间。

第六步，只自动化高置信度、低代价分支，不确定和高风险结果保留升级路径。

第七步，把模型、问题、criteria（选项判定标准）、阈值和评测集一起版本化；生产流程固定版本，升级前用同一数据回放。

Jev 从低风险试点到渐进放权的七步上线流程

图 4｜上线分为「定义问题、观测校准、渐进放权」三个阶段。模型、问题或阈值变更后，需要回到同一评测集重新回放。

完成后，每个语义判断都有明确输入、有限答案、可检查阈值和失败去向。团队也能回答一个关键问题：自动化为何在这里继续、在那里停下。Jev 很少改变 Agent 的「大脑」，主要重构周围的控制系统：何时调用强模型，哪些动作可放行，哪些结果要复核。

当代码重新拿回分支、权限和失败处理，模型只负责代码算不清的语义判断，Agent 才有机会同时获得速度与可控性。

参考资料

  1. TypeSafe AI：Introducing System One Models & Jev[1]，2026-09-15
  2. TypeSafe AI：System One[2]，2026-09
  3. TypeSafe AI：Models[3]，访问于 2026-09-19
  4. TypeSafe AI：Confidence[4]，2026-09
  5. TypeSafe AI：Jev 1.13 jaggedness[5]，2026-09-17
  6. TypeSafe AI：Parallel questions[6]，2026-09
  7. LangChain：Building a Harness with Jev[7]，2026-09-17
  8. Flavio Copes：A deep dive into Jev, TypeSafe's System One model[8]，2026-09-18
  9. Akshay Pachaar：Jev Clearly Explained[9]，2026-09-18

引用链接

[1]Introducing System One Models & Jev: https://typesafe.ai/blog/introducing-system-one-models-and-jev

[2]System One: https://docs.typesafe.ai/concepts/system-one

[3]Models: https://docs.typesafe.ai/models

[4]Confidence: https://docs.typesafe.ai/confidence

[5]Jev 1.13 jaggedness: https://docs.typesafe.ai/model-jaggedness/jev-1.13

[6]Parallel questions: https://docs.typesafe.ai/cookbooks/parallel\_questions

[7]Building a Harness with Jev: https://www.langchain.com/blog/building-a-harness-with-jev

[8]A deep dive into Jev, TypeSafe's System One model: https://flaviocopes.com/jev/

[9]Jev Clearly Explained: https://x.com/akshay\_pachaar/status/2101037514945597645