EN
AI模型

Jev 为什么突然爆火？从通关宝可梦看 AI 决策模型的价值与边界

Jev 不生成文字，而是把应用状态转换成带概率的结构化决策。本文从它通关 Pokémon Red 的热门实验出发，拆解 System One Model 的工作方式、成本优势、工程价值与真实边界。

Jacky Wang 11 分钟阅读 41 阅读

最近开发者社区频繁提到一个反直觉的 AI 产品：Jev。让它迅速出圈的不是一场聊天模型跑分，而是一批让 Jev 玩《Pokémon Red》、Doom、赛车和无人机模拟的实验。最吸引眼球的一次公开运行中，Jev 在 37 小时 40 分钟内通关《Pokémon Red》，完成 16,150 次决策，项目记录的模型调用成本约为 1.65 美元。

这些数字很容易制造一种印象：一个比大语言模型便宜得多的新模型，已经学会了长期规划和自主行动。实际情况更有意思，也更值得工程团队关注——Jev 不陪你聊天，不写长文，也不直接生成代码。它接收程序整理好的状态和有限选项，再返回可直接交给软件处理的选择、评分或概率。

这也是“跳过聊天，直接输出带置信度的结构化决策”这句话的真实含义。Jev 不是要取代 GPT、Claude 或 Codex，而是想接管 Agent 和软件系统里数量巨大、重复发生、答案范围明确的“小判断”。

但围绕它传播最广的“快 193 倍、便宜 445 倍”“低成本通关宝可梦”和“长任务不再失忆”，都需要加上条件。Jev 的确提供了不同于聊天模型的接口，不过它的优势只在适合的任务形状里成立。

Jev 到底是什么？

TypeSafe AI 在 2026 年 9 月 15 日发布 Jev，并把它称为首个公开的 System One Model。这个名字借用了《思考，快与慢》里的“系统一”：快速、直觉式判断。按照 TypeSafe 的官方定义，Jev 接收一份状态（state）和一组类型化问题，然后并行返回程序可以直接消费的答案。

目前官方文档列出三种问题类型：

  • Choice：从预先定义的选项中选一个，同时返回各选项概率与置信度；
  • Score：按照你给出的等级描述进行评分，并返回各等级的概率分布；
  • Noul：判断某个陈述是否成立，返回 0 到 1 的概率。

例如，一条客户消息写着“支付接口连续三天无法连接，已经影响销售”。普通 LLM 可能先写一段分析，程序再解析它到底属于哪个部门、是否紧急。Jev 可以在一次请求里直接返回：部门选择为 technical、紧急程度概率较高、挫败感位于哪一级。

这不是把聊天回答换成 JSON 外壳。Jev 的答案空间在请求前就已经定义，业务代码仍然掌握路由、阈值、权限和最终动作。模型只负责那些无法用普通 if/else 精确表达、却又不值得调用长推理模型的语义判断。

它为什么突然受到关注？

Jev 击中了当前 Agent 架构中的一个浪费点：很多流程调用大模型，并不是为了创作或复杂推理，只是为了回答“这是什么类型”“风险高不高”“该走哪条分支”。让一个会生成长文本的模型处理这种任务，往往意味着更高延迟、更多输出 token，以及额外的格式校验。

TypeSafe 的路线是把开放式生成与封闭式判断拆开：

普通代码保留确定性规则、数学计算和权限控制；

Jev 处理分类、排序、相关性、风险和路由等模糊判断；

GPT、Claude 等生成模型继续负责写作、规划、代码生成和复杂推理；

低置信度或高风险结果交给人类复核。

对 Agent 来说，这相当于增加一层轻量“判断中间件”。它可以先决定该调用哪个工具、哪些检索结果值得保留、某个动作是否需要确认，再把真正需要推理或生成的部分交给大模型。

通关 Pokémon Red，Jev 到底做了什么？

Jev 玩宝可梦的实验很好地展示了这种分工。在 Christian Mathiesen 公开的项目中，普通代码负责读取模拟器内存，把地图、队伍、战斗状态和屏幕文字整理成结构化状态；代码还负责寻路、菜单操作、伤害估算和检查游戏进度。Jev 看到的不是原始画面，也不能任意修改游戏内存，它只在程序列出的合法选项中做选择。

