最近社区里有人用 Jev 做了一个游戏 demo给它一段当前状态让它在“上、下、左、右、攻击、喝药”里选一个动作。它选完以后游戏代码负责移动、碰撞、伤害和画面下一轮再把变化后的状态交给它。这件事看起来像“让 AI 玩游戏”但我更关心的其实不是它有没有玩赢而是这套分工Jev 没有负责理解整块屏幕也没有生成游戏更没有替游戏引擎做物理计算。它只负责一个很窄的问题——在程序已经列好的动作里下一步选哪一个。Jev 游戏 demo 的实际分工模型选择动作游戏代码处理地图与执行Jev 游戏 demo 的实际分工模型选择动作游戏代码处理地图与执行这也是理解 Jev 最好的入口。它不是一个“更会聊天的小模型”而是一个把语义判断单独拿出来的决策组件。我先把它的接口和解码路径拆开再回到 Agent 里看它应该放在哪一层。1.软件经常只需要一个判断普通软件里有大量分支if 金额大于 100走人工审核 if 库存小于 10提醒补货 if 命令会删除数据要求二次确认当条件是数字、枚举或布尔值时代码很好写。麻烦在于越来越多的条件藏在自然语言里这封邮件是不是退款请求这条工单该交给哪个团队这段输入有没有提示注入这次代码修改属于简单修补还是需要更强的模型Agent 刚刚拿到的工具结果应该保留、压缩还是丢弃这些问题不是让模型写一篇文章。它们更像“理解语义之后替程序选一条分支”。传统做法通常是调用一个通用大模型让它返回一句话或一个 JSON然后由代码再把这句话解析成标签。模型为一个很小的判断走完了完整生成流程调用方还要承担格式错误、额外文本和模型自行发明标签的风险。Jev 的接口从一开始就承认如果答案空间已经知道就没有必要让模型自由写。它要求调用方先声明回答形状再把当前状态和问题交给模型。现在最值得先记住的是三种形状类型要解决的问题返回结果Choice在有限选项里选一个最优选项、各选项概率Score把输入放到定义好的等级上分数、等级概率Noul判断一件事是否成立“是”的概率例如客服工单可以同时问两个问题{ state: 同一笔订阅被重复扣费。, questions: { urgent: { type: noul, instructions: 这条工单需要立即处理吗 }, team: { type: choice, instructions: 这条工单应该交给哪个团队, criteria: { billing: 扣费、账单、退款, technical: 产品故障和错误, account: 登录和权限问题 } } } }返回结果不需要是一段解释{ urgent: {probability: 0.61}, team: { choice: billing, probabilities: { billing: 0.91, technical: 0.06, account: 0.03 } } }程序可以直接读取这些数字再决定是否自动分流、升级到更大的模型或转人工。多个互不依赖的问题还可以放进同一个请求。Score 也不是简单地返回一个整数。假设“未解决、部分解决、已解决”分别对应 0、1、2模型给出的概率是 0.05、0.25、0.70那么下游可以计算出 1.65 的加权分数。它表达的是“明显偏向已解决但仍保留部分不确定性”比直接截成 2 更适合做升级或复核判断。这个分数和 confidence 都不是经过业务验证的正确率或风险概率是否能拿来设阈值仍要用标注数据校准。Choice、Score、Noul 三种有限判断接口2.它和结构化输出差在哪“返回 JSON”不是 Jev 最重要的地方。通用模型也能按照 schema 返回 JSON甚至能把字段限制成枚举值。区别在于许多采用自回归生成的结构化输出实现仍然要一个 token 接一个 token 地解码直到把 JSON 写完具体路径和优化方式取决于服务端实现。Jev 的目标则是在模型完成第一次前向计算后直接读取有限答案的分数不进入多 token 的文本生成循环。普通生成大致是输入状态计算下一位置的 logits选择一个 token把 token 接回上下文再计算下一个 token循环到回答结束。如果目标答案只有 A、B、C 三个选项就不一定要执行第 3 步以后所有的生成循环。一次前向计算已经产生了词表中每个候选 token 的分数调用方只要拿出 A、B、C 对应的分数再在这三个候选之间归一化即可。普通生成与有限答案评分的整体路径对比结构化输出仍然需要解码固定答案评分在解码循环前取出候选分数这不是把模型“变聪明”而是换了接口从“请你写一个答案”变成“请你在这组答案里给出判断”。3.logits、softmax以及为什么只取三个数字语言模型在生成下一个 token 时会为整个词表给出一组 logits。普通生成会对全词表做 softmax再结合温度、采样等规则选出下一个 token。全词表上的 softmax所有候选共享一个归一化分母有限答案评分只关心声明的候选。假设三个候选的 logits 是A 6.8 B 4.3 C 3.1普通 softmax 是P(i) exp(z_i) / Σ_j exp(z_j)固定答案评分把分母里的 j 限制在 A、B、CP(A) exp(z_A) / (exp(z_A) exp(z_B) exp(z_C))所以它得到的不是“A 在整个词表中的概率”而是“在这三个允许答案之间模型更偏向哪一个以及偏向程度如何”。词表 logits 被过滤为三个声明的候选 token这解释了它为什么适合程序分支下游拿到的不是一段还要解析的说明而是一组可以直接进入阈值判断的数。不过候选标签最好是单 token。不能假设 billing 在每个 tokenizer 里都是一个 token带不带前导空格也可能映射到不同 token ID。单字母标签比完整单词更容易稳定落在一个 token 上工程上要用模型自己的 chat template 渲染完整 prompt再逐个检查标签的 token 数量。这里用单字母 A、B、C 做这个验证for label in choices: response requests.post( f{BASE_URL}/tokenize, jsnotallow{ model: MODEL, prompt: label, add_special_tokens: False, }, timeout30, ) response.raise_for_status() token_ids response.json()[tokens] if len(token_ids) ! 1: raise ValueError(f{label!r} is not a single token: {token_ids})如果 tokenizer 把某个标签拆成两个或更多 token就应该停下来改标签而不是继续相信后面的概率。同一个字母有无前导空格时可能对应不同 token ID4.固定选项不等于判断正确假设路由器只允许三个选项billing、technical、account。安全事件进来以后模型仍然会被迫从这三个选项里选一个。即使正确答案其实是“升级安全事件”它也可能非常自信地挑出一个最接近的标签。候选集合通常要把未知情况也写进去billing technical account OTHER ESCALATE“不能幻觉”最多只能在很窄的意义上成立模型不会返回 schema 之外的标签也不会自行发明第四个团队但它仍然可能在已有选项里做出错误判断。schema 能阻止列表外答案但不能保证列表内答案正确候选集合不是随手填的参数而是业务规则的一部分。候选定义、未知分支、升级路径和人工复核都应该像代码一样被评审和版本化。5.概率为什么比一个标签更有用只返回 billing 还不够。0.52 的 billing 和 0.91 的 billing不应该触发同一条自动化路径。一个简单的置信度可以看胜者与第二名之间的 marginconfidence top_probability - second_probability如果三个选项的概率是{ billing: 0.52, technical: 0.46, account: 0.02 }billing 虽然赢了但只赢了 0.06。把它直接自动分流风险明显高于 0.91 对 0.05 的结果。对应的程序分支可以写成if probabilities[billing] 0.9: route_automatically(ticket, teambilling) elif confidence 0.3: send_to_human_review(ticket) else: escalate_to_larger_model(ticket)阈值应该放在代码和配置里而不是埋在模型权重中。阈值也不能凭感觉填写要用有标签的业务样本做 shadow mode比较不同概率区间的真实正确率再决定哪些分支可以自动化。choice probability、confidence 和实际正确率不是一回事。一个模型可以平均准确率不错但在最容易被信任的高置信区间里频繁犯错。概率能不能用作业务阈值必须用自己的数据校准。6.用开源服务理解“有限答案评分”Jev 本身是闭源服务但用开放模型也能把这套机制拆出来看用 SGLang 启动 Qwen2.5-0.5B-Instruct再调用评分接口只取 A、B、C 三个 token 的分数。下面这段命令和请求结构先用来理解接口真正运行时还要按自己的显卡、服务版本和模型环境核对依赖。完整的环境安装、模型服务启动和排障我放到下一篇姊妹篇里展开。python3 -m venv .venv source .venv/bin/activate pip install sglang[all]0.5.10.post1 requests2.34.2 python -m sglang.launch_server \ --model-path Qwen/Qwen2.5-0.5B-Instruct \ --host 127.0.0.1 \ --port 30000客户端先定义候选和状态import requests BASE_URL http://127.0.0.1:30000 MODEL Qwen/Qwen2.5-0.5B-Instruct choices { A: billing and payments, B: technical support, C: account access, } ticket I was charged twice for the same subscription. choice_lines \n.join( f{label} {meaning} for label, meaning in choices.items() ) prompt fTicket: {ticket} Question: Which category matches the ticket? Allowed labels: {choice_lines} Return only the label. Label: prompt 刻意停在模型本来要开始输出标签的位置。随后调用评分接口label_token_ids [32, 33, 34] # 示例占位值实际值必须用 tokenizer 查询 response requests.post( f{BASE_URL}/v1/score, jsnotallow{ model: MODEL, query: prompt, items: [], label_token_ids: label_token_ids, apply_softmax: True, }, timeout120, ) response.raise_for_status() scores response.json()[scores][0] probabilities { choices[label]: float(score) for label, score in zip(choices, scores, strictTrue) } decision max(probabilities, keyprobabilities.get)这条路径返回三个概率最后由普通 Python 把最大值映射回业务标签。这里的“判断”来自模型对语义的评分“执行”来自代码的映射和分支。SGLang 客户端从一次前向计算拿回三个概率示例中的 logits 经过受限 softmax 后得到对应概率这条开源路径的价值不是证明 Qwen 等于 Jev而是把“只取候选 logits再做受限 softmax”变成可以阅读和继续实验的代码。下一篇姊妹篇会沿着这里的接口继续单独处理开源版 Jev 的本地部署。7.Jev 应该放在 Agent 的哪一层一个实用的分工是三层规划模型处理开放式目标、长链推理和计划更新Jev在程序生成的有限候选里选择下一步或判断是否升级、回退、保留结果确定性代码执行工具、寻路、权限检查、状态更新和结果验证。Browser Use 的jev-ultrafastdemo 里页面先被整理成编号元素Jev 决定点击哪个元素、选择哪个链接需要填写城市名称时再调用生成模型负责写文字。Browser Use 的网页操作 demo判断动作与目标文字输入仍交给生成模型同一套分工还能放到后台工具路由在搜索、数据库、代码执行等已知工具里选一个安全门禁把 shell 命令分成只读、可逆、破坏性操作工单分流同时判断团队、紧急程度和是否需要人工上下文整理决定工具结果要完整保留、截断还是删除结果检查判断 Agent 是否已经完成任务或是否陷入重复失败。Jev 可以作为 Agent 循环旁边的模型路由、工具审批和结果检查点这里的关键不是“把更多调用换成 Jev”而是先看这个判断是否满足几个条件答案能否提前枚举判断是否高频每次判断是否不需要开放式长链推理候选集合是否包含 OTHER 或升级分支误判后是否能重试、回退或人工介入概率是否已经在自己的样本上校准。如果普通 if 已经能正确完成任务就继续用 if。如果问题需要解释、写代码、发现未知答案或多步规划也不应该强行塞给 Jev。8.写在最后Jev 的边界其实很清楚答案必须能提前列出来判断最好足够高频而且不需要模型展开一段开放式推理。下面这些任务就不应该因为“也能给出几个标签”而硬塞给它写回复、总结文档、生成代码或解释原因这些仍然是生成模型的工作算术、计数、日期比较和精确字符串处理这些交给普通代码更稳需要串起多个隐藏推理步骤的判断应该拆成更小的问题或交给推理模型从文本中直接找出一个未知值应该先由提取组件找到候选再让 Jev 在候选中选择把无关上下文一股脑塞进去输入越杂判断未必越准原始图片、界面或传感器数据不能直接交给当前的文本接口必须先转成它能消费的状态描述。所以Jev 不是通用模型的缩小版更像是 Agent 内部一枚有明确输入和输出边界的判断部件。游戏和浏览器 demo 能证明把高频小判断从生成流程里拆出来在受控环境中确实能跑起来一次调用返回有限结果也更容易接入程序分支。它们不能证明Jev 一定比 GPT 更会玩单次浏览器任务的耗时可以推广到所有网页官方价格就是所有业务的真实成本某个 demo 的成功意味着生产系统已经可靠概率高就等于判断一定正确。前面的游戏 demo 明确区分了动作概率和界面上的 confidence它们都不是“这一局最终获胜的概率”。如果要拿概率驱动自动执行仍然要用自己的数据评测误判代价、覆盖率和回退行为。再看两组值得区分的数字。TypeSafe 在自己的产品介绍中给过 70—500 毫秒延迟、每百万输入 token 0.042 美元且输出免费以及相对其他工作流更快、更便宜的说法。这类数字首先是产品方在特定条件下的宣传口径不能直接当成所有业务的成本预算。另一组来自 LangChain 的公开测试它用自己的 Deep Agents 和 LangSmith对 Jev、GPT-5.6 Luna、GPT-5.6 Terra 和 Claude Sonnet 4.6 做了重复判断比较。在 5 个测试案例上重复进行 500 次 pass/fail 判断时整理出来的结果是Jev 100.0%GPT-5.6 Terra 99.8%GPT-5.6 Luna 96.4%Claude Sonnet 4.6 80.0%。这个数字说明重复性和校准值得测但测试样本很窄不能外推成 Jev 在所有任务上都更准。社区测试中不同 judge 的重复判断结果对照更稳妥的上线方式是先选一个低风险、边界清楚的判断把每个候选的定义和未知分支写成 rubric收集正常、模糊和对抗样本先 shadow mode只记录结果不改变生产分支按概率区间画出准确率和覆盖率先自动化最安全的分支在代表性的输入长度和上下文规模上复核行为、成本与失败模式把模型或服务版本、问题、候选定义和阈值一起版本化版本变化后重新评估。模型调用便宜不代表错误便宜。错误可能带来重试、人工复核、错误退款、危险命令或整条 Agent 链路的恢复成本。Jev 更准确的定位是它把“理解语义之后做一个有限判断”变成了可以高频调用的程序部件。它不会替通用模型写计划也不会替代码执行动作它只把原本模糊的判断位变成一个有候选、有概率、有回退的接口。资料展示下面是我整理的AI大模型 学习资料和工具包预览适合收藏后按主题逐步学习