问题背景：Agent 流水线里那些「不值得大模型」的判断
任何做 Agent 系统的人都会撞上同一堵墙：流水线里大量判断是简单的分类——这条工单该路由给退款组还是物流组？这句话是不是愤怒语气？这个语音命令是「播放」还是「暂停」？用旗舰大模型做这些判断，每次要花数秒和数千 token 去生成一段需要再解析的自由文本；用传统 NLU 又要为每个场景训练专属模型。9 月 28 日登上 Hacker News（202 分）的开源项目 Jeff（firelex/jeff）给出了第三条路：一组为分类微调的小模型（0.8B 到 2B），单次前向传播直接输出校准概率，与 System 1 模型 Jev 使用相同的请求格式，RTX PRO 6000 上约 22 毫秒、Apple M4 Max 上约 28 毫秒完成一次决策。
Jeff 是什么：为零样本分类特化的小模型
Jeff 是 Qwen3.5 与 Gemma 4 的微调版本，训练基于开源的 AutoJev 配方，发布三个权重：Jeff-Qwen3.5-0.8B、Jeff-Qwen3.5-2B 与 Jeff-Gemma4-E2B，全部托管在 Hugging Face。它的工作方式是：你用自然语言描述情境并列出候选选项，模型在一次前向传播里为每个选项输出校准概率、选中的选项和置信度——没有文本生成，没有解析环节。零样本意味着选项完全由你定义，不需要出现在训练数据里。
项目的自我定位很诚实，值得原样转述：这是非常小的模型，它们做的是「极快、校准良好的判断」，在基准上接近甚至偶尔超过 Jev，但推理能力远不及运行在更大模型上的 Jev。换句话说，Jeff 的目标是 Jev 旁边而不是 Jev 的替代品——Agent 流水线里 80% 的高频简单判断交给它，剩下 20% 需要真推理的升级给大模型。
本地部署：五分钟跑起来
项目用 uv 管理依赖，部署三个平台路径。NVIDIA GPU 或 CPU（PyTorch 后端）：
uv sync
uv run hf download mstrasser/Jeff-Qwen3.5-0.8B --local-dir checkpoints/jeff-0.8b
JEFF_CHECKPOINT=checkpoints/jeff-0.8b PORT=8765 uv run jeff-serveApple silicon（MLX 后端，Qwen 模型专用，Mac 上快得多）：
uv sync --extra mac
JEFF_BACKEND=mlx JEFF_CHECKPOINT=checkpoints/jeff-0.8b PORT=8765 uv run jeff-serve服务起来后，用一个客服路由的真实例子发请求：
curl -s localhost:8765/v1/systemone -H 'content-type: application/json' -d '{
"model": "jeff-latest",
"state": "Refund request: the customer says the parcel arrived crushed and wants their money back.",
"questions": {
"route": {"type": "choice", "instructions": "Which team should handle this?",
"criteria": {"1": "Refunds and payments", "2": "Damaged or lost parcels", "3": "Account and login problems"}},
"angry": {"type": "noul", "instructions": "Is the customer angry?"}
}
}'三种问题类型覆盖了绝大多数判断需求：choice 从最多 255 个选项中选一，noul 返回是否概率，score 在自定义量表上打分。注意上面这个例子的设计巧思：路由问题和情绪判断在同一次请求里一起回答——组合判断不放大延迟。
基准成绩：0.8B 模型的真实水位
官方用五个公开基准共 4599 道题加 JevBench 硬核档做了横评。综合五基准得分：Jeff-Qwen3.5-0.8B 为 79.1，2B 版为 83.1，Gemma4-E2B 版为 81.6，对照 Jev 公布成绩 83.0、AutoJev-27B 为 84.9。也就是说 2B 版综合成绩已经打平 Jev。分项看结构很清晰：分类与接地任务是小模型的甜区——Financial PhraseBank 上三个 Jeff 版本全部在 96 分以上，反超 Jev 的 77.0；RAGTruth 上 2B 版 88.9 追平 27B 基线的最好成绩。而推理密集的 BBH（64.0 对 Jev 的 94.3）和 JudgeBench（62.6 对 78.6）差距明显。选型结论由此直接得出：把 Jeff 用在分类和接地判断上，别让它做推理。
项目还做了一个有趣的零样本压力测试：让模型纯靠文字描述玩 Frogger、Doom 和吃豆人——每回合代码用自然语言描述局面和合法走子（说明每步会导致什么，但不说哪步是对的），模型来选。这验证了它在训练数据之外的泛化边界。
微调：半小时把 31.7% 拉到 95.8%
零样本不够用时，Jeff 的微调路径是它最务实的卖点。官方语音导航案例：在一个 GPU 上不到半小时，留出集准确率从 31.7% 提到 95.8%。整个训练流程完全本地化——0.8B 在单块 RTX PRO 6000 上约 2 小时训完、2B 约 3.5 小时，合成训练数据全部由开源模型 Qwen3.8-Flash-Next 在两台 DGX Sparks 上生成，训练数据里没有任何闭源模型输出（闭源模型只用于抽查合成数据质量）。这意味着你可以构建一条完全不出内网的判断模型生产线：开源模型造数据、本地微调、边缘部署，对数据敏感行业（医疗、金融、法务）非常友好。
与 Jev 生态的关系：兼容而非依附
理解 Jeff 的生态位需要先厘清它与 Jev 的关系。Jev 是 TypeSafe 公司推出的 System 1 决策模型，凭借「自然语言描述选项、单次前向输出概率」的请求格式在 Agent 工程圈快速铺开；Jeff 是独立项目，明确声明与 TypeSafe 无隶属或背书关系，但刻意保持了与 Jev 完全相同的请求格式。这个设计选择的价值在迁移成本上：已经接入 Jev 的系统，把 base URL 换成本地 Jeff 服务、模型名换成 jeff-latest 即可完成切换，业务代码一行不动；反过来，从 Jeff 起步的团队未来要升级到更大规模的 Jev 部署时，同样不需要重写请求层。AutoJev（27B 量级的开源复现）也在同一坐标系里：它综合成绩 84.9 是当前开源天花板，但 27B 的显存需求把部署门槛抬到了多卡服务器级别，Jeff 填补的正是「笔记本与单卡工作站」这一档的空白。三者构成了从边缘 0.8B 到服务器 27B 的完整梯度，按延迟预算与硬件预算选档即可。
落地场景与集成建议
结合架构看四个高价值落点。第一，客服与工管系统的前置路由：Jeff 做毫秒级意图分类与队列分派，大模型只接住升级的复杂对话。第二，审核与风控过滤：noul 类型天然适配「是否违规」的概率判断，把 95% 的明确案例在本地过滤，边界案例再送大模型。第三，语音交互：28 毫秒的延迟配合语音命令分类，本地设备上的响应体验可以做到无可感知延迟。第四，Agent 流水线的廉价门控：在调用昂贵工具前用 score 类型给情境打分决定是否值得升级。
工程化落地还有三条细节。其一，schema 设计要像写测试用例一样认真：选项描述里写清楚每个选项「覆盖什么、不覆盖什么」，官方的游戏实验证明模型依赖选项描述做判断——描述质量直接决定准确率。其二，为低置信度判断设计显式升级通道：给概率设阈值（例如低于 0.7 转人工或转大模型），并在日志里记录完整概率分布，上线两周后就能用这些分布校准阈值。其三，把 Jeff 的输出当作遥测数据的一部分：概率分布的漂移往往早于业务指标恶化，盯着它等于给判断层装了预警。小模型的正确用法不是替代判断，而是把判断的成本结构重排一遍。