你付着前沿模型的价格，去问一个是非题。模型写了一小段散文，你从散文里把答案解析出来，包一层重试，再加一个 schema 校验器，因为它有时候写「Yes!」，有时候写一段关于细微差别的长篇论述。

你两年前就知道这很浪费。你只是一直没有别的地方可以发这个调用。

2026 年 9 月 15 日，TypeSafe AI 结束了两年隐身。他们唯一的产品叫 Jev，40 百万美元的种子轮由 DCVC 领投，创始人是 Diogo Almeida，在 OpenAI 参与过 RLHF 和 InstructGPT 的那批工作。Jev 最反直觉的地方在于它不能写字：不生成散文，不生成代码，不聊天。你给它一段程序状态和一组带类型的问题，它在一次并行采样里返回选项、档位和概率，70 到 500 毫秒。

这个特质让它几乎是为 Codex 这类编程 agent 的「检查位」量身定做的。而围绕它的开源集成，在过去一周里已经长出了四种相当成熟的形态。

一、Jev 是什么：一次调用，三种问法#

TypeSafe 把这类模型叫做 System One，取自 Kahneman 的快思考。他们的赌注是：软件内部的大多数决策本来就是 System 1 判断（这属于哪个桶、这个紧急吗、这个相关吗），而我们一直在租 System 2 来做它们。

整个 API 只有三种问题类型。这不是一个需要绕开的限制，这就是设计本身。

Choice 从一个集合里挑一个选项，最多支持 255 个。返回 .choice、每个选项的概率分布、以及一个置信度。这是分类和路由的原语，在循环里它同时也是命名的停止状态：继续、重试、停止、询问。

Score 把一个状态放在有序的光谱上，2 到 10 个档位，每个档位用文字描述。返回值可以落在档位之间，比如 1.035。档位索引来自数组顺序，所以第 0 档是第一个元素。

Noul 是个生造词。你给一句陈述，它返回 0 到 1 之间的一个数，即这句话成立的概率。它没有单独的置信度字段，因为那个数字本身就是信念。接近 1 是强肯定，接近 0 是强否定，接近 0.5 意味着模型不知道。

价格是每百万输入 token 0.042 美元，输出不计费。状态和问题的合计上下文大约 32k token。端点只有一个：POST https://api.typesafe.ai/v1/systemone。

训练方法叫 RLCD，Reinforcement Learning for Calibrated Decisions。RLHF 优化的是让人类评审偏好这段文本，RLCD 优化的是让输出的概率在总体上正确。这两个目标不一样，而这个差别就是整个产品。Almeida 给媒体的说法很短：问题出在文本本身。

名字致敬的是经济学家 William Stanley Jevons。Jevons 悖论讲的是：一项资源的效率提升之后，它的总体消耗反而上升，因为原先不划算的用途变得划算了。把一次决策的边际成本压到接近零，对决策的需求就会爆炸。

Jev前沿 LLM
端到端延迟70ms 到 500ms3s 到 329s
输入价格$0.042 / 百万 token$0.20 到 $10 / 百万 token
输出价格免费约为输入价格的 5 倍
结构化输出错误0%（由构造保证）0.58% 到 45.5%

需要提前说明：这张表是 TypeSafe 自己跑出来、未被独立复现的数字。我在最后一节会回到这件事上。

二、为什么它天然落在 Codex 的「检查位」#

一个生产级的 agent 循环有两个角色。maker 负责写、规划、打补丁、调工具。checker 负责判断这份工作是否完成、是否安全、是否够好到可以交付。

Jev 当不了 maker，它一句话也写不出来。它是一个 checker 形状的模型。循环还是两个角色，只是 checker 换了物种。

两个后果来自架构本身，而不是来自训练质量，这才是真正值得在意的地方。

它没法胡说，因为它输出不了散文。 没有自由文本通道可以出错。它不是被教会了不要啰嗦，它是设计上就啰嗦不出来。有些网关目录仍然会在响应里报出少量输出 token，那只是计费口径，不是一段话，你读不到它也不用为它付钱。

它出不了类型错误。 你事先声明形状，采样器被约束在这个形状里。没有 JSON 修复，没有 except JSONDecodeError，也没有「换一个更严厉的提示词重试」。这一整层代码从「更可靠」变成了「不必要」。

代价同样是结构性的。没有思维链可以检视，因为没有思维链。它能告诉你这份工作失败了，但它没办法告诉 maker 该怎么改。对 checker 这个位置来说，这是同一个句子的特征和局限。

