Atom Wang
2026-07-31

AI 工程 · 技术选型

手机已经能被点了，缺的是那个决定点哪儿的模型

当截图、视频流、模拟触控、按键触发这四个接口都已经就位，剩下的问题只有一个：把哪个模型接到这条回路上。 这份报告对比 2026 年 7 月能落地的八条路线——两条闭源 API、四个开源权重、两家国际大厂—— 核心判据不是榜单分数，而是模型输出的动作能不能直接喂进你已有的接口。

调研日期
2026-07-31
使用场景
已有手机端截图 / 视频流 / 触控 / 按键接口，选配决策模型
候选数
8 条路线
方法
厂商一手文档 + HuggingFace / GitHub API 当日实测 + arXiv 基准论文 + Hacker News 一手评论
前提假设
目标平台为 Android（见 §1 说明）

一句话结论

先用 阿里云百炼 GUI-Plus 打通回路，同时把 GUI-Owl-1.5 作为自部署备份。 原因不是它分最高，而是它输出的动作集和你手上的接口几乎是逐条对应的——集成成本接近零。

首选 · 先跑通

GUI-Plus（gui-plus-2026-02-26）

百炼上的界面交互专用模型。移动端动作集 click / swipe / type / key / long_press / system_button / open / wait，坐标归一化到 1000×1000，按键直接用 adb keyevent 语法。¥1.5 / ¥4.5 每百万 token，送 100 万免费额度。

备选 · 自部署

GUI-Owl-1.5（MIT）

与 GUI-Plus 同源的开源家族，2B/4B/8B/32B 四档。8B-Thinking 在 AndroidWorld 拿 71.6，2B 也有 67.9。要断网、要私有化、要压成本时换它。

备选 · 本地优先

Holo3.1（Apache 2.0）

AndroidWorld 官方口径 79.3（35B-A3B），是本次候选里最高的公开手机成绩，且提供 FP8 / NVFP4 / Q4 GGUF 量化档。中文 App 无针对性证据。

不建议做主力

Claude computer use

官方工具面向桌面，文档里没有移动环境。手机竖屏必须自己缩放到长边 1568px 以内，小字识别会掉。它适合桌面，不适合当手机 agent 的大脑。

你的接口，已经把答案框住了一大半

市面上「能操作手机的大模型」分两类：一类连带整套执行框架（droidrun、mobile-use、Mobile-Agent）， 一类只做大脑、把执行交给调用方。你已经自建了执行层，所以框架那一类对你只剩参考价值，真正要选的是后一类。 而后一类之间的差别，主要落在三个点上。

1. 动作集对不对得上

决定集成成本，也是这次的首要判据

  • 手机原生动作集的模型（GUI-Plus、GUI-Owl-1.5、Gemini ENVIRONMENT_MOBILE）直接输出 swipe、long_press、系统返回键、开 App。
  • 桌面动作集的模型只有 click / double_click / 键盘快捷键，你得自己把「滑动」翻译成拖拽、把「返回」翻译成某个按键——每多一层翻译就多一层错误来源。

2. 坐标怎么给

决定你要不要写缩放层

  • 归一化坐标（GUI-Plus 的 1000×1000、Gemini 的 0–999）：截图多大都不影响，乘一下分辨率就是真实触点。
  • 绝对像素（Claude）：模型看到的是被你缩放过的图，返回的坐标在缩放后的空间里，你必须自己保留 scale factor 再乘回去。1080×2400 的竖屏按 Claude 的限制会被压到约 705×1568。

3. 见没见过中文 App

决定 grounding 是不是在猜

  • 国际模型的训练分布以英文界面为主。国产 App 的图标语义、底部导航习惯、弹窗样式都不一样，grounding 精度会掉，但没有公开数字能量化掉多少。
  • 阿里系（GUI-Plus / GUI-Owl）和 AgentCPM-GUI 是有中文语料证据的两条线。
一个必须先确认的前提：Android 还是 iOS

