api.new.bi 的 `/v1/responses` 接入 TypeSafe System One jev决策模型

一、Jev 是什么：一个不写作文，只做判断的模型

Jev 是由 TypeSafe AI 发布的 System One（系统 1）决策模型。它的定位非常明确：不生成任何自由文本，只输出结构化判断结果。

用一句话概括它和普通大模型的区别：

传统大模型负责「生成内容」，Jev 负责「做判断」。

你把一份业务上下文 state 和一组问题 questions 提交给它，它会并行返回每个问题的判定结果——带概率、带置信度、带加权分数。结果可以直接喂给代码里的 if，不需要再写解析器去猜模型想说什么。

这就是 TypeSafe System One 决策模型 被称作「机器原生决策」的原因：它的输出天然是给程序读的，而不是给人读的。

Jev 的核心特征

特征	说明
无自由文本输出	返回纯结构化 JSON，无需后处理
一次多问	一个请求提交多组 `questions`，并行独立判定
概率化结果	每个问题返回概率分布 + 置信度
面向工程	可直接嵌入业务逻辑，做高频决策任务
当前版本	`jev-1.13.0`（别名 `jev-latest`）

Jev 适合做什么

工单路由：一条工单同时判「是否退款 + 归属团队 + 紧急度」

内容安全：违规判定 + 违规类目分类

意图分类：客服对话意图识别、满意度打分

风险打分：Agent 工具调用前的操作风险评级

置信度路由：低置信度结果自动转人工

二、Jev 国内使用：为什么需要第三方接口

Jev 官方只提供原生接口与 SDK，国内开发者实际接入时会遇到几个现实问题：

直连体验不稳定，官方 SDK 需要单独配置

计费口径与现有系统不统一，你的项目可能已经在用一套统一账单

协议不统一，团队里有的服务用 OpenAI 风格，有的用 Anthropic 风格

调试成本高，出问题只能看到一句模糊报错，没有本地日志

所以「Jev 第三方接口」成了很自然的选择：找一个兼容 OpenAI / Anthropic 协议、统一计费、可观测的中转网关，把 Jev 当成普通模型挂进来。

api.new.bi 就是这样一个网关。

三、为什么推荐用 api.new.bi 接入 Jev

api.new.bi 是一个 AI API 网关，聚合多家上游模型，用统一的 OpenAI / Anthropic 兼容协议对外提供服务。把 Jev 模型接进 api.new.bi，你能直接拿到这些好处：

优势	具体表现
双协议支持	同一模型同时提供 `/v1/responses` 与 `/v1/messages`，团队用什么风格都能接
统一鉴权	一把 `sk-` 密钥访问全部模型，不用为 Jev 单独管一把 key
精确按量计费	token 用量取自上游真实值，与上游账单一致，不估算
可观测	每次调用都有日志，Jev 调试时能直接查到请求、响应、token 与耗时
免改代码	OpenAI SDK / Anthropic SDK 直接指向 `api.new.bi` 即可

对国内团队来说，把 Jev API 挂到 api.new.bi 上，是接入成本最低、后续最好维护的方式。

四、接入准备

1. 获取密钥

在 api.new.bi 控制台创建一个令牌，形如：

sk-xxxxxxxxxxxxxxxxxxxxxxxx

2. 确认端点

api.new.bi 上调用 jev-1.13.0，推荐使用 /v1/responses：

POST https://api.new.bi/v1/responses
Authorization: Bearer sk-xxxxxxxx
Content-Type: application/json

重点提醒：请使用 /v1/responses，不要用 /v1/chat/completions。
原因见第八节「计费」——后者会导致 token 用量统计失准。

五、`/v1/responses` 请求参数详解

顶层参数

参数	类型	必填	说明
`model`	string	是	固定填 `jev-1.13.0`
`input`	any	是	占位字段，填任意非空值即可（如 `"placeholder"`）。Jev 不使用该字段
`state`	string \| object \| array	是	待判定的业务上下文
`questions`	object	是	判定问题集合

