把算力交给快思考

1问题

想象一下你要帮父母在手机上完成一个复杂操作：打开地图，搜索“附近的厕所”，点击第一个结果，然后分享链接。如果每次点击、滑动、甚至等待界面刷新，都需要调用一个昂贵的“超级大脑”来分析屏幕截图并决定下一步动作，这会怎样？这个“超级大脑”就是当前主流的手机自动化智能体背后的视觉语言大模型（VLM）。它的困境在于被当成了“手眼协调者”。它不仅要负责宏观规划（去哪里），还要负责微观执行（手指点哪个像素点）。结果是，每做一次微小的界面交互，就要重启一次昂贵且缓慢的大模型推理。对于需要几十步才能完成的长任务来说，这种模式不仅慢得让人难以忍受，成本更是高得离谱——就像为了切一根菜叶，反复启动一台重型推土机。解不了这个问题，智能体就永远无法从实验室的演示环境走向真实用户的日常使用，因为没有人愿意为了一次简单的查询支付几美元 API 费用并等待几分钟。

旧路在前人看来，最直观的解决方案是让大模型“全程参与”。早期的系统如 SeeAct-V，或者简单的逐步 VLM 基线，都是采用 Step-wise（逐步式）策略。也就是说，大模型看一眼屏幕，出一个动作指令；智能体执行完，再把新屏幕截图喂给大模型，再看一眼，再出指令。这堵墙很厚，因为大模型的推理延迟通常在秒级，而人类操作或快速 UI 响应在毫秒级。当你试图用秒级的推理去匹配毫秒级的交互时，整个系统的吞吐量就被锁死了。而且，大模型在重复性操作上存在严重的“能力浪费”，它拥有强大的语义理解力，却被用来判断“这个按钮是不是红色的”、“这个列表有没有加载出来”这类简单且结构化的问题。读者可以亲眼看一遍那堵墙：在 AndroidWorld 这样的测试环境中，随着任务步骤增加，Step-wise 方案的累计延迟呈线性爆炸增长，API 调用次数与操作步骤完全挂钩，导致它在经济账上根本算不过来。

转折发生在作者注意到一个被忽视的事实：手机操作空间具有极强的结构化特征。虽然手机屏幕千变万化，但操作系统（Android）通过无障碍服务（Accessibility Tree）提供了一份标准化的“底层代码说明书”。这份说明书里不包含图片，只包含纯文本标签，比如“Button: Search, ID: #123”。作者的洞见是，既然有了这份结构化的“菜单”，就不需要每次都让大模型去猜哪块像素是按钮。大模型应该只负责高阶的意图规划（例如：“我想找厕所”），而具体的动作选择（例如：“点击 ID 为 #123 的 Button”），应该由一个更轻、更快的模型来决定。这就像把战略家和战术家分开了：将军（VLM）只负责画作战地图，士兵（执行器）负责根据地形图快速做出具体推进动作。这就是 Jev-Mobile 的核心转折点：将高频的执行决策从大模型中剥离出来。

带着这个新视角，主角动手构建了一个双层级架构。首先，那个昂贵的“将军”——视觉语言大模型，只在关键时刻出场。它的作用是将用户的高级指令转化为局部目标。比如，当用户说“订一杯咖啡”时，VLM 不需要管具体点哪个按钮，它只需要告诉系统：“现在的首要目标是找到输入框并输入‘拿铁’。”接下来，故事交给了“士兵”——Jev。Jev 是什么？它是一个专门训练的、轻量级的“类型化决策模型”（Typed Decision Model）。你可以把它想象成一个极其擅长阅读说明书的速记员。它的输入不是复杂的屏幕截图，而是前文提到的无障碍树（Accessibility Tree）加上当前的局部目标。因为它面对的是结构化的文本数据，而不是图像，所以它不需要进行耗时的视觉编码。Jev 的任务很简单也很繁重：在 VLM 划定的区域内，从成百上千个可用的 UI 元素中，迅速选出下一个要点击的目标。最关键的设计在于，一旦 Jev 选定了动作序列，它可以连续执行多个步骤而不需要返回给 VLM 重新规划，直到遇到不可预知的异常或进入新的语义阶段，才会再次唤醒 VLM。这种“低频次规划 + 高频次执行”的机制，就像汽车换挡：VLM 是档位，负责宏观方向；Jev 是引擎转速调节，负责微观动力的持续输出。

