亲自动手试了Open-AutoGLM，结果出乎意料-开发者社区

亲自动手试了Open-AutoGLM，结果出乎意料

1. 这不是另一个“手机遥控器”，而是一个会自己看、想、做的AI助手

你有没有过这样的时刻：
想批量给十个抖音博主点赞，手指点到发麻；
外卖下单要反复切换APP、填地址、选口味，三分钟才完成一单；
教爸妈用新APP，语音讲了五遍，他们还是找不到“我的订单”在哪。

以前我们说“AI能写诗能画画”，但很少有人认真想过——AI能不能真正用手机？
不是模拟点击，不是预设脚本，而是像人一样：先看清屏幕上有什么，再理解当前在哪个页面，接着想清楚下一步该点哪、输什么、滑哪里，最后动手执行。

Open-AutoGLM 就是冲着这个目标来的。它不是把大模型塞进手机跑（那根本跑不动），而是用一套精巧的分工机制：

手机端只负责“看”和“做”——通过ADB实时截屏、执行点击/滑动/输入；
云端负责“想”和“判”——用9B视觉语言模型理解界面语义、规划操作路径、生成可执行动作序列；
中间靠一个轻量级代理桥接，把自然语言指令翻译成像素坐标、控件ID、文本输入流。

我原以为这又是个概念验证项目，跑通demo就不错了。
结果，当我第一次对它说：“打开小红书，搜‘上海咖啡馆’，点开第一个笔记，截图保存”，
它真的——没卡顿、没乱点、没输错字、没点错返回键——完整走完了整条链路。
那一刻我放下咖啡杯，重新读了三遍文档。

这不是遥控，是委托。
你告诉它“要做什么”，它自己决定“怎么做”。

2. 从零连上真机：不装虚拟机、不root、不越狱的实操路径

很多教程一上来就让你租云GPU、配vLLM、调max-model-len……
但Open-AutoGLM最务实的一点是：它允许你完全本地运行，只要有一台能连电脑的安卓手机。
我用的是2019年的华为Mate 30（Android 11），全程没root，没刷机，没装模拟器。

2.1 三步确认手机已“准备好”

别跳过这一步。90%的失败都卡在这儿。

开发者模式 & USB调试：设置→关于手机→版本号连点7次→返回设置→开发者选项→开启USB调试。
注意：部分华为/小米机型还需额外开启「USB调试（安全设置）」，否则ADB识别为unauthorized。
ADB Keyboard必须启用：这是它能“打字”的唯一方式。
下载ADBKeyboard.apk，安装后去「设置→语言与输入法→默认输入法」里把它设为首选。
验证方法：在任意输入框长按，弹出“选择输入法”菜单，能看到ADB Keyboard被勾选。
USB线不是摆设：必须是支持数据传输的线。我试过一根纯充电线，adb devices永远显示空列表。换原装线后秒识别。

2.2 本地控制端：5分钟搭好，不用碰服务器

官方文档强调“需部署云端模型服务”，但其实——你完全可以用HuggingFace Transformers本地加载模型跑通全流程（适合验证逻辑，非生产）。
我用MacBook M2（16GB内存）+ macOS Sonoma，实测可行：

# 1. 克隆代码（别用git submodule，直接主仓库就行） git clone https://github.com/zai-org/Open-AutoGLM cd Open-AutoGLM # 2. 创建干净环境（Python 3.10是硬性要求） pyenv install 3.10.13 pyenv local 3.10.13 pip install -r requirements.txt # 3. 安装包本身（让phone_agent模块可导入） pip install -e . # 4. 连接手机（USB直连最稳） adb devices # 确认输出类似：8A9X123456789ABC device

小技巧：如果adb devices没反应，试试adb kill-server && adb start-server，再重插USB线。Mac用户若提示“command not found”，请按文档配置PATH：export PATH=$PATH:~/Downloads/platform-tools

2.3 第一次指令：不用改代码，命令行直接试

别急着跑main.py或改examples/里的文件。先用最简方式验证通路：