三、四种接法#

3.1 MCP 工具层：把「选哪个能力」和「证据排序」外包出去#

jev-in-codex（作者 teempai）是一个本地 MCP server，暴露三个工具。

工具输入输出
jev_select_capability目标，以及一份你提供的工具/技能清单排序后的候选，可以推荐「都不选」
jev_search问题、工作区范围、可选查询词重排后的代码/文档片段，带路径和行号
jev_triage问题，以及一份已保存的输出产物相关原文片段、完全重复的分组、覆盖度

接法是往 ~/.codex/config.toml 里加一段：

[mcp_servers.jev]
command = "node"
args = ["/absolute/path/to/jev-in-codex/dist/index.js", "--root", "/absolute/path/to/your-project"]
env_vars = ["TYPESAFE_API_KEY", "JEV_MODEL"]
tool_timeout_sec = 90

它自己划的边界很干净，我觉得这点比功能本身更值得注意：Codex 提供目标并做最终决定，服务器只在本地检索有界候选、问 Jev 相关性问题、返回原始证据。它不执行被选中的能力，也不拦截任意的 Codex 工具调用，更不替代 Codex 的压缩。作者也坦白这是实验性 MVP，排序质量和时间/token 节省都没有做过基准测试。

3.2 权限闸门：在 PreToolUse 里放一个几乎零成本的判断#

jev-use（作者 shitianfang）的接法更轻：

codex mcp add jev -- npx -y "jev-use@0.7.1" serve

等价的手写配置：

[mcp_servers.jev]
command = "npx"
args = ["-y", "jev-use@0.7.1", "serve"]
env_vars = ["TYPESAFE_API_KEY", "OPENROUTER_API_KEY", "AI_GATEWAY_API_KEY"]

Codex 通过标准的 tools/list 调用发现 jev_judge 和 jev_gate 两个工具。这里有个细节需要注意：Codex 目前没有插件 skill 机制，所以作者的建议是把 skills/jev-use/SKILL.md 里的路由表粘到你的 AGENTS.md，模型才知道什么时候该把棒交出去。

真正有意思的是那个可选的 PreToolUse 闸门 hook。Codex 的 hook 是 Claude 形状的，所以同一份适配器可以直接复用。在 ~/.codex/hooks.json 里写：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "npx -y jev-use@0.7.1 hook gate",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

Codex 要求你先通过 /hooks 审查并信任非受管的 hook，之后它才会运行。另外两个环境变量 JEV_GATE_THRESHOLD 和 JEV_GATE_STATE 需要在 Codex 的运行环境里导出，后者用来携带 hook 事件本身装不下的事实，会被附加到每一个被判定的状态上。

如果让我挑一种先试，我会挑这个。原因是它落在最需要「便宜且快」的那个位置上。闸门这个位置的特征是高频、单次信息量低、答案只有两三种。之前你只能用一个小模型来做，延迟和成本都还挂在账上。现在这个位置的边际成本几乎可以忽略，于是你可以开始问一些以前问不起的问题。

3.3 上下文压缩：只删「可验证的只读证据」#

codex-jev-compaction（作者 Wang-auspicious）解决的是长任务里最烦人的一件事：工具输出不断堆积，而那些东西早就没用了。生成的摘要可能丢掉一条精确的约束、一个路径、一段报错。

codex plugin marketplace add Wang-auspicious/codex-jev-compaction
codex plugin add codex-jev-compaction@codex-jev-compaction

它由一个 skill、一个 stdio MCP 工具、一个零依赖 CLI 组成。MCP server 名是 jev_context，工具名是 curate_context。输入是 goal（必填的当前目标）和 blocks（有序的原始块列表）。每个块带 id、role、content、callId、toolName、readOnly、verified、pin、status 这些字段。

它的合格条件窄到有点苛刻：只有一个完整、无歧义的「一次调用对应一次结果」配对，来自已知的只读操作（read、read_file、search、list、inspect、fetch），并且结果已验证，才有资格进入候选。未知工具名、写操作、不完整的配对，全部保留。

Jev 被问到的问题也只有一个：这个旧的、已验证的只读工具配对，是否应该留在交接包里。

然后是三个让我很欣赏的设计选择。

