Mac上部署Open-AutoGLM：手机GUI Agent本地运行全攻略-平芜编程栈

把 Open-AutoGLM 跑在 Mac 上这件事，我前后折腾了差不多两星期。如果你以为“本地部署一个手机 AI 助理”就是把仓库拉下来、装几个依赖、跑一条命令这么简单，那第一关的报错就会让你头皮发麻；但只要你把环境、设备、模型调用这几个关键环节理顺，后面看到的完全值得这些折腾：你用一句普通话描述一个任务，它像真人员工一样自己盯着手机屏幕，一句一句复述自己在干什么，然后一步步点击、滑动、输入，把活干完。

Open-AutoGLM 本质上是一个开源的手机 GUI 操作 Agent：它调用视觉大模型去“看”手机截图，理解当前界面，再结合用户给的任务目标生成下一步操作，最后通过 ADB 把动作执行到手机上。整个过程形成了一个“感知—推理—执行—再感知”的闭环。对 Mac 用户来说，你的笔记本不需要很强的显卡，也不需要本地跑几十 GB 的模型权重，重推理负担被放到了大模型 API 侧，本地只负责调度和指令下发。这篇文章不讲废话，就按照“原理—部署—运行—优化—排坑”的顺序，把我在 Mac 上从零跑通 Open-AutoGLM 的完整路线交给你，包括那些文档里不会写、但你不注意一定会踩的坑。

1. Open-AutoGLM 是什么，以及为什么值得折腾

1.1 它解决的问题

平时用手机最烦的事情，就是那些步骤固定但特别啰嗦的操作：每天打开某个 App、进入某个页面、点几个按钮、复制一段文字再切到微信发给别人。传统做法是写 UI 自动化脚本，比如用 Appium 或者按键精灵。这类方案有一个致命弱点：它们依赖界面元素的 ID、坐标、文本属性，App 一改版，脚本就废了一半。而且写这类脚本本身就是体力活，定位控件、处理等待、处理弹窗，每一件事都需要你手动去适配，并不是真的“省事”。

Open-AutoGLM 换了一条路。它不需要你预先写死任何操作步骤，只需要你告诉它“最终要达成的结果”，然后它自己通过截图观察屏幕、理解界面内容、决定下一步动作。你可以把它理解成一个戴了眼镜、手比较慢但理解力还不错的实习生：你给他布置一个任务，他自己看着工位上的东西决定先拿什么后拿什么，每一步做完还会再看一眼确认效果。

这个思路其实就是把指令跟随能力、视觉理解能力、推理规划能力三者结合在一起，做成一个通用的手机操作框架。它在很多场景下比传统脚本更皮实：哪怕 App 的按钮位置变了、界面配色换了，只要语义还在，它大概率还是能找到目标。

1.2 和传统手机自动化的核心区别

我把两者做了一个对比，这样你一眼就能看出差异：

维度	传统 UI 脚本	Open-AutoGLM 这类 GUI Agent
任务定义方式	编写代码，指定控件选择器和动作序列	用自然语言描述目标，由 Agent 自主规划
对界面改版的鲁棒性	很脆弱，控件 ID 或坐标一变就失效	较强，基于屏幕语义理解而非硬编码
使用门槛	需要熟悉自动化测试框架	主要需要会配环境、会写清晰的指令
执行速度	快，毫秒级动作	较慢，每步都要截图并调用模型推理
适用复杂度	适合高度固定的重复流程	适合语义明确但步骤多变的操作

简而言之，前者是“你把每一步都告诉机器”，后者是“你把目标告诉机器人”。Open-AutoGLM 是后面这种思路里目前开源体验比较完整的一个选择。

1.3 它的边界在哪里

说清楚边界，可以避免你部署完以后失望。目前 Open-AutoGLM 这类方案主要面向 Android 设备，因为它的动作执行层依赖 ADB（Android Debug Bridge），Mac 上通过 USB 连接安卓手机后，才能拿到截屏能力和模拟点击的能力。iPhone 上由于系统权限限制，没法走这条路子。如果你想在 Mac 上控制自己的 Android 手机，这个项目是可以直接用的；如果你手里只有 iPhone，那这个方案基本别想。

另外它还做不到完全理解人类那样模糊的意图。你的任务描述越具体、越可检验，它完成任务的成功率就越高。这也是我后面会花很大篇幅讲任务描述的原因。

2. 部署前必须搞懂的核心原理

2.1 它怎么“看见”你的手机

