Open-AutoGLM深度体验：视觉理解能力实测

1. 引言：从指令到执行的智能闭环

随着多模态大模型的发展，AI 正逐步突破“只能对话”的局限，向“能看会动”演进。Open-AutoGLM 是智谱 AI 开源的一款基于视觉语言模型（VLM）的手机端 AI Agent 框架，其核心目标是让 AI 能够像人类一样观察屏幕、理解界面、规划动作并自动执行操作。

用户只需输入一句自然语言指令，如“打开小红书搜索美食”，系统即可通过 ADB 自动完成一系列点击、滑动和输入操作，实现真正意义上的“动口不动手”。这一能力的背后，依赖于三大关键技术：

视觉理解：通过多模态模型解析手机截图，识别当前界面元素
意图与规划：将用户指令转化为可执行的任务流
自动化控制：利用 ADB 实现对设备的操作模拟

本文将围绕 Open-AutoGLM 的视觉理解能力进行深度实测，重点评估其在复杂 UI 场景下的感知准确性、语义理解能力和边界情况处理表现。

2. 技术架构与工作流程解析

2.1 系统整体架构

Open-AutoGLM 构建了一个完整的“感知—决策—执行”闭环系统，主要由以下模块组成：

ADB 控制层：负责设备连接、截图获取、触控指令下发
视觉语言模型（VLM）：接收屏幕图像 + 用户指令，输出结构化动作
任务规划引擎：维护状态机，判断是否需要继续交互或终止
安全确认机制：对支付、删除等敏感操作进行人工干预提示

整个流程如下：

用户指令 → 截图捕获 → 图文输入模型 → 动作预测 → ADB 执行 → 新界面 → 循环直至完成

2.2 视觉理解的核心机制

模型采用类似 Qwen-VL 或 LLaVA 的架构设计，具备强大的图文对齐能力。其输入为：

图像输入：当前手机屏幕截图（通常为 720×1440 左右）
文本输入：用户指令 + 历史上下文 + 系统 prompt

输出为 JSON 格式的动作指令，例如：

{"action": "Click", "element": "搜索框", "text": "美食"}

关键在于，模型不仅要“看到”按钮的位置，还要“理解”它的功能，并结合上下文做出合理决策。

3. 视觉理解能力实测方案

为了全面评估 Open-AutoGLM 的视觉理解性能，我们设计了五个典型测试场景，覆盖不同应用类型和界面复杂度。

3.1 测试环境配置

项目	配置
设备	Google Pixel 6 (Android 13)
运行方式	本地部署（vLLM + AutoGLM-Phone-9B）
模型路径	`zai-org/AutoGLM-Phone-9B`
推理框架	vLLM 0.4.2
显卡	NVIDIA RTX 3090 (24GB)
Python 版本	3.10.12

所有测试均使用 WiFi ADB 连接，确保无线远程控制稳定性。

3.2 测试用例设计

编号	应用	指令	关键挑战
T1	小红书	“打开小红书搜索‘露营装备推荐’”	文本输入 + 多标签页切换
T2	美团	“找一家评分4.8以上的人均50元以下的川菜馆”	数值条件理解 + 列表筛选
T3	微信	“给妈妈发消息：我到家了”	联系人识别 + 输入法切换
T4	淘宝	“搜索蓝牙耳机，按销量排序”	多步操作 + 排序控件定位
T5	设置	“关闭Wi-Fi和蓝牙”	系统级设置入口识别

每个测试重复运行 3 次，记录成功率、错误类型及耗时。

4. 实测结果分析

4.1 各场景执行情况汇总

测试编号	成功率	平均步数	主要问题
T1 小红书搜索	3/3 ✅	4	无
T2 美团找餐厅	2/3 ⚠️	6	第一次误判价格范围
T3 微信发消息	3/3 ✅	3	无
T4 淘宝排序	2/3 ⚠️	5	一次未识别“销量”按钮
T5 关闭设置	3/3 ✅	2	无

总体成功率为87%，表明模型在大多数常见任务中已具备较高可用性。

4.2 典型成功案例：T1 小红书搜索

用户指令：

“打开小红书搜索‘露营装备推荐’”

模型思考过程输出：

💭 当前界面：桌面 需要启动小红书 App 🎯 执行动作: {"action": "Launch", "app": "小红书"}

进入首页后：

