JEV 1.13 怎么用？从客服分流到 Agent 路由，实测这个低成本决策模型

JEV 1.13 怎么用？从客服分流到 Agent 路由，实测这个低成本决策模型#

“客户说支付接不上，已经影响营业。这张工单该转给谁？急不急？客户情绪怎么样？”

这是 AI 产品里很常见的小任务。你最终需要的可能只有三个字段：technical、一个紧急概率、一个情绪等级。这些字段决定工单进入哪个队列、排在什么位置，以及是否需要人工优先处理。

JEV 1.13 就擅长做这种边界明确的判断。 你给它背景和判断标准，它返回程序可以直接读取的选择、概率或评分。

最近关于 JEV 的介绍很多：有的讲“System One”，有的讲低成本和极速决策，有的把它接进 Agent 工作流。对想上手的人来说，最值得弄清楚的是：它能接走哪些任务，以及怎样验证它确实适合自己的业务。

本文先解释模型，再带你打开 [Crazyrouter JEV Decision Playground]playground 实际体验，最后给出可以直接调用的 Python 示例。文中的测试在 2026 年 9 月 23 日通过 Crazyrouter 进行，成功和超时都有保留。

JEV 1.13 是什么？先记住三个输出#

JEV 是 TypeSafe AI 推出的决策模型。官方将这类模型称为 System One Models：读取当前状态，快速完成分类、判断、评分，给软件提供可执行的判断依据。

它的输入主要由两个部分构成：

• state：背景事实。 可以是一段客服消息、一段文档，也可以是包含订单状态的 JSON 对象。
• questions：你希望判断的问题。 每个问题写明类型、判断说明，以及必要的选项或评分标准。

最核心的三种问题类型如下：

三种问题可以放进同一次请求。比如客服工单同时判断“哪个部门处理”“是否紧急”“情绪程度”，返回的三个结果直接供代码使用。

JEV 当前支持文本形式的输入，包括文本组成的对象和数组；不直接接收图片、音频或视频。写回复、写文章、生成代码这些任务，仍然交给生成式模型。这个能力边界在 TypeSafe 的 System One 文档 中有明确说明。

它厉害在哪里？让小判断值得被自动化#

1. 结果直接进入程序，少一层解释与转换#

假设你定义了三个部门：billing、technical、sales。

JEV 的 Choice 结果会给出其中一个选项，并附上概率分布。你的程序可以直接读取 answers.department.choice，根据结果选择处理队列。

通用大模型也能通过结构化输出完成分类。JEV 值得关注的地方，是它把有类型的判断与概率输出作为核心接口，并围绕这类任务优化。

对于每天要处理大量消息、文档或路由请求的系统，这种专门化有实际意义：你可以把分类结果、复核条件、执行动作分别写清楚。

2. 可以一次问多个独立问题#

同一份背景里，往往能提取多个判断：

• 客户在问什么？
• 是否影响正常使用？
• 是否需要尽快处理？

TypeSafe 官方文档说明，这些问题会针对同一份 state 独立、并行评估。应用层因此可以用一次请求拿到多个维度，再由代码组合。

这里有个使用细节：同一请求里的问题彼此独立。 如果第二步必须依赖第一步的答案，应让程序先读取第一步结果，再组织后续请求。

3. 单次输入成本很低，适合高频调用#

截至本次核验，参考价格为：

按每次请求合计 1,000 个输入 token 估算，单次输入费用约 $0.000042**；调用 10 万次，输入部分约 **$4.20。

这是按参考单价做的计算。背景、问题和标准都会占用输入预算；实际 token 数看响应 usage，本站最终实扣看消费日志。当前价格可在 Crazyrouter 模型列表 核对。

这意味着，一些以前“不值得专门调一次大模型”的小判断，也有机会加入产品：文档是否相关、反馈属于哪个主题、请求是否应该交给更强的模型等。

4. 概率可以帮助你设计处理分支#

选中 technical 之后，如果分布非常集中，程序可以直接分流；如果多个选项接近，就可以增加信息、改用其他模型或交给人工。

不过，confidence 不能直接当成正确率。 它描述返回分布的确定程度。某次返回 0.91，不表示这次判断已经被证明有 91% 的正确率。

官方强调的“校准”需要在一批带有参考答案的样本上评估。你仍然应该用自己的工单、自己的标准来选择阈值。详见 Confidence 文档。

不写代码，先在网页里跑一次#

打开 JEV Decision Playground，也可以直接进入 中文决策工作台。

页面提供 12 个可编辑场景：

建议第一次选“客服工单分流”，按下面的步骤操作：

1. 在 Token 管理页 获取 Crazyrouter API Token，填入工作台。
2. 保留默认场景，先读一遍背景和三个问题的标准。
3. 点击“运行决策”。
4. 在右侧查看部门选择、概率分布、情绪评分、耗时和 token 用量。
5. 将背景改成自己的文本，再运行一次，对比判断变化。

提交会产生真实 API 费用；输出不计费不代表整次调用免费。页面说明 Token 仅保留在当前页面内存中，不写入浏览器存储。

本次在实际网页上运行默认中文工单，得到：

