大模型正在进入一个有些尴尬的阶段。很多系统已经具备不错的生成能力却仍然需要用它们处理大量简单判断这条消息该交给哪个团队这个工具要不要调用任务应该继续、重试还是转人工用户是否明确要求退款这些问题的答案通常并不长甚至只需要一个枚举值或一个概率。但传统大语言模型处理它们时依然要走完整的文本生成流程。模型先理解上下文再逐字生成答案最后由业务代码负责解析、清洗和兜底。Jev出现的背景正是这类工程问题积累到一定程度后的自然结果。它不负责写文章也不试图完成开放式问答而是把模型能力收缩到一个更具体的接口给定上下文和有限选项直接判断每个选项的概率。一、Jev把大模型变成了选择题判卷器按 TypeSafe 公布的信息Jev于2026年9月15日发布并迅速接入Vercel AI Gateway。上线24小时内已有接近13%的付费团队使用过它覆盖速度超过同期部分新模型。这个数据的意义不在于它短期内有多少用户而在于它说明了一个变化开发者开始主动寻找生成模型之外的补充组件。Jev的定位非常明确。官方设计原则中有一句话Building prod, not God造生产工具而不是造神。这句话基本概括了它的产品取舍。Jev不追求长文本生成、复杂对话或者开放式创作而是把能力集中在系统中的判断节点上。生成式模型处理判断任务成本并不低假设业务需要判断一条用户评论是否属于垃圾广告。调用普通聊天模型时即使提示词写得非常严格请只回答“是”或“否”不要输出任何解释。模型依然在执行文本生成。它需要从上下文中预测下一个Token再继续预测后续Token。最终结果可能是是也可能是是的这条评论很可能属于垃圾广告。甚至可能带上换行、标点或额外说明。对人来说这些结果都能理解对程序来说它们可能意味着不同的分支路径。开发者只能增加正则清洗、格式校验和异常兜底。这套方案的问题主要有三个生成过程存在不必要的延迟输出格式受模型行为影响结果解析与业务判断耦合在一起。如果一个系统每秒要处理数千个工具路由请求这种额外成本很快就会放大。Jev的思路是把问题重新表示成选择题状态一条用户评论 问题它是否属于垃圾广告 选项是、否 输出每个选项的概率模型不再生成一段解释而是直接返回结构化结果。二、三种原语覆盖大多数业务判断Jev把开发者经常遇到的判断任务抽象成三类原语Choice、Score和Noul。名字可以先放在一边核心区别其实很直观。原语适合的问题典型输出Choice从多个类别中选择一个账单、订单、技术支持Score对对象进行等级或连续程度判断严重程度、情绪、风险等级Noul二元判断是否退款、是否违规、是否需要升级Choice从多个类别中路由例如一条客服消息可能属于账单、订单或售后三类中的某一类。模型返回的重点不是一句“建议转给账单团队”而是每个类别对应的概率{ choice: billing, probabilities: { billing: 0.86, orders: 0.09, support: 0.05 }, confidence: 0.86 }业务代码可以直接使用这个结果完成路由也可以根据置信度决定是否转人工。Score对有序等级进行判断Score适合处理有顺序关系的等级问题比如故障严重程度from typesafe_sdk import Score, TypeSafeClient with TypeSafeClient() as client: response client.system_one( state( The export button crashes the settings page in Safari. It works in Chrome, but some customers only use Safari. ), questions{ bug_severity: Score( instructionsHow severe is the reported issue?, criteria[ Cosmetic; no impact to functionality, Broken or degraded feature, but workaround exists, Blocking issue; no workaround exists, ], ) }, ) print(response.answers[bug_severity].score)可能得到这样的结果{ type: score, score: 1.43, confidence: 0.35, legend: { 0: Cosmetic; no impact to functionality, 1: Broken or degraded feature, but workaround exists, 2: Blocking issue; no workaround exists }, probabilities: { 0: 0.00, 1: 0.57, 2: 0.43 } }这里的score不是模型直接选择的等级编号而是按概率加权后的结果0 × 0.00 1 × 0.57 2 × 0.43 1.43因此1.43说明模型在“有影响但存在替代方案”和“阻塞性问题”之间存在摇摆。这个设计比简单返回一个等级更有用。业务方可以根据分布做更细的判断分数较低自动进入普通队列分数接近最高等级提升优先级两个等级概率接近转人工复核高风险等级概率超过阈值触发告警。Noul把二元判断变成概率Noul主要处理只有两个结果的问题例如用户是否明确要求退款这段输出是否包含未经证实的事实是否应该调用支付工具是否需要人工接管。它通常只需要一个概率值即可表达结果因此没有额外的confidence字段。这三类原语可以在同一个请求里并行使用。对于同一份上下文同时提出多个问题并不会像连续调用多个聊天模型那样线性增加延迟。需要注意的是概率、置信度和分数承担的职责不同概率描述每个选项获得支持的程度confidence描述模型对当前判断的集中程度score描述有序等级按概率加权后的平均位置。把这几个字段混在一起使用是接入这类模型时最容易出现的错误之一。三、关键变化发生在推理路径上普通聊天模型生成答案大致要经历这样的过程输入上下文 ↓ 预测下一个Token ↓ 拼接到已有输出 ↓ 再次预测下一个Token ↓ 循环直到结束如果最终输出包含几十个Token模型就需要执行几十轮解码。每一轮都可能受到采样策略、停止条件和上下文长度的影响。Jev采用了另一条路径输入上下文 问题 候选项 ↓ 一次模型前向计算 ↓ 读取候选结果的相对分数 ↓ 归一化为概率并返回它不执行逐词解码也不需要采样更不需要拼接自然语言答案。从工程角度看这带来三类收益。延迟更稳定没有逐Token生成响应时间不再随着解释文本长度增长。对于工具路由、风控初筛、流程判断等场景这种稳定性比单次平均延迟更重要。结果更适合程序消费开发者拿到的是带类型的数据代码可以直接比较、排序、路由answer response.answers[topic] if answer.confidence 0.75: return route_to_human_review(ticket) if answer.choice billing: return route_to_billing(ticket)不需要从自然语言中猜测模型到底想表达什么。同一上下文可以挂多个判断一份客服工单可以同时计算应该由哪个团队处理用户是否要求退款情绪是否已经升级是否需要优先响应。这几个判断共享同一份state在模型内部可以并行求值。问题数量增加时通常只增加少量问题描述和候选项成本。但“单次前向”不等于“零成本”。输入上下文仍然需要编码候选项也需要参与计算API网络延迟和服务端排队仍然存在。它优化的是生成阶段和调用组织方式不能理解成所有判断都能在本地瞬间完成。四、概率校准决定了它能不能进生产只返回一个类别远远不够。生产系统真正关心的是模型有多确定这个概率是否可信当模型给出0.95时实际正确率是否真的接近95%这就是概率校准问题。一个模型可能经常预测正确但概率完全不可信。例如正确率只有70%却长期输出0.98预测结果不稳定但置信度总是很高面对训练分布之外的语言或业务数据仍然给出极高信心。这种模型接入高风险流程后会非常危险。Jev把概率和置信度作为核心输出说明它试图服务于“可控决策”而不只是追求分类准确率。对于Agent来说置信度可以参与更上层的策略高置信度 ├── 直接调用工具 └── 直接进入自动化流程 中等置信度 ├── 增加一次校验 └── 调用更强的生成模型 低置信度 └── 转人工或暂停执行这类设计与传统机器学习中的校准评估、Brier评分和严格适当评分规则有一定联系。模型输出的概率越接近真实发生概率越适合被下游系统作为决策依据。工程上不能只看模型在公开评测集上的准确率。至少还需要关注真实业务数据上的混淆矩阵不同类别的召回率置信度分桶后的准确率新业务、新语言和异常输入上的表现阈值变化对人工成本和误操作率的影响。一个分类器的价值往往取决于它能否让系统在不确定时停下来而不是始终给出一个看似果断的答案。五、开源社区正在复刻三条路线Jev的商业发布带来了较高关注度但“对固定选项进行概率判断”这条技术路线并非凭空出现。开源社区很快出现了不同方向的实现主要可以分成三类。双向编码器路线代表项目包括Laya。这类方案使用ModernBERT、mmBERT等编码器架构对输入文本进行整体理解再对候选结果进行分类。它的特点是推理路径短参数规模相对可控延迟低更容易做多语言和本地化适配。据项目公开信息Laya单张消费级GPU上的延迟约为32.8毫秒并提供多语言模型与字符集检测分流能力。它更适合需要离线部署、中文处理和高吞吐判断的场景。因果解码器路线另一类项目基于Qwen等成熟大模型底座进行微调例如Metask-Jev-4B和Bespoke Nimble。这类模型的优势是能利用成熟大模型的语言理解能力更容易接入长上下文迁移到复杂领域时微调空间更大。代价也很明显模型体积更大部署成本更高长上下文能力不能只看架构上限实际可用长度仍需要业务数据验证。以某些模型卡给出的信息为例架构上限可能达到数十万Token但经过充分验证的评测点位只有4096Token。两者之间的差距正是工程落地时最容易被忽略的地方。轻量封装与边缘交互路线还有一些项目更关注开发体验和边缘场景。例如SemIf尝试把这种单次前向判断封装成接近Python条件分支的形式jev-visual则把轻量决策模型放进3D虚拟环境用于让NPC根据当前状态快速选择动作。这类项目未必直接进入企业核心链路却说明社区已经开始把“模型做判断”当作一种基础能力而不是某个单独产品的专属接口。六、Agent最适合把Jev放在哪里Jev这类模型很适合放在Agent的控制层而不是内容生成层。一个实际的工单处理流程可以这样设计from typesafe_sdk import TypeSafeClient, Choice, Noul, Score if ticket[status] closed: return no_action state { message: ticket[message], plan: customer[plan], open_orders: [ order for order in customer[orders] if order[status] ! delivered ], } questions { topic: Choice( instructions该消息应由哪个团队处理, criteria{ billing: 账单、扣费、退款或订阅争议, orders: 订单状态、物流、取消或退货, }, ), refund_requested: Noul( instructions用户是否明确要求退款或赔偿 ), frustration: Score( instructions用户情绪表现如何, criteria[ 平静客观, 烦躁但克制, 极度愤怒或威胁流失, ], ), } with TypeSafeClient() as client: response client.system_one( statestate, questionsquestions, ) answers response.answers topic answers[topic] if topic.confidence 0.75: return route_to_human_review(ticket) if topic.choice billing: return route_to_billing( ticket, refund_requestedanswers[refund_requested].noul 0.70, ) return route_to_orders(ticket)这段流程里生成模型可以负责理解复杂上下文、生成回复和执行多步推理。Jev则负责几个相对明确的控制点当前请求应该进入哪条工作流是否允许调用某个工具是否需要重试是否需要用户补充信息是否进入人工审核模型输出是否满足预设约束。这是一种比较合理的分工。让生成模型承担所有任务系统会变得昂贵且难以观测让判别模型承担所有任务又会损失复杂语义理解能力。两者组合通常比单独押注某一类模型更稳妥。七、它最容易翻车的地方是语言和分布外数据Jev目前更适合英文业务这一点需要认真对待。如果模型主要使用英文数据训练那么它在中文、日文或其他非拉丁字符上的表现可能明显下降。更麻烦的是错误预测和高置信度可能同时出现。这类情况在工程上比低置信度更危险。低置信度至少会触发人工审核错误的高置信度则可能直接穿过自动化流程。中文业务接入时可以考虑三条路线方案优势风险直接使用英文模型接入快、成本低中文准确率和校准表现不可控前置语言检测后分流英文与中文使用不同模型系统复杂度增加选择多语言开源模型可本地评估和微调部署、运维成本更高我的建议是只要业务核心数据不是英文就不要因为官方Demo效果不错而直接上线。先拿真实中文样本做评估尤其要看低频类别、模糊表达和口语化输入。另外以下场景不适合完全自动交给这类模型删除数据资金支付权限授予合同或法律结论高风险账号封禁不可逆的生产变更。模型可以参与筛选和建议但最终动作仍应由明确的规则、人工审批或多重校验控制。八、接入生产前先做影子测试这类模型最适合渐进式接入。第一阶段在调试界面或本地Demo中输入真实数据。不要只拿几条精心准备的示例而要覆盖正常样本边界样本互相矛盾的样本空字段和异常格式多语言输入历史上最容易误判的样本。第二阶段选择现有系统中维护成本最高的一段条件分支先接入影子模式。影子模式的特点是新模型参与判断不改变线上真实结果记录模型输出、概率、置信度和最终人工结果与原有规则或人工标签进行对比。经过一段时间后再评估几个指标模型准确率 置信度校准误差 人工转接率 误操作率 单次判断成本 端到端延迟只看准确率是不够的。比如一个模型准确率提升了2%却让人工复核量增加一倍整体系统未必更好。还要注意调用数量。单次判断确实可能比调用生成模型便宜但如果一个请求里串联几十个判断节点高并发下的累计成本依然可观。系统设计时需要区分哪些判断必须由模型完成哪些可以用普通代码解决哪些可以合并成一次请求哪些判断结果会被后续多个节点复用。能写成稳定规则的逻辑不必强行交给模型。模型应该处理规则难以覆盖、但又足够适合分类和评分的问题。九、Jev背后的Agent架构变化Jev创始人Diogo Almeida曾参与InstructGPT和ChatGPT早期工作也参与了RLHF相关研究。TypeSafe AI据公开信息完成了由DCVC领投的4000万美元种子轮融资。比个人履历和融资数字更值得关注的是他对Agent架构的一种判断当前不少Agent系统过度依赖不断增长的上下文链。工具调用、终端输出、历史消息和中间状态被串成一条长链系统依赖KV Cache降低重复计算成本。会话变长后又不得不做上下文压缩。压缩过程一旦处理不当就可能把关键规则、约束条件和早期决策依据一起削弱。有些团队会通过大小模型混合路由降低费用。例如先让小模型处理子任务再切回大模型完成主任务。但如果切换破坏了原有缓存大模型可能需要重新预填充大量历史上下文。这意味着“模型单价更低”不一定等于“系统总成本更低”。在长会话Agent中真正应该优化的是整体计算路径包括上下文是否重复编码工具结果是否需要全部保留判断节点能否独立计算是否可以提前终止错误分支是否能将固定决策下沉到轻量模型。Jev这类模型可以充当Agent内部的动态控制器根据当前状态选择下一步动作减少无意义的工具调用和重复推理。它不负责替代大模型而是帮助大模型少做一些本不需要做的工作。十、轻量决策模型会成为Agent的基础组件过去两年模型竞争主要集中在参数规模、上下文长度和推理能力上。这些能力当然重要但系统落地后真正消耗资源的往往是大量小判断要不要继续要不要重试该选哪个工具需不需要人工输出是否可信风险是否超过阈值。这些判断如果全部交给生成模型系统很容易变得迟钝、昂贵而且难以控制。Jev和Laya代表的方向提供了另一种工程选择让生成模型负责开放式问题让轻量判别模型负责分类、评分、路由和护栏。这种架构不会让所有Agent立刻变快也不会自动解决数据质量、模型偏差和业务规则混乱等问题。它真正提供的是一种更清晰的职责划分以及更适合程序调用的概率接口。对开发团队来说值得关注的也许不是Jev这个具体产品能否长期占据市场而是一个更基础的趋势当系统中的“选择题”足够多时专门做选择题的模型可能比一个什么都能写的大模型更适合站在流程前面。 
长河君 · 2026/10/18 6:21:06 · 阅读 1.2k Jev把Agent判断做成了概率接口
大模型正在进入一个有些尴尬的阶段。很多系统已经具备不错的生成能力却仍然需要用它们处理大量简单判断这条消息该交给哪个团队这个工具要不要调用任务应该继续、重试还是转人工用户是否明确要求退款这些问题的答案通常并不长甚至只需要一个枚举值或一个概率。但传统大语言模型处理它们时依然要走完整的文本生成流程。模型先理解上下文再逐字生成答案最后由业务代码负责解析、清洗和兜底。Jev出现的背景正是这类工程问题积累到一定程度后的自然结果。它不负责写文章也不试图完成开放式问答而是把模型能力收缩到一个更具体的接口给定上下文和有限选项直接判断每个选项的概率。一、Jev把大模型变成了选择题判卷器按 TypeSafe 公布的信息Jev于2026年9月15日发布并迅速接入Vercel AI Gateway。上线24小时内已有接近13%的付费团队使用过它覆盖速度超过同期部分新模型。这个数据的意义不在于它短期内有多少用户而在于它说明了一个变化开发者开始主动寻找生成模型之外的补充组件。Jev的定位非常明确。官方设计原则中有一句话Building prod, not God造生产工具而不是造神。这句话基本概括了它的产品取舍。Jev不追求长文本生成、复杂对话或者开放式创作而是把能力集中在系统中的判断节点上。生成式模型处理判断任务成本并不低假设业务需要判断一条用户评论是否属于垃圾广告。调用普通聊天模型时即使提示词写得非常严格请只回答“是”或“否”不要输出任何解释。模型依然在执行文本生成。它需要从上下文中预测下一个Token再继续预测后续Token。最终结果可能是是也可能是是的这条评论很可能属于垃圾广告。甚至可能带上换行、标点或额外说明。对人来说这些结果都能理解对程序来说它们可能意味着不同的分支路径。开发者只能增加正则清洗、格式校验和异常兜底。这套方案的问题主要有三个生成过程存在不必要的延迟输出格式受模型行为影响结果解析与业务判断耦合在一起。如果一个系统每秒要处理数千个工具路由请求这种额外成本很快就会放大。Jev的思路是把问题重新表示成选择题状态一条用户评论 问题它是否属于垃圾广告 选项是、否 输出每个选项的概率模型不再生成一段解释而是直接返回结构化结果。二、三种原语覆盖大多数业务判断Jev把开发者经常遇到的判断任务抽象成三类原语Choice、Score和Noul。名字可以先放在一边核心区别其实很直观。原语适合的问题典型输出Choice从多个类别中选择一个账单、订单、技术支持Score对对象进行等级或连续程度判断严重程度、情绪、风险等级Noul二元判断是否退款、是否违规、是否需要升级Choice从多个类别中路由例如一条客服消息可能属于账单、订单或售后三类中的某一类。模型返回的重点不是一句“建议转给账单团队”而是每个类别对应的概率{ choice: billing, probabilities: { billing: 0.86, orders: 0.09, support: 0.05 }, confidence: 0.86 }业务代码可以直接使用这个结果完成路由也可以根据置信度决定是否转人工。Score对有序等级进行判断Score适合处理有顺序关系的等级问题比如故障严重程度from typesafe_sdk import Score, TypeSafeClient with TypeSafeClient() as client: response client.system_one( state( The export button crashes the settings page in Safari. It works in Chrome, but some customers only use Safari. ), questions{ bug_severity: Score( instructionsHow severe is the reported issue?, criteria[ Cosmetic; no impact to functionality, Broken or degraded feature, but workaround exists, Blocking issue; no workaround exists, ], ) }, ) print(response.answers[bug_severity].score)可能得到这样的结果{ type: score, score: 1.43, confidence: 0.35, legend: { 0: Cosmetic; no impact to functionality, 1: Broken or degraded feature, but workaround exists, 2: Blocking issue; no workaround exists }, probabilities: { 0: 0.00, 1: 0.57, 2: 0.43 } }这里的score不是模型直接选择的等级编号而是按概率加权后的结果0 × 0.00 1 × 0.57 2 × 0.43 1.43因此1.43说明模型在“有影响但存在替代方案”和“阻塞性问题”之间存在摇摆。这个设计比简单返回一个等级更有用。业务方可以根据分布做更细的判断分数较低自动进入普通队列分数接近最高等级提升优先级两个等级概率接近转人工复核高风险等级概率超过阈值触发告警。Noul把二元判断变成概率Noul主要处理只有两个结果的问题例如用户是否明确要求退款这段输出是否包含未经证实的事实是否应该调用支付工具是否需要人工接管。它通常只需要一个概率值即可表达结果因此没有额外的confidence字段。这三类原语可以在同一个请求里并行使用。对于同一份上下文同时提出多个问题并不会像连续调用多个聊天模型那样线性增加延迟。需要注意的是概率、置信度和分数承担的职责不同概率描述每个选项获得支持的程度confidence描述模型对当前判断的集中程度score描述有序等级按概率加权后的平均位置。把这几个字段混在一起使用是接入这类模型时最容易出现的错误之一。三、关键变化发生在推理路径上普通聊天模型生成答案大致要经历这样的过程输入上下文 ↓ 预测下一个Token ↓ 拼接到已有输出 ↓ 再次预测下一个Token ↓ 循环直到结束如果最终输出包含几十个Token模型就需要执行几十轮解码。每一轮都可能受到采样策略、停止条件和上下文长度的影响。Jev采用了另一条路径输入上下文 问题 候选项 ↓ 一次模型前向计算 ↓ 读取候选结果的相对分数 ↓ 归一化为概率并返回它不执行逐词解码也不需要采样更不需要拼接自然语言答案。从工程角度看这带来三类收益。延迟更稳定没有逐Token生成响应时间不再随着解释文本长度增长。对于工具路由、风控初筛、流程判断等场景这种稳定性比单次平均延迟更重要。结果更适合程序消费开发者拿到的是带类型的数据代码可以直接比较、排序、路由answer response.answers[topic] if answer.confidence 0.75: return route_to_human_review(ticket) if answer.choice billing: return route_to_billing(ticket)不需要从自然语言中猜测模型到底想表达什么。同一上下文可以挂多个判断一份客服工单可以同时计算应该由哪个团队处理用户是否要求退款情绪是否已经升级是否需要优先响应。这几个判断共享同一份state在模型内部可以并行求值。问题数量增加时通常只增加少量问题描述和候选项成本。但“单次前向”不等于“零成本”。输入上下文仍然需要编码候选项也需要参与计算API网络延迟和服务端排队仍然存在。它优化的是生成阶段和调用组织方式不能理解成所有判断都能在本地瞬间完成。四、概率校准决定了它能不能进生产只返回一个类别远远不够。生产系统真正关心的是模型有多确定这个概率是否可信当模型给出0.95时实际正确率是否真的接近95%这就是概率校准问题。一个模型可能经常预测正确但概率完全不可信。例如正确率只有70%却长期输出0.98预测结果不稳定但置信度总是很高面对训练分布之外的语言或业务数据仍然给出极高信心。这种模型接入高风险流程后会非常危险。Jev把概率和置信度作为核心输出说明它试图服务于“可控决策”而不只是追求分类准确率。对于Agent来说置信度可以参与更上层的策略高置信度 ├── 直接调用工具 └── 直接进入自动化流程 中等置信度 ├── 增加一次校验 └── 调用更强的生成模型 低置信度 └── 转人工或暂停执行这类设计与传统机器学习中的校准评估、Brier评分和严格适当评分规则有一定联系。模型输出的概率越接近真实发生概率越适合被下游系统作为决策依据。工程上不能只看模型在公开评测集上的准确率。至少还需要关注真实业务数据上的混淆矩阵不同类别的召回率置信度分桶后的准确率新业务、新语言和异常输入上的表现阈值变化对人工成本和误操作率的影响。一个分类器的价值往往取决于它能否让系统在不确定时停下来而不是始终给出一个看似果断的答案。五、开源社区正在复刻三条路线Jev的商业发布带来了较高关注度但“对固定选项进行概率判断”这条技术路线并非凭空出现。开源社区很快出现了不同方向的实现主要可以分成三类。双向编码器路线代表项目包括Laya。这类方案使用ModernBERT、mmBERT等编码器架构对输入文本进行整体理解再对候选结果进行分类。它的特点是推理路径短参数规模相对可控延迟低更容易做多语言和本地化适配。据项目公开信息Laya单张消费级GPU上的延迟约为32.8毫秒并提供多语言模型与字符集检测分流能力。它更适合需要离线部署、中文处理和高吞吐判断的场景。因果解码器路线另一类项目基于Qwen等成熟大模型底座进行微调例如Metask-Jev-4B和Bespoke Nimble。这类模型的优势是能利用成熟大模型的语言理解能力更容易接入长上下文迁移到复杂领域时微调空间更大。代价也很明显模型体积更大部署成本更高长上下文能力不能只看架构上限实际可用长度仍需要业务数据验证。以某些模型卡给出的信息为例架构上限可能达到数十万Token但经过充分验证的评测点位只有4096Token。两者之间的差距正是工程落地时最容易被忽略的地方。轻量封装与边缘交互路线还有一些项目更关注开发体验和边缘场景。例如SemIf尝试把这种单次前向判断封装成接近Python条件分支的形式jev-visual则把轻量决策模型放进3D虚拟环境用于让NPC根据当前状态快速选择动作。这类项目未必直接进入企业核心链路却说明社区已经开始把“模型做判断”当作一种基础能力而不是某个单独产品的专属接口。六、Agent最适合把Jev放在哪里Jev这类模型很适合放在Agent的控制层而不是内容生成层。一个实际的工单处理流程可以这样设计from typesafe_sdk import TypeSafeClient, Choice, Noul, Score if ticket[status] closed: return no_action state { message: ticket[message], plan: customer[plan], open_orders: [ order for order in customer[orders] if order[status] ! delivered ], } questions { topic: Choice( instructions该消息应由哪个团队处理, criteria{ billing: 账单、扣费、退款或订阅争议, orders: 订单状态、物流、取消或退货, }, ), refund_requested: Noul( instructions用户是否明确要求退款或赔偿 ), frustration: Score( instructions用户情绪表现如何, criteria[ 平静客观, 烦躁但克制, 极度愤怒或威胁流失, ], ), } with TypeSafeClient() as client: response client.system_one( statestate, questionsquestions, ) answers response.answers topic answers[topic] if topic.confidence 0.75: return route_to_human_review(ticket) if topic.choice billing: return route_to_billing( ticket, refund_requestedanswers[refund_requested].noul 0.70, ) return route_to_orders(ticket)这段流程里生成模型可以负责理解复杂上下文、生成回复和执行多步推理。Jev则负责几个相对明确的控制点当前请求应该进入哪条工作流是否允许调用某个工具是否需要重试是否需要用户补充信息是否进入人工审核模型输出是否满足预设约束。这是一种比较合理的分工。让生成模型承担所有任务系统会变得昂贵且难以观测让判别模型承担所有任务又会损失复杂语义理解能力。两者组合通常比单独押注某一类模型更稳妥。七、它最容易翻车的地方是语言和分布外数据Jev目前更适合英文业务这一点需要认真对待。如果模型主要使用英文数据训练那么它在中文、日文或其他非拉丁字符上的表现可能明显下降。更麻烦的是错误预测和高置信度可能同时出现。这类情况在工程上比低置信度更危险。低置信度至少会触发人工审核错误的高置信度则可能直接穿过自动化流程。中文业务接入时可以考虑三条路线方案优势风险直接使用英文模型接入快、成本低中文准确率和校准表现不可控前置语言检测后分流英文与中文使用不同模型系统复杂度增加选择多语言开源模型可本地评估和微调部署、运维成本更高我的建议是只要业务核心数据不是英文就不要因为官方Demo效果不错而直接上线。先拿真实中文样本做评估尤其要看低频类别、模糊表达和口语化输入。另外以下场景不适合完全自动交给这类模型删除数据资金支付权限授予合同或法律结论高风险账号封禁不可逆的生产变更。模型可以参与筛选和建议但最终动作仍应由明确的规则、人工审批或多重校验控制。八、接入生产前先做影子测试这类模型最适合渐进式接入。第一阶段在调试界面或本地Demo中输入真实数据。不要只拿几条精心准备的示例而要覆盖正常样本边界样本互相矛盾的样本空字段和异常格式多语言输入历史上最容易误判的样本。第二阶段选择现有系统中维护成本最高的一段条件分支先接入影子模式。影子模式的特点是新模型参与判断不改变线上真实结果记录模型输出、概率、置信度和最终人工结果与原有规则或人工标签进行对比。经过一段时间后再评估几个指标模型准确率 置信度校准误差 人工转接率 误操作率 单次判断成本 端到端延迟只看准确率是不够的。比如一个模型准确率提升了2%却让人工复核量增加一倍整体系统未必更好。还要注意调用数量。单次判断确实可能比调用生成模型便宜但如果一个请求里串联几十个判断节点高并发下的累计成本依然可观。系统设计时需要区分哪些判断必须由模型完成哪些可以用普通代码解决哪些可以合并成一次请求哪些判断结果会被后续多个节点复用。能写成稳定规则的逻辑不必强行交给模型。模型应该处理规则难以覆盖、但又足够适合分类和评分的问题。九、Jev背后的Agent架构变化Jev创始人Diogo Almeida曾参与InstructGPT和ChatGPT早期工作也参与了RLHF相关研究。TypeSafe AI据公开信息完成了由DCVC领投的4000万美元种子轮融资。比个人履历和融资数字更值得关注的是他对Agent架构的一种判断当前不少Agent系统过度依赖不断增长的上下文链。工具调用、终端输出、历史消息和中间状态被串成一条长链系统依赖KV Cache降低重复计算成本。会话变长后又不得不做上下文压缩。压缩过程一旦处理不当就可能把关键规则、约束条件和早期决策依据一起削弱。有些团队会通过大小模型混合路由降低费用。例如先让小模型处理子任务再切回大模型完成主任务。但如果切换破坏了原有缓存大模型可能需要重新预填充大量历史上下文。这意味着“模型单价更低”不一定等于“系统总成本更低”。在长会话Agent中真正应该优化的是整体计算路径包括上下文是否重复编码工具结果是否需要全部保留判断节点能否独立计算是否可以提前终止错误分支是否能将固定决策下沉到轻量模型。Jev这类模型可以充当Agent内部的动态控制器根据当前状态选择下一步动作减少无意义的工具调用和重复推理。它不负责替代大模型而是帮助大模型少做一些本不需要做的工作。十、轻量决策模型会成为Agent的基础组件过去两年模型竞争主要集中在参数规模、上下文长度和推理能力上。这些能力当然重要但系统落地后真正消耗资源的往往是大量小判断要不要继续要不要重试该选哪个工具需不需要人工输出是否可信风险是否超过阈值。这些判断如果全部交给生成模型系统很容易变得迟钝、昂贵而且难以控制。Jev和Laya代表的方向提供了另一种工程选择让生成模型负责开放式问题让轻量判别模型负责分类、评分、路由和护栏。这种架构不会让所有Agent立刻变快也不会自动解决数据质量、模型偏差和业务规则混乱等问题。它真正提供的是一种更清晰的职责划分以及更适合程序调用的概率接口。对开发团队来说值得关注的也许不是Jev这个具体产品能否长期占据市场而是一个更基础的趋势当系统中的“选择题”足够多时专门做选择题的模型可能比一个什么都能写的大模型更适合站在流程前面。