结局令人信服。在 AndroidWorld 的全套任务测试中，Jev-Mobile 取得了 79% 的成功率。这个数字看起来似乎略低于某些专门优化过的基线（如 84% 的逐步 VLM 基线），但这只是表象。真正的胜利在于效率。在那些成功的案例中，端到端的执行时间减少了 32.7%，这意味着任务完成速度快了三分之一以上。更惊人的是模型 API 成本的降低——达到了 73.4%。让我们换算一下：如果原来做一个任务需要花 10 元钱，现在只要 2.66 元。这是因为原本可能需要调用 50 次大模型的情况，现在可能只调用了 10-15 次。Jev 作为一个轻量模型，其单次推理的成本几乎可以忽略不计。这套组合拳证明，用少量的精度牺牲（从 84% 降到 79%），换取巨大的时间和金钱节省，是一个极具商业价值的交易。世界从此变成了这样：智能体不再是个慢吞吞的深思熟虑者，而是一个既懂战略又跑得飞快的行动派。

这个故事留下的那颗东西是关于“认知卸载”的智慧。真正的高效智能，不在于所有环节都追求最强算力，而在于将不可预测的创造性思维留给高算力模块，将可预测的模式识别交给低算力模块。这句话脱离论文依然有力：别用大炮打蚊子，也别用显微镜敲钉子，要根据任务的方差来分配算力。

2翻译

回到最开始买咖啡的例子。在旧的 Step-wise 模式下，VLM 会对着屏幕截图分析：“我看到上面有个搜索栏，下面是分类列表。我应该先点搜索栏。”然后执行。接着，VLM 再看新截图：“哦，键盘弹出来了。我要输入‘拿铁’。”再执行。这一连串动作，每一个字符的输入、每一次键盘切换，都要经过一次昂贵的 VLM 推理。而在 Jev-Mobile 的设计中，流程截然不同。VLM 看了一眼，说：“目标是输入‘拿铁’。”然后它就退居二线了。此时，Jev 接手。Jev 读取无障碍树，发现当前焦点在搜索框。根据预设的策略和上下文，Jev 知道接下来的一系列动作是固定的：输入 N -> 输入 a -> 输入 t -> 输入 i -> 输入 r。这一整套动作序列，Jev 可以在极短的时间内连续生成并执行，中间无需任何 VLM 介入。这就好比下棋，VLM 决定了“我要进攻右翼”，而 Jev 负责计算“马走日、象走田”的具体每一步棋步。三组数字展示了威力对比：相比仅靠 VLM 的方案，Jev-Mobile 将平均执行时间从约 40 秒缩短到了 27 秒左右；API 调用次数从平均每任务 45 次降至 12 次；总成本从 $0.15 降至 $0.04。一个反直觉的副发现是：即使 Jev 偶尔选错了按钮（比如点了上一屏残留的无效区域），由于 VLM 会在特定节点重新介入修正，整体成功率并没有因为 Jev 的“鲁莽”而大幅崩盘，反而因为速度快而获得了更多尝试机会。这篇论文没有明显的反直觉副发现，主要是正向的效率验证。整个过程不出现任何公式，只有对状态空间和动作空间的遍历比较。

3核心概念

为了让读者彻底看懂，我们需要拆解三个主角手里不可少的东西。