本报告全部按 Android 展开。原因是硬的：GUI-Plus 的 key 动作明确写着「支持 adb 的 keyevent 语法」， Gemini 的移动环境标注是「Android-optimized」，AndroidWorld 这个基准本身就是 Android。 如果你的目标是 iOS，这些模型的视觉理解仍然可用（截图就是截图），但动作层的按键语义、开 App 方式、系统按钮都要你自己重映射， 且没有任何公开基准能告诉你 iOS 上的成功率。这一层差异需要你先确认，再决定要不要照本报告的排序走。

八条路线横向对比

点击表头排序，输入关键词过滤。AndroidWorld 一栏只填厂商一手文档或论文里明确写出的数字， 没有一手来源的一律留空——不用第三方聚合站的数字凑表。许可证与下载量为 2026-07-31 当日 API 实测。

方案 ▴ 形态 许可 / 接入 AndroidWorld 坐标 手机动作集 中文 App HF 月下载 价格
读表时请把这两件事记在心里

其一，AndroidWorld 分数不可跨来源比较。各家用的 harness、步数上限、重试策略都不同， GUI-Owl-1.5 的 71.6 和 Holo3.1 的 79.3 出自两家各自的评测，不构成「Holo 比 GUI-Owl 强 7.7 分」。 其二，下载量高不等于现在更好。UI-TARS-1.5-7B 月下载 65 万是本表最高，但它是 2025 年 4 月的模型， GitHub 仓库最后一次 push 停在 2026-01-27；GUI-Owl-1.5 是 2026-02 才发布的，下载量低主要反映时间差而非质量差。

首选路线：GUI-Plus 为什么是最省事的那个

阿里云百炼把这个模型定位成「基于屏幕截图和自然语言指令解析用户意图，转换为标准化 GUI 操作，供外部系统决策或执行」—— «供外部系统执行» 这句话，说的就是你这种已经有执行层的场景。

它的移动端动作集与你的接口对照

模型输出的动作你已有的接口需要写的适配
click(x, y)模拟触控坐标 ÷1000 × 实际分辨率
swipe(x, y, x2, y2)模拟触控同上，两个点
long_press(x, y, 秒)模拟触控同上，加时长
system_button(Back / Home / Menu / Enter)触发按键直接映射，四选一
key(adb keyevent 语法)触发按键若你的按键接口本来就是 adb 语义，零适配
type(text)输入设备需预装 ADB Keyboard 并设为默认输入法
open(app)—需你补一个按名启动 App 的通路
wait / answer / terminate—循环控制，不涉及设备
唯一的意外成本：输入法

官方文档明确要求把设备默认输入法设成 ADB Keyboard，type 动作才能把文本打进去。 如果你的触控接口是走 uiautomator / 无障碍而不是 adb，这一条要单独验证；文本输入是整条链路里最容易在真机上翻车的动作。

要接受的限制

顺带提一句：通义 UI Agent 是另一个东西

同在百炼下还有一个「通义 UI Agent」，定位是「基于终端屏幕理解操作手机 / 车机 / 电视 / PC 的多模态智能体方案，即插即用」， 移动端链路参数 device_type: "mobile"、model_name: "pre-gui_owl_7b"，返回 Thought / Operation / Explanation 三段， 文档标注限时免费。但它的移动端链路是简化版——PC 端才有 manager 规划、worker 执行、reflector 反思、notetaker 记忆的多 agent 编排， 移动端文档里写着「当前版本只处理第一个元素」。适合零成本试水，不适合作为长期主力。

三个开源候选，各自解决不同的问题

如果你的顾虑是数据不能出内网、成本要压到自有 GPU、或者想微调，那么闭源 API 这条线要换掉。 开源侧值得看的只有三个，它们不是同一个替代关系。

GUI-Owl-1.5 / Mobile-Agent-v3.5

