用Open-AutoGLM做了个自动刷抖音项目，全过程分享-洪萨配资

用Open-AutoGLM做了个自动刷抖音项目，全过程分享

最近在技术圈看到一个让人眼前一亮的项目：Open-AutoGLM。它不是又一个“调API写提示词”的玩具，而是一个真正能看懂手机屏幕、理解界面元素、并动手点击滑动的AI手机助理。我决定不只看看热闹，而是亲手把它跑起来——目标很明确：让AI自动打开抖音，搜索指定博主，进入主页，完成关注。整个过程不碰手机，全靠一行命令驱动。

这不是概念演示，也不是实验室里的Demo，而是我在自己电脑上实打实跑通的完整链路。过程中踩了坑、改了代码、调了参数，也看到了它真实的能力边界。下面我把从零到落地的每一步都拆解清楚，不省略任何细节，包括那些文档里没写的“潜规则”。

1. 先搞明白它到底是什么：不是大模型，是能动手的AI代理

很多人第一眼看到“Open-AutoGLM”，会下意识以为这是个新语言模型。其实不然。它的核心身份是Phone Agent——一个运行在电脑端的AI代理框架，背后调用的是智谱开源的视觉语言模型 autoglm-phone-9b。

关键区别在于：

普通大模型只能“说”，它还能“看”和“做”。
它通过ADB实时抓取手机屏幕截图，送入视觉语言模型理解当前界面（比如：“这是一个抖音首页，底部有‘首页’‘发现’‘同城’三个Tab，中间是视频流，右上角有搜索图标”）。
理解之后，它不是输出一段文字，而是生成一系列可执行的ADB指令（如：adb shell input tap 500 1200），再自动下发执行。
整个过程形成闭环：看 → 想 → 做 → 再看 → 再想 → 再做……直到任务完成。

所以，它本质上是一个多模态感知 + 任务规划 + 自动化执行的三层系统。你给它的是一句人话，它还你的是真实的手机操作。

这解释了为什么它能绕过APP的反自动化机制——它不注入脚本、不模拟触摸事件底层协议，而是像真人一样，用系统级的ADB命令去点击、滑动、输入。微信封禁的是“模拟点击工具”，但很难封禁“一个正在用ADB调试自己手机的开发者”。

2. 硬件与环境准备：三步到位，别卡在第一步

整个流程依赖四个关键组件协同工作：你的电脑、安卓手机、ADB通道、云端模型服务。我们按顺序理清每一步的真实要求。

2.1 电脑端：别被Python版本劝退

操作系统：Windows 10/11 或 macOS Monterey 及以上均可。Linux理论上支持，但文档未覆盖，新手建议先用Win/mac。
Python：必须是3.10+。我试过3.12，部分依赖包（如gradio）会报兼容性警告；3.9则直接安装失败。稳妥起见，用3.10或3.11。

虚拟环境：强烈建议创建独立环境，避免污染全局Python：

python -m venv openautoglm-env # Windows: openautoglm-env\Scripts\activate # macOS/Linux: source openautoglm-env/bin/activate

2.2 手机端：开发者选项不是摆设，要真开

很多教程一笔带过“开启开发者模式”，但实际中80%的连接失败都源于此。请严格按以下步骤操作：

开启开发者选项：
设置 → 关于手机 → 连续点击“版本号”7次（不是5次，不是10次，就是7次），直到弹出“您现在处于开发者模式”的Toast提示。
启用USB调试：
返回设置 → 系统 → 开发者选项 → 找到“USB调试”，务必勾选。注意：有些手机（如小米）还有“USB调试（安全设置）”，也要一并打开。
安装并启用ADB Keyboard：
这是Open-AutoGLM实现文本输入的关键。
- 下载APK（GitHub Release页有提供，或搜索“ADB Keyboard”官方版）
- 安装后，进入手机“设置 → 语言与输入法 → 当前键盘”，将默认输入法切换为“ADB Keyboard”。
- 验证方法：在任意输入框长按，选择“输入法”，确认ADB Keyboard在列表中且已启用。

注意：部分国产手机（华为、OPPO）会默认关闭“允许通过USB调试修改系统设置”，需在开发者选项里手动开启，否则AI无法自动输入文字。

2.3 ADB配置：环境变量不是玄学，是必经之路

