实测Open-AutoGLM的多模态能力，在真实界面表现如何

实测Open-AutoGLM的多模态能力，在真实界面表现如何

你有没有试过一边做饭一边想点个外卖，结果手油乎乎没法摸手机？或者深夜刷短视频，突然看到一条“打开小红书搜美食”的弹幕，手指已经抬起来了，却卡在要不要切APP的犹豫里？这些微小的“操作摩擦”，正在被一种新东西悄悄抹平——不是语音助手，不是快捷指令，而是一个能真正“看见”你手机屏幕、理解你话里意思、还能自己点按滑动的AI代理。

Open-AutoGLM 就是这样一个框架。它不只说“我懂”，而是真动手；不靠预设脚本，而是靠视觉+语言+规划三重能力实时理解界面、拆解任务、执行动作。今天，我们不讲原理、不跑通流程，就用一台真机、一个日常场景、一句大白话指令，把它拉进真实世界里跑一跑：它到底能不能在纷乱的APP界面中认出按钮？能不能在弹窗、广告、加载动画之间不迷路？能不能把“帮我点个麦当劳巨无霸”这种模糊需求，变成精准点击“美团→搜索框→输入‘巨无霸’→选门店→加购→去结算”的一连串动作？

下面这场实测，没有滤镜，没有剪辑加速，所有延迟、误判、人工接管都原样呈现。我们关心的不是“理论上能做什么”，而是“此刻在你手上这台手机里，它稳不稳、快不快、像不像个靠谱的数字同事”。

1. 真机环境准备：从零到可操控，三步到位

别被“多模态”“Agent”这些词吓住——Open-AutoGLM 的控制端运行在你的电脑上，它只是借你手机的“眼睛”（截图）和“手指”（ADB），真正干活的是云端部署的 autoglm-phone-9b 模型。所以本地要做的，其实很轻量。

1.1 手机端：开开关、装工具、配输入法

这三步必须做对，否则AI再聪明也“睁眼瞎”：

• 开启开发者选项：设置 → 关于手机 → 连续点击“版本号”7次，直到弹出“您现在是开发者”的提示；
• 启用USB调试：设置 → 系统与更新 → 开发者选项 → 打开“USB调试”开关；
• 安装并启用 ADB Keyboard：这是关键一步。它让AI能通过命令直接输入文字，而不是依赖模拟点击。下载 APK 安装后，进入手机“设置 → 语言与输入法 → 当前输入法”，手动切换为“ADB Keyboard”。如果跳过这步，遇到需要打字的场景（比如搜索框），AI会卡住或报错。

小贴士：很多用户反馈“明明装了ADB Keyboard却检测失败”，这不是模型问题，而是系统输入法列表缓存未刷新。重启手机或手动在输入法管理中“停用再启用”一次，基本就能解决。

1.2 电脑端：ADB 配好，连接即用

Windows 和 macOS 用户只需确认一件事：adb devices命令能列出你的设备。

• Windows 用户：下载 platform-tools 后，把解压路径加入系统环境变量 Path，然后命令行输入adb version，看到版本号即成功；
• macOS 用户：终端执行export PATH=${PATH}:~/Downloads/platform-tools（路径按实际调整），再运行adb version验证。

连接方式有两种，我们实测下来更推荐 USB 直连：

• USB 连接：手机用数据线连电脑 → 手机弹出“允许USB调试吗？”点确定 → 终端执行adb devices，输出类似0123456789ABCDEF device即表示已识别；
• WiFi 连接：需先 USB 连接一次执行adb tcpip 5555，拔掉线后执行adb connect 192.168.x.x:5555（x.x 为你手机局域网IP）。但实测中 WiFi 偶尔掉线，导致操作中断，日常测试建议优先用 USB。

1.3 控制端部署：克隆、安装、验证

一切就绪后，本地只需三行命令：

git clone https://github.com/zai-org/Open-AutoGLM cd Open-AutoGLM pip install -r requirements.txt && pip install -e .

安装完成后，用官方提供的检查脚本快速验证通信链路是否畅通：

python scripts/check_deployment_cn.py --base-url http://你的云服务器IP:8000/v1 --model autoglm-phone-9b

