一个不会聊天的AI，为什么突然火了？Jev暴露了Agent时代最贵的浪费

最近的大模型市场，有点像手机行业发展到成熟期之后的样子。

GPT、Claude、Gemini、DeepSeek、Kimi、GLM，一轮接一轮更新。模型能力当然还在提升，上下文越来越长，推理越来越强，代码越写越好，但对普通用户来说，一个越来越现实的问题已经出现：

模型继续变强之后，我们到底还缺什么？

答案可能不再是“另一个更会聊天的大模型”。

2026年9月15日，一家此前保持低调的旧金山AI公司TypeSafe AI正式推出了一个叫 Jev 的模型。

它做了一件相当反常识的事情。

别人都在努力让AI写得更多、更长、更聪明，Jev却干脆把“写东西”这件事砍掉了。

它不会给你写文章。

不会跟你聊天。

不会生成一段漂亮的分析。

甚至按照TypeSafe自己的定义，它根本就不是一个传统意义上的大语言模型。

Jev主要干一件事：

做判断。

TypeSafe把这一类模型叫作“System One Models”，也就是专门面向软件内部决策的模型。输入可以是一段非结构化信息，输出却不是自然语言，而是软件可以直接调用的结构化概率和判断结果。

这个看上去像是“能力缩水”的设计，却迅速在开发者社区里引发了讨论。

真正值得关注的，也不是Jev是不是下一匹AI黑马。

而是它提出了一个越来越重要的问题：

我们是不是一直在用一个会写作文的AI，去干根本不需要写作文的工作？

帮AI学会说话的人，为什么开始让AI闭嘴？

Jev背后的创始人叫Diogo Almeida。

这个名字普通用户可能并不熟悉，但他曾经是OpenAI研究人员，而且是2022年InstructGPT论文的共同作者之一。

OpenAI当年在介绍InstructGPT时，明确把Diogo Almeida列在论文共同作者中。InstructGPT最重要的意义之一，就是通过人类反馈等方式，让语言模型从单纯“预测下一个词”，逐渐变成更愿意按照人的意图完成任务的助手。

后来出现的ChatGPT，与这条技术路线有非常直接的关系。

所以网上有人把Almeida称为“ChatGPT之父”。

这个称呼显然过于简单。

ChatGPT从来不是某一个人做出来的产品，更准确的说法应该是：Almeida是参与InstructGPT以及早期ChatGPT相关工作的研究人员之一。

有意思的地方也恰恰在这里。

一个曾经参与解决“怎样让AI更懂人、更会跟人说话”的研究者，离开OpenAI后，却用了大约两年时间，做出了一个尽量不说人话的AI。

这不是否定语言模型。

而是他认为，大语言模型解决的是一种特定需求：

人与AI之间的交流。

可今天越来越多AI已经不再只面对人。

它们开始面对软件。

Agent时代真正缺的，可能不是另一个聊天模型

理解Jev之前，可以先看一个非常普通的客服系统。

假设一家电商平台每天收到10万条用户消息。

软件首先要判断：

这是退款？

投诉？

物流咨询？

账号问题？

还是垃圾信息？

如果使用传统大模型完成这件事，一个典型过程可能是：

模型先阅读用户消息，然后在内部或者输出中组织出一段语言分析，最后得出“投诉”这个结论。

问题在于：

后面的程序根本不需要那段文章。

系统最终只需要：

complaint

甚至只需要：

3

这有点像参加一道选择题考试。

题目问：“A、B、C、D选哪个？”

一个人却每做一道题，都先写800字论述，然后再把文章压缩成一个字母。

从人的角度看，语言解释很有价值。

但从软件系统角度看，中间那些文字很可能只是计算成本。

而Agent恰恰会把这个问题放大。

因为一个复杂Agent执行一次任务，可能不是调用模型一次，而是在后台连续完成几十甚至上百个微小判断：

现在应该调用哪个工具？

这个网页按钮能不能点？

这一段资料还需不需要保留？

这封邮件应该进入哪个队列？

当前操作风险有多高？

结果需不需要人工复核？

每一个动作，都可能意味着一次模型调用。

如果每个判断都启动一个擅长长文本生成和深度推理的前沿模型，Agent当然也能工作。

只是成本和延迟会越来越明显。

Anthropic最近披露的一组内部数据，可以很好地说明这个趋势。

截至2026年8月，Claude已经在Anthropic内部“主导”约26%的AI研发工作，而2026年2月这一比例还不到1%；与此同时，Anthropic最常使用的内部平台上，任意时刻大约有3万个AI Agent正在执行研究和工程任务。

但Anthropic也特别强调，目前Claude还没有在其测量的AI研发工作中实现完全自主运行。

这个限定非常重要。