Windows用户：
下载platform-tools，解压到一个无中文、无空格的路径（如C:\adb）。
然后：Win+R→ 输入sysdm.cpl→ 高级 → 环境变量 → 在“系统变量”中找到Path→ 编辑 → 新建 → 粘贴你的ADB路径（如C:\adb）。
最后打开新命令行窗口，输入adb version，看到版本号即成功。
macOS用户：
解压后，在终端执行：
```
echo 'export PATH=$PATH:/path/to/your/platform-tools' >> ~/.zshrc source ~/.zshrc adb version
```
替换/path/to/your/platform-tools为你实际的解压路径。

3. 部署控制端：克隆、安装、验证，三行命令搞定

这一步最简单，但也最容易因网络或权限问题中断。我们用最稳的方式操作。

3.1 克隆代码并安装依赖

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

小技巧：如果pip install -e .报错error: Microsoft Visual C++ 14.0 or greater is required（Windows），请先安装Microsoft C++ Build Tools，或改用pip install --no-build-isolation -e .。

3.2 验证ADB连接：必须看到“device”

用USB线连接手机与电脑，确保手机弹出“允许USB调试吗？”提示，勾选“始终允许”并点确定。

然后执行：

adb devices

正确输出应类似：

List of devices attached ZY322FDQJL device

或（WiFi连接时）：

192.168.1.100:5555 device

如果显示unauthorized，说明手机未授权，重新插拔USB并确认授权弹窗；如果为空，检查USB线是否支持数据传输（很多充电线不行）。

3.3 验证模型服务：别等运行时才发现连不上

假设你已在云服务器部署好 autoglm-phone-9b 模型（使用vLLM，端口映射为8000），执行：

python scripts/check_deployment_cn.py \ --base-url http://YOUR_SERVER_IP:8000/v1 \ --model autoglm-phone-9b

看到类似这样的输出，说明模型服务就绪：

Model 'autoglm-phone-9b' is ready. Health check passed. Response time: 1.2s (avg over 3 requests)

如果超时，请检查：云服务器安全组是否放行8000端口、vLLM是否正常运行、URL中的IP是否为公网IP（非内网10.x或172.x）。

4. 刷抖音实战：从打开APP到完成关注，一条命令全包

这才是重头戏。我们以“打开抖音，搜索抖音号 dycwo11nt61d，进入其主页，点击关注按钮”为完整任务链，逐层拆解。

4.1 构造自然语言指令：越具体，成功率越高

Open-AutoGLM对指令的语义理解很强，但仍有优化空间。推荐写法：

❌ 模糊：“帮我关注一个抖音博主”
清晰：“打开抖音APP，点击顶部搜索框，输入抖音号‘dycwo11nt61d’，点击搜索结果中昵称为‘XXX’的用户，进入其主页，找到并点击‘关注’按钮”

我们最终使用的指令是：

“打开抖音APP，搜索抖音号为dycwo11nt61d的博主，进入他的主页，点击关注按钮”

注意：

明确写出APP名（“抖音APP”而非“抖音”），避免模型误判为网页；
使用“点击”而非“tap”或“press”，保持自然语言风格；
不写坐标（如x=500,y=1200），那是给机器看的，不是给人看的。

4.2 执行命令：带上所有必要参数

python main.py \ --device-id ZY322FDQJL \ --base-url http://10.1.21.133:8000/v1 \ --model "autoglm-phone-9b" \ "打开抖音APP，搜索抖音号为dycwo11nt61d的博主，进入他的主页，点击关注按钮"

参数说明：

--device-id：来自adb devices的设备ID（不是序列号，是那一串字母数字）；
--base-url：模型服务地址，格式必须是http://IP:PORT/v1；
最后字符串：你的自然语言指令，必须用英文引号包裹，且不能换行。

4.3 实际运行过程：它在做什么？我们能看到什么？

执行后，控制台会实时打印日志，这是理解其工作流的关键：

[INFO] Capturing screenshot... [INFO] Sending image + text to model... [INFO] Model response: {"action": "click", "element": "search_icon", "confidence": 0.92} [INFO] Executing: adb shell input tap 280 120 [INFO] Capturing screenshot... [INFO] Sending image + text to model... [INFO] Model response: {"action": "input_text", "text": "dycwo11nt61d"} [INFO] Executing: adb shell am broadcast -a ADB_INPUT_TEXT --es msg "dycwo11nt61d" ... [INFO] Task completed successfully

你会发现：

它每一步都先截图，再分析，再行动，再截图……循环往复；
每次分析都给出置信度（confidence），低于0.85时会主动暂停，等待人工确认；
文本输入走的是ADB广播，不是模拟键盘，因此不受输入法限制；
点击坐标是模型根据截图识别出的元素中心点，不是固定值，适配不同分辨率。

实测耗时：从命令执行到关注成功，约42秒（含3次截图、2次模型推理、4次ADB操作）。比真人慢，但全程无需干预。