如果返回{"status": "success", "message": "Model is ready"}，说明模型服务、网络通路、认证配置全部 OK。此时，你离“动口不动手”只剩一句指令的距离。

2. 首轮实测：从“打开抖音”看多模态理解力

我们没选最复杂的任务开场，而是用一句最基础的指令：“打开抖音搜索抖音号为：dycwo11nt61d 的博主并关注他！”

为什么选它？因为这句话里藏着三个典型挑战：

• 意图解析：AI要区分“打开抖音”是启动APP，“搜索抖音号”是进入搜索页，“关注”是进入个人主页后的操作；
• 界面定位：抖音首页有Tab栏、推荐流、搜索图标；搜索页有输入框、历史记录、热门推荐；个人主页有“关注”按钮、头像、简介——它得在正确页面找到正确元素；
• 动作泛化：不同版本抖音UI略有差异，按钮位置、文案、图标可能变化，AI不能死记硬背坐标。

执行命令如下（请替换为你的设备ID和服务器地址）：

python main.py \ --device-id 0123456789ABCDEF \ --base-url http://10.1.21.133:8000/v1 \ --model "autoglm-phone-9b" \ "打开抖音搜索抖音号为：dycwo11nt61d 的博主并关注他！"

2.1 实际过程还原：慢，但每一步都可解释

整个流程耗时约 48 秒，分五阶段：

1. 截图采集（3秒）：AI调用adb shell screencap截取当前屏幕，传给视觉模型；
2. 界面理解（8秒）：模型分析截图，识别出“抖音”图标在桌面第一页第二行，标注置信度 92%；
3. 动作规划（5秒）：生成操作序列：①点击抖音图标 → ②等待APP启动完成（检测“搜索”图标出现）→ ③点击搜索图标 → ④点击输入框 → ⑤输入“dycwo11nt61d” → ⑥点击搜索结果第一项 → ⑦等待个人主页加载 → ⑧点击“关注”按钮；
4. 执行与校验（27秒）：逐条执行，每次点击后自动截图比对。在“点击搜索图标”后，因抖音首页顶部有横幅广告遮挡，AI多等了 4 秒才确认图标完全可见；在“点击关注”前，检测到按钮文案是“已关注”，主动跳过，避免重复操作；
5. 任务完成（5秒）：最终截图显示“已关注”状态，返回 success。

关键观察：它没有因为广告遮挡就乱点，也没有在“已关注”状态下强行再点一次。它的“犹豫”不是卡顿，而是基于视觉反馈的主动判断——这才是多模态Agent和脚本自动化最本质的区别。

2.2 效果对比：和纯文本Agent的差距在哪？

我们同步用同一台手机、同一句指令，测试了一个仅依赖APP包名启动+固定坐标点击的传统方案：

结论很清晰：多模态能力不是锦上添花，而是从“能启动”升级到“能导航”的分水岭。

3. 进阶实测：在美团点单，考验复杂流程拆解能力

如果说抖音测试考的是“单页面精准识别”，那么美团点单就是一场“跨页面、多状态、强交互”的综合考试。指令是：“在美团上点个麦当劳巨无霸”。

这句话的模糊性极强——它没说哪家店、没说是否自提、没说加不加薯条。AI必须自行补全逻辑：先找最近的麦当劳门店 → 进入店铺 → 找“巨无霸”商品 → 加入购物车 → 结算。

我们全程录屏，截取三个关键节点：

3.1 节点一：首页识别与入口选择

美团首页信息密度极高：顶部Banner、中部“附近”Tab、下方“美食”“酒店”等分类图标、右侧悬浮“我的订单”。AI没有盲目点击“美食”，而是先分析截图，发现“附近”Tab下有高亮的“麦当劳”商家卡片（置信度87%），于是直接点击该卡片进入店铺列表。

这说明它不是机械匹配关键词，而是结合视觉显著性（高亮色块）+语义关联（“麦当劳”在“附近”区域）做联合决策。

3.2 节点二：菜单页商品定位与筛选

进入麦当劳店铺后，页面滚动展示数十个商品：汉堡、薯条、饮料、套餐。AI没有逐个滑动查找，而是调用OCR识别商品标题，快速定位到“巨无霸套餐”（含“巨无霸”字样且价格区间符合预期），并点击进入详情页。