阿里通义 · MIT · 2026-02 · Qwen3-VL 基座

  • 选它的理由：与 GUI-Plus 同源，先用 API 验证再换自部署时，prompt 与动作协议几乎不用重写。
  • 规模覆盖最全：2B / 4B / 8B / 32B，Instruct 与 Thinking 双版本。2B-Instruct 在 AndroidWorld 拿 67.9，8B-Thinking 71.6——小模型掉分不多，这对端侧部署是好消息。
  • 动作集扩展到工具：官方说动作空间已超出 click/type/scroll，包含外部工具调用、API 调用与 MCP 交互。
  • 要注意：HF 月下载仅 3,155，社区踩坑经验极少，遇到问题基本只能自己啃论文和源码。

Holo3.1

H Company · Apache 2.0 · 2026-06-01 · Qwen 基座

  • 选它的理由：本表最高的手机成绩（35B-A3B 从 Holo3 的 67% 提到 79.3%，4B / 9B 从 58% 提到 71%），且是本次唯一官方提供 FP8 / NVFP4 / Q4 GGUF 三档量化的。
  • 为本地推理而生：官方明确目标是「从云推理到终端设备完全本地执行」，还有 0.8B 档。
  • 发布动机值得注意：官方自述 Holo3.1 就是为了修 Holo3 的问题——「在一个环境下表现好不代表能迁移到另一个，移动设备、不同 agent 框架、不同执行框架都会引入分布偏移」。这句话本身就是对整个品类的诚实提醒。
  • 要注意：没有任何中文 App 的针对性证据。

AgentCPM-GUI

THUNLP / 人大 / 面壁 · Apache 2.0 · 2025-05 · MiniCPM-V 8B

  • 它的独特价值只有一条：号称首个专门为中文 App 微调的开源 GUI agent，覆盖高德、大众点评、bilibili、小红书等 30 多个国产 App，自建的中文基准 CAGUI 上 Exact-Match 91.28。
  • 动作集为端侧设计：紧凑 JSON，平均输出仅 9.7 token，延迟优势明显。
  • 但它已经落后一代：HF 月下载 212，GitHub 最后一次 push 停在 2026-01-11。当作「中文 grounding 的对照组」或微调起点比当主力合理。

UI-TARS —— 名气最大，但要看清版本

字节 Seed · Apache 2.0 · GitHub 11.2k star

  • 开源的仍是 UI-TARS-1.5-7B（2025-04）。UI-TARS-2 只发了技术报告，权重没开——它是 230B 总参 / 23B 激活的 MoE，从 Seed-thinking-1.6 初始化，本来也不是能自部署的体量。
  • 生态最厚：HF 月下载 655,936，是本表最高，UI-TARS Desktop 有独立生态。踩过的坑网上都能搜到。
  • 但已经半年没动：bytedance/UI-TARS 最后 push 2026-01-27。GUI-Owl-1.5 的论文里，UI-TARS-1.5-7B 在长程记忆基准 MemGUI-Bench 上只有 8.3，被 GUI-Owl-1.5-32B 的 27.1 拉开——多步长任务上代差是真实的。
  • 商用路线：火山引擎有 Doubao-1.5-UI-TARS 商用 API。其公开活动页的价格展示无法可靠对应到该模型，需在控制台确认，本报告不给数字。

Gemini 与 Claude：一个进了手机，一个还在桌面

如果目标 App 是英文的、或者你需要一家有全球 SLA 的供应商，那国际方案要单独看。这两家在手机这件事上的态度完全不同。

Gemini Computer Use ✅ 有移动环境

推荐 gemini-3.6-flash

  • 官方文档把环境分成三类：ENVIRONMENT_BROWSER、ENVIRONMENT_MOBILE、ENVIRONMENT_DESKTOP，其中移动环境标注为「Android-optimized environment actions」。
  • 移动环境自带 open_app 与 list_apps——这正好补上 GUI-Plus 那条需要你自己实现的 open。
  • 坐标归一化 0–999，「scaled to the height and width of the screen」，和 GUI-Plus 一样不需要你维护 scale factor。
  • 这是本次候选里，闭源国际大厂中唯一在官方文档层面把 Android 列为一等环境的。