这套系统最终用了 37 小时 40 分钟通关，记录了 16,150 次 Jev 决策、约 3,920 万输入 token、约 1.65 美元调用成本，以及约 0.4 秒的典型决策时间。它也并非一路顺利：队伍团灭 16 次，其中 14 次发生在 Elite Four，最终经过 15 次尝试才完成挑战。

另一个受到广泛报道的 Jev 宝可梦项目也暴露了同样的现实：当模型陷入循环时，开发者需要持续调整提供给它的选项、事实和调用节奏，Claude 还被用来分析日志并帮助修改这套“脚手架”。换句话说，Jev 的成功不是一个模型端到端看懂游戏并独立规划，而是确定性代码、领域知识、决策模型和人工迭代共同完成的系统成果。

这并不会削弱实验的意义，反而说明了 Jev 真正可能进入生产环境的方式。它不是万能 Agent 的大脑，而像一个高速判断部件：软件先把世界压缩成可靠状态，再让模型在受控边界内回答“下一步选哪个”。

“193.6 倍快、444.6 倍便宜”应该怎样理解？

TypeSafe 官网确实展示了 193.6 倍更快、444.6 倍更便宜的数字。它不是网友杜撰，但也不是所有任务都能获得的通用加速比。

根据 TypeSafe 的发布文章，这些数字来自其自行设计的 System One 工作流评测。参测模型运行同一套分解后的决策工作流，并以 GPT-6 Astra 与 Fable 5.1 的平均结果作为参考概率。官方同时主动披露了几个重要限制：

  • 这些结果处于现实收益的高端；
  • 工作流由 TypeSafe 模型能力团队成员设计，可能存在偏差；
  • 短而密集的输入更有利于 Jev 的并行采样方式；
  • LLM 对照组被包装为兼容 TypeSafe API 的结构化决策接口，但生成概率仍然更慢、更贵。

因此，准确说法应该是：在问题已经被拆成多个边界清楚、可并行的 System One 判断时，Jev 的延迟和成本可能远低于通用 LLM；这不是对写作、编码、长链推理或任意 Agent 任务的总体性能结论。

TypeSafe 公布的早期定价为每百万输入 token 0.042 美元，输出 token 不单独计费；其发布材料称服务端端到端响应通常为 70–500 毫秒。价格、模型版本和访问政策都可能变化，实际项目应以控制台和当前文档为准，并在自己的网络位置、数据分布和并发量下重测。

Jev 最有价值的五种用法

1. Agent 的工具与模型路由

当用户提出请求时，Jev 可以在一组已知工具中选择最匹配的目标，或判断任务应该交给便宜模型、强推理模型还是人工处理。程序根据概率和置信度执行，而不是从一段自然语言解释中猜结果。

2. 客服、工单和运营分流

它适合判断工单部门、紧急程度、投诉风险和是否需要升级。多个问题可以共享同一份 state 并行执行，避免串行调用多个模型。

3. RAG 上下文筛选

在检索增强生成里，真正昂贵的往往不是搜索，而是把大量不相关文本反复塞回主模型。Jev 可以对候选段落进行相关性评分，由代码只保留值得进入上下文的内容。这能减少 token 消耗，也可能降低无关信息造成的“上下文腐化”。

4. Agent 动作前的风险闸门

在删除、付款、修改权限或对外发送等动作前，可以让 Jev 对“是否涉及高风险操作”“是否需要人工确认”等窄问题提供概率信号。不过模型判断不能代替真正的权限系统；最终授权必须由确定性代码和用户确认控制。

5. 结构化提取的选择环节

Jev 不擅长凭空生成任意字符串，但可以从代码或正则表达式找到的候选值中选择最可能的那个。例如先提取文档里的所有日期和金额候选，再让 Jev 判断哪一个对应“合同生效日”或“应付总额”。

它能解决长任务“越跑越失忆”吗？

答案是：只能间接帮助，不能把它描述成已经解决。

Jev 可以在每轮任务后判断哪些事实、工具结果和约束仍然重要，让主 Agent 只保留高价值状态。这样确实可能压缩上下文，降低长任务中无关信息不断累积的问题。

但官方对 Jev 1.13 的限制说明同样指出：它有有限上下文窗口，当 state 塞入大量无关细节时准确率会下降，甚至会出现自己的 context rot。官方建议先在代码里检索和过滤，只发送当前问题真正需要的字段。