5. 那些文档没写的“潜规则”：避坑指南

跑通不等于跑顺。我在测试中遇到几个典型问题，解决方案都来自源码层，这里毫无保留分享。

5.1 ADB Keyboard检测失败：改一行代码即可

现象：执行时报错ADBKeyboard not installed or not enabled，但你明明已安装并启用。

原因：main.py第127行的检测逻辑过于严格，只检查APK包名是否匹配，未校验输入法状态。

解决：打开main.py，找到类似以下代码段：

if not adb_keyboard_installed(): raise RuntimeError("ADBKeyboard not installed...")

将其注释掉，或直接改为：

# bypass keyboard check for testing print("[WARN] Skipping ADBKeyboard check.")

5.2 模型响应慢或乱码：不是模型问题，是vLLM参数

现象：check_deployment_cn.py能通，但main.py执行时卡住或返回乱码。

排查重点：

max_model_len必须 ≥ 4096（autoglm-phone-9b最低要求）；
gpu-memory-utilization建议设为0.9，避免OOM；
启动命令中必须包含--enforce-eager（某些显卡驱动需要）。

正确vLLM启动示例：

python -m vllm.entrypoints.api_server \ --model zhipu/autoglm-phone-9b \ --tensor-parallel-size 1 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --enforce-eager \ --port 8000

5.3 WiFi连接不稳定：优先用USB，远程用adb reverse

现象：WiFi连接后频繁断开，adb connect失败。

更稳方案：

用USB连接手机，执行adb tcpip 5555；
断开USB，用WiFi连接；
但关键一步：在云服务器上执行adb reverse tcp:5555 tcp:5555，将服务器的5555端口反向映射到手机。这样模型服务就能通过本地回环访问手机，彻底规避WiFi丢包。

6. 它能做什么？不能做什么？一份诚实的能力清单

经过一周密集测试（抖音、小红书、美团、B站、设置菜单），我对它的能力边界有了清晰认知。不吹不黑，列在这里供你决策参考。

6.1 做得好的事（强项）

场景	表现	说明
APP启动与跳转	“打开微信”“切到支付宝”“返回桌面”，准确率接近100%，响应快
结构化界面操作	☆	如电商APP的商品列表页→点击某商品→进入详情页→点击“加入购物车”，逻辑链完整
文本输入与搜索	支持中英文混合输入，自动处理软键盘唤起与收起，搜索框识别稳定
多步任务编排	☆	“打开小红书，搜‘北京咖啡’，点第一个笔记，下滑三屏，点赞”，成功率约85%

6.2 当前短板（需谨慎评估）

限制	原因	应对建议
动态内容识别弱	视频流、滚动广告、弹幕等高频变化区域，截图帧率跟不上，易误判	避免指令涉及“当前播放的视频”“最新弹幕”，聚焦静态UI元素
模糊指令容错低	“找那个穿红衣服的人”“点右边那个大的”等指代不清的描述，模型无法关联视觉锚点	指令必须基于APP内可见文字（如按钮名、Tab名、标题）
敏感操作需人工接管	涉及支付、账号注销、权限授予时，模型会主动暂停并输出`WAIT_FOR_HUMAN_CONFIRMATION`	这是设计的安全机制，不可绕过，需预留人工响应时间
小字体/低对比度界面识别不准	某些APP的灰色小字、半透明浮层，OCR识别失败率高	测试前可先在手机设置中调高字体大小与对比度

7. 总结：它不是一个玩具，而是一把打开手机自动化的钥匙

回看整个过程，Open-AutoGLM的价值不在于它能“自动刷抖音”——那只是个吸引眼球的demo。它的真正意义在于，它把过去需要写几十行UiAutomator脚本、反复调试坐标的繁琐工作，压缩成了一行自然语言。

它证明了一件事：当AI不仅能读图，还能理解图中UI的语义层级，并规划出符合人类操作直觉的动作序列时，“手机自动化”就从工程师的专利，变成了普通人的工具。

当然，它离完美还有距离：推理速度、长任务稳定性、小众APP兼容性都需要迭代。但开源的意义，正是让社区一起打磨它。你可以基于它做：

电商比价机器人（自动扫N个APP查同款价格）
无障碍助手（为视障用户语音描述界面并代点）
APP回归测试脚本生成器（用自然语言描述用例，自动生成可执行测试流）

技术终将下沉。而Open-AutoGLM，是这场下沉中，一块扎实的垫脚石。

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

用Open-AutoGLM做了个自动刷抖音项目，全过程分享