Open-AutoGLM 的第一输入来源是截图。它通过 ADB 执行一行截屏命令，把手机当前屏幕的画面保存下来，然后交给一个支持视觉理解的大模型。这个大模型不仅能看到屏幕上有什么文字、按钮，还能理解这些元素的空间位置关系和功能语义。比如它看到屏幕上有“确认支付”这个按钮，就知道这是用于提交订单的。

这里有个很容易被忽略的细节：大模型拿到的不仅是一张图片，很多实现里还会同时拿到截图的分辨率、尺寸以及设备型号信息。这样模型在推算“我应该点哪里”的时候，输出的是相对坐标或者像素坐标，执行层再用 ADB 转换为真实的点击位置。

你可以简单理解为：截图是它的眼睛，ADB 是它的手，模型是它的大脑，而你输入的那句话是它的 KPI。

2.2 完整的工作循环：感知—推理—执行—验证

我实际观察过它的运行日志，Open-AutoGLM 的执行过程基本是下面这样一个循环：

执行截屏，获取当前屏幕状态；
把截图和任务描述一起交给视觉大模型；
模型输出当前应该执行的动作，比如“点击屏幕坐标 (540, 1200)”或“输入文本”；
框架通过 ADB 执行该动作；
等待一小段时间，再次截屏；
把新截图和任务完成状态判断一起交给模型，决定是继续下一步还是结束任务。

这个循环和人在操作手机时的思路很接近，叫作“感知-行动回路”。它每一步都在对着真实屏幕确认自己的操作结果，而不是蒙着眼睛按剧本走。所以你看到的不是一串写死的机械点击，而是每一次动作前都要重新审视当前的状态。

2.3 为什么 Mac 配置平平也能跑

不少第一次接触这类项目的朋友会担心一个事：我笔记本没有独立显卡，怎么跑大模型？其实 Open-AutoGLM 的架构决定了它并不是一个“把大模型部署在本地”的方案。它部署在本地的是 Agent 主体：也就是任务解析、动作执行、截图管理、状态切换这一套调度逻辑。真正的视觉理解发生在云端 API 上，你只需要在配置文件里填入一个支持视觉理解的大模型接口 Key。

打个比方：你不是开了一家餐厅要自己掌勺，而是开了个前厅，负责接单、传菜、上菜，后厨的活外包给了专业厨师团队。前厅肯定开在你自己店里，但厨房可以在别处。这就是“本地部署”的真实含义：本地部署的是操作调度中心，不是模型推理引擎。

当然，App 启动和中间界面跳转都发生在你手机本地，跟云端的交互只有截图上传和操作指令返回。所以它对网络有要求但不高，只要不是频繁断网，体验都能接受。

2.4 目标拆解和任务描述的原理

模型能干活，一半靠模型本身的底子，另一半靠你描述任务的清晰度。从原理上讲，大模型拿到一段任务描述之后，会把描述拆解成若干子目标。比如“帮我把今天的待办事项截图发给文件传输助手”，拆解后可能是：

打开系统备忘录；
找到今日待办列表；
对列表进行截屏；
打开微信并进入文件传输助手；
选取刚才的截图发送。

如果一开始的描述是“帮我记录一下”，模型根本不知道从哪里开始。所以在后面我会给出一套比较可靠的任务描述公式，先在这里记住一个核心思想：**你能给模型一个可验证的终点，它就更容易规划出一条有效路径。**可验证的意思是，模型在最后一步可以通过截图判断“目标是否达成了”，比如看到图片已经发送、页面已经跳转、文字已经输入。

3. Mac 本地部署完整实操流程

3.1 部署前的环境检查清单

我的建议是先花十分钟把清单核对一遍，不要急着拉代码，很多部署失败都来自环境不一致。

你需要准备：

一台 Mac，Intel 芯片或苹果芯片都行，内存 8GB 以上比较舒服；
一部 Android 手机，Android 7.0 以上即可，品牌不限；
一根能传输数据的 USB 线，只支持充电的线会让你怀疑人生；
可以访问大模型开放平台的账号，用于申请 API Key；
手机里提前装好你要测试的 App，比如计算器、日程应用、微信等。

我踩过最蠢的坑就是拿了一根只能充电的线，连上以后 adb devices 永远看到不到设备，一度以为是驱动问题。排查了半天，换根线就好了。你现在先记住这句话：数据线，而不是充电线。

3.2 安装基础工具：Homebrew、Python、ADB

如果你的 Mac 上已经装过 Homebrew，这一大步可以跳过一部分。没装的先装，终端里执行：

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

装完以后用 brew 安装必要的工具：

brew install python@3.11 android-platform-tools

