还记得前段时间突然出圈的 Jev 吗？它把一类经常被大模型包办的工作单独拆了出来：不写长篇回答，只做判断。
现在，蚂蚁集团 inclusionAI 开源了同一路线的新模型 LemonDecider。模型以 Qwen3.5-4B 为基座，参数量只有 4B，接收一段共享上下文和若干问题，直接返回选项概率、是或否的概率，或者一个有序评分。
最受关注的一组新数据是：LemonDecider 在 Decision Index 0.4.1 Public 中得到 61.67 分，超过 Jev 1.14 的 60.70 分；约 14 万条测试请求的中位推理耗时为 50.7ms。一个小模型把 Agent 中高频、重复的判断工作做成了专用能力。
Jev 打开的路，LemonDecider 用 4B 继续走普通生成模型处理一个判断任务时，通常会先生成文字，再由程序从文本里解析结论。比如 Agent 要选择下一个工具，模型可能先解释每个工具的用途，最后才给出工具名。真正被程序使用的，其实只是那个选项。
Jev 让更多人注意到“决策模型”这个方向。模型读取状态、问题和候选项，直接给每个选项一个概率。LemonDecider 延续了这个接口思路，把输出收敛为三种类型。
1 Choice：从候选项中选一个
适合工具路由、意图识别和工作流分支。输入用户请求与候选工具，输出每个工具的概率。
2 Yes / No：回答一个二元问题
官方协议里叫 noul。它可以判断证据是否支持结论、请求是否符合规则，返回“是”的概率。
3 Score：给出有序评分
适合检索相关性、回复质量、内容风险等需要等级判断的任务，支持 3、4、5 或 10 档评分。
一次前向计算，可以回答同一上下文里的多个问题LemonDecider 很实用的一点，是原生支持联合决策。一次请求里可以放一段共享的 state，再提交多个具名问题。
以售后 Agent 为例，同一段用户对话可以同时问：应该进入退款还是查物流流程？包裹是否已经损坏？这两个问题共用上下文。只要总长度没有超过容量，模型会在一次联合前向计算中返回两个结果，省去重复读取整段对话的开销。
{
"state": "客户想退回运输中损坏的包裹",
"questions": {
"action": {
"type": "choice",
"criteria": {
"refund": "发起退款",
"tracking": "查询物流"
}
},
"damaged": {
"type": "noul",
"instructions": "包裹是否损坏？"
}
}
}当前版本每个分块最多 8192 tokens，每道题最多 255 个选项。问题列表过长时，服务会按原顺序递归拆分，每个分块仍保留完整上下文和全部选项；如果单个问题加上下文也放不下，请求会被拒绝，不会静默截断。
120 万条训练数据，也一并开放了这次开放的不只是模型权重。官方发布了 1,199,692 条 typed decision 训练数据，来自 287 个上游数据集，覆盖 864 个任务标签。Choice 占 84.4%，Yes / No 占 15.2%，Score 占 0.4%。
数据范围包括意图和工具路由、自然语言推断、事实性判断、检索与商品相关性、内容安全、回复质量、常识与数学选择题等。官方还保留了 61,057 条软标签数据，让模型学习“各选项有多大概率合适”，不只学习一个硬答案。
模型仓库提供权重、联合决策读出、推理脚本、本地 HTTP 服务和测试代码，同时公开了训练参数与数据清洗说明。数据集逐行保留上游许可信息，其中部分来源限制非商业使用或许可未明确，准备商用训练时仍要逐项核对。
61.67 分超过 Jev，这组数据该怎么读图片来源：X @aigclink（2026-11-09）
模型
规模
Decision Index 0.4.1 Public
LemonDecider
4B
61.67
Jev 1.14
闭源服务
60.70
61.67 比 Jev 1.14 高 0.97 分，差距不算大，模型规模和开放程度更有看点。完整评测约 14 万条请求，中位耗时 50.7ms，说明 4B 专用模型有机会常驻在 Agent 的高频判断环节。
评测口径：截至 2026 年 11 月 9 日，Decision Index 0.4.1 的 11 月 6 日公开榜单快照可以复核 Jev 1.14 的 60.70 分，但尚未出现 LemonDecider 条目。LemonDecider 官方模型卡当前列出的可复核完整成绩是 Decision Index 0.3 Public 的 60.03 分，中位 HTTP 请求耗时 53.3ms。文中的 61.67 与 50.7ms 来自最新公开传播的 0.4.1 评测结果，仍需等待榜单或官方结果文件更新。
它适合放进哪些 Agent 环节工具选择：根据用户请求，从搜索、数据库、代码执行和业务 API 中挑选下一步工具。
证据门控：判断检索到的材料能否支持回答，证据不足时继续搜索。
流程路由：把工单、售后对话或企业请求送入对应工作流。
结果排序：对检索结果、候选回复或内容质量评分，再交给后续模块处理。
LemonDecider 已经在 Hugging Face 开放权重与数据，采用自定义模型代码加载，本地服务提供 POST /v1/systemone 接口。部署前需要检查仓库中的自定义代码和依赖；当前公开服务为纯文本，模型输出的概率也不等于正确率保证，重要业务仍应保留规则校验和人工兜底。
从 Jev 到 LemonDecider，决策模型正在形成一条清晰路线：让生成模型处理开放问题，把路由、分类、判断和评分交给体积更小、输出更稳定的专用模型。
对正在搭 Agent 的开发者来说，LemonDecider 最值得尝试的地方就是联合决策。先从一段上下文、多道判断题开始，把重复调用生成模型的环节替换掉，很快就能看出延迟和吞吐量的变化。