多数智能体技术栈都默认：每一次智能判断都值得再来一次生成式调用。循环让同一个前沿模型负责撰写、分类、选择工具、估计风险、判断证据是否充分、校验结果，并决定何时停止。从外部看，这像是一个无所不能的智能体；从内部看，它是一大堆以「散文生成」方式实现的小分支。
这些分支的成本很容易被忽略，因为它很少出现在最终答案里。它表现为串行延迟、上下文的重复传输、JSON 修复、schema 重试，以及弱分支决策之后的补救。多一次调用也许可以接受；二十次相互依赖的调用则可能主导整个工作流——哪怕可见的产出物很短。
Jev 把原语（primitive）从「文本生成」换成「类型化语义判断」（typed semantic judgment）。调用方提供当前状态和一个或多个预定义问题；响应包含声明过的答案类型和概率分布。软件不再需要从散文中恢复决策、从语气里猜测置信度分数，或者指望一个临时拼凑的 JSON schema 在生成过程中幸存下来。
这种限制正是重点。Jev 不会起草邮件、不会撰写报告、不会产出代码补丁；但它可以决定这封邮件应进入哪个队列、这份报告的证据是否足够、这个拟议补丁在执行前是否需要人工审查。受约束的输出让这些决策可以与普通程序逻辑自由组合。
TypeSafe 将 Jev 描述为一个以「强化学习训练、面向校准决策」的系统一模型（system one model）。它的优化目标是决策质量加上有用的不确定性，而不是漂亮的 prose。公开的服务特性——Jev 形态请求约 70–500 毫秒、每百万输入 token 0.042 美元且不计输出 token 费用——让高频语义分支成为可能。
但这些服务特性并不能替代系统设计。一个便宜却选错工作器（worker）的决策，造成的下游成本可能超过一个昂贵的正确决策；一个快速却放行不完整工作的校验器，会在后面补上延迟账单。因此，分析单位应当是「完成的任务」，而不是孤立的一次调用。
在接入 Jev 之前，先把智能体中已经存在的每一个语义分支写下来：请求是否清晰、工作器选择、模型选择、检索结果去留、工具风险、任务完成、重试、升级与停止。记录今天每个分支由哪个组件做出，以及该分支是在创造语言、解读语义，还是在执行一条精确规则。
这份盘点会暴露出此前埋在提示词里的决策，也防止不加区分的迁移。有些分支应当留在 LLM，因为其输出是生成式的；另一些应当移入代码，因为其条件是精确的。只有剩下的语义分支，才是 Jev 的候选。
生产级智能体应当把工作分配给三个不同的归属方：生成式 LLM 创造开放式产物；Jev 在答案形态已知时解读模糊语义；确定性代码执行精确不变式。把三者混在一起，会把彼此独立的失败模式坍缩进一次不透明的模型调用。
| 问题 | 归属 | 理由 |
|---|---|---|
| 起草研究摘要 | LLM | 产出物本身需要被创作 |
| 选择下一个工作器 | Jev | 语义模糊；菜单已知 |
| 评估证据质量 | Jev | 量表有序且属于语义判断 |
| 尝试三次后停止 | 代码 | 规则是精确的 |
| 批准一笔支付 | 代码 + 人工 | 副作用后果重大 |
| 校验一份报告 | Jev + 代码 | 既需语义量表，也需产物检查 |
置信度分数是运行信号，不是许可。Jev 可以估计某条命令风险很低，但它能否执行仍由策略引擎决定。这一区分在以下场景最为要紧：发布、购买、删除、账户访问、权限变更、数据库写入、资金转移，以及代表用户对外行事。
安全的顺序在所有集成中都是稳定的：Jev 判断；代码核查策略；工具执行；轨迹记录。颠倒这个顺序，就把概率性判断变成了无边界权限——分类器内含策略，应用代码只是服从。这种设计难以审计，扩展起来也不安全。
目标不是取代 LLM，而是停止在不需要生成的地方使用生成。每移除一次 prose 调用，图就更小、schema 更简单、决策更容易被评估。因此，Jev 工程本质上是边界设计：决定语言在哪里创造价值、类型化判断在哪里消解模糊、代码在哪里必须寸步不让。
对一个分支问三个问题。输出本身必须被创作吗？是，则用生成式模型。语义模糊而答案形态已知吗？是，则用 Jev。条件必须被精确执行吗？是，则用代码。看似三者都需要的分支，应当分解为生成、判断、执行三个步骤。
这种分解让职责在实现与轨迹两侧都可见。故障因此可以被归到产物创作、语义判断或策略执行中的某一环，而不是含糊地归咎于「智能体」。