Jev 与 Agent 工具链分工：三类任务该给谁做

大熊 技术创作者 2026-09-21 2414 阅读

先说结论

  1. Jev 不是聊天模型，而是一个做结构化决策的 System One 模型。它输入程序状态，输出带概率的类型化答案，不生成文本、不解释推理。
  2. 工具链至少要有四层：规则/正则（确定性）→ 决策模型（结构化判断 + 置信度）→ 专用小模型（有标注数据）→ 通用 LLM（开放生成/长链推理）。Jev 主要补第二层。
  3. 第三方基准指向两个明确场景：60 例工具调用风险分类基准显示校准结论成立（社区二手），适合执行前门禁；物理 AI 实测给出 $0.042/百万输入 token、output free 的第三方价格口径，指向机器人/边缘分诊。
  4. 接入位置应在网关/路由层，而不是生成层：LiteLLM 把它用于 Auto Router 分类，Netlify 已将其纳入 AI Gateway；它在链路里负责“决定走哪条路”，不负责“生成内容”。
  5. 四类情况别用：需要解释理由、输入是长自由文本且结构不稳定、判定必须可审计到规则级、调用量极低。

证据与过程

1. System One 模型的边界：只判断，不生成

根据 TypeSafe 官方文档，System One 模型是一个区别于 LLM 的类别。它像 LLM 一样理解自然语言输入，但返回的是类型化的决策和概率，而不是生成的文本。Jev 是 TypeSafe 的首个 System One 模型，也是旗舰模型。

官方文档明确写了三个关键点：第一，Jev 目前只接受文本输入，评估字符串、JSON 对象和文本数组；不支持图像、音频、视频（官方数据）。第二，它不写回复、不产代码、不生成推理过程的解释。第三，它的概率是被校准的，但校准是群体层面的概念，不保证单个答案一定正确。

这种特性让 Jev 不适合做“生成”，而适合放在一个动作发生之前做判断。例如 Netlify 官方 changelog 给出的示例是一个联系表单路由：把提交内容交给 Jev，让它从 sales、support、spam 三个选项里选一个，返回的是 answers.team.choice，代码可以直接分支。

2. 四层分工：从零成本确定性到开放生成

下面这张表是我根据官方文档和社区实测整理的分工表。表中“判断”表示这是根据工程常识的自己推算，不是官方数据。

任务类型 首选层 典型例子 原因 来源/判断
固定格式、确定性规则 正则与规则 URL 白名单、字段格式校验、固定关键词命中 零成本、可审计、实时 自己推算
高频、结构化判断、需要置信度 决策模型（Jev） 工具调用风险门禁、工单分派、退款意图识别、情绪评分 返回类型化答案 + 校准概率，适合请求路径 官方文档 + Netlify changelog
有标注数据、量大 小模型/专用分类器 垃圾邮件过滤、特定意图分类、文本主题标注 训练数据明确，模型可压缩、可本地部署 自己推算（常见 ML 实践）
开放生成、长链推理、需要解释 通用 LLM 代码生成、复杂多步规划、需要自然语言回复或解释链 生成能力、上下文长度、推理能力 自己推算

3. 接入位置：网关/路由层，不是生成层

两个官方集成案例说明了 Jev 在链路中的位置。

LiteLLM 官方博客 显示，LiteLLM 将 Jev 用于 Auto Router 的分类环节。从博客标题列表可以看到一篇题为“TypeSafe Jev on LiteLLM Auto-Router: Switching Tiers Without Encrypted Content Failures”的文章，表明它是作为路由器的分类器，而不是生成节点。不过该博客的具体测试条件和性能数字（如标题所称“5.43x as Fast as Haiku, 96% Lower Cost”）本次未读取到正文，这里不展开（未能核实）。

Netlify changelog 给出了更完整的官方说明。Jev 现在可以直接在 Netlify AI Gateway 中使用，零配置，SDK 为 @typesafe-ai/sdk，无需创建 API key。changelog 明确写到：状态和问题共享约 32,000 token 预算（约 150,000 字符英文文本），TypeSafe 报告端到端响应时间为 70–500ms（官方数据）。这些数字说明它适合放在请求路径上做快速分诊，而不是离线批处理。

Netlify 的官方示例代码（有删减）如下：

