TypeSafe Jev 接入 CodeGateway | 类型化决策调用指南

大多数接入 AI 的应用并不需要另一个聊天机器人。它们需要的是一句明确的判断：这条工单归哪个队列、这个 agent 想执行的命令危不危险、这次请求该路由给哪个模型。这类判断过去靠提示词加解析，成本和延迟都按整段文本生成来付。

TypeSafe 的 Jev 走的是另一条路：它不生成文本，只回答问题，并给出概率。我们把它接进了 CodeGateway，跑在 POST /v1/systemone 上。

为什么单独开一个端点

Jev 的请求体是 { state, questions }，返回是 { model, answers, usage }——没有 choices[]，也没有可流式输出的正文。它和聊天补全不是同一种形状，硬塞进 /v1/chat/completions 只会得到上游的 400：我们把 messages 发过去时，Cloudflare 直接回了一句 Unsupported fields passed: messages, stream. Valid fields: state.。

所以 CodeGateway 没有做兼容层去伪造聊天接口，而是加了一个独立分支：POST /v1/systemone，请求和响应都保持 Jev 的原生形状。GET /v1/models 里它的那一行带 api: "systemone" 标记，客户端按这个字段分流，不会误发给聊天端点。

一次调用长什么样

bash

curl https://api.codegateway.dev/v1/systemone \
  -H "Authorization: Bearer $CODEGATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "我们的 API 集成 20 分钟前开始每个请求都返回 500，订单处理全部卡住。",
    "questions": {
      "urgent": {
        "type": "noul",
        "instructions": "这段内容是否表达了紧急或时效性？"
      },
      "department": {
        "type": "choice",
        "instructions": "这条请求应该交给哪个队列处理？",
        "criteria": {
          "billing": "费用、发票、退款",
          "technical": "程序缺陷、故障、集成问题",
          "sales": "价格、升级、新账号"
        }
      },
      "complexity": {
        "type": "score",
        "instructions": "这个请求需要多少推理？",
        "criteria": ["简单：单一事实", "中等：几步、单一领域", "困难：多个约束交织"]
      }
    }
  }'

返回是类型化答案加概率，而不是一段需要再解析的文字（codegateway 那一块是网关自己加的账务信息，其余字段原样透传）：

json

{
  "model": "jev-1.13.0",
  "answers": {
    "urgent": { "type": "noul", "noul": 0.99 },
    "department": {
      "type": "choice",
      "choice": "technical",
      "confidence": 0.92,
      "probabilities": { "billing": 0.03, "technical": 0.92, "sales": 0.05 }
    },
    "complexity": { "type": "score", "score": 1.07, "confidence": 0.88 }
  },
  "usage": { "input_tokens": 527, "output_tokens": 74 }
}

三类问题覆盖了绝大多数"智能 if 语句"：noul 回答是或否并给出"是"的概率，choice 从固定选项里选一个并返回整个分布，score 在有序档位上打分。一次请求可以并行问多个问题，多问几个几乎不增加延迟——只多花一点输入 token。

我们实测的数字

从我们的开发机直连 Cloudflare 发起的四次调用（路由紧急故障、路由普通查询、判断 rm -rf 是否危险、判断 git status 是否安全）：

端到端延迟 420–1125 毫秒。TypeSafe 的服务目前主要部署在美国西岸，从亚洲发起的网络往返明显吃掉了它标称的 70–500 毫秒，所以这个数字更接近跨境访问的现实。
每次调用成本约 $0.00002：输入按 $0.042/MTok 计费（约合 $42/十亿 token），输出免费。
行为符合预期：紧急故障的 urgent 概率 0.99、路由到 frontier；普通查询 0.05、路由到 cheap；rm -rf 的危险判定 0.87、建议 confirm/block；git status 0.01、建议放行。

它不能做什么

两个容易踩的坑值得说清楚。

第一，类型安全不等于事实正确。它不会输出 schema 之外的值，但完全可能给一个格式合法、内容错误的答案。真正能救你的是那个概率：低于阈值的答案应该走人工复核或交给更强的模型，而不是硬跑。我们跑的例子里就能看到这个信号——rm -rf 那次的 action 分布是 block 0.5 / confirm 0.5、confidence 只有 0.25，模型在"直接拒绝"和"先问人"之间摇摆；这种答案正好该被 harness 转成一次确认，而不是挑概率最高的硬执行。

第二，它不能替代大模型。Jev 只接受文本输入（state 可以是字符串、JSON 对象或数组），state 加最长问题要落在 32k token 预算内（整请求 64k），不支持图像、音频、视频，也不生成任何文字。英文准确率最好，其他语言包括中文可用，但建议先在自己的数据上验证一遍。

CodeGateway 侧的实现

通道：Cloudflare 模型目录里的 typesafe/jev，经 REST /accounts/{id}/ai/run 调用，走 Unified Billing。CodeGateway 不持有、也不需要任何 TypeSafe 的 provider key——和仓库里其它上游一样是 keyless 的。
计费：只按输入 token 计费，输出免费。价格同时写进了 D1 的 model_costs（迁移 0159）和代码里的兜底表，两者由平价门禁强制一致。
计量：预扣、调用、结算走和其它媒体通路一样的流程，request_logs 里能看到每次调用的 token、成本和延迟。
响应：Jev 的原始 model / answers / usage 字段原样返回，外面包一层 codegateway 块（cost_usd_micro / markup / latency_ms），调用方不用自己算账。

什么时候该用它

如果你的系统里已经有一堆"让大模型输出 JSON 然后解析"的判断点——分类、路由、打分、护栏——Jev 这类模型值得单独拿出来试：它把这些判断从"生成一段文字再解析"变成"一次类型化推理"，延迟和成本都低一个数量级。但如果你的任务需要生成、需要多步推理、或者需要看图片，它帮不上忙，那还是留给聊天模型。

在 CodeGateway 上调用 TypeSafe Jev：用类型化决策替代聊天补全