input 只是为了让网关的请求校验通过，不参与判定，可以直接填 "placeholder"。

`state`：把业务数据原样丢进去

state 支持三种形态，推荐对象形态，因为不需要你拼接长文本：

纯文本（适合用户原话）：

"state": "用户：结账页面点击支付后一直空白，换了两个浏览器都不行"

对象（适合业务原始数据，推荐）：

"state": {
  "message": "订单 A-104 被扣两次钱，请退还重复扣费",
  "policy": "重复扣款符合退款条件",
  "order": { "charges": [49, 49] }
}

数组（适合多轮反馈的聚合）：

"state": [
  "第一次反馈：支付后页面空白",
  "第二次反馈：仍然无法支付，已影响全天订单"
]

`questions`：三种问题类型

这是 Jev 最有价值的设计——同一个请求里可以混用三种问题类型，并行计算。

类型一：`noul` —— 是非判定

输出「是」的概率，取值 0~1。

"is_refund": {
  "type": "noul",
  "instructions": "用户是否在申请退款",
  "criteria": {
    "true": "用户明确提出退款诉求",
    "false": "没有退款请求"
  }
}

字段	必填	类型	说明
`type`	是	string	`"noul"`
`instructions`	是	string	判定指令，必须提供
`criteria`	否	object	true / false 的语义边界

常见错误：只写 criteria 不写 instructions，会直接报错。

类型二：`choice` —— 单选分类

从枚举选项里选一个，并返回全选项概率分布与置信度。

"department": {
  "type": "choice",
  "instructions": "该工单应交给哪个团队处理",
  "criteria": {
    "billing": "账单、发票、退款相关",
    "technical": "功能缺陷、集成故障",
    "account": "账号登录、资料问题"
  }
}

字段	必填	类型	说明
`type`	是	string	`"choice"`
`instructions`	否	string	判定指令
`criteria`	是	object	key 为选项标识，value 为语义说明。1~255 个选项

类型三：`score` —— 有序等级打分

输出概率加权后的连续分数，可以落在两个等级之间。

"frustration": {
  "type": "score",
  "instructions": "客户情绪严重程度",
  "criteria": ["平静", "沮丧", "非常愤怒"]
}

字段	必填	类型	说明
`type`	是	string	`"score"`
`instructions`	否	string	判定指令
`criteria`	是	array	顺序即等级（下标 0、1、2……）。2~10 个等级

参数速查表

类型	`criteria` 类型	数量限制	额外必填
`noul`	object（可选）	—	`instructions`
`choice`	object	1~255	`criteria`
`score`	array	2~10	`criteria`

choice 用对象、score 用数组，写反会报错。

六、返回结果详解

完整返回结构

{
  "model": "jev-1.13.0",
  "answers": {
    "is_refund": {
      "type": "noul",
      "noul": 0.96
    },
    "department": {
      "type": "choice",
      "choice": "billing",
      "confidence": 0.88,
      "probabilities": { "billing": 0.91, "technical": 0.05, "account": 0.04 }
    },
    "frustration": {
      "type": "score",
      "score": 1.2,
      "confidence": 0.71,
      "legend": { "0": "平静", "1": "沮丧", "2": "非常愤怒" },
      "probabilities": { "0": 0.1, "1": 0.7, "2": 0.2 }
    }
  },
  "usage": {
    "input_tokens": 1970,
    "output_tokens": 70
  }
}

各类型输出字段

类型	输出字段
`noul`	`noul`（0~1 概率，无 `confidence`）
`choice`	`choice`、`probabilities`、`confidence`
`score`	`score`、`legend`、`probabilities`、`confidence`

三个解析要点

① legend 是对象，不是数组

"legend": { "0": "平静", "1": "沮丧", "2": "非常愤怒" }

