Agent 逼出了“语义判断市场”

9月15日，TypeSafe 把Jev称为 System One Model：不擅长陪人聊天，不负责写一段漂亮的文本；它接收非结构化状态，直接返回软件能调用的、带类型和概率的决策。公司宣称，它为自动化而生，放弃了文本生成，因此可以把速度和成本压到前沿大模型的两个数量级之外。

令人想探寻的是，它为什么偏偏出现在今天？

因为拆开看，Jev 所依赖的几块技术拼图，早就不新了。

分类模型早就存在；用自然语言临时定义任务，GPT-3 时代就已成为现实；Function Calling 在 2023 年走向主流；Structured Outputs 在 2024 年已经让大模型可以稳定返回符合 JSON Schema 的结果。

换句话说，到了 2023—2024 年，开发者理论上已经能“拼”出一个很像 Jev 的东西：一个大模型，加一套提示词，加函数调用，加结构化输出，加一点工作流工程。

可，为什么市场上没有出现 Jev？

答案可能是：那时它还没有一个足够痛的客户。

Jev 不是到 2026 年才终于能做出来的模型。它更像是 Agent 到了今天，才终于有必要为它单独付费的一类模型。

真正发生变化的，不是某个模型突然开窍，而是 AI 的工作负载变了。

过去，大模型面对的主要是人；现在，它越来越多地面对软件、工具链、浏览器、工作流和另一个 Agent。

当 AI 的客户从人变成软件，智能的最佳接口，也就不再只是语言。

一、Jev 之前，行业已经把大模型“伪装”成函数很多年了

先把 Jev 放回它的技术前史里。

过去十年，AI 行业一直在做一件事：把不确定的语义理解，变成程序可以执行的确定结构。

最早是分类器。

输入一封邮件，输出“垃圾邮件”或“正常邮件”；输入一张图片，输出“猫”或“狗”；输入一段客服对话，输出“退款”“投诉”或“咨询”。

这种模型很快、很便宜，也很适合软件调用。但它有一个明显限制：任务必须在训练前就定义好。你想加一个标签、换一个业务规则，往往意味着重新收集数据、训练、部署。

后来，大模型改变了这件事。

开发者不再需要为每一种分类单独训练一个模型。只要用一句自然语言告诉模型：“请判断这段文本属于哪一类”“请从会议纪要中抽取负责人和截止日期”“请决定下一步要调用哪个工具”，模型就可以临时完成任务。

这其实是大模型最重要、也最容易被忽略的一种能力：它把“定义任务”这件事，从训练阶段搬到了运行阶段。

但此时的大模型仍然更像一个会说话的人。你得先问它，等它组织语言，再从它的答案里找出能被系统使用的信息。

于是，行业进入第三阶段：让大模型输出结构化结果。

2023 年，Function Calling 让模型能够选择工具并生成参数；2024 年，Structured Outputs 开始承诺让模型输出严格遵循开发者给定的 JSON Schema。此前需要靠提示词、正则、重试和解析器解决的麻烦，被逐步变成底层能力。

这套路线的本质是：

非结构化状态
→ 大模型逐 token 生成文字或 JSON
→ 系统解析结果
→ 决定下一步动作

到这里，大模型已经很像一个函数了。

但 Jev 的问题更进一步：

如果软件最终只需要一个函数结果，为什么中间还要让模型生成一段文字？

这正是 Jev 和“更严格的 JSON 输出”之间的分水岭。

Structured Outputs 解决的是：模型能不能按格式交付结果。

Jev 想解决的是：模型能不能直接成为结果。

它的理想路径是：

非结构化状态
→ 语义判断
→ 类型 + 概率
→ 软件执行

TypeSafe 给这个思路起了一个很有野心的名字：frontier-intelligence function call，前沿智能函数调用。

说白了，就是把“理解这件事”从聊天能力里拆出来，变成软件基础设施。

二、2024 年已经能让大模型“像函数”；2026 年，Agent 才让函数本身变成刚需

如果只有结构化输出，Jev 未必会成为一个值得讨论的产品类别。

因为在大量普通应用里，大模型慢一点、贵一点，并不构成致命问题。

一个用户问 ChatGPT：“帮我总结这份报告。”

模型花 5 秒还是 10 秒，输入输出多一点 token 还是少一点 token，用户通常能等。甚至模型多说几句、多做一点推理，用户还会觉得它更聪明。

聊天界面的成本结构是：