Claude computer use ⚠️ 面向桌面

beta，需 computer-use-2025-11-24 header

  • 官方定义是「give Claude screenshot, mouse, and keyboard control of a desktop environment」，文档通篇没有移动或 Android 环境。
  • 坐标是绝对像素，且文档明确警告：不要依赖服务端自动降采样，否则你拿不到把坐标映射回真实屏幕所需的 scale factor，必须自己按 min(1568/长边, √(1150000/总像素)) 缩放后再乘回去。
  • 对手机竖屏这是实际代价：1080×2400 按此规则会被压到约 705×1568，宽度只剩 705px，小字与图标标签的识别余量明显变窄。
  • 有一个缓解手段：computer_20251124 开 enable_zoom 后，模型可以对指定区域调用 zoom 看全分辨率。能救小字，但每次 zoom 都是额外一轮往返，步数和成本都会涨。

你提到的视频流：别用在主循环上，但它有一个不可替代的位置

你的接口清单里有「界面视频流」，这是个比多数人手上多出来的能力。诚实的结论是： 本报告里所有模型的主推理循环都是「截图进、动作出」，视频流在主循环上用不到。 但学界在 2026 年恰好证明了截图循环有一类硬缺口，而那个缺口正好只有视频能补。

截图循环的隐含假设：两次动作之间世界是静止的

LivingScreen（2026-06） 专门做了个基准来打这个假设。它的原话是：现有环境「把屏幕当作离散的截图序列，世界在两次 agent 动作之间是冻结的」， 而短视频平台这类界面上内容会自动播放、持续变化。它把「看多久、以什么粒度看」提升成一等决策， 并指出主要失败模式是观测过度与观测不足。

实测结果值得记住：视频输入的 MLLM 里 Gemini-3.5 拿到 69.3 的成功率，人类是 94.0。 也就是说——即使给了视频，这类动态界面上模型离人类仍有 25 分的差距；但不给视频，纯截图路线在这类场景上连门都摸不到。

给你的具体建议：让视频流当「什么时候该截图」的裁判

主循环保持截图驱动（成本低、所有模型都吃这个）。把视频流用在三件截图判断不了的事上： ① 判断动画 / 转场 / 加载是否结束，从而决定何时截下一张图，而不是靠固定 sleep； ② 判断上一个动作到底有没有生效（点击有没有反馈、页面有没有真的滚动）； ③ 处理短视频、直播、游戏这类内容自己在变的界面。 这三件事都不需要把视频喂给大模型——用轻量的帧间差分就能做，成本几乎为零，却能显著减少「在加载中截图导致模型误判」这一类失败。

另有 OmniGUI 把观测状态正式定义成 (截图, 视频片段, 音频, 历史) 四元组，其中视频片段就是「上一个动作执行完到当前这一步之间的屏幕动态」。 这个形式化和上面的建议是同一个思路，说明这条路线在学界已经成形——只是还没有可直接调用的商用模型。

上生产之前必须知道的四件事