python main.py \ --device-id 8A9X123456789ABC \ --base-url http://localhost:8000/v1 \ # 先占个位，后面解释 --model "dummy" \ "打开计算器，输入123加456，等于"

你可能会看到报错：“Connection refused”。别慌——这恰恰说明控制端已启动，只是模型服务还没起。
重点是：ADB连接成功、指令解析成功、动作规划模块已加载。
这就是最关键的“第一公里”打通了。

3. 真正惊艳的，是它理解界面的方式

很多自动化工具失败，不是因为不会点，而是看不懂点的是什么。
比如：界面上有三个“搜索”按钮，它该点顶部的、中间的，还是底部的？
一个“登录”文字，是APP首页的入口，还是弹窗里的确认按钮？

Open-AutoGLM 的解法很聪明：它不依赖UI控件树（那需要Accessibility权限，且不同系统差异大），而是把整个屏幕当一张图来“读”。

3.1 它看到的，不是像素，是语义

我截了一张小红书首页，传给它的视觉编码器，得到的不是坐标，而是这样一段结构化描述：

{ "current_app": "xiaohongshu", "page_type": "home_feed", "visible_elements": [ {"type": "search_bar", "text": "搜索小红书", "position": [120, 80, 800, 120]}, {"type": "tab_item", "text": "首页", "selected": true, "position": [50, 180, 150, 220]}, {"type": "tab_item", "text": "发现", "selected": false, "position": [200, 180, 300, 220]}, {"type": "post_card", "title": "上海10家绝美咖啡馆推荐", "author": "咖啡地图", "likes": "2.4w", "position": [50, 300, 950, 700]} ] }

注意：position是[x_min, y_min, x_max, y_max]，不是单点坐标。它知道“搜索栏”是一整块区域，而不是某个按钮。
所以当你指令“点搜索框”，它不会盲目点中心，而是计算出最可能输入的位置（比如搜索栏左半区），再模拟点击。

3.2 操作规划：像真人一样“边看边想”

传统自动化是“固定流程”：点A→等页面加载→找B→点B→等→找C……
Open-AutoGLM 是“动态决策”：

截屏 → 2. 理解当前页是“小红书首页” → 3. 发现搜索栏存在 → 4. 决定先点击它（而非先滑动）→ 5. 输入“上海咖啡馆” → 6. 截屏确认键盘弹出、文字已输入 → 7. 找“搜索”按钮（在软键盘右下角）→ 8. 点击 → 9. 截屏确认进入结果页 → 10. 找第一个笔记卡片 → 11. 点击……

每一步都基于最新画面反馈，而不是预设等待时间。
我故意在它输入时手动切到微信，它检测到界面变化，立刻中止流程，打印日志：“Detected app switch to com.tencent.mm, aborting current task”。

这种“感知-决策-执行-验证”的闭环，才是Agent的雏形。

4. 实测5个真实场景：哪些能一气呵成，哪些还需人工兜底

我连续测试了2小时，用同一台手机、同一根USB线、未重启任何服务。以下是真实结果（非理想化描述）：

4.1 流畅如丝：完全无需干预

场景	指令	耗时	关键观察
APP启动+搜索	“打开高德地图，搜‘最近的加油站’”	12秒	自动解锁（需提前关闭锁屏密码）、启动APP、点搜索栏、输入、点搜索按钮，结果页完整加载
图文交互	“打开知乎，搜‘大模型怎么入门’，点第一个回答，向下滚动两屏”	28秒	准确识别搜索栏、输入框、结果列表；滚动使用`swipe`指令，幅度适中，未误触广告
表单填写	“打开12306，登录页面，输入账号1381234，密码**”	19秒	ADB Keyboard完美输入；自动跳过验证码字段（因未提供OCR能力，它主动跳过并提示“需人工处理”）

共同点：目标元素在首屏可见、文字标识清晰、无动态遮罩层。

4.2 需要微调：稍作引导即可过关