一个人
→ 一次问题
→ 一次模型回答

但 Agent 的成本结构完全不同。

一个 Agent 要完成“订一张机票”“筛选一批简历”“处理一笔报销”“检查一段代码”“更新一个客户工单”时，通常不是调用模型一次，然后结束。

它会进入一个循环：

观察当前状态
→ 判断下一步
→ 调用工具
→ 得到新状态
→ 再判断下一步
→ 再调用工具

在这个循环里，真正需要“写出一篇回答”的时刻并不多。

更多时候，Agent 只需要做一些细小但高频的判断：

• 当前页面上哪个元素是目标按钮？
• 这一步应该点击、输入、滚动，还是返回？
• 这次工具调用失败了，要重试还是改走另一条路径？
• 这条信息和当前任务相关吗？
• 这段记忆要不要放进上下文？
• 这笔交易风险够不够高，是否要转人工？
• 现在该调用一个贵的强模型，还是一个便宜的快模型？
• 任务是否已经完成，还是只是看上去完成了？

对人类来说，这些问题琐碎到不会被单独命名。

但对 Agent 来说，每一个都意味着一次模型调用、一次等待、一次不确定性，以及一次可能扩散到后续步骤的错误。

于是，过去不重要的两件事，突然变成了第一性问题：

延迟 × 调用次数
成本 × 调用次数

这也是 Jev 出现在今天的真正背景。

不是模型第一次能够判断，而是 Agent 第一次把“判断”变成了一种高频、密集、昂贵的工作负载。

过去，模型回答错一句话，用户可以追问。

现在，模型在第 17 个微决策中多绕了一步，可能意味着整个浏览器任务失败；模型把 0.52 的风险误当成确定性结论，可能意味着自动化流程在不该放行的地方放行。

Agent 不只是需要更强的模型，它开始需要更适合不同环节的模型。

三、Agent 基础设施成熟后，“不是每一步都配得上大模型”成了现实问题

Jev 的出现，与 Agent 在过去两年的产品化进程高度同步。

2024 年，Computer Use 和 MCP 让模型开始更系统地接触浏览器、工具和外部系统；2025 年，围绕工具调用、编排、交接、追踪、护栏的基础设施逐渐成熟。OpenAI 在 Agents SDK 中明确提供了 Agent、Handoff、Guardrails 和 Tracing 等能力，解决的正是长链条 Agent 在生产环境中的组织与观察问题。

这意味着行业开始不再只问：

这个模型会不会回答问题？

而是在问：

这个模型能不能在一个持续运行的软件系统里，稳定完成任务？

两种提问之间差别很大。

前一种以模型能力为中心。大家追逐更长上下文、更复杂推理、更强多模态、更高 benchmark。

后一种以系统效率为中心。大家不得不面对一个更现实的问题：一个 Agent 的一百步里，到底有几步真的需要调用最贵、最慢、最会生成的模型？

答案通常不是一百步。

比如，在一个浏览器 Agent 中，真正需要自然语言生成的，可能只是“把用户的姓名、地址、搜索词填进输入框”。但在点击、选择、判断、检查、重试这些环节中，系统大多只需要一个结构化决定。

Browser Use 围绕 Jev 做的实验，很能说明这种架构变化。

它把浏览器操作拆开：Jev 负责在当前页面状态下选择操作和目标元素；只有当操作是“输入文本”时，才交给小型语言模型生成文字。在一个 Google Flights 的单一任务中，项目公布的六次交替测试显示，中位完成时间从 9.450 秒降到 7.092 秒，浏览器协议调用数从 1092 次降到 101 次。

它揭示了一件更重要的事：

在 Agent 时代，性能优化不只是把同一个大模型跑得更快；还包括重新决定，哪一步根本不该交给生成式大模型。

这是一种系统架构的变化。

四、Jev 真正要卖的，不是“JSON”，而是软件敢不敢相信一个概率

Jev 最值得重视、是“校准”。

今天很多人已经习惯了结构化输出。

系统让模型返回：

{
  "department": "billing",
  "confidence": 0.91
}

看上去这已经足够软件化了。

但问题在于，0.91 到底意味着什么？

它可能只是模型写出来的一个看似合理的数字。模型很擅长用自信的语气回答，也很擅长在 JSON 里填一个漂亮的小数；但“格式正确”不等于“概率诚实”。

这是两种截然不同的可靠性：

Structured Outputs 已经大幅推进了前者。