这里我明确用 python@3.11，而不是最新版 3.13。原因很简单：Open-AutoGLM 依赖的很多 Python 库对最新版的支持还不完善，我一开始图省事装了默认 Python，结果某个依赖包直接编译报错。3.11 是目前兼容性最稳的选择，没必要在这里追求新版本。

安装完后验证：

python3.11 --version adb version

两条命令能正常输出版本号，说明基础环境已经就位。

3.3 手机端准备：开启开发者模式与 USB 调试

这一步没做对，后面所有操作都会卡住。打开手机的“设置”，找到“关于手机”，连续点击“版本号”七次左右，直到系统提示“您已进入开发者模式”。然后在设置里找到“开发者选项”，打开“USB 调试”。

用数据线连接 Mac 和手机后，手机上会弹出一个“是否允许 USB 调试”的对话框，勾选“始终允许”并确认。这个弹窗一定不能忽略，我第一次就是没注意手机屏幕，直接跑去终端敲命令，结果 adb 一直显示没权限。

终端里验证设备是否到位：

adb devices

正常情况下你会看到类似这样的输出：

List of devices attached XXXXXXXX device

注意状态必须是device，如果是unauthorized，说明手机上的授权弹窗还没点确认，拿出手机处理一下。

3.4 拉取项目并创建虚拟环境

在你想放项目的目录下，打开终端，执行：

git clone https://github.com/你的项目地址/OpenAutoGLM.git cd OpenAutoGLM

具体的仓库地址你去项目主页复制即可，这里不展开 URL。克隆完成后，创建独立的 Python 虚拟环境，这一步强烈建议做，防止依赖包污染你 Mac 上的全局 Python 环境：

python3.11 -m venv .venv source .venv/bin/activate

激活后你的终端提示符前面会出现一个(.venv)的标志，看到它说明虚拟环境生效了。之后无论安装什么依赖，都只会进到这个独立的虚拟环境里，不会把系统环境搞乱。

3.5 安装依赖包

执行：

pip install -r requirements.txt

这一步会装不少包，时间长短取决于你的网络状况。如果你发现某个包下载特别慢或者超时，可以临时指定国内 PyPI 镜像源，操作方式是加一个-i参数，比如：

pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

这是常规的镜像源配置，不算什么特殊手段。装完后我习惯跑一下pip list | grep auto，确认核心模块确实进来了。

3.6 配置大模型 API Key

Open-AutoGLM 需要一个支持视觉理解的模型接口。我用的是国产大模型团队提供的 GLM 系列视觉模型开放接口，它同时支持对话和图片输入，比较符合这个项目的需求，而且有免费额度可以白嫖，适合拿来熟悉流程。

注册账号以后，去开放平台创建一个 API Key。然后回到项目目录，找到环境变量示例文件，复制一份：

cp env.example .env

编辑.env文件，把里面的 Key 字段换成你自己的：

API_KEY=你的key MODEL_NAME=glm-4v-flash

重要提醒：不要把真实 Key 写进代码仓库，更不要提交到 Git。写进.env之后，确认项目启动时会加载这个文件即可。很多人项目跑不起来，一查发现 Key 没生效，就是因为改错了文件或者根本没有创建.env。

3.7 代码里调整一下你的手机设备 ID

如果adb devices里显示的手机序列号是例如emulator-5554或一串字母数字组合，你需要在项目配置里指定设备 ID，防止后续有多个设备时选错目标。找到配置文件里的设备相关字段，把序列号填进去。

没有多设备需求时可以不管，但一旦你同时插着多个调试设备，不指定 ID 的话动作可能发给错误的设备，后果你来担。

4. 第一次运行与任务构造技巧

4.1 跑一个安全又简单的任务

第一次运行，千万不要让它碰支付、登录、发朋友圈这种不可逆的操作。我的建议是先让它做一个“打开计算器，输入 1+2”这样的指令，成本低、验证快、出错了也无所谓。

在项目目录下，执行启动脚本并传入任务描述。不同版本启动方式略有差异，但核心操作类似：

python run.py --task "打开计算器，计算1加2等于多少"

如果你看到终端开始打印日志，第一行大概率是类似“任务已接收，正在执行”的提示，紧随其后就是截屏和模型推理的动作。这时你可以低头看一眼手机屏幕：它会在你的注视下自己解锁屏幕、找到计算器图标、点击打开，然后一个数字一个数字地输入。那种感觉相当神奇，这是你第一次直观地理解“AI 操作手机”到底是怎么一回事。

4.2 好的任务描述和坏的任务描述

跑通第一个简单任务之后，你会忍不住想让它干更复杂的事情。这时候最容易翻车的就是任务描述写得过于随意。我做了一个对比：