只删低于 0.2 的。 Jev 返回的是分类概率，代码决定哪些证据合格、校验每一个答案、保护受保护内容、再组装成包。只有当验证后的保留概率低于 0.2 时才丢弃，0.2 及以上一律保留。作者写了一句很清醒的话：概率不是无关性的证明。

批量原子化。 每一批必须返回请求的每一个概率，且都是 [0, 1] 区间内的有限数。任何一个失败都会放弃这一批所有提议的删除，退回到完整输入。

失效时保留一切。 没有合格配对、没有 API key、状态超过 24000 个 UTF-8 字节、HTTP 失败、网络错误或 15 秒超时、响应格式非法，全部保留完整输入，不做任何截断或推断。这个 24000 字节的硬上限意味着它宁可退回原状，也不做有损处理。

它还有一条纪律我认为值得单独抄下来：元数据必须诚实。verified: true 表示读取确实完成了、结果被观察到并验证过。绝不能把 shell 命令、编辑、发送、删除重新标记成只读读取。因为诚实与否直接决定了哪些证据会被删掉，这条纪律是整条链路的安全前提。

最后它明确声明自己不做的事：不替代 Codex 的原生自动压缩，不回收当前会话的 token，不修改 Codex 的会话文件。它只负责准备一份显式的交接包。

这份设计里最值得学的是它的保守性。用「摘要」做压缩是有损的、无法审计的，你把一个不可逆的变换交给了一个会犯错的模型。而「删掉一整对工具证据」是离散的、可审计的、可以逐条列出理由的。同样是让模型参与压缩，后者犯了错你能发现，前者犯了错你只能等到某天 agent 突然丢了一个约束才知道。

3.4 模型路由：让 Jev 挑这一轮该用哪个模型#

这是四种玩法里最热门的一类，一周内出现了两个不同粒度的实现。

按轮路由：jev-router（gargpratyush）

npm install -g jev-router
echo "JEV_API_KEY=..." > ~/.jev-router.env
jev-codex

机制是这样的：命令启动一个本机回环代理，然后启动真正的上游 CLI，并把 CLI 已有的授权头原样转发，不读取、不存储、不修改它们。它在 Codex 原生的 /model 选择器里注入一个临时 provider 并选中 jev-router。你手动选一个具体模型就暂停路由，选回 Jev Router 就恢复。

每次决定会以一行 Codex 注释出现：

[Jev] routed this turn to gpt-5.6-sol (jev, confidence 0.91).

Codex 侧的四档默认是：Fast 对应 gpt-5.6-luna，Balanced 对应 gpt-5.6-terra，Strong 对应 gpt-5.6-sol，Long 对应 gpt-6-astra。

它的策略规则我建议逐条读一遍，因为每一条都在处理一个真实的工程反直觉：

  • 显式请求（use opus、use luna、use strong）优先级最高，人说话的时候机器让路。
  • Jev 失败、超时、或返回无法识别的答案时，保持当前模型。
  • 低置信度永不降级，升级最多到 balanced 档。不确定的时候不要乱动。
  • 大对话拒绝降级，因为浪费掉的提示缓存工作量比省下来的更多。
  • 档位不可用时向上走，而不是默默选一个更弱的模型。
  • 长档默认关闭，除非显式设置 JEV_ALLOW_FABLE=1。
  • 工具循环的后续调用沿用本轮开头选定的档位，一轮之内不来回跳。
  • 主对话和子 agent 分开固定。

整个路由是 fail-open 的，Jev 挂掉不会阻塞你的 CLI。也不需要 OpenAI 的 API key，只要 CLI 已经用订阅登录过就行。它自己声明的限制很克制：只有用户的提示词文本会发给 TypeSafe，别的什么都不发。

按调用路由：jev-codex-router（0xNatoshi）

这个版本把粒度压到了每一次模型调用，而且把模型选择和思考深度一起决定，速度模式固定为标准。它的目标不是「用最便宜的模型」，而是「用刚好够胜任下一个决定的模型」。

成本数字非常具体：一次决定约 0.00003 美元，约 0.6 秒。作者在 237 个真实轮次的 7 天重放上做了一次历史模拟，对比全 Astra 基线约省 60%。他自己也标注了这属于历史模拟，不是实测的 Codex 配额节省，也不能作为当前策略的证据。

它不自建路由，而是通过现有本地 Codex Router 的官方扩展点接入（一个通用 provider 加一个受管的 model），所以 router 本身的升级不会覆盖它。