后者却仍然是 Agent 自动化的深水区。

假设一个风控系统收到以下输出：

欺诈风险 = 0.12 → 自动通过
欺诈风险 = 0.67 → 二次校验
欺诈风险 = 0.93 → 转人工审核

这套系统要求模型的概率能够支持阈值决策。

如果 0.93 只是“模型感觉自己很有把握”，那么自动化不但没有降低风险，反而把风险封装进了一套看上去很专业的工作流里。

TypeSafe 把自己的训练方法称为 RLCD，即 Reinforcement Learning for Calibrated Decisions，并将“校准决策”放在产品叙事的中心。但目前还只是官方用例。

但无论 Jev 最终表现如何，它把一个过去常被忽略的问题推到了台前：

未来 AI 系统真正稀缺的，是“能让软件据此承担行动后果的判断”。

五、为什么 OpenAI、Anthropic 没有先做一个 Jev？

这并不意味着前沿实验室没看到这个方向。

更可能的解释是：它们的目标函数不一样。

OpenAI、Anthropic、Google 这样的公司，必须持续优化一个尽可能通用的模型。

它要能写代码、能研究、能对话、能处理图片、能理解长上下文、能调用工具、能做复杂推理。它当然也要适合 Agent，但它不能只为 Agent 的某一种细颗粒度判断而生。

它们竞争的是：

更强的通用能力
更长的推理链
更好的答案
更高的人类偏好

Jev 的赌注则不同。

它不是问“我能不能成为最强的通用模型”，而是问：

我能否在足够好的前提下
更快、更便宜、更稳定地完成一类语义决策？

这有点像计算产业从 CPU 到 GPU，再到 ASIC 的变化。

CPU 没有失去价值；GPU 也没有取代所有计算。但当一类工作负载足够大、足够稳定时，专用化就会成为新的效率来源。

Jev 所做的，是把过去被大模型一并吞进去的能力——选择、路由、判断、验证、筛选——重新拆出来。

RouteLLM 已经是一个相邻信号：它关心的是“面对一个请求，该调用强模型还是便宜模型”。Jev 更进一步，它试图把“决策”本身变成独立模型类别。

这也解释了为什么一家公司有机会从这个缝隙切入。

前沿实验室的重点是把模型做得更全能。

新公司的机会，往往是承认：有些任务根本不值得全能。

六、Jev 真正对应的，不是一个产品，而是一张新的模型分工图

过去几年，AI 行业习惯了一个方向：能力集中。

一个模型会聊天、会写作、会编程、会看图、会搜索、会调用工具、会长推理。越大的模型，越像一个万能接口。

但 Agent 的兴起，可能推动另一种趋势：能力拆分。

未来，一个成熟的 Agent 可能同时调用很多不同的“智能元件”：

• Router：决定该调用哪个模型、哪个工具；
• Verifier：判断上一步结果是否可信；
• Memory Selector：决定哪些历史信息该进入上下文；
• Relevance Judge：筛选哪些文档、页面或消息真正相关；
• Semantic Trigger：判断是否满足某个业务触发条件；
• State Estimator：判断任务现在究竟处于什么状态；
• Planner：负责真正复杂、长链条的推理与规划；
• Generator：只在需要写给人看的内容时，负责语言生成。

这才是 Jev 最有意思的地方。

它说的是：“生成式 AI 不该负责所有事。”

对于人类，语言当然仍是最自然的接口。

但对于软件，一个更好的接口可能是类型、概率和状态转移。

可以把这两种时代压缩成一组变化：

2022—2024：
模型 → 人
最佳接口：语言

2025—2026：
模型 → 软件 / Agent / 另一个模型
最佳接口：类型 + 概率 + 状态转移

Jev 提出了一个正确的问题。

过去，行业总在问：怎样让模型更像人？

接下来，越来越多的公司可能开始问：怎样让模型更像一个可靠的软件组件？

这两件事，未必通向同一条路。

>/作者：王零壹，920.org.cn（AI Research Institute）创始人，港大AIBT研究生，前上市公司 CMO。长期研究 AI 产品、Agent 架构与商业增长，并持续观察技术变迁如何重塑人的工作、判断与生活。

*著有《AIGC从0到1》系列丛书、及东方寓言小说《飞将军》；

*善于洞察先机，中文互联网第1个意识到OpenClaw范式价值的人（1月26日）；

关注我，一起AIGC从0到1~