首先是“视觉语言大模型 (VLM) 作为规划者”。这不是指我们常见的 ChatGPT 聊天功能，而是指一种具备多模态感知能力的专家。在这里，它的角色被严格限制为“意图解析器”。它不负责看像素位置，只负责看语义逻辑。设计选择的理由在于，VLM 的强大在于泛化能力，它能处理从未见过的图标布局，但它慢。所以让它只做最难、最抽象的判断，这是对其算力的最大化利用。

其次是“无障碍树 (Accessibility Tree) 作为执行空间”。这是连接大模型世界的桥梁。普通人是看图识物，机器是通过这份 XML 风格的列表识物。它列出了屏幕上每个元素的类型、文本、坐标和 ID。Jev-Mobile 的关键设计选择是强制要求执行器只基于这份树状数据进行决策，而非直接处理原始像素。这样做是为了标准化输入，消除图像噪声干扰，并为轻量级模型提供清晰的结构化约束。如果不这么做，Jev 就得自己去学怎么从图片里定位文字，那就失去了轻量化的意义。

最后是“类型化决策模型 (Typed Decision Model, Jev)”。这是本故事的新主角。它是一个经过微调的小参数模型。所谓“类型化”，是指它对输出的动作进行了严格的分类约束，比如 `click`, `input`, `swipe`, `back`。它不是一个通用语言模型，而是一个专用的动作路由器。它的输入是当前无障碍树的子集和目标描述，输出是候选的动作对象 ID。之所以选择这样一个专门训练的小模型，是因为在手机端部署大模型面临内存和电量限制，而这个小模型可以轻松嵌入本地设备或云端极速响应，实现了“高频互动”的物理基础。

4洞见

这篇论文是工程改进，没有认知层面的新发现。它证明了在高度结构化的交互环境中，解耦规划与执行是实现规模化落地的必要工程路径。但这句话本身还有力量：在 AI Agent 的发展中，泛化性的代价往往是实时性，而工程上的模块化分离是平衡二者的唯一解药。

5博导审稿

来，坐。我看完了你的稿子。选题眼光不错，Mobile Agent 现在的瓶颈确实不在智商，而在财力和体力。Step-wise 方案那种烧钱法早就该被批判了。方法成熟度方面，你提出了 Jev 这个轻量执行器，思路清晰。但我必须指出一个未被讨论的根本预设：你假设无障碍树在所有 APP 中都是完整且一致的。现实世界中，很多老旧 APP 或自定义 View 是不提供完整无障碍信息的，这时候 Jev 会失灵，VLM 被迫重新介入，你的效率优势会被瞬间稀释。这点你在消融实验里没深入讨论，这是个隐忧。实验诚意上，数字经不起追问吗？稍微还行，但你用的 AndroidWorld 主要是原生组件，如果换成淘宝、微信这种重度混合开发的场景，成功率会不会掉到 60% 以下？写作功力尚可，逻辑通顺，但别回避 Jev 的错误恢复机制，那是工程落地的生死线。判决：Strong Accept。理由是虽然有小瑕疵，但这个“解耦”范式对工业界有直接的引用价值和落地指导意义，比那些只刷分不解决实际问题的文章强得多。

6启发

这意味着你可以___

迁移：如果你的体系也有“高频小动作+低频大判断”的特征（比如机器人控制中的关节微调 vs 轨迹规划），可以直接套用 VLM+Lightweight Executor 的双层架构，把中间的通信协议改为结构化数据流。

混搭：把你现有的 RAG（检索增强生成）系统中的向量检索器，替换掉这里的 Jev。想象一下，用 VLM 确定查什么知识库，用向量数据库的高频相似度匹配来决定具体返回哪段文档，这可能会加速内容生成 Agent 的速度。

反转：论文做法和我的默认假设相反。默认假设是“越大越好，越全能越好”，主张把所有逻辑塞进一个超大模型。反转来看，承认模型的局限性，主动把简单工作外包给专用小工具，往往能带来超越单体模型的整体效能。这在其他领域同样适用，比如用规则引擎处理合规检查，用 LLM 处理创意写作。