它告诉我们，Agent并不是突然变成了可以自己完成一切的“数字员工”。

真正发生的变化，是：

大量原来由人逐步完成的小决策，正在被机器接管。

而这恰恰是Jev想吃掉的市场。

Jev到底输出什么？

TypeSafe目前把Jev的核心判断分成三类。

一种叫 Choice。

给定几个候选项，从中选择一个，同时给出概率分布。

例如：

退款、投诉、物流、咨询。

一种叫 Score。

不是简单分类，而是在某个尺度上打分。

例如：

欺诈风险0到10分。

客户流失可能性0到100。

还有一种比较特殊，TypeSafe把它叫 Noul。

本质上就是Yes/No判断，同时输出概率。

例如：

“这次操作是否需要人工审核？”

传统大模型可能回答：

“综合用户历史行为和交易金额，我认为此次交易存在一定异常风险，因此建议人工审核。”

Jev更接近：

YES: 0.94

TypeSafe公开的Workflow Evals也采用了这三种基本判断方式：Noul、Choice和Score，再把判断结果交给普通代码继续处理。

这就是Jev真正不同的地方。

它没有试图重新发明软件。

相反，它重新划了一条边界：

确定性的事情让代码做，不确定但需要判断的事情让模型做，需要语言表达的时候才让LLM做。

这个思路可能比“全部交给一个超级模型”更值得关注。

200倍速度、400倍成本差距，应该怎么看？

Jev发布后，最吸引眼球的当然还是性能数据。

TypeSafe给出的说法是，在它针对的System One任务中，Jev可以达到比传统前沿语言模型高20到200倍的速度，并将成本降低40到400倍。

公司公开价格目前是：

每100万个输入Token约0.042美元，输出不单独计费。

换算下来，就是每10亿输入Token约42美元。

TypeSafe自己公布的一组Workflow测试甚至出现过约193.6倍速度和444.6倍成本差异。

但这里必须加一句非常重要的限定。

TypeSafe自己都在发布文章里承认，这组数字很可能处于现实收益的高位，而且测试场景、工作流设计以及参考答案的选择都可能带来偏差。

换句话说：

“Jev比所有大模型快200倍”是错误的理解。

更准确的表述应该是：

在Jev专门针对的结构化判断任务上，放弃文本生成之后，它有机会获得远高于通用生成模型的速度和成本优势。

这是两个完全不同的说法。

前者是营销标题。

后者才是产品逻辑。

Browser Use的7秒演示，真正值得看的并不是“7秒”

Jev爆火之后，一个传播很广的案例来自Browser Use。

开发者让浏览器Agent在Google Flights上完成从苏黎世到伦敦的航班搜索。

公开演示中，任务最终在大约 7.073秒 内完成。

看起来很惊人。

但如果认真查看Browser Use公开的性能记录，会发现事情比“一换Jev就从几分钟变7秒”复杂得多。

他们后来做了6次交替测试。

原始方案的中位任务时间约为9.45秒，优化方案约为7.09秒，下降约25%；浏览器协议调用次数则从中位1092次下降到101次。

而且整个任务并不是全部由Jev完成——需要真正生成“Zurich”“London”等文本时，系统仍然调用了Mercury语言模型。Browser Use自己也明确表示，样本量只有3组配对实验，不足以得出很强的统计结论。

这个案例反而比“快几十倍”的标题更有价值。

因为它展示了未来Agent很可能出现的一种架构：

LLM负责写，Jev这一类模型负责判断，代码负责执行。

而不是所有步骤都扔给同一个模型。

“零幻觉”也不能理解成“永远不会错”

Jev还有一个传播非常广的卖点：

Zero Hallucinations。

这句话尤其需要解释。

TypeSafe所谓的“零幻觉”，主要建立在输出类型受到严格约束的基础上。

如果系统要求模型只能从：

refund
complaint
shipping
other

四个选项里选择，那么Jev不会突然回答：

“建议首先与用户友好沟通。”

它不会生成一个系统没有定义过的第五种答案。

从软件工程角度，这非常重要。

因为很多Agent事故并不是模型完全不懂问题，而是它生成了一个程序根本无法处理的格式。

但是：

不会乱生成格式，不代表判断一定正确。

Jev仍然可能把投诉分成咨询，也可能给一个本来危险的操作较低风险概率。

TypeSafe自己的服务协议同样明确提醒，服务可能产生“不准确或错误的输出”，用户仍然需要自行评估结果。

所以更严谨的说法是：

Jev解决的是“类型幻觉”和结构化输出可靠性问题，而不是彻底解决AI判断错误。

这个区别非常重要。

为什么偏偏是2026年的这个时间点？