所以，“安装一个 Skill，长任务从此不会失忆”属于过度宣传。更可靠的方案仍然是把观察事实、长期记忆、当前目标和模型推断分开存储，用检索和确定性代码管理状态，再让 Jev 参与“哪些内容值得进入下一轮上下文”的判断。

Jev 的优势，也正是它的边界

Jev 的优势很明确：输出类型稳定、答案可直接进入代码、多个问题可以并行、输出带概率信号，而且不需要为长篇生成内容付费。对高频、低延迟、答案集合有限的工作流，这种接口比“提示 LLM 返回 JSON”更自然。

但它并不适合：

  • 写文章、回复邮件、生成代码等开放式内容；
  • 需要多步推理、复杂间接关系或长计划的任务；
  • 精确数学、计数、日期比较和确定性查找；
  • 把大量无关文档原样塞进 state；
  • 未经专项测试就处理高风险安全决定。

TypeSafe 还披露，Jev 1.13 可能过度按字面理解问题，不可靠地处理数字和日期，面对提示注入式对抗文本也可能被影响。所谓“类型安全”保证的是输出符合预先定义的结构，不保证判断内容永远正确。置信度也不是正确率承诺，而是从选项概率分布中压缩出来的信号，阈值需要用自己的真实数据校准。

怎样申请并在 Codex 中使用 Jev？

目前 Jev 仍处于早期访问阶段。官方流程可以分成“获得服务权限”和“让 Codex 学会正确集成”两部分。

第一步：注册并申请访问

进入 TypeSafe 官网 或直接打开 TypeSafe Console，登录并申请 early access。是否需要等待名单取决于当时的账号开放状态；不要把某位用户的申请经历当成永久规则。

获得权限后，先在 Playground 粘贴一段真实但不敏感的测试文本，分别尝试 Choice、Score 和 Noul，确认这种问题形状是否适合你的项目。

第二步：安装官方 TypeSafe Skill

TypeSafe 为 Codex 和其他兼容 Skill 的编码 Agent 提供了官方安装方式：

npx skills add typesafe-ai/skills --skill typesafe-ai

安装器会要求选择目标 Agent。默认是项目级安装；只有确实希望所有项目都使用时才加 -g。安装后重启或重新加载 Agent，然后在任务中明确写：

Use the TypeSafe skill. Find one bounded decision in this project that is suitable for Jev, design the questions and confidence fallback, and show me the integration plan before changing code.

要注意：这个 Skill 是设计与集成知识，不是 Jev 模型本身。它会帮助 Codex 阅读当前 API、选择问题类型、设计阈值并生成调用代码，但不会仅靠一句 “Use the TypeSafe skill” 就自动调用 Jev。

第三步：创建并安全保存 API Key

在 TypeSafe API Keys 页面 创建密钥。不要把完整 key 粘贴进聊天、提交到 Git，或写入前端可见的环境变量。服务器端开发通常把它保存为：

TYPESAFE_API_KEY=your_key_here

密钥应该进入本地或部署平台的 Secret 管理，不应进入仓库。官方 HTTP 端点为 POST https://api.typesafe.ai/v1/systemone，也可以使用 TypeSafe 的 Python 或 JavaScript SDK。

第四步：从一个窄问题开始做 A/B 测试

不要一上来重构整个 Agent。选一个已有真实结果的步骤，例如工单分类或 RAG 段落筛选，同时保留旧流程。记录 Jev 的答案、概率、延迟、成本和最终业务结果，再决定自动执行、进入复核队列，还是退回原来的 LLM。

Jev 真正值得关注的地方

Jev 最重要的意义不是又出现了一个“更强模型”，而是它重新追问了一个工程问题：软件里的每次 AI 调用，真的都需要生成一段文字吗？

当任务需要创意、解释和复杂推理时，LLM 仍然不可替代；当任务只是高频地做一个有边界的语义判断时，专用决策模型可能更便宜、更快，也更容易接入代码。未来成熟的 Agent 很可能不是由单个万能模型包办所有工作，而是由确定性代码、生成模型、决策模型和人工复核共同组成。

Jev 值得试，但正确的试法不是相信一个夸张倍数，而是找到一个真实、窄小、可以衡量结果的判断步骤，然后用自己的数据证明它是否值得留下。

参考资料

推荐站内阅读

发表评论