这里面有一个工程细节，我认为是整份材料里最有价值的一条。它维持两个独立的投影：

Jev 只看到有界的决策状态。 执行模型收到的是 Codex 持有的完整规范重放：指令、历史或压缩交接、工具调用和工具结果。

为了让这件事成立，内嵌的 router 把确切的 jev/auto 路由从会话窗口化和工具结果老化里排除了出去。否则那些本身合理的优化，会在服务器能把上下文转发出去之前就把它毁掉。

这一条值得所有想在 agent 中间插一层的人抄下来：判断用的输入和执行的输入，是两个不同的东西，需要显式地分开管理，不能共用一条被各种优化处理过的管道。

它同样有 fail-open、一个哨兵文件构成的即时 kill switch、以及配额耗尽时的回退路径。

四、这几套集成共有的六条工程约定#

把四种接法放在一起看，会发现它们不约而同地遵守了同一套规矩。这比任何单个工具都更有参考价值。

第一，版本固定。 生产里应该写死模型 id，比如 TypeSafeClient(model="jev-1.13.0")，而不是用 jev-latest。理由很实在：一个决策模型在你背后悄悄改变了校准，正是那种你在仪表盘上看不见的故障。

第二，fail-open。 四种集成都这么做。路由失败就保持当前模型，工具闸门失败就放行，压缩失败就保留全部输入。原则是 Jev 的不可用绝不能升级成工作流的不可用。

第三，决策必须可检视。 jev-router 会把每次决定的精确提示词、System One 请求和响应存在本地临时文件里，目录权限 700、文件权限 600，7 天未更新自动删除。它打包的 $jev-explain 技能从这些存档渲染报告，不会重新去问 Jev 打分。jev-codex-router 也保留本地决策日志作为校准数据来源。让机器做决定的系统，必须留下人能看到决定理由的地方。

第四，置信度阈值按动作分级。 不要写一个全局阈值。只读操作门槛可以低，会动钱的操作门槛要高，低于底线就转人工。Jev 是用 RLCD 训练的，专门优化概率的校准，所以置信度在统计意义上是有意义的，值得按不同动作的犯错代价分别设定。

第五，按调用计数，不要按问题计数。 问题是被并行评估的，所以第十个问题增加的是 token，几乎不增加时间。TypeSafe 的 cookbook 里有一个例子：对一篇长维基百科文章跑 13 个问题的合规简报，把所有问题合进一次调用，比逐条问便宜 12.2 倍、快 10.0 倍，答案完全相同。这直接推翻了「先做一次便宜的调用，需要时再追问」的直觉，正确答案是反过来，一次问全，让代码去挑哪些答案有用。

第六，永远留一个 other 选项。 Choice 支持到 255 个选项，每个选项只花几个 token，所以把完整清单给它，不要给短名单。同时一定要加一个显式的 other，让模型有地方说「都不合适」，而不是在你给的选项里挑一个最接近的错误答案。

五、三条必须知道的边界#

Jev 值得认真对待，但它的宣传语比实际保证要宽。有三件事必须先搞清楚。

「不能胡说」比听起来窄得多。 它不能返回你 schema 之外的值，但它可以返回一个合法的错误值。那个 0% 是断言，不是测量。TypeSafe 自己写得很直白：「我们的数字不是经验性的。schema 匹配是有保证的，所以我们能有把握地把 0% 加进图表里。」所谓零幻觉，指的是零类型错误。那个 45.5% 的对比数字来自一个离群值（Haiku 4.5），大多数模型落在 0.58% 到 13.2% 之间，不是 45%。

精度数据是自研自评的。 TypeSafe 设计了工作流、搭了 harness、自己跑的结果。标签是用 GPT-6 Astra 和 Claude Fable 5.1 在高思考档下取平均做出来的共识标签，然后让所有模型对着这份共识打分。它测量的其实是「与两个前沿模型的一致程度」，这也是为什么那两个模型没有出现在结果里。TypeSafe 自己承认这偏向 OpenAI 和 Anthropic。目前没有独立复现。速度数字还是在西海岸的笔记本上跑的，服务本身也在那里。你应该在自己的流量上评估。

度量标尺的陷阱。 有一份第三方评测给出了 Jev 的第一个公开精度数字：0 到 2 档的相关性精度 88%，可信度精度 96%，25 个样本，平均答案置信度 0.77。但这份报告里最有价值的不是这个数字，而是它附带的教训。