② score 的 probabilities 也是对象

"probabilities": { "0": 0.1, "1": 0.7, "2": 0.2 }

③ answers 的键顺序不固定

返回顺序按字典序重排，与你在 questions 里的书写顺序无关。一律按问题 ID 取值，不要依赖下标。

usage

字段	说明
`input_tokens`	输入 token，计费依据
`output_tokens`	输出 token

经 api.new.bi 的 /v1/responses 调用时，这两个值与上游真实用量完全一致。

七、完整调用示例

curl

Python（OpenAI SDK）

因为 /v1/responses 是 OpenAI 协议族端点，可以直接用官方 OpenAI SDK，只需把 base_url 指向 api.new.bi，并用 extra_body 传入 Jev 专有字段：

用 with_raw_response 是为了直接拿到 Jev 的原生 answers 结构，避免 SDK 按标准 Responses 结构解析。

Python（requests，最直接）

JavaScript

结果消费：把判定接进业务逻辑

八、计费：为什么必须用 `/v1/responses`

这是 Jev 第三方接口调试中最容易踩的坑，单独说明。

api.new.bi 按输入 token 计费，依据是上游返回的真实 usage。而 Jev 返回的 token 字段名是：

"usage": { "input_tokens": 1970, "output_tokens": 70 }

/v1/responses 的协议规范里使用的正是 input_tokens / output_tokens，因此网关能精确读取真实用量。

而 /v1/chat/completions 的规范字段是 prompt_tokens / completion_tokens，Jev 不返回这两个字段，网关取不到值后会退化为估算——实测同一份 state 下：

端点	统计到的输入 token
`/v1/responses`	1970（真实值）
`/v1/chat/completions`	9（估算值，严重偏离）

结论很直接：

调用 Jev API，请使用 /v1/responses。
用 /v1/chat/completions 会导致计费与上游账单严重不一致。

关于输出计费：output_tokens 在 /v1/responses 下会被正确统计。如果你的业务希望与上游「输出免费」的口径保持一致，可以在 api.new.bi 中把该模型的补全倍率调低或设为 0。

九、核心场景案例

案例 1：工单智能路由

一次请求拿到三个判定，替代三次串行调用。

{
  "model": "jev-1.13.0",
  "input": "placeholder",
  "state": {
    "ticket": "订单 A-104 被扣两次钱，请退还重复扣费，已经等了两天没人回",
    "policy": "重复扣款属于退款条件",
    "order": { "charges": [49, 49], "waited_hours": 48 }
  },
  "questions": {
    "is_refund": { "type": "noul", "instructions": "用户是否在申请退款" },
    "department": {
      "type": "choice",
      "instructions": "该工单应交给哪个团队",
      "criteria": {
        "billing": "账单、发票、退款",
        "technical": "功能缺陷、集成故障",
        "account": "账号与资料问题"
      }
    },
    "priority": {
      "type": "score",
      "instructions": "处理优先级",
      "criteria": ["低", "中", "高", "紧急"]
    }
  }
}

价值：不用写分类规则、不用训练分类模型，一次调用完成分流 + 优先级排序。

案例 2：内容安全判定

noul 做闸门，choice 定违规类目。

{
  "model": "jev-1.13.0",
  "input": "placeholder",
  "state": "用户提交的评论：<待审文本>",
  "questions": {
    "is_violation": { "type": "noul", "instructions": "内容是否违反社区规范" },
    "category": {
      "type": "choice",
      "instructions": "违规类目",
      "criteria": {
        "spam": "垃圾营销",
        "harassment": "人身攻击",
        "adult": "成人内容",
        "normal": "无违规"
      }
    }
  }
}

价值：is_violation 阈值可调召回率，probabilities 可用于人工复审队列排序。

案例 3：Agent 工具调用前的风险校验