import { choice, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();
const { answers } = await client.systemOne({
  state: await req.json(),
  questions: {
    team: choice("Route this contact form submission", {
      sales: null,
      support: null,
      spam: null,
    }),
  },
});

// answers.team.choice 只会是 "sales" | "support" | "spam" 之一
// 每个答案还带概率分布和 confidence，可据此决定是否升级到人工

这个示例体现了关键点：答案被约束在选项内，不需要 JSON 解析；同时携带置信度，可以设置门槛，高置信度直接执行，低置信度兜底。

4. 第三方实测：两类适合场景

第三方社区仓库的实测提供了两个场景的证据。

第一个是 60 例工具调用风险分类基准。该基准公开任务集，结论是 Jev 的校准成立（社区二手）。关键数字：准确率 91.7%（55/60）；按题目难度分层，清晰题（n=34）100%、模糊题（n=14）71.4%、对抗题（n=12）91.7%；ECE（10 个分箱）0.0712；延迟 p50 421.6ms、p95 542.0ms；平均输入 413 tokens，按 $0.042/百万 token 算单次约 $0.0000173；置信度恰好 1.000 的有 40/60，而这些高置信答案里没有一个是错的（5 次失误的置信度分别落在 0.130~0.785）。这意味着它输出的概率与真实风险水平具有一致性，适合作为工具执行前的“门禁”：对于高风险工具调用，即使 LLM 生成了动作，也要先经过一个独立的风险判断；判断通过再执行，不通过转人工。

但这个结论有两个必须一起说的限制（作者自己写的）：一是样本只有 60 例，任务分布是作者自己定的，不能外推成通用安全分类器；二是 0.9~1.0 这个置信度分箱里装了 60 例中的 50 例，也就是说 ECE 这个总分基本由这一个箱子决定——看分箱占用率，而不是只看一个 ECE 数字。另外作者记录了约 240 次调用中出现过 1 次瞬时 API 错误，重试后答案一致。

第二个是 物理 AI 实测。该仓库报告了机器人/边缘分诊场景下的延迟和账单数据，价格口径为 $0.042/百万输入 token、output free（第三方口径，社区二手），并在开头给出 70–500ms 的延迟量级。说明：本轮抓取时该仓库页面超时（raw.githubusercontent 连接超时），因此它内部更细的延迟分位数我没有逐项复核；上面那段具体的 p50/p95 来自 60 例基准仓库的复现结果，两者不是同一个测试，别混着比。

这两类实测都指向同一个结论：Jev 在链路里是“判断器”，而不是“执行器”。

5. 一个两段式链路的最小伪代码

下面给出一个“决策模型门禁/分级 → 通过则交给 LLM 或工具执行 → 低置信度走兜底”的最小链路：

state = build_state(user_input, tool_metadata, policy)

// 决策模型并行评估多个问题
answers = jev.system_one(state, {
  risk: noul("Does this tool call have irreversible side effects?"),
  intent: choice("Which tool category?", ["read", "write", "delete"]),
  urgency: score("How urgent is this request?", ["low", "medium", "high"])
})

if answers.risk.probability > 0.8 and answers.intent.choice == "delete":
    route_to_human_review  # 高风险 + 破坏性操作，即使置信度高也升级
else if answers.risk.probability < 0.3 and answers.intent.choice == "read":
    route_to_generic_llm_or_tool  # 低风险读操作，直接放行
else:
    route_to_fallback_rule_or_human  # 中间地带或低置信度，走兜底

这个伪代码不是生产代码，只是表达分层判断的思路：决策模型负责快速分级，生成模型只在通过后介入。

自己的判断：什么时候别用

以下清单是基于这次核实的来源和工程经验给出的判断，不是官方指南。

  1. 需要解释理由：如果用户或下游要求“为什么这么判断”，Jev 无法生成推理过程，因为你不给它生成能力。这时应该用通用 LLM 或人工。
  2. 输入是长自由文本且没有稳定结构：Jev 的状态和问题共享约 32k token 预算（官方数据），但它的强项是给定状态下的结构化判断。如果输入是松散的长篇叙述，判断边界本身就不清晰，用 LLM 先做摘要或抽取可能更合理。
  3. 判定结果必须可审计到规则级：在金融合规、医疗等场景，每个决策都要能追溯到明确规则。概率模型的校准不等于可解释，即使给出置信度，也不满足审计要求。此时应坚持规则引擎或决策树。
  4. 调用量极低：如果每天只有几十次调用，人工判断的准确率和成本可能都更优；引入决策模型反而增加维护和版本管理的复杂度。
  5. 不要为了让 AI 参与而用：如果正则和规则已经覆盖 95% 的边界，剩下 5% 人工处理，就不要用决策模型；过度设计只会增加延迟和故障点。

这次没核实的

  • Vercel AI Gateway 的具体接入方式：工单提到 Vercel，但本次来源集中未提供 Vercel 官方链接，未能核实。
  • LiteLLM 官方博客标题中“5.43x as Fast as Haiku, 96% Lower Cost”的测试条件与基准细节：仅见标题，未读取到正文。
  • 物理 AI 实测仓库中更细的延迟分位数与硬件型号：本轮抓取该仓库时连接超时（raw.githubusercontent），只核到价格口径与 70–500ms 的量级，未逐项复核。
  • 60 例基准任务集的标注细则（每条标签是谁标的、有无第二人复核）：任务集 tasks.jsonl 公开、可自行改标签重跑，但标注流程文档未在本次证据中展开。
  • Jev 模型的训练数据、参数量、知识截止时间等官方文档未披露。

参考来源

# Agent# 知识

评论区

0 条评论

登录后可评论。

大熊 2414 阅读