• 部门：technical，该选项概率 0.94。
• 紧急概率：0.97。
• 情绪评分：1.01，对应的三个等级是“平静陈述事实 / 不满但克制 / 非常愤怒”。
• 页面显示耗时：0.70 秒。
• 用量：467 个输入 token，73 个输出 token。

实际返回版本为 typesafe/jev-1.13-20260917。这是一次真实网页调用的结果；重新运行时，概率和耗时可能变化。

页面还有“预览请求”，能查看 JSON、cURL、JavaScript 和 Python 示例。先把场景调到满意，再复制请求接入自己的产品，会比直接从空白代码开始更容易。

改一段背景，看看它会不会改变判断#

只跑默认示例，还不足以知道模型有没有用。更有价值的是保留问题标准，替换背景，观察它是否跟着证据改变答案。

我们通过同一个 Decisions 端点测试了 6 个不同输入。下面是实际记录：

这些结果能说明几件具体的事。

客服分类可以同时处理主题和语气。 把背景从“已经影响营业”换成“提前询价、不急”，部门和紧急概率都随之变化。

RAG 筛选可以把相关程度和可回答性分开。 一个片段可能高度相关，却仍然不足以完整回答问题。示例里相关性接近最高等级，可回答概率为 0.80，这两个维度分别有用途。

低成本不意味着没有调用失败。 证据不足的退款案例没有返回结果，因此我们不为它补写一个“模型正确选择了调查”的结论，也无法仅凭超时确定问题出在模型、上游服务还是网络路径。

本轮包含首测、两次重试和一次网页调用，共 9 次请求，6 次取得成功响应，3 次读取超时。六次成功响应报告的上游费用合计 $0.000115962；这不包含未核对的超时请求结算，也不是本站账户的完整实扣账单。

样本小，输入是人为编写的演示案例。这是上手和连通性测试，不能据此计算通用准确率或承诺服务稳定性。

“快几百倍”“没有幻觉”，应该怎么理解？#

TypeSafe 的 官方发布文章 写到：在其测试条件下，端到端响应为 70–500 毫秒；首页的 193.6 倍速度、444.6 倍成本优势来自特定工作流评测。官方也说明，这些收益处于实际应用中较高的一端，并交代了内部工作流和参考答案的构造方式。

这些数字帮助理解产品方向，但不能直接套用到你的网络、数据和整个 Agent 流程。

本次 Python 调用取得成功响应的耗时是 0.675–5.413 秒，网页一次显示 0.70 秒，另外发生了读取超时。这些时间包含本地到网关及上游的调用路径，和模型自身计算时间不是同一个指标。本次没有做与其他模型的同题速度对照。

“没有幻觉”也需要看限定范围。官方强调的是输出类型与预先定义的答案空间受到约束：如果候选项是三个部门，模型不会随意生成一个新的部门名。

选项合法，不代表选项一定正确。 模型仍可能把账单问题误分给技术团队，也可能对错误判断给出集中的概率分布。真正上线时，应保留已知答案的测试集，观察错误类型，再确定哪些判断可以自动执行。

开发者怎么接入？使用 Decisions API#

本次在 Crazyrouter 的 /v1/models 中确认了公开模型名 jev-1.13；网页使用 typesafe/jev-1.13，也已成功运行。成功响应会给出解析后的实际版本。

本次实测使用：

站点：https://crazyrouter.com
接口：POST /api/alpha/decisions
模型：jev-1.13
认证：Authorization: Bearer <Crazyrouter API Token>

JEV 使用专门的 Decisions 接口，不适用于把 model 改成 JEV 后继续调用 /v1/chat/completions 或 /v1/responses。这里返回同步 JSON，也不使用流式输出。

下面是与客服实测一致的完整 Python 请求。先安装 requests，并在本机环境变量中配置 CRAZYROUTER_API_KEY：

import json
import os

import requests

payload = {
    "model": "jev-1.13",
    "state": "我尝试连接 Stripe 已经 3 天了，集成一直失败，正在损失销售额。请尽快处理。",
    "questions": {
        "department": {
            "type": "choice",
            "instructions": "应该由哪个团队处理该工单？",
            "criteria": {
                "billing": "支付、账单或订阅问题",
                "technical": "错误或集成故障",
                "sales": "价格或采购问题",
            },
        },
        "is_urgent": {
            "type": "noul",
            "instructions": "这条消息是否表达了紧迫性？",
        },
        "frustration": {
            "type": "score",
            "instructions": "客户表现出的挫败程度如何？",
            "criteria": ["平静陈述事实", "不满但克制", "非常愤怒或使用激烈措辞"],
        },
    },
}

try:
    response = requests.post(
        "https://crazyrouter.com/api/alpha/decisions",
        headers={
            "Authorization": f"Bearer {os.environ['CRAZYROUTER_API_KEY']}",
            "Content-Type": "application/json",
        },
        json=payload,
        timeout=(10, 60),
    )
    response.raise_for_status()
except requests.Timeout as exc:
    raise SystemExit("请求超时：未取得判断。检查调用记录后再决定是否重试。") from exc
