Jev-Mobile架构深拆：低频VLM高层规划+高频Jev执行器，79%任务成功率与32.7%端到端延迟下降是怎么做到的

Jev-Mobile架构深拆低频VLM高层规划高频Jev执行器79%任务成功率与32.7%端到端延迟下降是怎么做到的【免费下载链接】jev-chat-jarvisThe chat decision assistant: before you reply, Jev reads the chat, judges intent and risk, and drafts replies you fill in with one tap. You press send. Android · Windows · macOS · iOS | 聊天辅助决策工具先看懂对方再回复发不发由你。项目地址: https://gitcode.com/gh_mirrors/je/jev-chat-jarvis移动端 GUI 智能体Mobile GUI Agent过去几年一直困在同一个死结里让大模型看懂屏幕 决定下一步 操作界面一次循环至少一轮多模态推理。AndroidWorld 上的典型方案每执行一步都要调一次 VLM——视觉编码、全局推理、动作生成全挤在一次调用里延迟以秒计、成本随步数线性膨胀任务稍长就跑不动。Jev-Mobile 给出的答案是另一种分工把看和想交给低频的 VLM把点和选交给一个毫秒级、几乎零成本的结构化决策模型 Jev。VLM 只在关键节点做高层规划、输出局部子目标Jev 则基于实时无障碍树Accessibility Tree生成的结构化候选动作逐节点做类型化决策一次 VLM 调用可以驱动多步 GUI 操作。最终在 AndroidWorld 基准上拿到79% 任务成功率、成功轨迹端到端延迟下降 32.7%、VLM API 开销减少 73.4%。本文结合社区情报与 jev-chat-jarvis 仓库源码把这条架构链路拆开Jev 作为执行器到底长什么样、候选动作如何从无障碍树里程序化生成、VLM 与执行器之间如何划分控制权、三项指标各自说明了什么——以及这套低频规划 高频执行的组合拳和本仓库里已在真机跑通的聊天副驾工程共享着哪些设计内核。一条被低估的分工线System One 决策模型不该只做路由Jev-Mobile 的核心判断藏在对 Jev 这个模型的定位里。Jev 是 TypeSafe AI 于 2026 年 9 月发布的System One模型不生成文本只在封闭集合内输出带概率与置信度的类型化答案——choice选择、score打分、noul是非。社区对它的一个经典概括是Jev 不是聊天机器人而是一个智能 if 语句另一个更工程化的说法是把重复性判断从 LLM 卸载到专用决策层构建高效的混合智能体系统。从成本与延迟曲线看这种卸载极其划算Jev 的响应落在70–500ms区间输入价格约$0.042/百万 token且输出 token 免费——一次典型判断请求仅约 1000 输入 token、实测约 900ms 返回、成本 0.00004 美元级别。在通用 LLM 上同等的一次判断需要一次完整的模型前向与几百上千 token 的文本生成在 GUI 智能体里这一步的代价会被乘以任务步数。因此 Jev-Mobile 的分工是VLM 负责需要语义理解、跨步骤推理的高层规划Jev 负责在给定选项里选一个、给候选动作打分的局部决策。前者低频后者高频。这一分工在 cn/CLAUDE.md 里描述的三路客户端结构里可以找到同构的印证判断Jev、回复DeepSeek 生成、视觉OCR 用各自独立成客户端判断路一次请求打包全部题目、约 1 秒返回生成路才承担起草候选回复的文本任务。判断用专用模型、生成用通用模型不是一个想法而是已经被真机工程验证过的模式。无障碍树是执行器的手眼候选动作由代码程序化生成Jev 作为执行器要能干活前提是它必须看得见当前界面。Jev-Mobile 的做法与 jev-chat-jarvis 如出一辙用 Android 无障碍服务读实时无障碍树而不是让 VLM 看截图。差异只在于用途——聊天副驾用它提取对话内容GUI 执行器用它生成可执行候选动作。在 global/a11y/src/main/java/com/jev/overseas/a11y/NodeCollector.kt 里NodeCollector 以最多 8000 个节点的预算遍历当前窗口的无障碍树把每个节点拷贝成结构化的 NodeRecordviewId、text、contentDescription、屏幕坐标 bounds、可点击 / 可滚动 / 可编辑等 flag 集合、以及动作列表CLICK、SCROLL_FORWARD、SET_TEXT…。关键设计是只读不写它从不调用 performAction。这批结构化为执行器铺好了路。Jev-Mobile 中的候选动作生成是程序化的从无障碍树里把可点击、可滚动、可输入的节点枚举出来结合屏幕坐标与控件类型编译成一组受限的候选动作点这个按钮、滚这条列表、往这个输入框填文本。Jev 需要做的不是想象下一步而是在这组真实存在的候选里做选择/评分——这正是 choice/score/noul 三类问题的天然用武之地。仓库里可对照的真实案例是 cn/app/src/main/java/com/jev/probe/capture/ChatAppAdapter.kt每个聊天 App 一个适配器把无障碍树变成中性的 ChatSnapshot。QQ 靠id/mjn节点取正文、按气泡贴哪侧头像判发送方X 私信是 Compose 树消息全在 content-desc 里按发件人正文。时间。Read。的格式解析飞书正文自绘树里只有气泡矩形于是改为矩形 离线 OCR。无论哪种形态采集层输出的都是统一的Msg(side, text)消息列表下游判断、回复、悬浮窗全部无关 App。适配器只认树里真实存在的东西绝不去猜——这与执行器候选动作必须来自无障碍树的原则完全一致。再看 cn/app/src/main/java/com/jev/probe/capture/NewMessageGate.kt它以 (side, text) 为键维护已见消息集合只有当未见消息出现在某条已见消息之下即消息真正抵达底部才判定为新消息上下翻历史、列表滚动都不会触发误判。GUI 执行器面临同样的扰动问题——界面滚动、控件移动、加载动画——一个可靠执行器同样需要这类变化检测来确认动作是否生效而非每帧都交给模型重新理解。显式控制权移交单次 VLM 调用执行多步动作的关键设计Jev-Mobile 的第二项核心创新是显式控制权移交explicit control handover机制它支撑起单次 VLM 调用驱动多步 GUI 动作的能力。传统移动端智能体每步一个循环截图 → VLM 推理 → 输出动作 → 执行 → 再截图。Jev-Mobile 则让 VLM 输出局部子目标之后进入执行器主导的局部闭环Jev 依据无障碍树候选动作逐节点决策一连执行多步直到子目标达成、或遇到无法类型化判断的局面才把控制权交还给 VLM。移交的显式之处在于它不是软性的模型自觉而是有明确判定条件的状态转移——执行器在候选空间内能安全收敛就继续候选枯竭、动作失败、或需要新的语义理解时才触发 VLM 调用。这套低频高层 高频局部的节奏在本仓库的会话状态机里能找到非常接近的工程形态。global/core/src/main/kotlin/com/jev/overseas/core/session/AssistantSession.kt 是整个聊天副驾的流控核心意图方法在 UI 线程立即返回读取与模型调用全部跑在后台 executor 上并且每一项后台工作都携带它启动时的 generation 号一旦 generation 前进迟到的结果直接丢弃。打开面板 → 读取聊天 → 分析Jev 判断→ 用户选立场 → 起草 → 检查评分 → 填入——每一步都是一次显式的状态转移任何一步的结果过期都不会污染后续流程。与之配套的是 global/core/src/main/kotlin/com/jev/overseas/core/engine/Assistant.kt 里的RunBudget单轮模型请求上限 17 次、模型等待时间上限 90 秒请求失败只重试一次且必须是可重试类型限流、服务端、超时、网络鉴权错误绝不重试。并行请求在等待时只计一次时间。这给高频执行划了一条工程红线执行器再快也不能无限消耗模型预算——与 Jev-Mobile 用执行器压低 VLM 调用频率的动机完全同构。再往深一层看global/core/src/main/kotlin/com/jev/overseas/core/engine/Analysis.kt 展示了 Jev 决策如何被代码转译成行动AnalysisEngine 把行为问题与摩擦问题拆成两个并行请求——主请求覆盖行为、线索与语气摩擦请求只看最近一轮加前 4 条消息防止一条旧消息把平静的当下误判为紧张返回的概率经阈值0.7 命中 / 0.3 缺席中间是 unsure转译成 detected / unsure / absent而unsure 且影响决策的答案会让用户选择而不是猜测并派生出明确的 NextStepDIRECT_DRAFT、CHOOSE_STANCE、NO_REPLY_NEEDED、SAFETY_HOLD、BOUNDARY、UNCLEAR。这与执行器的行为模式如出一辙概率输出必须落成确定的行为分支拿不准就交还控制权。VLM 规划下发的局部子目标在本仓库里对应的就是 global/core/src/main/kotlin/com/jev/overseas/core/engine/Goal.kt 的 Goal 结构起草前先把回复目标固化为 summary、mustInclude、mustAvoid、authorized_commitments起草模型只能在目标内写字Jev 再逐条检查——先定目标再让高频决策器在目标约束下工作是两套系统共享的设计语言。79%、32.7%、73.4%三项指标到底说明了什么Jev-Mobile 在 AndroidWorld 上报告的三个数字对应三个不同层面的收益值得分别解读。79% 任务成功率是结果指标。AndroidWorld 以真实 App 交互为评测环境成功率对每一步的可靠性都敏感——一次误点、一次滚动失败、一次对弹窗的误判都可能断送整个任务。79% 的可信度取决于一个前提高频执行步骤的质量没有因为换了个小模型而塌方。而执行器质量的保障恰恰来自候选动作的受限生成——Jev 不在开放空间里自由发挥只在无障碍树提供的真实候选里做类型化选择动作空间的收缩直接压低了低级错误率。仓库的实测数据提供了同方向的证据global/docs/TESTING.md 记录的在线评测中预期为真的行为信号 48/48 命中、预期为假 51/54 判清3 个 unsure、0 个判错、含违规回复的拦截 6/6、干净回复不误拦 11/12、摩擦 73/74、语气 37/37。决策模型的可靠性可以用把选择题答准来量化验证这正是它敢扛起高频执行环节的底气。成功轨迹端到端延迟下降 32.7%是架构收益。移动 GUI 智能体的延迟大头从来不是动作执行本身而是每步一次的多模态推理往返。把大部分步骤从VLM 一次前向降级为Jev 一次 70–500ms 的类型化判断多步任务的总延迟自然被削掉近三分之一。这个数字成立的关键在于成功轨迹这个限定——失败的轨迹往往伴随着额外的重试与异常处理不能用来衡量架构的稳态性能。仓库里同类的延迟哲学可见于 cn/CLAUDE.md判断路一次打包 7 题约 900ms 返回回复路与视觉路才走更重的模型cn/CHANGELOG.md 记录只要 1 条候选时不做排序出得更快判断和回复各自最多等 30 秒超时给重试——延迟是显式的预算项被主动管理与优化而非被动承受。VLM API 开销减少 73.4%是成本收益。开销按调用次数或 token 计量。执行器接管后任务中大部分决策步骤不再触碰 VLM总 API 开销被压到原来的约四分之一。这里要强调一个容易被忽略的事实73.4% 是减少不是归零——VLM 仍然承担高层规划说明作者保留了语义理解环节只砍掉了重复的、可类型化的部分。这与 Jev 的成本曲线完全吻合Jev 输出 token 免费、输入约 $0.042/M、单次判断约 1000 输入 token、成本 0.00004 美元量级而 cn/CHANGELOG.md 记录的在线评测同样佐证这种便宜量又足的决策用量draft 评测 21 次请求共 $0.0038edge 评测 22 次请求共 $0.0035revision 评测 162 次请求共 $0.0205——每类判断一次调用单次成本以亚美分计。当执行器把这类决策从每步一次 VLM替换为每步一次 Jev时73.4% 的开销下降是算术上必然的结果。需要保持清醒的是评测边界。AndroidWorld 是封闭基准79% 尚未与真实世界 App 更新的对抗性环境划等号无障碍树的候选生成依赖目标 App 的控件暴露程度——仓库在 cn/README.md 中把隐藏界面内容或禁止截屏的 App 一律不读列为硬约束cn/CLAUDE.md 也明确只读目标 App 正常开放给无障碍服务的内容这就是同一物理边界的工程表达。此外Jev-Mobile 的指标来自其论文与工程实现本文未逐字复现其评测脚本三个数字应作为架构效果的量化锚点而非放之四海皆准的承诺。同一内核的两次落地从 GUI 执行器到聊天副驾把 Jev-Mobile 与本仓库对照着看会发现它们不是恰好相似而是同一套设计哲学在不同任务域的两次实现结构化状态而非原始像素。执行器读无障碍树生成候选动作聊天副驾读无障碍树提取消息列表。模型永远不直接面对未经处理的屏幕。决策与生成分离。Jev 做判断意图、危险等级、该不该回、候选排序生成模型只负责起草文本GUI 侧则让 Jev 做动作选择VLM 只做规划。判断路的典型延迟约 1 秒、成本亚美分正是它能够高频运转的原因。显式状态机与显式控制权。Generation 失效丢弃、RunBudget 预算封顶、NextStep 分支明确执行器同样以显式条件决定继续执行还是交还 VLM。拿不准就交还给人或上层。unsure 答案让用户选择而非猜测回答不完整的请求宁可失败重来也不编造答案Missing answers are never filled in执行器遇到候选枯竭或无法类型化判断的局面同样交还控制权。这套架构的启示在于移动端智能体的瓶颈不是模型不够聪明而是把每一步都交给最贵的模型。Jev-Mobile 用 79% 的成功率证明把高频决策从 VLM 卸载到 System One 决策模型非但不掉质量反而因为动作空间受限、决策确定性提高而更稳用 32.7% 的延迟下降和 73.4% 的开销缩减证明这种卸载在经济上是压倒性的。当社区还在争论要不要让大模型直接操作手机时Jev-Mobile 与 jev-chat-jarvis 已经从两个方向给出了同一个答案让大模型负责理解与规划让专用决策模型负责执行与选择让显式的状态边界决定二者何时交接。【免费下载链接】jev-chat-jarvisThe chat decision assistant: before you reply, Jev reads the chat, judges intent and risk, and drafts replies you fill in with one tap. You press send. Android · Windows · macOS · iOS | 聊天辅助决策工具先看懂对方再回复发不发由你。项目地址: https://gitcode.com/gh_mirrors/je/jev-chat-jarvis创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考