坏描述	好描述
“帮我叫杯咖啡”	“打开外卖 App，搜索门店‘某咖啡’，选择大杯拿铁，加入购物车，进入结算页，但不要提交订单”
“存一下这个地址”	“打开备忘录，新建一条笔记，输入文字‘北京市某某地址’，保存”
“写个今日计划”	“打开日历 App，为明天上午 9 点到 10 点创建一个日程，标题为‘项目评审’”

区别在哪？好的描述具备几个特点：有明确起点、有可执行的动作清单、有终点边界、有“不要做什么”的安全护栏。不是说每次都要写成一串步骤才叫好，而是模型在执行模糊指令时容易迷失方向，你必须帮它把任务边界框定清楚。

4.3 第一次运行会看到的日志长什么样

运行过程中你会看到类似下面的循环日志：

Observation: 当前屏幕为桌面，显示应用图标包括计算器、微信、备忘录... Thought: 我需要先找到计算器应用图标，它应该在屏幕第一屏或第二屏 Action: 滑动到第二屏 Observation: 屏幕发生滚动，计算器图标已出现在可视区域 Action: 点击坐标 (320, 1050) Action: 输入文本 "1+2" Action: 按下计算键 Observation: 屏幕显示计算结果为 3，任务已完成

这就像有一个虚拟员工在旁边一边自言自语一边干活。你看到它思考错了也别慌，观察一步如果发现不对，它会纠正。

4.4 让它自动执行还是有风险的操作要看着

我的建议是：前二十次运行，都让手机放在你面前，屏幕常亮，不要锁屏。不是说它有几率乱来，而是你需要感受它的节奏和失误模式，才知道后面的任务描述该怎么改。

不要把手机拿在手里来回摆弄。它的整个执行逻辑基于截图，如果设备被移动、界面被占住，截图内容和真实屏幕不一致，模型会以为自己看到了一个不存在的界面，然后开始胡点。

4.5 关于“每一步都很慢”这件事

第一次跑复杂任务时，你可能会觉得它效率太低：一个滑动等三秒，一个点击等五秒，中途还有大量“思考”时间。这很正常。它每走一步都要重新截屏、上传图片、等待模型推理、再下发控制指令，本质上它是拿速度换通用性。想要更快，后面优化章节会讲。

5. 优化运行效果：让它干得更稳更快

5.1 降低来回推理次数：把长任务切成两段

如果你让它执行一个十步以上的任务，中途出现一次模型理解偏差，后面所有步骤都可能跟着歪掉。我实际用的优化手段是：把长任务拆成两段甚至三段，每一段都单独启动一次。

比如“预定高铁”这个任务，我会先让它“打开票务 App，搜索某线路、某日期、某车次”，执行完后再发第二条指令“选择二等座默认乘客，进入订单确认页，但不要支付”。这样做的好处是，任务链短，每段的目标都清晰，失败时可以精确定位到是哪一段出了问题，而不需要从头排查。

5.2 调整动作间隔：别调得太激进

项目配置里通常有一个动作之间的等待时间参数。默认值一般是 1 到 2 秒。有的人觉得太慢，改成 0.1 秒，结果屏幕动画还没结束，下一张截图已经拍下来了，模型对着一个半渲染状态的界面思考，大概率给出错误动作。

我的经验是：等待时间保持在默认值的 0.5 到 1 倍之间，不要低于 0.5 秒。如果你的手机性能一般，App 切换动画明显，甚至可以调大一点，用轻微的时间成本换取更高的成功率。

5.3 提高截图和视觉识别的正确率

有几个小操作可以明显提升模型的识别效果：

调整手机屏幕亮度到中等以上，太暗的截图会丢失按钮细节；
关闭深色模式，部分 App 在深色模式下按钮对比度低，模型容易漏看；
在开发者选项里把“动画程序时长缩放”调成 0.5x，减少过渡动画对截图的干扰；
截图分辨率保持默认即可，不必追求高分辨率，反而增加图片上传时长。

尤其是动画缩放，这是被很多人忽略的点。动画时间越长，模型截图时拍到的“中间态”就越多，误判率直线上升。把动画时长缩到 0.5x 之后，我实测复杂任务成功率有明显提升。

5.4 选择更合适的模型

Open-AutoGLM 接入不同的模型 API，速度和成功率差异很大。我最初用免费模型实验时，发现它在简单任务上表现没问题，但一旦界面元素复杂、图标很多，就会出现“视而不见”的问题，明明按钮就在屏幕上，它说找不到。

