为什么有了 GPT、Claude，我们还需要 Jev？

最近我拿 Jev 做了一个挺有意思的小实验。

我把它塞进了一个 2048 游戏里，让它自己玩。

2048 这个游戏大家都知道，规则并不复杂。每一步能做的事情只有四个：

上
下
左
右

模型不需要写一篇分析，也不需要跟我解释为什么这么走。

它只需要干一件事：

做决定。

把当前棋盘状态交给它，然后告诉它可选的动作，让它判断下一步往哪个方向走。

运行起来以后，右边不断刷出模型的决策日志，左边的棋盘则根据它的判断一步一步变化。

这个 Demo 看起来很简单，但做完以后，我反而觉得它很好地解释了一个问题：

为什么我们已经有 GPT、Claude、Gemini、Codex 这些能力这么强的模型，还需要专门做 Jev 这样的模型？

答案可能就藏在「做决定」这三个字里。

---

我们好像习惯了什么都问 GPT

现在做 AI 应用，很容易形成一种习惯。

有问题，找 GPT。

写文章，找 GPT。

分析数据，找 GPT。

写代码，可以用 Claude、Codex。

需要理解一个复杂需求，还是把整段内容扔给大模型。

这当然没什么问题。

因为这些模型最擅长的，本来就是：

输入信息
↓
理解、推理
↓
生成新的内容

你给它一段需求，它给你代码。

你给它一堆资料，它给你总结。

你问一个问题，它给你一段答案。

但做 Agent 做久了以后，会遇到一个很现实的问题：

软件系统里的很多任务，根本不需要 AI 给我们写一段话。

比如：

这个请求要不要联网？

这个文件能不能读取？

这段代码有没有风险？

这个任务应该调用哪个工具？

这次操作要不要交给人工审核？

A、B、C、D 四个方案应该选哪个？

程序真正想要的结果，很多时候可能就这么简单：

Yes / No

或者：

A / B / C / D

再或者：

风险：82%

如果最终只需要这么一个结果，那我们真的有必要每次都调用一个擅长长文本生成的大语言模型吗？

这就是 Jev 这类决策模型让我觉得有意思的地方。

---

它不是来陪你聊天的

如果要用一句话区分，我觉得可以这么理解：

GPT、Claude 更擅长「生成」。

而 Jev 更偏向「判断」。

比如我们给 GPT 一段文字，它最后通常还是返回一段文字。

哪怕你要求它：

不要解释，只返回 JSON。

最后可能得到：

{
  "action": "search_web",
  "confidence": 0.91
}

从工程上看，这已经很好用了。

现在很多 Agent 其实就是这么干的。

先让 GPT 判断用户意图，然后要求它输出固定 JSON，再由程序把 JSON 解析出来，决定下一步调用哪个工具。

但这里有一个很有意思的区别。

JSON 只是我们限制了大模型的输出格式，并没有改变它本身还是在“生成”。

底层仍然是一个 Token 接着一个 Token 往后生成。

只是原来让它生成一段自然语言，现在强制它生成：

{"action":"A"}

而 Jev 的思路不是这样。

它更像是提前把「答案空间」定义好。

比如：

A：联网搜索
B：读取文件
C：调用 API
D：拒绝执行

模型需要做的是：

在这几个确定的结果里面进行判断。

而且除了告诉你最终选择什么，它还可以把这个判断的概率一起交给你。

例如：

A：0.82
B：0.11
C：0.05
D：0.02

这个时候，事情就开始变得有意思了。

---

很多时候，“有多确定”比答案本身更重要

假设我们做一个风控系统。

收集到一堆用户行为以后，交给模型判断：

这个用户是不是存在欺诈风险？

最简单的结果当然是：

是

或者：

不是

但真实系统一般不会这么干。

因为「是或者不是」太粗了。

我们更关心的是：

你有多确定？

比如模型给出的欺诈概率是 97%。

那系统可以直接拦截。

如果是 78%，可能不应该直接封掉，而是进入人工审核。

如果只有 20%，则可以正常放行。

于是整个流程可能变成：

欺诈概率 > 95%
直接拦截

60% ～ 95%
人工审核

< 60%
正常放行

当然，真实业务里的阈值不可能这么随便拍脑袋决定，这里只是为了方便说明。

重点在于：

真正能落地的自动化系统，很少只关心模型说“是”还是“不是”。

它还需要知道模型对这个结果有多大的把握，然后再由系统决定接下来怎么处理。

因为模型的判断本来就不是数据库里的 1 = 1。

模型面对大量复杂信息时，很多结果天然就是概率性的。

与其假装模型永远正确，不如干脆把这种不确定性暴露出来。

然后把最终控制权留给程序，或者留给人。

我觉得这反而更符合软件工程的思路。

---

做 Agent 的人应该很容易理解这个问题

我们平时做 Agent，一条请求进来以后，背后可能发生很多事情。

举一个很常见的流程：

