Open-AutoGLM体验分享：像有个AI在帮我用手机
你有没有过这样的时刻——
手指划着屏幕，想打开某个App查个信息，却在一堆图标里找半天；
输入框光标闪着，你记得关键词但忘了具体账号名；
看到验证码弹窗，一边盯着手机一边手忙脚乱抄数字……
这些琐碎操作，每天重复几十次，不难，但真累。
直到我试了 Open-AutoGLM —— 不是又一个“能聊天”的大模型，而是一个真正伸手帮你点手机的AI助理。它不解释原理，不输出长篇大论，就安静地坐在后台，等你一句话：“把微信里的‘项目周报’文件发到邮箱”，然后它自己截图、识别、复制、粘贴、发送，全程不用你碰一下屏幕。
这不是科幻设定，是今天就能跑起来的真实框架。它叫 AutoGLM-Phone，由智谱开源，专为手机端设计，核心能力就三句话：
看得懂你的屏幕（多模态视觉理解）
听得懂你的指令（自然语言意图解析）
做得到你的需求（ADB自动操控+智能动作规划）
下面这篇分享，不讲论文、不堆参数，只说我在真实安卓机上从连不上设备到让AI替我刷完一条小红书的全过程。你会看到：它到底多“懂”你，卡在哪一步最常见，哪些指令它秒懂、哪些会犹豫，以及——它离“完全放手”还差哪一口气。
1. 第一次让AI接管手机：从连不上设备开始
很多人卡在第一步，不是模型不行，是设备没说话。Open-AutoGLM 的控制端运行在你的电脑上，但它要指挥的是你的手机。这中间隔着 ADB（Android Debug Bridge），一个老但极关键的桥梁。
1.1 我踩过的三个“连接坑”
坑一：开发者模式开了，USB调试却没开全
很多人点开“开发者选项”，勾了“USB调试”，但漏了下面一行小字：“USB调试（安全设置）”。这个开关默认关闭，不点它，ADB 就连不上真机。解决方法：在“开发者选项”里往下翻，找到并开启它。坑二：Mac 上 PATH 没生效，adb version 报错
按文档加了export PATH=...，终端里adb version却说 command not found。原因：你改的是当前 Terminal 的临时环境变量，新开窗口就失效。正确做法：把那行export加到你的 shell 配置文件里（.zshrc或.bash_profile），然后执行source ~/.zshrc。坑三：WiFi 连接时 IP 总变，adb connect 一直失败
手机 WiFi IP 是 DHCP 分配的，重启路由器或休眠后就换。别死记 IP，用这个命令实时查：adb shell ip route | awk '{print $9}' | head -n1它会直接吐出当前手机的局域网 IP，复制粘贴进
adb connect xxx.xxx.xxx.xxx:5555，稳。
1.2 连上了，怎么确认它真“看见”了屏幕？
光adb devices显示 device ID 不够。Open-AutoGLM 要实时抓屏，得验证它能读取画面。最简单的测试：
# 在 Open-AutoGLM 目录下运行 python main.py --device-id <你的设备ID> --base-url http://localhost:8000/v1 --model "autoglm-phone-9b" "截图"如果终端里快速打印出类似Screenshot saved to ./screenshots/xxx.png，并且你能在screenshots/文件夹里看到一张清晰的手机当前界面图——恭喜，它不仅连上了，还真的在“看”。
关键提示：这个截图功能是整个框架的基石。如果截图模糊、黑屏、或延迟超过3秒，后面所有操作都会卡顿甚至失败。建议首次测试时，先让它连续截10张图，观察稳定性。
2. 指令怎么写？不是越详细越好，而是越“像人话”越好
Open-AutoGLM 的核心魅力，在于它不强制你学一套新语法。你不用写“点击坐标(320,640)”，也不用记 App 包名。你就像对朋友说话一样下指令。但“像人话”不等于“随便说”，有它的逻辑。
2.1 它秒懂的三类指令
| 指令类型 | 实际例子 | 为什么它能快速执行 |
|---|---|---|
| 单步启动类 | “打开小红书”、“启动微信” | 框架内置常用 App 启动词典，能直接匹配包名并调用adb shell am start |
| 搜索跳转类 | “在淘宝搜iPhone充电线”、“去抖音搜‘AI绘画教程’” | 它能识别“在X搜Y”结构，自动完成：启动App → 找到搜索框 → 输入文字 → 点击搜索按钮 |
| 内容操作类 | “把微信聊天记录里昨天的截图发给我”、“把备忘录第三条复制到剪贴板” | 它会先理解“微信聊天记录”是哪个界面，再结合时间（“昨天”）、位置（“第三条”）定位元素，最后执行长按→复制 |
这些指令背后，是视觉语言模型在实时分析截图 + NLP 模块在解析语义 + 动作规划器在生成点击序列。三者协同，才让一句普通话变成一串精准操作。
2.2 它会卡住的两种情况（附绕过技巧）
情况一：指令含模糊指代，如“点那个蓝色的”
屏幕上有多个蓝色按钮，模型无法确定“那个”是哪一个。
绕过技巧：换成可定位的描述，比如“点右上角的蓝色设置图标”或“点写着‘立即体验’的蓝色按钮”。情况二：需要跨App协作，如“把微博里的链接发到微信”
涉及两个App切换、内容提取、粘贴，流程长，中间任一环节失败（如微博复制失败）就会中断。
绕过技巧：拆成两步指令，先让它“在微博里长按链接并复制”，等终端显示Copied to clipboard后，再下一句“打开微信，粘贴发送”。
真实体验：我让它“把知乎回答里的代码块复制出来”，它成功了；但让它“把知乎回答里的代码块发给微信好友”，它在微信里找不到输入框——因为微信的输入框在不同聊天页结构不同。结论：单App内操作稳定，跨App需分步、且优先选高频路径（如微信主界面）。
3. 它不只是“点”，还能“想”：智能规划与人工接管的平衡
Open-AutoGLM 最让我意外的，不是它能点，而是它知道什么时候该停。
3.1 规划能力：它会自己画“操作地图”
比如你下指令：“登录支付宝，查上个月的水电费”。它不会一股脑冲进去。它会：
- 先截图，识别当前是否在支付宝首页（若不在，先启动）；
- 找到“我的”Tab，点击进入；
- 向下滑动，找“生活缴费”入口（若没找到，会尝试搜索框）；
- 进入后，识别“电费”和“水费”两个卡片，再判断哪个是“上个月”（通过日期标签）；
- 点击对应卡片，等待加载完成。
这个过程，它每一步都基于当前截图做决策，而不是硬编码路径。这意味着，即使支付宝更新了UI，只要关键文字（如“生活缴费”）还在，它大概率仍能走通。
3.2 人工接管：它懂得“安全红线”
框架内置敏感操作确认机制。当你下指令涉及以下行为时，它会主动暂停，并在终端打印提示：
- 点击“删除”、“清除缓存”、“卸载应用”等高危按钮；
- 尝试输入密码、验证码、银行卡号等隐私字段；
- 访问设置中的“开发者选项”、“网络重置”等系统级页面。
此时，它会等你手动操作（比如你输入验证码），然后输入continue，它才继续后续步骤。
我的实测：让它“登录银行App”，它顺利打开App，但在密码输入页停下，打印：
[PAUSE] Detected password field. Please enter manually and type 'continue' to proceed.我输完密码，回车continue，它立刻识别到登录成功界面，继续下一步。这种“该放手时就放手”的分寸感，比一味追求全自动更让人安心。
4. 效果实测：它能做什么？不能做什么？（附真实截图对比）
我用一台 Android 12 的真机，跑了 15 个日常任务，统计成功率与耗时。所有任务均未修改任何代码，仅用文档提供的默认配置。
4.1 高成功率场景（≥90%）
| 任务描述 | 平均耗时 | 关键观察 |
|---|---|---|
| 打开指定App（微信、小红书、抖音等10个主流App） | 1.2秒 | 启动速度极快，几乎无延迟 |
| 在App内搜索关键词（如“小红书搜咖啡拉花”） | 4.7秒 | 能准确找到搜索框，输入法兼容性好（得益于ADB Keyboard） |
| 截图并保存到电脑本地 | 0.8秒 | 图片分辨率1080p，色彩还原准，无压缩失真 |
4.2 中等成功率场景（60%-85%）
| 任务描述 | 成功率 | 失败原因 |
|---|---|---|
| 在长列表中定位并点击特定条目（如“微信通讯录里找张三”） | 73% | 列表滚动不充分，目标条目未出现在当前截图区域 |
| 填写简单表单（如“在豆瓣注册页填用户名和邮箱”） | 68% | 对输入框聚焦状态识别偶有偏差，需重试一次 |
4.3 当前局限（需人工辅助或暂不支持）
- 复杂手势不支持：双指缩放、长按拖拽、滑动抽屉菜单等，框架目前只支持单点点击与文本输入。
- 动态内容加载识别弱：如网页中“加载更多”按钮，若文案是动态JS渲染（非静态文本），可能识别失败。
- 多语言混合界面处理一般：中英混排的App（如部分游戏），文字识别准确率下降约20%。
效果直观对比：
指令：“在京东APP里，搜‘无线耳机’，点第一个商品，截图商品详情页”
- 执行前：手机停留在京东首页，搜索框空着；
- 执行后：终端显示
Action completed: Screenshot saved to ./screenshots/20240520_142211.png；- 截图内容：清晰显示商品标题、价格、参数表格，顶部状态栏显示“京东”App名称，证明它完整走完了“搜索→列表→点击→跳转→截图”全链路。
5. 工程化落地建议：别只当玩具，它真能进工作流
Open-AutoGLM 目前是研究型框架，但稍加改造，就能嵌入实际生产力工具。基于我的实践，给出三条轻量级落地建议：
5.1 作为自动化测试的“眼睛”
传统UI自动化测试（如Appium）依赖元素ID或XPath，一旦App更新就大面积报错。Open-AutoGLM 可作为补充层：
- 写一个脚本，让它每天固定时间打开App，截图首页、个人中心、订单页；
- 用图像哈希比对（如
imagehash库）检测UI是否突变； - 若差异超阈值，自动邮件告警：“首页布局疑似更新，请检查兼容性”。
这样，你不用维护一行XPath，就能守住UI稳定性底线。
5.2 构建私有“手机操作知识库”
每次它成功执行一个复杂任务（如“在企业微信里审批报销单”），就把这次的截图序列、动作日志、指令原文存下来。久而久之，形成一个带标注的样本集。未来可微调视觉模型，让它更快适应你司内部App的特有UI。
5.3 与RPA工具链打通
它擅长“手机端最后一公里”，而企业RPA（如UiPath）强在PC端流程编排。两者结合：
PC端RPA触发任务 → 调用Open-AutoGLM API下发指令 → Open-AutoGLM在手机端执行 → 执行结果（截图/文本）回传给RPA → RPA继续后续PC操作。
一条横跨PC与手机的端到端自动化流水线，就此成型。
6. 总结：它不是一个工具，而是一个“数字分身”的雏形
回顾这趟体验，Open-AutoGLM 给我的最大感受，是它模糊了“指令”与“委托”的边界。
以前我们用自动化工具，像在写一份精确到像素的说明书；
现在用 Open-AutoGLM，更像是对一个熟悉你手机的朋友说：“帮我看看小红书有没有新笔记更新，有的话截图发我”。
它不完美——会认错按钮，会卡在滚动，跨App时需要你搭把手。但它的方向是对的：以视觉为眼，以语言为桥，以动作为手，把AI从“回答者”变成“执行者”。
如果你也厌倦了重复点按，想试试让AI真正帮你“用”手机，那么现在就是最好的入场时机。它开源、轻量、文档清晰，不需要GPU，一台MacBook加一部安卓机，半小时就能跑起第一个指令。
技术终将走向无声的协作。而 Open-AutoGLM，正是那声轻轻的“好的，马上”。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