后来切换到了更高性能的付费视觉模型，问题缓解了很多。我的建议是：先免费额度跑通流程，不要急着氪金；确认基本可用后，再按照你的任务复杂度评估是否升级模型。对 Agent 来说，模型的能力上限决定了它操作手机的上限，这是回避不了的事实。

5.5 给指令加上“安全护栏”

我在任务描述里越来越喜欢加一句“不要做某事”。比如：

“不要点击任何弹出广告”
“不要登录第三方账号”
“不要跳过确认弹窗”

不要小看这句话的作用。模型在很多情况下会主动弹窗是否要登录、是否要开启通知、是否同意隐私协议，如果护栏没写清楚，它可能会乱点。有了护栏，它遇到相关界面时会选择更保守的策略，或者明确告诉你“当前界面存在不需要处理的弹窗”。

5.6 保存常用任务模板

如果你有每天重复的操作，可以把任务描述写进一个本地文本文件，比如tasks/daily_report.txt，下次直接读取文件里的内容作为--task参数传入。这样既不用每天重新打字，也方便你持续迭代描述的质量。模板化之后，你能更清晰地对比不同描述的跑通率，比凭感觉改指令靠谱得多。

6. 常见问题与坑位速查

6.1 部署阶段高频问题记录

现象	常见原因	解决方式
adb devices 没有任何输出	数据线不支持数据传输	换一根可传输数据的原装线
设备状态显示 unauthorized	手机上的调试授权弹窗未确认	解锁手机，勾选允许调试
pip 安装依赖失败	Python 版本不对或网络问题	使用 python3.11 并指定国内镜像源
启动时报缺少模型 Key	`.env`文件不存在或字段名不对	确认`.env`中 Key 字段与示例文件一致
运行后报“设备未找到”	项目配置文件中的设备 ID 未填写	把`adb devices`显示的序列号填入配置

这里我想重点强调一下.env的问题。很多人觉得自己明明填了 Key，代码却读不到。我遇到的情况是：项目加载环境变量的模块只会读取项目根目录下的.env，而我当时在子目录里创建了这个文件，导致始终加载失败。进入项目根目录再做这个操作，能避开大部分问题。

6.2 运行阶段经典翻车现场

截图黑屏或全白，大概率是手机息屏了。Open-AutoGLM 虽然有概率帮你唤醒屏幕，但在部分系统上不行。解决方案是：连接期间把手机的“自动锁屏”调成最长时间，或者在开发者选项里打开“充电时保持唤醒”。

点击位置总是不对，常见原因有两个。一是屏幕分辨率信息和模型接收到的不一致，截图被缩放后模型输出的坐标和目标位置对不上；二是界面动画未完成就开始截图。前者去配置里确认是否传了设备真实分辨率，后者属于上一节提到的等待时间问题。

模型反复执行同一个动作陷入死循环，这是 Agent 类应用最典型的失败模式。当它面对一个无法理解的界面时，会尝试一个动作，发现没生效，再尝试同一个动作，陷入原地打转。解决办法是给任务加上最大步数限制，比如超过 15 步没完成就主动终止。宁可让它失败退出，也别看它无限循环浪费 API 额度。

6.3 安全和权限使用建议

说了这么多怎么让它干活，最后必须认真聊聊安全问题。Open-AutoGLM 拿到的是对你的手机的完整控制权，这意味着它能点击任何位置、输入任何文本。它虽然是个开源项目，但模型本身无法判断“这个操作是否违法或者有损你的利益”。所以你有几条铁律要守住：

不要在任务描述里包含支付密码、验证码等敏感信息；
不要让它操作你不希望被自动执行的高风险动作，比如转账、删除邮件、发布公开内容；
ADB 端口不要暴露到公网，调试完及时拔掉数据线；
首次运行复杂任务前，把手机里的重要 App 退出登录，或者至少保证任务里没有涉及私人数据的操作。

从我的实测感受来说，Open-AutoGLM 目前最可靠的用法是处理那些“非敏感、步骤固定、但很烦人”的效率型任务，比如自动整理日程、自动搜索信息、自动填表。你让它碰钱包和社交账号，那是给自己找麻烦。

最后再分享一个个人经验：我给任务描述加了一个小习惯，每次都会在末尾写一句“如果遇到不确定的情况，告诉我你的困惑，不要自动执行”。这句话听起来很虚，但它确实能减少它在歧义路口上自作主张的概率。AI 手机助理这个方向刚起步，它不能像人一样读懂每一条潜规则，但只要你把边界画清楚，它能在你画好的圈子里干得比你想的更利索。从简单的“打开计算器”到今天能替你走完一套完整流程，中间那些坑我都替你试过了，照着上面的步骤来，你今晚就能看到它在你的手机屏幕上自己动起来。