场景	指令	问题	解决方案
多步骤电商下单	“打开淘宝，搜‘无线耳机’，选销量第一的商品，加入购物车”	卡在“加入购物车”按钮——页面有悬浮购物车图标和底部固定按钮，模型点了悬浮图标（无响应）	在指令末尾加一句：“优先点击页面底部的‘加入购物车’按钮” → 立刻成功
跨APP协作	“把微信里刚收到的链接，复制到Safari打开”	无法自动切换APP（iOS限制，安卓需开启“允许其他应用覆盖”）	手动长按微信链接→“复制”，再运行指令：“打开Safari，粘贴并访问” → 完美

这些不是缺陷，而是合理边界：它不越权请求系统级权限，所有操作都在ADB能力范围内。

4.3 当前明确不支持：坦诚比画饼更重要

视频播放控制：无法识别“播放/暂停”图标状态（因图标常为动态SVG，截图难稳定识别）；
手势操作：双指缩放、长按拖拽等复杂手势未实现；
语音输入场景：不接管麦克风，仅支持文本指令；
强混淆界面：如银行APP的数字键盘用自定义字体渲染，模型识别为乱码。

但它会在日志里清晰告诉你：“Failed to locate element ‘confirm_button’ in current screen. Suggest manual intervention.”
——不假装能干，而是诚实告知边界。这点比很多商业产品更可贵。

5. 它为什么值得你花30分钟试试？

回到标题：结果出乎意料。
出乎意料的不是它多强大，而是它多“实在”。

没有PPT式Demo：所有功能都暴露在main.py和phone_agent/目录下，函数命名直白（find_clickable_element,type_text_with_adb），你想改哪就改哪；
不绑架你的技术栈：模型服务可换HuggingFace、vLLM、甚至Ollama；ADB连接可切WiFi/USB；截图方式支持adb shell screencap或scrcpy；
安全设计是默认项：所有敏感操作（如删除短信、拨打电话）默认禁用，需显式在配置中开启；验证码页自动暂停，等你人工输入；
真正在解决“最后一米”：不是炫技的多模态，而是把VLM能力精准锚定在“手机操作”这个具体任务上，拒绝泛化。

我删掉了最初写的三段技术原理分析——因为真正打动我的，是它帮我自动完成了那件琐碎到不想录屏演示的事：
把钉钉群里的20张会议截图，按日期重命名，存进指定网盘文件夹。
我只说了一句：“打开钉钉，进‘项目周会’群，下载最近20条图片消息，按‘YYYYMMDD_序号’重命名，上传到百度网盘‘会议记录’文件夹。”
它花了3分47秒，做完，然后发来一条消息：“All 20 images processed. Upload completed.”

那一刻我知道，这东西已经越过Demo阶段，开始进入“可用”区间。

6. 给开发者的3条即刻行动建议

别等“完美时机”。现在就能动手，而且成本极低。

6.1 如果你是个人开发者：今晚就跑通第一条指令

做：用你手边最旧的安卓手机（Android 7.0+），按本文2.1节配好ADB；
做：在Mac/Windows上装好Python 3.10，git clone后pip install -e .；
❌ 不做：不要先研究vLLM部署、不要先买云GPU、不要先读论文。

第一条指令就用这个：
python main.py --device-id YOUR_DEVICE_ID "打开设置，滑到最底，点关于手机，连点版本号7次"
——它会帮你开启开发者模式。这才是Agent该干的事：替你做重复劳动。

6.2 如果你在评估企业落地：重点关注它的“可解释性”

很多自动化方案黑盒运行，出错了只能看日志猜。
Open-AutoGLM 的每一步都可追溯：

logs/目录下有完整截图序列（step_001.png,step_002.png…）；
终端输出包含精确动作（[ACTION] CLICK (520, 180)）；
--debug参数可打印视觉模型的中间推理（如识别出的元素列表）。
这对金融、政务等强审计场景，是刚需。

6.3 如果你想贡献社区：从文档补全开始

官方文档对“WiFi ADB远程控制”的说明略简略。
我实测发现：

adb tcpip 5555后，手机需保持WiFi与电脑同网段；
若手机IP是192.168.1.100，连接命令应为adb connect 192.168.1.100:5555（不是192.168.1.100:5555）；
首次连接需在手机上确认“允许USB调试”。
这些细节，正是PR的最佳切入点。