💭 当前界面：小红书主页，底部有「首页」「消息」「发布」「我」四个标签 顶部有搜索框，提示“搜索内容与用户” 🎯 执行动作: {"action": "Click", "element": "搜索框"}

随后：

🎯 执行动作: {"action": "Type", "text": "露营装备推荐"} 🎯 执行动作: {"action": "Click", "element": "搜索"}

全程无需人工干预，准确率高，响应流畅。

4.3 边界案例分析：T2 美团数值理解偏差

首次失败原因分析：

用户指令包含两个数值条件：“评分4.8以上”、“人均50元以下”。

但模型第一次执行时仅关注“川菜馆”关键词，忽略了价格过滤条件，在列表页直接选择第一家店铺打开。

根本原因推测：

模型对复合数值条件的权重分配不足
当前界面未显示人均消费信息，导致无法有效筛选
缺乏“先打开筛选面板”的推理链

后续改进策略：

可通过优化 system prompt 提升模型对数值条件的重视程度，例如添加：

“当指令中出现价格、评分、距离等数值条件时，请优先调出筛选菜单进行设置。”

第二次和第三次测试中，加入该提示后任务顺利完成。

4.4 可视化理解能力评估

我们提取了几次关键操作中的截图与模型注意力热力图（通过 Grad-CAM 方法生成），发现模型具备较强的区域定位能力。

示例：淘宝“销量排序”按钮识别

真实位置：位于商品列表上方，“综合”右侧的“销量”文字按钮
模型注意力集中区域：准确聚焦于该按钮及其周边控件
误识别情况：有一次将“筛选”按钮误认为“销量”，可能因两者样式相近

这说明模型不仅依赖文本标签，也学习到了一定的 UI 布局规律。

5. 视觉理解的关键优势与局限

5.1 核心优势总结

✅ 多模态语义对齐能力强

模型能够将“搜索框”这样的抽象概念与具体 UI 元素精准匹配，即使图标无文字标注也能识别。

✅ 上下文记忆能力良好

在跨页面操作中（如从小红书主页跳转至搜索结果页），模型能记住原始任务目标，不会中途偏离。

✅ 支持中文输入与复杂表达

无论是“帮我订个火锅”还是“找离我最近的充电桩”，都能被正确解析为可执行动作。

5.2 当前存在的局限性

❌ 对动态加载内容响应滞后

当页面存在懒加载或无限滚动时，模型可能在内容未完全展示前就做出判断，导致点击空白区域。

❌ 小字体或低对比度文本识别困难

部分应用（如某些银行App）使用灰色细体字提示信息，模型容易忽略这些关键字段。

❌ 多同名元素区分能力弱

若页面出现多个“立即购买”按钮，模型难以判断应点击哪一个，需依赖额外上下文。

❌ 不支持非标准控件

对于自定义绘制组件（如游戏内UI、WebView中的H5按钮），由于缺乏语义标签，识别成功率显著下降。

6. 工程优化建议与实践技巧

6.1 提升视觉理解稳定性的方法

方法一：增强 system prompt 引导

修改phone_agent/config/prompts.py中的系统提示词，强化对关键条件的关注：

SYSTEM_PROMPT = """ 你是一个手机操作专家，请严格按照以下原则行动： 1. 如果指令中包含价格、评分、时间等数值条件，必须先找到并设置筛选项 2. 在点击前确认目标元素可见且可交互 3. 若连续两次操作失败，尝试返回上一级重新开始 """

方法二：增加截图预处理

在传入模型前，可对截图进行增强处理：

调整亮度与对比度，提升可读性
添加边框标注，突出按钮区域
OCR 辅助提取文本，作为额外输入特征

方法三：引入动作验证机制

每次执行后增加“预期结果验证”步骤，例如：

if action == "Launch" and app == "小红书": expected_elements = ["搜索框", "首页", "消息"] if not check_elements_on_screen(expected_elements): retry()

6.2 敏感操作的安全控制

尽管 Open-AutoGLM 内置了确认机制，但在实际使用中仍建议启用自定义回调函数：

def safety_check(message: str) -> bool: sensitive_keywords = ["支付", "转账", "删除", "注销"] if any(kw in message for kw in sensitive_keywords): print(f"\n⚠️ 危险操作预警：{message}") return input("继续执行？(y/n): ").lower() == 'y' return True agent = PhoneAgent( model_config=model_config, confirmation_callback=safety_check )

这样可以在关键时刻阻止潜在风险行为。