{
  "model": "jev-1.13.0",
  "input": "placeholder",
  "state": {
    "user_request": "把上个月的报表全部删掉",
    "pending_tool_call": {
      "name": "delete_reports",
      "args": { "period": "last_month", "scope": "all" }
    },
    "policy": "删除类工具需要用户显式确认，且不允许批量删除"
  },
  "questions": {
    "should_execute": { "type": "noul", "instructions": "该工具调用是否应直接执行" },
    "risk": {
      "type": "score",
      "instructions": "该操作的风险等级",
      "criteria": ["安全", "低风险", "高风险", "危险"]
    }
  }
}

价值：给 Agent 加一层可量化的护栏，比让模型「自己想一想」稳定得多。

案例 4：客服意图分类与满意度质检

{
  "model": "jev-1.13.0",
  "input": "placeholder",
  "state": "客服通话转写：<通话文本>",
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "客户主诉意图",
      "criteria": {
        "cancel": "要退订/解约",
        "complaint": "投诉体验",
        "consult": "咨询产品",
        "renew": "要续费"
      }
    },
    "satisfaction": {
      "type": "score",
      "instructions": "客户满意度",
      "criteria": ["很不满意", "不满意", "一般", "满意", "很满意"]
    }
  }
}

案例 5：结构化字段抽取

需要从非结构化文本得到确定值时，用 choice 把选项写成枚举，比让生成模型吐 JSON 可靠得多。

{
  "model": "jev-1.13.0",
  "input": "placeholder",
  "state": "邮件正文：<邮件文本>",
  "questions": {
    "urgency": {
      "type": "choice",
      "instructions": "紧急程度",
      "criteria": { "p0": "需立即处理", "p1": "当日处理", "p2": "本周处理" }
    },
    "needs_reply": { "type": "noul", "instructions": "是否需要人工回复" }
  }
}

十、Jev 调试与排错速查

在 api.new.bi 上做 Jev 调试，可以直接在日志里看到完整请求与响应，配合下表定位问题。

报错	原因	解决
`model, state and questions are required`	顶层必填参数缺失	补全 `model` / `state` / `questions`
`input is required`	`/v1/responses` 缺少 `input`	填 `"placeholder"`
`state must be a string, object or array`	`state` 传了数字等非法类型	改为字符串 / 对象 / 数组
`question "q" has unsupported type "xxx"`	`type` 非法	只能是 `noul` / `choice` / `score`
`question "q" needs instructions or criteria`	`noul` 缺 `instructions`	补上 `instructions`
`needs criteria`	`choice` 缺 `criteria`	补上选项对象
`must be an object with 1 to 255 options`	`choice` 的 `criteria` 写成了数组	改为对象
`score criteria must be an array of 2 to 10 levels`	`score` 的 `criteria` 写成了对象，或等级数越界	改为 2~10 项的数组
`max_tokens_exceeded`	单条 `state` + question 超 32k token	拆分上下文
`Token not provided`	缺少 `Authorization` 头	补 `Authorization: Bearer sk-...`
`无可用渠道（distributor）`	该路径未配置路由	在渠道的「高级自定义路由」中补充对应 `incoming_path`

三个最常见的调试误区

误区 1：串行提问

很多人受「省 token」习惯影响，一次只问一个问题，连发三次请求。Jev 的设计就是一次问多组，并行判定不额外增加往返延迟，串行反而浪费时间和调用次数。

误区 2：以为需要写解析器

Jev 输出结构化 JSON，直接取值即可，不需要正则或二次模型解析。

误区 3：用 /v1/chat/completions 调试后对不上账

这是计费失准的根源，请统一用 /v1/responses（或 /v1/messages）。

十一、限制与注意事项

项	限制
上下文总长	64k token
`state` + 单条 question	32k token
输入模态	仅文本，不支持图片 / 音频 / 视频
训练语言	以英文为主，中文可用但建议自测精度
`score` 等级数	2~10
`choice` 选项数	1~255
速率	250k token/s，1200 请求/分钟（动态调整）