只做分类、排序、打分的机器学习系统，当然不是2026年才出现。

传统机器学习时代就有大量分类模型。

大模型也早就能够输出JSON和结构化结果。

所以真正值得问的是：

为什么Jev这种思路现在突然获得这么多关注？

我认为核心原因并不是某个神奇的新架构。

而是AI的主要瓶颈正在变化。

2023年的问题是：

AI会不会写？

2024年的问题是：

AI会不会推理？

2025年开始，问题逐渐变成：

AI能不能调用工具，把事情真正做完？

到了2026年，越来越多团队真正把Agent塞进生产环境以后，又冒出了新的问题：

能做是一回事，能不能便宜、快速、稳定地做一百万次，是另一回事。

这其实是所有软件技术都会经历的过程。

刚出现的时候，人们关心能力上限。

真正进入产业之后，大家开始关心单位成本、延迟、可靠性和吞吐量。

Jev踩中的，就是这个转换点。

甚至连TechCrunch采访到的实际开发者反馈也呈现出这种特点：Vercel工程师报告，在一个命令安全分类任务中切换到Jev后，速度提升约5到18倍；另一位开发者测试商业邮件分类时，Gemini准确率略高，但成本高出约10到20倍。

这些当然仍然只是具体开发者案例，不代表所有任务。

但它们透露出的趋势很清楚：

开发者开始愿意为了“更合适”，而不是“更全能”，选择不同模型。

大模型时代可能正在结束“一把梭”的阶段

过去两三年，我们形成了一个很自然的习惯：

有AI任务？

扔给最强模型。

写代码，最强模型。

看合同，最强模型。

分类邮件，最强模型。

判断按钮，还是最强模型。

这在AI能力还不足的时候非常合理。

因为通用模型首先要解决的是“能不能完成”。

但当能力逐渐过剩，经济账就开始变重要。

一个企业每天处理1000次判断时，调用成本可能无所谓。

每天100万次呢？

每天1亿次呢？

这时候真正的问题就从：

“哪个模型最聪明？”

变成：

“这一小步，到底需要多少智能？”

这可能也是Jev最值得关注的地方。

它未必会取代GPT、Claude或者Gemini。

事实上，它很可能恰恰需要与这些大模型共存。

未来一个成熟Agent背后，也许不会只有一个AI模型。

复杂规划交给推理模型。

写邮件交给语言模型。

识别图片交给视觉模型。

语音交流交给语音模型。

风险判断、分类、路由、排序，则交给Jev这一类低延迟决策模型。

最后再由传统代码把所有东西连接起来。

AI系统正在从“一个超级大脑”，逐渐变成“一支专业分工的模型团队”。

Jev真正给普通人的启发，不是去学一个新模型

如果只是从工具学习角度看Jev，很容易再次掉进“追新模型”的循环。

今天学GPT。

明天学Claude。

后天学Jev。

过两个月又有新的东西。

实际上Jev带来的更重要启发，并不是“大家赶紧学会Jev”。

而是一个产品设计原则：

不要从模型能力出发设计问题，要从任务本身出发选择模型。

先问：

用户究竟想完成什么？

这个步骤真的需要生成文字吗？

需要复杂推理吗？

只是分类吗？

只是判断吗？

只是排序吗？

能不能交给普通代码？

只有回答完这些问题之后，才应该决定调用哪一个AI。

这是Agent时代一个很重要的能力。

未来真正懂AI的人，未必是记住模型最多的人。

而是能够把一个复杂工作拆成：

哪里需要语言，哪里需要判断，哪里需要代码，哪里根本不需要AI。

我甚至认为，这可能比Prompt技巧更重要。

因为随着模型越来越强，Prompt本身会越来越容易。

但定义问题、拆解任务、选择正确工具，不会因此消失。

最后

Diogo Almeida参与过让语言模型更会“说话”的研究。

几年以后，他又做了一款主动放弃说话能力的模型。

表面上看，这是一次180度转弯。

实际上，它们背后的逻辑可能完全一致：

InstructGPT解决的是——

人真正需要模型做什么？

而Jev重新问了一遍同样的问题：

软件真正需要模型做什么？

答案显然并不总是一篇漂亮的文字。

有时候，一个数字、一个选择、一个Yes或者No，就已经足够了。

过去几年，我们一直在追求更全面、更强大的AI。

Jev提醒我们的则是另一件事：

能力更多，不等于产品更好。

一个模型真正有价值的地方，从来不是它“什么都会”。

而是它是否在正确的地方，用正确的成本，完成了正确的任务。

这可能才是Agent真正进入生产环境以后，AI行业接下来要补的一课。

---

关注本站，每天分享跨境电商前沿资讯（ Ctrl + D 收藏本站/收藏为书签 ）