APUS 开源 OpenJev-v1：本地 9B 模型复现 Jev 决策范式

结论先行：9 月 19 日，麒麟合盛网络技术股份有限公司（APUS）旗下 AI 实验室公布了对 TypeSafe AI 决策模型 Jev 的独立开源复现成果，并封装为开箱即用的 Agent Skill，支持纯本地模型离线执行。代码以 MIT 协议向全球开发者开放。实测中，一台消费级笔记本靠本地 9B 模型，全程离线完成真实维基百科检索任务的中位耗时约 18 秒，表单填报、站内导航约 3 秒，单任务模型打分仅 4 次，零云端调用、零 API 费用、数据不出本机。

一、三天之内，决策模型赛道被拆了两次

把时间线摆出来，这件事的意义比它看起来的更大：

日期	事件	性质
9 月 16 日	TypeSafe AI 发布 Jev，定位”系统一模型”，不生成文本、直接返回结构化决策	闭源 API
9 月 18 日	Convai Innovations 发布 Laya，非自回归决策引擎，Apache 2.0 权重可自托管	开源原生实现
9 月 19 日	APUS 公布 Jev 的独立开源复现成果（OpenJev-v1），MIT 协议 + Agent Skill 封装	开源复现

一个 9 月 16 日才出现的闭源新范式，三天内被验证可以在本地跑通。这不是”又一个开源平替”的故事，而是验证了这条路线的核心机制本身并不依赖某个闭源黑箱。

二、APUS 复现了什么

据 APUS 披露，团队基于 Jev 公开文档展示的输入范式与评估逻辑，反推出了其核心机制——跳过自回归解码、用隐状态直接打分。开源项目中具体复现了两点：

单 Token Logits 快速决策：不做逐 token 生成，一次前向传播直接给出打分结果
Jev KV-Cache 广播与并发批量评估：把候选集合的公共前缀只算一次，再并发地对每个候选打分

这两点合起来正是”系统一模型”能快一个数量级的原因：传统做法是让 LLM 生成一段文本再解析，而这条路线把输出空间压缩成”给候选打一个分”。

在浏览器自动化里长什么样

配套的 fast-browser-use 给出了一个很具体的落地形态：它把页面上真实可见、可交互的元素整理成带编号的候选动作集合，然后交由本地运行的 Qwen3.5-9B 通过单次前向计算，直接完成”点哪里、选哪个”的决策。

这个设计的价值在于机制上消除了两类经典失败：模型生成错误的选择器（selector），以及输出格式幻觉。因为输出空间从”任意字符串”变成了”从 N 个编号里挑一个”，模型在物理层面无法编造一个页面上不存在的元素。

三、实测数据：慢，但足够用

场景	耗时	说明
真实维基百科检索任务	中位约 18 秒	消费级笔记本，全程离线
表单填报	约 3 秒	同上
站内导航	约 3 秒	同上
单任务模型打分次数	4 次	而非数十次自回归生成

需要诚实地读这组数字：18 秒并不快，闭源 API 方案的同类任务通常是个位数秒级。它的意义在另外三个维度——

成本为零：没有 token 计费，跑一万次也是电费
数据不出本机：页面内容、表单信息全部留在本地，对内网、涉密、合规敏感场景是硬需求
可离线：断网环境也能跑，这一点云端 API 永远做不到

单任务仅 4 次打分尤其关键。它意味着瓶颈不在模型推理，而在浏览器渲染与页面解析——换句话说，这条路线已经把模型侧的开销压到不再是主要矛盾。

四、部署门槛：这次是真的低

项目支持 macOS、Linux、Windows 三大桌面与服务器系统，既可在 GPU 服务器上运行，也能在没有 GPU 的 Mac 和 PC 上跑。这一点与同期其他开源决策模型形成了对比——同类方案中不少型号在无 GPU 的机器上热推理要几十秒，实际只能批处理。

配合 Agent Skill 的封装形式，开发者不需要自己搭 harness：装好 skill，本地模型就能接管”选哪个动作”这一层。

五、APUS 想证明什么

该实验室相关负责人给出的定位很明确，两条：

验证”用模型做 Harness”技术路线在工程上可行——不是让模型生成代码去驱动工具，而是让模型本身充当决策层，直接输出选择
证明在闭源 API 之外，开源权重加端侧算力同样能支撑该范式，且数据全程留在本机

第二条我认为才是重点。过去一年 Agent 落地的默认假设是”决策必须调用云端最强模型”，而这条假设带来了三个成本：钱、延迟、数据外流。OpenJev-v1 加上此前的 Laya，正在从两个方向同时拆掉这个假设——前者证明机制可被独立复现，后者证明小模型就能跑。

六、与 Laya 的分工：一个复现，一个重做

两者常被放在一起比较，但目标并不相同：

维度	OpenJev-v1（APUS）	Laya（Convai Innovations）
性质	对 Jev 的独立开源复现	独立构建的原生开源实现
协议	MIT	Apache 2.0
形态	Agent Skill + 浏览器自动化框架	模型权重（choice/score/noul 三原语）
典型底座	Qwen3.5-9B 本地运行	ModernBERT-large / mmBERT-base 系列
验证重点	机制可复现 + 端侧离线可行	延迟与校准指标（延迟 32.8ms 级、ECE 校准）

想要”拿来就用的浏览器 Agent 决策层”，看 OpenJev-v1；想要”可量化的延迟与校准指标、以及多语言覆盖”，看 Laya。

FAQ

Q1：没有 GPU 能用吗？速度如何？

可以。项目明确支持无 GPU 的 Mac 和 PC。消费级笔记本实测：维基百科检索任务中位约 18 秒，表单填报与站内导航约 3 秒。这个速度不适合高频交互式任务，但对批量离线处理、内网自动化、定时巡检类场景完全够用。

Q2：和原生调用 Jev API 相比，优势在哪？

不是性能优势，是成本与合规优势：零 API 费用、零云端调用、数据不出本机、可离线运行。代价是绝对速度更慢、决策质量取决于本地底座模型（实测使用 Qwen3.5-9B）。若任务不涉及敏感数据且追求极致延迟，闭源 API 仍然更合适。

Q3：为什么它能做到不产生错误选择器？

因为输出空间被限制了。fast-browser-use 先用程序把页面真实可见、可交互的元素枚举成带编号的候选集合，模型只需从前向计算中给出”选几号”的打分，而不生成任何文本。模型无法输出一个不在候选集合里的选择器，格式幻觉也就无从产生。

小结

OpenJev-v1 最值得记的不是 18 秒这个数字，而是它把”决策层必须用闭源云端大模型”这个默认假设拆开了一道口子：机制能被独立复现，9B 模型就能驱动，数据可以不出本机。对做内网自动化、合规敏感场景、或者单纯不想为每个决策付费的团队，这是值得现在就试的一条路。

APUS 开源 OpenJev-v1：本地 9B 模型复现 Jev 决策范式，18 秒离线完成维基检索