第一遍评分时，他们把 Jev 的原始加权分和精确的整数区间做比较，得到 28% 的相关性精度，其中「漏判」的样子是「期望 [2,2]，实际得到 1.96」。把分数四舍五入到最近的档位（等价于取最大概率的档位），真实数字才是 88%。28% 和 88% 之间的全部差距，来自你用的是什么尺子。

更微妙的是，TypeSafe 自己的文档明确警告不要在各档阈值之间做插值，而这份评测的 harness 恰恰对 Jev 违反了自己的建议。报告作者的结论值得每个人记住：任何人在评测一个 System One 模型之前，都应该先把区间匹配的语义定下来，再去读结果。

这条教训不只适用于 Jev。它是所有「需要人预先定义评分区间」的评测的通用陷阱。先定尺子，再看数字。

还有一个值得单独说的观察。Jev 发布五天后，出现了 2.8MB 的复刻版本，有人把一个决策引擎缩到了一个小电子表格的大小。这不必然是坏消息，但它说明这类模型的护城河不在权重上。它更可能落在延迟、价格承诺、以及围绕它积累起来的工程约定上。对于一个只需要「是或否加一个概率」的位置，可替代的东西会来得很快。

六、如果今天就想动手，我的顺序#

第一步，先做影子模式。 不要迁移任何生产上的东西。在现有循环里，把那个 checker 调用复制一份发给 Jev，两边结果都记下来，跑一两周，对比一致性。你需要的是一份属于自己流量的数据，而不是厂商的图表。

第二步，从 PreToolUse 闸门开始，而不是从路由开始。 闸门位置的错误代价最小（最坏情况是多问一次），收益立刻可见。路由会影响你所有轮次的模型选择，值得等你的置信度数据攒够了再上。

第三步，版本固定、fail-open、决策日志，这三件事在第一天就做。 不要等到出问题。你以后回头看，会发现这三件事决定了这个模型是可管理的还是不可管理的。

第四步，最后再碰上下文压缩。 它是四种玩法里最有想象力的一种，也是最容易造成不可逆信息丢失的一种。如果要做，先照 codex-jev-compaction 的保守规则来：只删可验证的只读证据，只删保留概率低于 0.2 的，把原始输入留作权威档案。

结语#

Jev 真正有意思的地方，不是它更快或更便宜。

而是它把一类长期混在 LLM 里的调用重新分类了出来。你之前付着前沿模型的价格去问一个是非题，只是因为没有别的地方可以发这个调用。现在有了。

当一次决策的边际成本接近零，你的代码能问的问题就变多了：这个改动是否安全、这个文件是否相关、这个工具是否需要、这一轮该用哪个模型、这段旧证据是否还值得携带。这些问题以前都存在，只是问不起。

Jevons 悖论讲的正是这件事。在 Jev 之前，这个悖论是对未来的预测。现在它是一个可以今天就跑起来的工程决策。

参考来源：本文综合了多个来源。TypeSafe AI 的模型定义与 API 形态来自其官方发布与公开文档，https://typesafe.ai/blog/introducing-system-one-models-and-jev ；三种原语、定价、上下文限制与五种使用模式参考 Valyu 的实操指南，https://dev.to/valyuai/how-to-use-jev-a-practical-guide-to-typesafes-system-one-model-g5e ；Maker 与 checker 的角色分析、RLCD 与 RLHF 的区别、以及成本换算的估算方法来自 Rick High 的分析文章，https://rickhigh.substack.com/p/the-model-that-cannot-write-a-sentence ；MCP 工具层与配置示例来自 teempai 的 jev-in-codex 与 shitianfang 的 jev-use，https://github.com/teempai/jev-in-codex 、https://github.com/shitianfang/jev-use ；上下文压缩的规则与失效保护表来自 Wang-auspicious 的 codex-jev-compaction，https://github.com/Wang-auspicious/codex-jev-compaction ；两套模型路由的档位、策略规则与工程细节分别来自 gargpratyush 的 jev-router，https://github.com/gargpratyush/jev-router ，以及 0xNatoshi 的 jev-codex-router，https://github.com/0xNatoshi/jev-codex-router ；第三方精度评测与度量标尺教训来自 jev-scout 的 golden set 研究报告，https://github.com/kierandotai/jev-scout 。文中观点、判断顺序与工程解读部分为本文作者的独立分析。所有厂商自评数字均未经过独立复现，请在自己的流量上验证后再做生产决策。