用户提出需求
↓
GPT 理解需求
↓
判断应该使用哪个工具
↓
调用工具
↓
拿到工具结果
↓
GPT 再判断下一步做什么
↓
继续执行

这里 GPT 看起来很忙。

但仔细把这个流程拆开，会发现中间很多节点其实并不需要它写什么内容。

只是不断在做判断。

比如：

要不要联网？

要不要读取文件？

需不需要执行 Shell？

调用哪个 MCP？

代码有没有明显问题？

这个操作安全吗？

工具执行失败以后，是重试还是换一个工具？

这些问题有什么共同点？

答案空间都非常小。

很多甚至只有：

Yes / No

但现在我们的做法，往往还是调用一次 GPT，让它推理、生成，再拿它的输出决定下一步。

单个请求看不出什么。

可一个复杂 Agent 一次任务可能要做几十次这样的判断。

这时候你会发现：

我们真正需要的，未必是每一个节点都让一个大模型进行长推理。

有些地方只需要一个快速、稳定的判断器。

---

Jev 不应该替代 GPT，而应该站在 GPT 前面

这是我觉得最容易被误解的地方。

第一次看到这种模型，很容易问一句：

它是不是想替代 GPT？

其实完全不是。

让 Jev 写一篇公众号文章，我觉得没什么意义。

让它写一套复杂代码，也不是它擅长的事情。

包括开放式问答、复杂推理、长文本创作，这些任务仍然更适合 GPT、Claude、Gemini、Codex、Grok 这些大语言模型。

Jev 更适合的是：

分类
路由
决策
风险判断
评估
过滤
工作流节点选择

所以更合理的架构不是：

Jev VS GPT

而应该是：

Jev
↓
GPT / Claude / Codex
↓
MCP / API / Shell

用户请求进来以后，先经过决策层。

决定：

谁来干？
要不要干？
怎么干？
风险有多高？

真正需要复杂理解和生成的时候，再交给 GPT 或 Claude。

到了具体执行环节，再让 MCP、API、Shell 或其他工具完成。

这样一来，不同模型做的是自己擅长的事情。

---

为什么我拿 2048 来演示

现在再回到前面的 2048。

我觉得这个游戏很适合解释 Jev。

因为它的动作空间是完全确定的。

无论棋盘多复杂，下一步只能：

UP
DOWN
LEFT
RIGHT

绝对不会突然出现第五个答案：

“我建议我们重新思考一下游戏目标。”

程序也根本不需要模型输出：

经过对当前棋盘结构的综合分析，我认为左侧具有更大的合并空间，同时可以为后续数字移动预留……

这些话对程序一点用都没有。

程序要的就是：

LEFT

最好再告诉我：

LEFT    72%
DOWN    16%
RIGHT    9%
UP       3%

然后程序执行就完了。

所以做这个 Demo 的时候，我有一个很明显的感受：

使用这种模型，重点可能已经不再是怎么写一段漂亮的 Prompt。

更重要的是：

你怎么定义 State。

当前是什么状态？

有哪些合法动作？

模型可以从哪些结果里面选？

什么概率可以自动执行？

什么概率必须让人介入？

以前大家天天研究 Prompt Engineering。

到了这种场景里，真正需要花时间设计的，反而可能是整个状态空间和决策空间。

---

Agent 以后可能不会只有一个“大脑”

过去这一两年，行业很喜欢讨论一个问题：

模型还能不能继续变得更大、更强？

似乎理想状态就是做出一个无所不能的超级模型。

聊天是它。

写代码是它。

识图是它。

调用工具还是它。

最后整个 Agent 从头到尾只有一个“大脑”。

但真正把 AI 接进软件系统以后，我越来越觉得，最终的形态可能不会这么简单。

更像是：

用户请求
↓
决策
↓
推理
↓
执行
↓
验证

不同阶段使用不同的模型或者工具。

需要判断的时候，用擅长判断的模型。

需要复杂推理的时候，交给 GPT、Claude。

真正需要修改文件、请求接口、执行命令的时候，则交给确定性的工具。

也就是说，未来一个 Agent 里面，可能不会只有一个模型。

而是不同能力开始分工。

如果一定要把这套思路压缩成一句话，我现在更愿意这么理解：

Jev 负责判断，GPT、Claude 负责思考，MCP、API 和 Shell 负责执行。

这三件事情本来就不是一回事。

只是过去大语言模型太强了，我们习惯了全部让它干。

---

最后

所以 Jev 真正值得关注的地方，我觉得不是：

它能不能成为下一个 ChatGPT。

如果只拿这个标准去看它，反而看偏了。

它让我觉得有意思的地方，是它提醒了我们一件很基础、却很容易被忽略的事情：

AI 的输出不一定非得是一段文字。

对于写文章的人来说，一千个 Token 当然很有价值。

但对于一个正在运行的软件系统来说，它有时候根本不要这一千个 Token。

它可能只想知道：

执行，还是不执行？

A，还是 B？

风险到底有多高？

这时候，

一个足够可靠的决定，可能真的比一千个 Token 更有价值。