2026年4月22日 · 阅读 —
GUI-Owl 1.5：让 AI 直接操控你的桌面，UI 自动化测试的新选择
GUI-Owl 1.5：本地部署，直接用于 UI 自动化测试
最近在找能做 UI 自动化的模型，发现了阿里 mPLUG 团队出的 GUI-Owl 1.5。这个模型的特点很直接：原生就是做 GUI Agent 的，支持多平台，而且可以本地部署。
先给个结论
可行。特别是如果你已经在做 UI 自动化测试、或者在搞 AI Agent 操控桌面/移动端，这个模型值得一试。
什么是 GUI-Owl 1.5
简单说，这是一个多模态 GUI Agent 模型家族，基于 Qwen3-VL 构建。
它能做的事：
- 看屏幕截图
- 理解界面元素
- 生成操作（点击、输入、滑动等）
- 支持桌面端、移动端、浏览器
关键是，这不是一个「只能看不能动」的视觉模型，而是从设计之初就奔着端到端操控 GUI 去的。
模型选择：从 2B 到 32B，丰俭由人
GUI-Owl 1.5 提供了完整的模型谱系，你可以根据自己的硬件和场景选：
| 模型 | 参数量 | 特点 | 适合场景 |
|---|---|---|---|
| GUI-Owl-1.5-2B-Instruct | 2B | 轻量，推理快 | 边缘部署、简单任务 |
| GUI-Owl-1.5-4B-Instruct | 4B | 平衡 | 大部分本地场景 |
| GUI-Owl-1.5-8B-Instruct | 8B | 综合能力强 | 推荐主力使用 |
| GUI-Owl-1.5-8B-Thinking | 8B | 带思考/规划 | 复杂任务 |
| GUI-Owl-1.5-32B-Instruct | 32B | 能力最强 | 不差钱/不差算力 |
| GUI-Owl-1.5-32B-Thinking | 32B | 最强思考版 | 超复杂任务 |
对 UI 自动化测试来说，8B-Instruct 是比较稳妥的起点——性能够用，部署门槛也不高。
性能如何？直接看基准测试结果
官方给出的性能数据（部分）：
| 基准测试 | 2B-Instruct | 8B-Instruct | 8B-Thinking | 32B-Instruct |
|---|---|---|---|---|
| OSWorld-Verified | 43.5 | 52.3 | 52.9 | 56.5 |
| AndroidWorld | 67.9 | 69.0 | 71.6 | 69.4 |
| OSWorld-MCP | 33.0 | 41.8 | 38.8 | 47.6 |
| Mobile-World | 31.3 | 41.8 | 33.3 | 46.8 |
| WindowsAA | 25.8 | 31.7 | 35.1 | 44.8 |
| WebArena | - | 45.7 | 46.7 | - |
| VisualWebArena | - | 39.4 | 40.8 | - |
| WebVoyager | - | 69.9 | 78.1 | - |
注意几个点：
- 在 AndroidWorld 上，即使 2B 版本也能到 67.9，说明移动端适配做得不错
- Thinking 版本在需要规划的任务上（如 WebVoyager）明显更强
- 整体是 SOTA 水平，在多个榜单上排在前面
核心能力：这几点对 UI 测试很重要
1. 多平台支持
- 桌面（Windows/macOS/Linux）
- 移动端（Android）
- 浏览器
- 不用为不同平台换模型
2. 原生支持工具调用 & MCP
- 可以直接调用外部工具
- 支持 MCP（Model Context Protocol）服务协调
- 这意味着你可以把它和现有的测试工具链结合
3. 内置长时记忆
- 不需要外部工作流编排
- 在 MemGUI-Bench 上领先所有原生 Agent 模型
- 长流程测试不用自己记中间状态
4. 多 Agent 就绪
- 可以独立用，也可以在 Mobile-Agent-v3.5 框架里扮演不同角色
- Planner（规划者）、Executor（执行者）、Verifier（验证者）、Notetaker（记录者）
- 适合复杂测试场景拆分
本地部署思路
虽然我没把完整仓库拉下来，但从 Hugging Face 页面和 GitHub 仓库结构来看，部署路径应该是：
- 去 Hugging Face 下模型：
mPLUG/GUI-Owl-1.5-2B-Instruct（或你选的版本） - 用 Transformers 或 vLLM 加载
- 结合截图输入 + 操作输出
GitHub 仓库在 X-PLUG/MobileAgent，里面应该有 Mobile-Agent-v3.5 目录，包含完整的运行代码。
怎么把它用在 UI 自动化测试上？
一个典型的测试流程可以是：
graph LR
A[测试需求] --> B[截图当前界面]
B --> C[输入模型：在这个界面上完成XX操作]
C --> D[模型输出：点击坐标/输入文本/滑动]
D --> E[执行操作]
E --> F[再次截图验证]
F --> G[判断是否通过]对测试工程师来说，这个模型的价值在于：
- 可以用自然语言描述测试用例，不用写大量选择器
- 对界面变化的鲁棒性更强（毕竟是看截图，不是看 DOM）
- 可以处理更复杂的、需要推理的测试流程
注意事项
- 这不是零代码解决方案——你还是需要写代码把模型和你的测试环境连起来
- 计算资源——8B 模型最好有 16GB+ 显存，32B 就得上 A100 之类的了
- 稳定性——Agent 模型做测试，依然会有「抽风」的时候，需要做结果校验
- 成本——如果用云端部署，长期跑测试成本不低，本地部署更划算
总结
GUI-Owl 1.5 是一个专门为 GUI 操控设计的模型家族，从 2B 到 32B 都有，支持多平台，性能是当前 SOTA 级别。
对 UI 自动化测试来说，这是一个很有潜力的方向：
- 如果你已经在做传统的 UI 自动化，可以用它来补充
- 如果你在探索 AI 驱动的测试，这个模型值得入手
- 本地部署可行，数据隐私可控
建议先从 8B-Instruct 版本开始试，成本不高，效果应该会让你惊喜。