benchmark 分数和生产可靠性之间隔着很远。下面四条来自一手证据，不是推测。

  1. 规模化下，纯 agent 驱动不是最佳解

    Hacker News 上 Minicor（YC P26，做 Windows 桌面自动化）团队的一手经验： 「我们在 computer use / agentic 自动化上做了大量实验，发现规模化时最好的是混合方案——自动化以确定性代码运行，agent 负责异常恢复。 跑关键任务（比如更新病历）时，你不会希望 agent 有可能搞砸。」 对你的启发：稳定路径固化成脚本，让模型只在脚本走不通时接管。这既省 token 又提升成功率。

  2. 可逆与不可逆动作必须分开处理

    同样来自 HN（2026-07-16，Coasty 发布贴下）：「点来点去是一回事，提交表单、发消息、确认支付是另一回事—— 有没有机制让 agent 在这些动作前暂停并交回给人？」这是所有 computer-use 产品的共同缺口。 在你的执行层上做这件事比在模型侧容易得多：给触控接口加一层动作白名单/确认门，识别支付、发送、删除类目标区域。

  3. 屏幕上的一切都是不可信输入

    AgentRAE（2026-03）演示了针对截图型手机 agent 的后门攻击： 用看起来正常的通知图标作为触发器实现远程动作执行，在十种手机操作上攻击成功率超过 90%，并绕过了八种代表性防御。 这意味着一条推论：任何进入截图的第三方内容（推送、广告、他人发来的消息）都是潜在的指令注入面。 执行层要做的是限制动作范围，而不是指望模型自己识破。

  4. OS 级手机助手正在遭遇生态反制

    arXiv 2604.17817 记录了一个事实：字节的豆包手机助手部署在中兴努比亚原型机上、以特权屏幕级访问操作 App， 随即被广泛使用的 App 以安全与隐私为由快速限制、被迫收缩能力。 如果你的产品形态是面向终端用户的手机助手而非自有设备的自动化，这条监管/生态风险比技术风险更早到。

落地路径

按「先证伪、再投入」的顺序排，每一步都有明确的止损点。

  1. 零成本试水：通义 UI Agent 移动端链路

    文档标注限时免费，传截图 + 指令即可拿到动作。目标不是评估质量，而是用最低成本确认你的接口能被这类协议驱动。半天工作量。

  2. 打通主回路：GUI-Plus + 你的执行层

    用官方给的手机端 System Prompt，把八个动作映射到你的接口（对照表见 §3）。先在 3–5 个真实任务上跑通，记录每步 token 数，用图像 token 公式算出真实单任务成本。100 万免费额度足够这一阶段。

  3. 建自己的评测集，不要信榜单

    挑 20–30 个你实际要自动化的任务，人工标注成功判据。AndroidWorld 的分数换不来你的成功率——各家 harness 不同，且你的 App 大概率不在基准里。这一步做完，后面所有换模型的决策才有依据。

  4. 分叉决策：继续 API 还是转自部署

    触发转向的信号只有三个：并发撞上 100 RPM 上限、数据不能出内网、或者单任务成本超预算。任一成立才上 GUI-Owl-1.5（同源，迁移最平滑）或 Holo3.1（量化档全，本地最友好）。三个都不成立就别自找 GPU 运维的麻烦。

  5. 加固：确定性脚本 + agent 兜底 + 动作确认门

    把评测集里稳定通过的路径固化成脚本，模型只负责脚本失效时的恢复；同时给不可逆动作加确认门。这一步做完才谈得上「生产可用」。

证据与可信度分级

本报告刻意区分了三类来源。表格里的所有数字只用 A 级，B 级仅用于交叉印证，C 级只作为线索、结论不依赖它。

A 级 · 厂商一手 / 当日实测

B 级 · 同行评审论文与一手社区发言

C 级 · 不予采信的来源

  • 第三方 benchmark 聚合站给出的「AndroidWorld 榜单」：样本仅 5 个模型，且未标注 harness，无法与厂商口径对齐。
  • 声称「某框架在 AndroidWorld 达到 100% 成功率」的二手内容：未找到一手出处，与所有厂商一手数字（最高 79.3）严重矛盾。
  • AI 生成的 SEO 内容农场对模型价格与准确率的描述。本报告中所有价格均回到厂商定价页核对；Doubao-1.5-UI-TARS 因公开页无法可靠对应单价，故留空而非填入推测值。
采集偏差提示

这个品类在 2026 年迭代极快——本报告的候选里，最新的 Holo3.1 距今不到两个月，GUI-Plus 的当前版本是 2026-02-26。 任何超过半年的评价都可能已经失效，包括本报告本身。表格里的下载量与 star 是 2026-07-31 单日快照，反映的是存量而非趋势。