最近 GitHub 上悄悄起了一波新的风口，名字听着挺唬人——「System 1 决策模型」。说穿了就一句话：别再让大模型写作文了，让它做选择题。
以前 Agent 每走一步都要调一次大模型，让它吐一段文字再解析成动作，又慢又贵。现在这批新项目反过来：模型一次前向传播直接给你一个「选项 + 概率」，一个字都不生成，几十毫秒出结果。今天这两个项目就是这波浪潮里涨得最凶的，一个 3.2 万星，一个 2.25 万星，都是 9 月中旬才建的仓。
laya：3.2 万星，把决策做成 33 毫秒的选择题
laya 是 9 月 18 日建的仓，现在已经 32080 星，Python，Apache-2.0 协议。作者是 NandhaKishorM，README 里还挂了篇 dev.to 文章，标题大意是「我一年前就做了非自回归决策模型，后来某前沿实验室把它包装成了新概念」——这吐槽我给满分。
它干的事很窄但很实在：你丢一段文本进去（字符串、字典、JSON 都行），再写几个「带类型的问题」，它直接返回答案。问题只有三种类型：
choice：从给定标签里选一个，还带 criteria 说明每个选项是什么意思score：按序数档位打分，比如「不着急 / 很快 / 卡住了」noul：是/否判断，返回的是概率值，不是硬邦邦的 true/false
关键在于延迟。README 给的是 Tesla T4 上的实测：单个问题 32.8 毫秒，5 个问题 40.1 毫秒，50 个问题 337 毫秒，摊到每题 6.8 毫秒。作为对比，它对标的 TypeSafe Jev 公开第三方实测是 236–276 毫秒，差了 7 倍多。而且它不是只能处理英文，内置 Router 会自动识别文字和语种，100 多种语言都能吃，非英文自动路由到多语言检查点。
生态位也铺得挺开：可以当 Python SDK 用，也有 MCP server、LangChain/LangGraph、LlamaIndex、CrewAI 集成，还有 HTTP 服务（接口兼容 Jev）、TypeScript 版、ONNX 和 GPU 快路径。
但我最欣赏的是它 README 里那段「诚实的局限」：基座模型在 typed-decisions 基准上 zero-shot 只有 0.362，随机基线是 0.318，多数类基线 0.461——等于裸模型基本不能用，0.766 的成绩是拿这个基准自己的训练集微调出来的。换句话说，laya 卖的不是一个开箱即用的决策引擎，而是一块又快又能校准的底座，你自己拿领域数据去微调。它还老实承认：语义标签不能防止否定句翻车，五条「我要取消」的否定样本里模型照样选了「取消账户」，有一条概率给到 0.9998。
jev-ultrafast：2.25 万星，浏览器 Agent 一轮只发一次请求
第二个是 jev-ultrafast，browser-use 家的，9 月 16 日建仓，22526 星，MIT 协议。browser-use 本体我们之前写过基础篇（11.7 万星那个浏览器 Agent），这算是它往「快」这个方向的激进分叉。
传统浏览器 Agent 每一步都要截一张图丢给多模态大模型，等它慢慢看图、想、输出一段 JSON，再解析成点击坐标。jev-ultrafast 把这套全拆了：
每次观测只做一次 DOM 原子读取，把页面上能点的控件列成一张带编号的表（[1] button 往返类型、[2] combobox 出发地……）。然后 TypeSafe 的 Jev 模型在同一次网络往返里同时选出「做什么操作」和「点哪个编号」——操作只有 CLICK、TYPE_TEXT、SELECT、SCROLL、WAIT、DONE、BLOCKED 这几种，目标问题还是投机执行的：如果 Jev 说 CLICK，那只有 click_target 这个头会生效。只有操作是 TYPE_TEXT 的时候，才会去调一个小模型写要输入的文字（demo 里用的是 inception/mercury-2.5，走 OpenRouter），其余时候大模型压根不出场。
实测数据在 README 里写得很细：Google Flights 上查苏黎世到伦敦的单程机票，一个自然语言目标丢进去，7073 毫秒跑完，包含模型调用、生成文字、浏览器干活、加载等待，而且有个独立校验确认单程设置、出发地、到达地、日期都对得上。六次交替对照跑，中位耗时从 9.45 秒降到 7.09 秒（省 25%），浏览器协议调用次数从 1092 次砍到 101 次。打开指定 Wikipedia 文章 2.798 秒。
安全设计上有一点值得说：模型输出永远不会变成选择器、坐标、shell 命令或者可执行的 JavaScript，每个执行的目标都必须是观测里真实存在的 DOM 节点，执行前还要再查一遍页面新鲜度和目标有没有被遮挡。
限制也别忽略：这玩意儿需要 TypeSafe API key，文本模型也要单独配 key，浏览器得靠 browser-harness 连本地 Chrome。README 明说 shadow root、iframe、canvas、文件上传、弹出标签页这些都不在 MVP 范围内，而且 3/3 的通过率只是「一个任务、一个浏览器 profile、三次重复」，不是通用可靠性基准。
实话
这批项目看着玄，本质其实很朴素：Agent 里有大量高频的小决策——工单该分给哪个部门、这条内容危不危险、页面上该点哪个按钮——这类活根本不需要一个会写诗的模型。用大模型跑这种步骤，钱是按 token 烧的，延迟是按秒算的，纯属高射炮打蚊子。
但也别走另一个极端。laya 自己都承认基座 zero-shot 接近随机，必须拿自己领域的数据微调才顶用；jev-ultrafast 依赖闭源 API，快是快，代价是决策黑盒。所以合理姿势是：把这类小模型放在 Agent 的「肌肉」位置，负责高频动作；把大模型留在「脑子」位置，负责规划和兜底。什么时候该用哪个，看的就是这一步到底需不需要「想」。