except requests.RequestException as exc:
    raise SystemExit(f"请求失败：{exc}") from exc

data = response.json()
answers = data.get("answers")
if not isinstance(answers, dict) or not all(
    key in answers for key in ("department", "is_urgent", "frustration")
):
    raise RuntimeError("响应没有完整的决策结果，请检查服务返回信息。")

print(json.dumps(answers, ensure_ascii=False, indent=2))
print("实际模型：", data.get("model"))
print("请求 ID：", data.get("id"))
print("用量：", data.get("usage"))

对应的首次 API 实测结果中，关键字段如下，省略了等级说明与部分概率分布：

{
  "id": "gen-dec-1790095587-mts183W9F0rPWFGshpnx",
  "model": "typesafe/jev-1.13-20260917",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "probabilities": {"technical": 0.94, "billing": 0.06, "sales": 0},
      "confidence": 0.91
    },
    "is_urgent": {"type": "noul", "noul": 0.98},
    "frustration": {"type": "score", "score": 1.01, "confidence": 0.98}
  },
  "usage": {"input_tokens": 467, "output_tokens": 73, "cost": 0.000019614}
}

这里有两个容易误读的字段：

Noul 0.98 是“是”的概率。 如果程序最终需要布尔值，你需要自行设置阈值。0.5、0.8 或 0.95 都只是可能的业务选择，应根据误判代价与验证样本决定。

Score 1.01 是等级索引的概率加权平均。 上例三个等级对应 0、1、2，因此它很接近“不满但克制”。Score 可以是小数，也不默认采用百分制。具体定义见 Score 官方文档。

最值得先试的三个业务位置#

客服入口：同时判断部门与紧急程度#

让 JEV 读取用户消息和已知订单状态，输出处理部门、紧急概率、需要补充的信息类别。程序根据结果建立队列，回复内容再由生成式模型或人工完成。

写选项时尽量清楚地区分边界，并为信息不足的情况预留“其他”或“需要进一步核实”。退款示例给出的只是建议，实际退款必须由你的业务系统按规则执行。

RAG 检索之后：筛掉不能帮助回答的片段#

拿到候选文档后，可以分别问“是否相关”和“能否支持回答”，再决定哪些片段进入最终生成上下文。

如果候选片段很多，应测量筛选本身增加的费用和等待时间。它节省了多少生成输入、是否误删重要证据，需要通过业务数据验证。

Agent 调用工具之前：选择下一步处理器#

把可用动作定义为 Choice，比如“查订单”“搜索知识库”“询问用户”“转人工”。JEV 选择动作，代码执行对应流程。

它适合承担这样的判断节点。接入方法与更多模式可参考 TypeSafe 快速入门，其他模型和接口可从 Crazyrouter API 文档 查看。

常见问题#

JEV 可以直接替换 Claude Code、Codex 或 Cursor 的主模型吗？#

不能。它不会生成代码、连续对话或像编程模型一样输出工具调用流程。你可以让编程 Agent 帮你写一个使用 JEV 的分类器或路由器。[官方 coding agents 文档]agents 对这点有专门说明。

JEV 支持中文吗？#

本次中文客服、中文问题说明与中文 RAG 片段均取得了有效结果。但这几个案例不足以证明其在所有中文业务上的准确性；专业术语、长文本和边界案例需要单独测试。

JEV 在线体验免费吗？#

Crazyrouter 工作台运行的是实际计费请求，需要本站 API Token。模型的输出单价为零，输入仍计费。不要把其他平台的临时免费活动套用到这里。

为什么接口返回有 output_tokens，但输出价格又是零？#

输出 token 统计与输出计费是两个不同概念。此次成功响应包含 output_tokens，参考价格的输出费率为零。

输入里只写“帮我看看”可以吗？#

你应提供足够的背景，并明确要判断的事情。比如把“这个客户好不好”拆成“是否有采购计划”“需求是否匹配”“是否愿意安排技术评估”。更清楚的问题标准有利于判断，也更容易测试。

confidence 很高，可以直接自动执行所有动作吗？#

不应只看一个数字。先用已知答案的案例验证，再按动作代价设置执行条件。分类标签与实际扣款、锁号等操作的错误代价不同，适用阈值和复核流程也应不同。

超时了是不是代表没有消费？#

不一定。客户端没有拿到响应，无法证明服务端没有处理。应检查调用与消费记录；本次报告只汇总已取得响应的费用，没有把超时请求视为免费。

现在就用你自己的两段文本试试#

打开 JEV 决策工作台，先跑默认客服工单，再改成一段“不紧急的普通询价”。保留相同的问题定义，观察部门、紧急概率和情绪评分怎么变化。

随后从你真实业务里挑一组已有答案的案例：清楚的、模糊的、容易混淆的都放进去。如果它能在可接受的费用和耗时下，稳定接走其中一类判断，就有了值得接入产品的位置。

资料与测试说明：本文依据 TypeSafe 官方发布与文档、Crazyrouter 当前模型信息、2026-09-23 的 API 和线上网页调用撰写。配图为实际页面截图及流程示意。官方性能主张已单独标明，本次小样本结果不作为通用基准排名。