这里有个细节：详情页有“单点”和“套餐”两个Tab，AI选择了“套餐”，因为指令中“点个巨无霸”更符合套餐消费场景，而非单点汉堡。这种常识推理，远超简单关键词匹配。

3.3 节点三：结算页异常处理与人工接管

在结算页，页面弹出“选择配送方式”弹窗，包含“美团专送”“到店自取”“预约送达”三个选项。AI识别到这是非标准流程，且模型训练数据中未覆盖该弹窗结构，于是触发内置机制：暂停执行，向控制台输出提示：

[INFO] Detected unhandled UI element: "选择配送方式" dialog. Please select option manually or confirm to proceed with default (Meituan Express). Type '1' for Meituan Express, '2' for Pickup, '3' to abort.

我们输入1，AI继续执行下单。整个过程没有崩溃、没有乱点，而是把“不确定”转化为“可协作”。

这正是 Phone Agent 设计的聪明之处：它不追求100%全自动，而是把人类最擅长的“临门一脚”决策权留给你，既保证安全，又不牺牲体验。

4. 真实体验总结：它不是万能遥控器，而是值得托付的数字同事

经过十余次不同指令测试（从“打开微信发消息给张三”到“在淘宝找红色连衣裙并加入收藏”），我们对 Open-AutoGLM 的真实能力边界有了清晰认知：

4.1 它真正擅长的三件事

• 跨APP导航：在桌面→抖音→搜索页→个人主页的链路中，准确率超90%，远高于依赖包名跳转的传统方案；
• 动态元素识别：对按钮、输入框、图标等UI组件的识别不依赖固定坐标，能适应不同分辨率、主题色、版本迭代；
• 模糊意图补全：面对“点个巨无霸”“搜美食”这类口语化指令，能结合上下文（当前APP、地理位置、历史行为）合理补全省略信息。

4.2 它当前的局限也很实在

• 强干扰界面易误判：如抖音首页的全屏开屏广告、美团闪促弹窗，会导致截图分析延迟3–5秒，偶尔需人工干预；
• 长文本输入稳定性待提升：在需要输入10字以上搜索词时，ADB Keyboard偶发漏字，建议指令中搜索词控制在8字内；
• 多任务并行不支持：一次只能执行一条指令，无法同时处理“发微信+点外卖+查天气”三个请求。

4.3 一句话评价：它让AI从“回答者”变成了“执行者”

过去我们用大模型，是问它“怎么点外卖”，它告诉你步骤；现在用 Open-AutoGLM，是你告诉它“点个巨无霸”，它真的去点。这个转变看似微小，实则重构了人机关系——我们不再需要翻译需求，AI也不再只输出文字，而是共享同一个操作界面，共同完成一件具体的事。

它不完美，但足够真实；它不炫技，但足够实用。当你在厨房手忙脚乱时，它可能是那个默默帮你点好外卖的同事；当你在地铁上想查资料又不想解锁手机，它可能是那个替你划开屏幕、输入关键词的助手。

技术的价值，从来不在参数多高，而在它是否愿意蹲下来，帮你解决那个“懒得动手指”的瞬间。

5. 下一步：你可以这样开始自己的实测

如果你也想亲手试试这个能“看会动”的AI，不需要GPU服务器，不需要安卓开发经验，只需四步：

1. 准备一台安卓手机（Android 7.0+）和一台电脑（Win/macOS）；
2. 按本文 1.1–1.2 节配置好 ADB 和手机调试环境；
3. 在云服务器或本地机器部署 autoglm-phone-9b 模型（参考前序博文）；
4. 克隆 Open-AutoGLM 仓库，运行python main.py，输入你的第一句自然语言指令。

别追求一步到位。先从“打开小红书”开始，看它能不能准确找到图标；再试“搜索咖啡”，看它能否唤起输入法；最后挑战“点一杯瑞幸拿铁”，观察它如何在复杂流程中做决策。

真正的智能，不在它多快，而在它多懂你；不在它多全能，而在它多愿意陪你一起把事情做完。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。