深度拆解
本文讨论AI判断模型、Skill、Agent与专业知识系统之间的关系，不构成任何产品采购建议。
这两天，一个叫 Jev 的AI模型突然引起关注。
它有一个非常特别的特点：
你给它一段状态，比如一封邮件、一张工单、一条记录，再给它几个提前定义好的问题，它直接告诉你：
> 选哪个；
>
> 分多少；
>
> 是，还是不是；
>
> 以及它有多大把握。
TypeSafe把Jev定义为一种面向软件自动化的 System One Model。官方强调，它不是为聊天和长文本生成优化，而是让软件直接拿到结构化、带概率的判断结果。Jev目前处于early access阶段，官方公布的输入价格是每百万token 0.042美元，输出不收费；其宣称的端到端延迟范围约为70—500毫秒。
这当然很便宜。
但我觉得，真正值得问的问题不是：
> Jev为什么这么便宜？
而是另一个更麻烦的问题：
> 既然“判断什么”本来就要由我们自己定义，那为什么一定要用Jev？
>
> 我为什么不能自己写一个Skill？
>
> 或者自己做一个Agent？
>
> 甚至直接把判断规则写进程序里？
一旦把这个问题想清楚，Jev真正值钱的地方，反而会比“一个超便宜的新模型”更清楚。
我们平时说“AI判断”，很容易把两件不同的事情混成一件事。
比如：
> “这条新闻值不值得继续研究？”
表面上，这只是让AI做一个判断。
但真正拆开以后，它至少包含三个问题：
第一：
> 什么叫“值得研究”？
第二：
> 根据什么资料判断？
第三：
> 拿什么工具把这个判断执行出来？
这三件事，根本不是同一层。
假设你有一套专业研究系统。
你的数据库里有大量历史数据，你也已经总结出了自己的研究标准：
> 什么叫重大变化；
>
> 什么叫有效传导；
>
> 什么叫有足够证据；
>
> 什么情况值得进入深度研究。
那么你的真正资产是什么？
不是某一个AI模型。
而是：
> 你的数据库。
>
> 你的判断标准。
>
> 你的历史案例。
>
> 你的错误记录。
模型只是拿这些东西去执行。
这一点非常重要，因为它直接决定了：
> Jev究竟解决了什么，没解决什么。
TypeSafe自己的公开资料，其实已经把这一点说得很清楚。
它的workflow方法不是：
> “把一个任务扔给Jev，让Jev自己想明白。”
而是先把任务拆成：
> programmatic rules（程序规则）
>
> ＋
>
> intelligent judgments（需要智能判断的部分）
然后把需要判断的部分进一步拆成几类结构化问题：
> Noul：是或否
>
> Choice：从预先定义的选项里选择
>
> Score：按照预先定义的尺度打分
最后，再把这些结果交回代码，决定下一步动作。TypeSafe的workflow evals页面甚至直接展示了这样一个过程：原本写成自然语言的业务政策，被拆成一部分代码规则，以及一组需要模型回答的问题。
这意味着一个非常关键的事实：
> Jev回答的是你定义好的问题。
>
> 而“什么问题值得问、什么选项合理、评分尺度怎么设”，仍然需要系统设计者来决定。
这不是Jev的缺点。
恰恰相反，这就是它的产品定位。
但也正因为如此，我们才更应该追问：
> 既然判断框架最终还是我的，为什么我不自己做？
这其实是最容易被AI宣传忽略的一层。
比如：
> 金额超过100万元，进入人工审核。（来源：本文机制示例，非真实企业阈值）（来源：本文机制示例，非真实企业阈值）
这是规则。
> 日期超过合同截止日，标记异常。
也是规则。
> 数据库里已经存在相同事件，不重复进入研究池。
还是规则。
这些东西都不需要模型。
SQL可以做。
Python可以做。
普通程序也可以做。
所以真正合理的自动化系统，不应该是：
> 凡是判断，都丢给AI。
更合理的方式应该是：
> 能规则化的，先规则化。
>
> 规则解决不了的，再交给模型。
为什么？
因为规则的特点是：
> 快；
>
> 稳；
>
> 可解释；
>
> 成本几乎可以忽略。
如果一个判断可以100%写成代码，却硬要花钱调用模型，反而是增加系统成本。（来源：本文机制示例）
这时候就轮到Skill了。
Skill可以理解成：
> 把一套已经确定的方法写下来，让系统按这个方法执行。
比如一个研究Skill可以规定：
> 先查哪些数据库；
>
> 再核哪些来源；
>
> 再计算哪些指标；
>
> 最后按照什么标准输出。
这里面大量工作，本质上不是“模型智能”。
而是：
> 把你的方法论写成可执行流程。
所以Skill和Jev解决的问题不同。
> Skill解决“怎么做”。
>
> Jev解决“当规则不够时，怎么做一个语义判断”。
Agent比Skill再往上走一层。
它负责的是：
> 调度。
比如一个研究Agent收到一条新闻以后，可以：
> 先查数据库；
>
> 再查公开资料；
>
> 再调用计算工具；
>
> 再执行Skill；
>
> 遇到规则解决不了的问题，再调用模型；
>
> 最后把结果写回数据库。
所以：
> 数据库是知识。
>
> Skill是方法。
>
> Agent是调度。
>
> 模型是判断引擎。
把这四件事情拆开以后，一个很重要的结论就出来了：
> Jev不是Agent的替代品。
>
> Jev甚至不是专业判断系统本身。
它更像是：
> 这个系统里面，一个可以被调用的模型。
而是：
> 你的Agent里，判断这一层到底用谁？
这时候事情突然简单了。
一个专业系统完全可以这样：
> 数据库
>
> ↓
>
> 规则
>
> ↓
>
> Skill
>
> ↓
>
> Agent
>
> ↓
>
> 判断引擎
>
> ↓
>
> Jеv / 其他模型 / 本地模型
>
> ↓
>
> 执行动作
甚至：
> 简单判断 → 不用模型
>
> 语义判断 → 用小模型
>
> 复杂推理 → 用通用大模型
>
> 高风险结果 → 人工复核
这才是比较合理的架构。
所以真正的问题从来不是：
> “我要不要Jev？”
而是：
> “我的系统里，这一类判断到底需要什么样的引擎？”
到了这里，我们终于可以公平地看Jev。
Jev并没有发明“机器判断”。
AI以前就可以判断。
甚至今天的大语言模型同样可以做判断。
真正发生变化的是：
> 过去你为了得到一个简单判断，往往要调用一个会读、会写、会推理、会生成长文本的通用大模型。
现在Jev说：
> 你只是想做一个选择题，为什么还要买一整套“会写文章的大脑”？
所以Jev真正解决的是：
> 把需要语义理解、但答案范围已经被限定的高频判断，做得更快、更便宜。
TypeSafe官方也正是这样定位它：让软件直接调用typed decisions，而不是先生成字符串，再由程序解析字符串。它强调的还有结构化输出、概率和confidence，以及为自动化场景设计的并行采样。
这其实是一个很具体的市场。
例如：
> 这封邮件属于哪个部门？
>
> 这笔费用是不是异常？
>
> 这个客户有没有流失风险？
>
> 这个安全事件要不要升级？
>
> 这一步Agent要不要调用工具？
这些问题：
> 规则太死。
>
> 通用大模型又太贵。
Jev就卡在中间这一层。
TypeSafe自己的回答是：
公司声称System One Model采用新的模型架构、新的parallel sampler，以及他们称为 Reinforcement Learning for Calibrated Decisions（RLCD） 的训练方法，并认为这种模型天然适合“软件直接消费判断”的场景。
这部分不能因为Jev很快出现竞品，就直接否定。
因为：
> 一个产品形态很容易复制，
>
> 不代表底层技术一定没有创新。
真正需要继续验证的是：
> 这种架构到底有多大的技术优势？
>
> 这种优势是否能稳定保持？
>
> 其他模型能不能很快达到同样效果？
>
> 成本和速度优势能保持多久？
这才是技术护城河的问题。
Laya是什么？
它不是Jev官方出的第二个版本。
它是一个开源项目。
GitHub上的Laya项目把自己定位成一个：
> 开源的、非自回归的System 1 decision engine。
它可以接收文本、邮件、工单或者JSON状态，然后针对你定义好的问题输出：
> `choice`
>
> `score`
>
> `noul`
也就是：
> 选哪个；
>
> 打多少分；
>
> “是真的”概率是多少。
它还提供本地模型权重，并支持自己部署。
更有意思的是，Laya甚至直接提供了Jev-compatible的接口，也就是说，开发者可以用非常接近Jev的方式来调用这种类型的判断模型。
这件事情为什么值得写？
因为它改变了我们对Jev的一个直觉。
原来我们可能会觉得：
> “Jev创造了一种特别新的机器判断接口。”
但很快就有人做出了：
> 类似的决策接口
>
> ＋
>
> 开源模型
>
> ＋
>
> 本地运行
>
> ＋
>
> 相近的decision primitives。
至少说明：
> “把机器判断做成一个独立、结构化、可直接调用的API”这个产品形态，本身并没有形成很高的复制门槛。
而且Laya自己的公开benchmark里还直接拿Jev做了对比。
例如，它报告在自己的typed-decisions测试上，Laya的一个专门微调checkpoint准确率为0.766，而Jev公开结果为0.727；同时也明确承认，在高选项数量的任务、概率分布匹配等部分，Jev仍然有优势。需要特别注意：Laya的Jev数据来自第三方公开结果，并非Laya团队直接调用Jev API测得，因此这些结果只能作为参考，不能当成严格的一对一实验结论。
这其实比“Laya已经超过Jev”更值得关注。
因为真正应该问的是：
> 如果连这种判断模型都可以很快出现开源替代，那么Jev最终靠什么形成长期护城河？
Laya的出现，并不能证明：
> “Jev就是一个工程技巧。”
这个结论证据不足。
因为TypeSafe明确声称Jev背后有新的架构、sampler和RLCD训练方法。要证明这些东西没有创新，需要技术论文、独立复现或者更充分的第三方研究，而不是看到一个开源竞品就可以直接判定。
但Laya确实把另一个事实摆到了台面上：
> Jev最容易被复制的，是产品形态和调用方式。
也就是说：
> “状态进来 → 几个结构化问题 → 概率化判断出来”
已经开始成为一种可以被其他开发者复现的接口范式。
所以真正应该观察的不是：
> “Jev是不是唯一？”
而是：
> “Jev能不能在模型能力、速度、价格和校准之间，长期保持别人复制不了的组合优势？”
假设你做的是一个专业研究项目。
你的数据库里已经沉淀了：
> 历史数据；
>
> 研究记录；
>
> 领域规则；
>
> 判断标准；
>
> 过去判断的正确率；
>
> 错误案例。
你现在希望系统每天自动判断：
> 哪些新闻值得继续研究？
>
> 哪些变化属于结构性变化？
>
> 哪些事件值得升级？
>
> 哪些材料只是噪音？
你首先应该做的，不是买Jev。
而是：
> 先把你的判断标准写清楚。
然后：
> 能规则化的，写进代码。
>
> 能流程化的，写成Skill。
>
> 需要调度的，放进Agent。
>
> 只有规则和程序解决不了、但又不值得调用通用大模型的语义判断，再考虑Jev这一类模型。
这样一来：
> Jev不是你的知识库。
>
> 也不是你的方法论。
>
> 更不是你的研究Agent。
它只是：
> 你可以替换掉的一个判断引擎。
因为如果你把整个系统都建立在第三方模型上，很容易出现一个问题：
> 模型在替你拥有系统。
今天：
> Jеv
明天：
> Laya
后天：
> 另一个模型
如果你的Agent只是：
> “把所有事情扔给Jev”
那么换模型的时候，你整个系统都得跟着变。
但如果你自己的结构是：
> 数据库
>
> ↓
>
> 判断标准
>
> ↓
>
> Skill
>
> ↓
>
> Agent
>
> ↓
>
> 模型接口
那就完全不同。
模型可以换。
甚至可以同时接多个模型。
例如：
> 简单分类 → Laya
>
> 高可信判断 → Jev
>
> 复杂推理 → 通用LLM
>
> 确定规则 → Python
你的系统还在。
真正留在你手里的，是：
> 判断标准。
过去大家比的是：
> 谁的模型更强。
后来开始比：
> 谁的token更便宜。
现在开始比：
> 谁的一次判断更便宜。
再往后，真正该比的可能是：
> 谁完成一次成功任务更便宜。
公式其实很简单：
> 单位成功任务成本
>
> ≈
>
> （模型成本 + 数据成本 + 基础设施成本 + 执行成本 + 监督成本 + 失败成本）
>
> ÷
>
> 成功率
于是一个模型即使：
> 0.000084美元一次，（来源：按 TypeSafe AI 公开定价 $0.042/十亿输入 token 推算，2026-09）
也不代表它真的便宜。
如果它判断错一次，会导致：
> 100美元损失；（来源：本文机制示例，非真实企业数据）（来源：本文机制示例，非真实企业数据）
那么之前省下来的调用费，很可能一眨眼就没了。
所以：
> 便宜的不是“智能”。
>
> 便宜的只是调用智能的那一层。
这才是Jev最值得我们研究的地方。
一个专业系统真正应该沉淀的，很可能是：
> 数据
>
> ＋
>
> 判断标准
>
> ＋
>
> 工作流
>
> ＋
>
> 历史结果
>
> ＋
>
> 错误记录
至于模型：
> 今天Jev。
>
> 明天Laya。
>
> 后天可能是更便宜的开源模型。
>
> 再以后，甚至可能是自己训练的模型。
模型一直在变。
但你的判断标准如果没有变，你的系统就仍然是你的。
当然有。
但它的意义并不是：
> “大家都应该用Jev。”
而是：
> “语义判断正在变成一种可以被单独计价、单独优化、单独替换的基础能力。”
以前的软件主要靠：
> 代码。
后来软件开始调用：
> 大模型。
现在可能逐渐出现：
> 代码 + 很多不同类型的智能微模块。
其中一个模块负责感知。
一个负责预测。
一个负责规划。
一个负责判断。
一个负责执行。
一个负责评价。
而Agent把它们串起来。
Jev只是把其中的“判断”这一层单独拿出来，做成一种非常便宜的服务。
所以：
> Jev的重要性，不一定来自“它是唯一的”。
>
> 而可能来自“它把一个原本藏在大模型里的能力单独拿出来卖了”。
而是：
> 既然判断标准还是人定义的，
>
> 既然规则能够自己写，
>
> 既然Skill可以自己做，
>
> 既然Agent可以自己搭，
>
> 既然开源社区已经可以出现Jev-compatible的判断模型，
>
> 那么Jev真正不可替代的东西到底是什么？
答案目前其实还没有完全确定。
TypeSafe需要继续证明的，是：
> 架构优势是否真实；
>
> 判断质量是否稳定；
>
> 概率是否足够校准；
>
> 速度优势是否能保持；
>
> 价格能否长期成立；
>
> 开源替代出现以后，自己的优势还能剩多少。
而开发者真正需要决定的，则不是：
> “要不要相信Jev。”
而是：
> “我的系统里，哪些能力必须自己拥有，哪些能力可以外包给模型。”
如果把这个问题落到一个真实的专业项目里，我会把系统拆成这样：
> 数据库
>
> ↓
>
> 自己的判断依据
>
> ↓
>
> 规则
>
> ↓
>
> Skill
>
> ↓
>
> Agent
>
> ↓
>
> 判断引擎
>
> ↓
>
> Jev / Laya / 其他模型
>
> ↓
>
> 结果回写数据库
>
> ↓
>
> 错误复盘
>
> ↓
>
> 更新判断依据
这里最重要的一步，其实不是模型。
而是：
> 结果回写以后，系统能不能越来越知道自己为什么错。
因为一个真正有价值的专业Agent，不应该只是：
> 今天替你判断一次。
而应该逐渐形成：
> 自己的历史判断数据。
到最后，你拥有的就不只是一个Agent。
而是一套：
> 可以不断换模型，但判断体系不会丢的专业系统。
Jev真正值得关注的，不是：
> “一次判断便宜到多少钱。”
而是它把AI重新拆开了。
过去我们容易把AI理解成：
> 一个大模型，什么都做。
现在开始出现另一种结构：
> 数据负责提供事实。
>
> 人负责定义标准。
>
> Skill负责执行方法。
>
> Agent负责调度。
>
> 模型负责处理规则无法完全形式化的部分。
>
> 程序负责执行动作。
Jev，只是其中“模型”这一层的一种新选择。
所以对专业项目来说，最值得拥有的从来不是：
> “我用了哪个模型。”
而是：
> “我到底依据什么做判断。”
因为模型可以替换。
Skill可以重写。
Agent可以重构。
API可以涨价。
开源模型也可能突然出现。
但如果你的：
> 数据库
>
> 判断标准
>
> 历史案例
>
> 错误记录
>
> 工作流
都掌握在自己手里，那么你始终拥有这套系统真正的核心。
所以，Jev最值得问的问题并不是：
> “它是不是下一个大模型？”
而是：
> “当机器判断已经便宜到几乎可以忽略之后，我们真正缺的，还是算力吗？”
也许不是。
真正稀缺的，可能越来越是：
> 我们到底该让机器按照什么标准判断。
它可以协助开发者设计问题、规则和工作流，但在生产workflow中，具体的问题、选项、评分尺度以及周围的程序逻辑需要由系统设计者定义。TypeSafe自己的workflow evals明确采用“程序规则＋智能判断”的拆解方式。
Skill主要描述“怎么执行一套方法”；Jev解决的是其中需要语义理解的机器判断。Skill可以调用Jev，但两者不是同一层。
Agent负责调度数据、工具、规则和模型，把整个任务跑完；Jev只是Agent可以调用的一个判断引擎。
Laya是一个开源的System-1决策模型/工程项目，可以对文本、邮件、工单和JSON状态执行`choice`、`score`、`noul`三类结构化判断，并提供本地部署能力；其项目还提供与Jev相近的调用接口。
不能这么下结论。Laya证明的是类似的产品形态和接口可以被快速开源实现；Jev底层架构、sampler和RLCD训练方法是否形成持续技术优势，还需要独立验证。
不要把问题变成“用还是不用”。先把自己的数据库、判断标准、规则、Skill和Agent搭起来，再根据具体任务决定：能写死的用规则，需要语义判断的可以用Jev或其他模型，需要复杂推理的再调用更强的通用模型。