无效参数：temperature、max_tokens、stream、response_format 等生成式参数对 Jev 无意义。传 stream: true 也不会返回 SSE 流，始终返回单个 JSON 对象。

十二、FAQ

Q1：Jev 在国内怎么用？
A：通过 api.new.bi 这类兼容 OpenAI / Anthropic 协议的网关接入最省事。把 base_url 指向 https://api.new.bi/v1，用 sk- 令牌鉴权，模型填 jev-1.13.0 即可，无需改业务代码结构。

Q2：Jev 会生成文字吗？
A：不会。Jev 是 System One 决策模型，只输出结构化判定结果（概率、选项、分数、置信度），没有任何自由文本。

Q3：用 OpenAI SDK 能调 Jev 吗？
A：可以。用 /v1/responses 端点，base_url 设为 https://api.new.bi/v1，Jev 专有参数通过 extra_body 传入。

Q4：应该用哪个端点？
A：/v1/responses 或 /v1/messages 都可以，两者实测行为一致。不要用 /v1/chat/completions，会导致 token 统计与计费失准。

Q5：noul 和 choice 的 criteria 有什么区别？
A：noul 的 criteria 是可选对象，且必须同时提供 instructions；choice 的 criteria 是必填对象（1~255 个选项）。

Q6：为什么 score 的返回值可以是小数？
A：score 是概率加权后的连续分数，可以落在两个等级之间，例如 1.2 介于「沮丧」和「非常愤怒」之间。

Q7：一次能问多少个问题？
A：单个请求可提交多组 questions，三类问题可自由混用、并行计算。注意问题之间互相不可见，不能做链式推理。

Q8：Jev API 计费怎么算？
A：按输入 token 计费，依据 /v1/responses 返回的 input_tokens，与上游真实用量一致。output_tokens 也会被统计，可通过补全倍率调整。

十三、总结

Jev 是 TypeSafe AI 的 System One 决策模型：不生成文本，只输出结构化判断

它适合工单路由、内容安全、意图分类、风险打分、置信度路由等判定类场景

国内接入 Jev API，推荐通过 api.new.bi：双协议兼容、统一鉴权、精确计费、日志可观测

调用端点是 /v1/responses，参数只需 model + input + state + questions

questions 支持 noul（是非）/ choice（单选）/ score（打分） 三类混用、并行判定

记住那个坑：别用 /v1/chat/completions

一句话落地：把 Jev 挂到 api.new.bi 上，用 /v1/responses 调，一次请求拿到全部判定结果。

api.new.bi 的 `/v1/responses` 接入 TypeSafe System One jev决策模型

一、Jev 是什么：一个不写作文，只做判断的模型#

Jev 的核心特征#

Jev 适合做什么#

二、Jev 国内使用：为什么需要第三方接口#

三、为什么推荐用 api.new.bi 接入 Jev#

四、接入准备#

1. 获取密钥#

2. 确认端点#

五、/v1/responses 请求参数详解#

顶层参数#

state：把业务数据原样丢进去#

questions：三种问题类型#

类型一：noul —— 是非判定#

类型二：choice —— 单选分类#

类型三：score —— 有序等级打分#

参数速查表#

六、返回结果详解#

完整返回结构#

各类型输出字段#

三个解析要点#

usage#

七、完整调用示例#

curl#

Python（OpenAI SDK）#

Python（requests，最直接）#

JavaScript#

结果消费：把判定接进业务逻辑#

八、计费：为什么必须用 /v1/responses#

九、核心场景案例#

案例 1：工单智能路由#

案例 2：内容安全判定#

案例 3：Agent 工具调用前的风险校验#

案例 4：客服意图分类与满意度质检#

案例 5：结构化字段抽取#

十、Jev 调试与排错速查#

三个最常见的调试误区#

十一、限制与注意事项#

十二、FAQ#

十三、总结#