许清风“没有豆包智能手机，也能用？”这个问题，最近在我所在的几个智能体交流群里反复出现。起因是一波“AI手机”的话题让大家产生了一个惯性联想：能让手机自己刷视频、自己订外卖的能力，是不是非得等专属硬件落地，或者绑定某个厂商的云端服务才能体验？智谱清言在这个节点开源 Open-AutoGLM，还打包了可离线部署的离线包，等于直接回答了这个问题：不用。普通安卓手机加一台能跑大模型的电脑，就能把“一句话让手机干活”这件事搭起来。这篇就结合我自己的部署实测，把 Open-AutoGLM 离线包的原理、部署、实测效果和踩坑点一次讲清楚。
1. 豆包手机带火的追问：手机智能体难道只配“专属硬件”？
1.1 从“语音助手”到“手机智能体”的这一步
过去几年我们一直在用“语音助手”这个词，但绝大多数语音助手的能力边界其实很明确：你说“帮我点个外卖”，它做得最熟练的往往是打开外卖 App，剩下的选择店铺、挑菜品、下单选地址，还得你亲手完成。为什么会这样？因为传统助手是“站在 App 外面”的，它没有自己的眼睛和手，只能调用 App 对外开放的那几个接口，或者做浅层跳转。一旦链路里出现 App 内部的搜索页、确认页、优惠弹窗，它就断掉了。
手机智能体（有的资料里叫 Phone Use Agent，或者 GUI Agent）换了一条完全不同的路线：不再依赖 App 接口，而是模仿人的操作方式——截取当前屏幕，用视觉模型理解屏幕里有什么，再决定手指该点到哪里、往哪个方向滑、输入什么内容。听起来简单，但这一步是质变，因为它把“人能在手机上完成的操作”整体变成了可模型化的任务。
AutoGLM 最初就是智谱清言 App 里内置的这个能力，也是国内第一批真正在真实安卓应用里长期跑通的手机智能体。它之所以能稳定工作，靠的不仅是通用大模型，而是在大量 GUI 数据上做了专门的界面对齐。这次开源的 Open-AutoGLM 把整套链路——模型权重、服务端、终端控制——都放了出来，还提供了一个可以直接落地部署的离线包。对想自己研究、自己改造 Agent 的人来说，这比任何演示视频都有价值。
1.2 云端智能体与本地离线包的真正区别
很多人第一次听说 Open-AutoGLM 时的反应是：“智谱清言里不是已经有 AutoGLM 了吗？直接打开 App 用不就行了？”这话对，但只对了一半。云端版本的优势是零部署、开箱即用，手机装 App 就能体验；但代价也很明显：任务指令和屏幕截图都要传到云端处理，有一定等待时间，高峰期还会受额度、限流的影响。
离线包解决的就是这个“能不能把能力抓在自己手里”的问题。所谓离线包，就是把模型权重、推理服务、智能体编排代码、安卓端控制组件打成一个可在本地环境安装运行的整套软件。部署完成之后，你的手机屏幕信息不再需要离开本地网络。
这对三类人特别有价值。第一类是隐私敏感场景，比如企业内部手机上跑自动化流程，截图里全是业务数据，出不了内网；第二类是高频调用场景，云端 API 按次计费、有限流，本地部署一次投入，后续基本边际成本为零；第三类是研究和二次开发场景，模型可以换、策略可以改、动作日志随便看。另外，离线部署虽然不依赖智谱的云服务，但它依然是开源项目，模型权重和代码都是公开的——这层“拿到了就能持续用”的确定性，才是它比云端方案多出来的核心价值。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Open-AutoGLM 离线包拆箱：模型、框架、终端三件套
2.1 核心模型 GLM-4V-Auto：一个会“看屏幕”的视觉语言模型
拆开离线包，最核心的部分是模型权重。Open-AutoGLM 用的主模型是 GLM-4V-Auto，它和智谱的 GLM-4V 系列共享同一个主干，参数规模大约在 9B 这一档，但和通用多模态模型有一个关键区别：它是在大量真实 GUI 界面上做了专门对齐的“界面操作模型”。
怎么理解这个区别？用一个生活化的类比。普通的视觉语言模型，像是进到一间陌生房间后能描述“这里有一张桌子、一扇窗户、桌上摆着杯子”的人；而 GUI 操作模型，是那种能直接告诉你“冰箱门把手在哪个位置、你应该先往左走两步再伸手拉开”的人。刷视频、订外卖这类任务，恰恰需要的是后者这种“界面元素级的空间理解”——模型要能判断屏幕上哪个区域是下一个视频的推荐位，哪个按钮是“选规格”，哪个浮层是“立即支付”。
模型的输入输出也比较直观。每次决策时，它接收三样东西：当前屏幕截图、用户下达的自然语言指令、以及此前几步的动作历史；输出则是一条结构化的动作指令，包括动作类型（点击、滑动、输入、返回、等待）和具体的坐标或文本。这个“截屏-决策-执行-再看屏幕”的循环，就是整个智能体的基本节拍。
2.2 离线包里的运行链路：从截图到点击的闭环
模型只是大脑，离线包里还包含把大脑和手机串联起来的整套传送带。完整链路大致分成四段：
- 终端设备：运行任务的那台安卓手机，或者 Android 模拟器，负责提供屏幕画面并执行真实操作。
- 控制通道：通过 ADB 或者安卓无障碍服务（AccessibilityService），把“点哪里、滑多远”变成真实的触摸事件。
- 推理服务：在电脑上启动的大模型推理进程，一般用 vLLM 这类框架承载，对外提供 OpenAI 兼容接口给上层调用。
- 智能体编排：一段运行在电脑上的服务端代码，负责把截图传给模型、解析模型输出、决定执行顺序、处理失败重试。
以我这次部署的典型链路为例（具体以官方仓库 README 为准）：先在电脑上把模型权重目录和代码仓库准备好，启动 vLLM 推理服务；然后用数据线把安卓真机连到电脑，打开 USB 调试并授权；最后启动智能体服务端，它会自动通过 ADB 拉取屏幕截图，进入“看屏-操作-再看屏”的循环。整个过程中，人的角色只剩下下达任务指令和监控是否出错。
这里多说一句，为什么“离线包”在下载阶段特别受关注。因为很多人是在内网环境部署，外网访问受限，模型权重和依赖包下载都比较折腾。所以准备阶段建议先把 Gradle 依赖、Python 包、模型权重都一次性下载缓存好，再带到离线环境安装——这其实就是“离线包”三个字在工程上的真正含义：不只是模型离线，是整个工具链都能离线跑起来。
2.3 硬件门槛：一张显卡到底够不够
接下来说说大家最关心的硬件问题。GLM-4V-Auto 参数规模约 9B，FP16 权重大概要占 18GB 左右的显存，再加上 KV Cache 和推理开销，24GB 显存的 RTX 3090/4090 能跑得比较从容。如果是 16GB 显存的卡，可以走 8bit 或 4bit 量化，模型体积能压到 6GB 上下，但代价是定位精度可能损失一点点。没有独显的 CPU 机器理论上也能推理，不过每一步可能要几十秒，刷视频这种高频操作会变成“慢动作回放”，拿来调通流程可以，日常用就比较难受。
我的建议是：不要一上来就追求量化。先用机器能跑的最大精度把整条链路跑通，确认任务能完成，再引入量化提速度。这样可以避免“明明逻辑没问题，但量化后定位偏了导致找不到按钮”这种分不清是模型问题还是配置问题的排查困境。
3. 实操：一句话让手机自动刷视频、订外卖
3.1 部署四步走
这块直接给一个“照抄版”的操作顺序，具体细节按官方文档再对一遍。
第一步，准备模型与代码。从 ModelScope 或 HuggingFace 拉取 GLM-4V-Auto 权重（如果访问海外源不稳定，优先用 ModelScope 会舒服很多），clone Open-AutoGLM 仓库，用 conda 单独建一个 Python 3.10/3.11 环境，按 requirements 装依赖。
第二步，启动推理服务。典型启动命令大概长这样：
bash复制# 以 GLM-4V-Auto 为例，具体参数以官方仓库为准
vllm serve glm-4v-auto --served-model-name glm-4v-auto --port 8000 --max-model-len 8192
启动后先用 curl 打一下接口，确认模型服务正常响应，再进入下一步。这一步多花两分钟检查，后面能省一小时。
第三步，连接安卓设备。真机需要打开开发者选项和 USB 调试，连接后执行 adb devices 确认状态是 device 而不是 unauthorized；如果之前没授权过，手机上会弹出调试授权框，记得勾选“始终允许”。想彻底摆脱数据线，也可以用 adb 的无线调试功能，但首次建议还是用线，少踩一个网络坑。
第四步，启动智能体服务端，下达任务。把用户指令作为参数传进去，例如“打开抖音，连续刷 10 分钟视频，遇到美食类视频就点赞”。接下来观察日志里每步“截图-决策-执行”的输出，看到动作序列连贯起来，就说明整条链路通了。
3.2 视频场景怎么“看懂”屏幕再动手
先看刷视频这个任务。它看起来简单，其实比很多人想象中更考验模型对视觉内容的软性理解。指令是“遇到美食类视频就点赞”，模型需要做的不只是一个动作，而是一整条判断链：先识别当前画面属于什么内容，再把画面内容归类到“美食类”还是“非美食类”，最后决定执行“点赞”还是“继续上滑”。判断“美食”这件事，候选视频的画面可能是菜品特写、探店 Vlog、烹饪过程混剪，模型基于屏幕截图做分类，和真人刷视频时“瞄一眼就知道是不是吃的”用的是同一个输入来源。
实测中比较明显的体感是：相比静态规则脚本，这种模型驱动的刷视频方式灵活很多。遇到广告、直播预告、陌生人社交卡片这些奇奇怪怪的页面，它不会像写死的坐标脚本那样乱点，而是会根据屏幕内容重新决策。当然，代价是每一步都有延迟，不可能做到真人那种丝滑手速，刷视频任务里的表现是“有节奏地停留、滑动”，不是连续快速翻页。
一个实用的调优建议：把指令里的主观词换成客观描述。不说“遇到有意思的就点赞”，而是说“遇到美食类视频就点赞，每看到一条美食视频最多点一次赞”。模型对客观分类的执行，通常比对主观偏好的理解稳定得多。
3.3 订外卖任务的关键节点与安全确认
再看订外卖，指令示例：“打开美团，帮我搜‘黄焖鸡米饭’，选一家评分 4.5 以上、价格在 30 元以内的店，下单大份黄焖鸡套餐，先不要付款。”
这个任务和刷视频完全不同，它是典型的跨页面长链路：从打开 App、搜索关键词、进入商家页、选择规格、加入购物车、进入结算页到最终下单，中间要经过七八个页面，每个页面布局都不一样，还可能突然弹出优惠券广告、开启位置权限的请求。模型需要边看边决策，每到一个新页面就重新理解当前屏幕，再决定下一步。
这里必须重点提安全机制。AutoGLM 这类手机智能体在执行高成本动作——支付、下单、发送消息、删除内容——时，设计上会要求用户确认。即使是本地离线部署，我也强烈建议保留这道确认关卡：把“下单”和“付款”拆成两个阶段，模型执行到付款动作前暂停，等人在终端上确认。毕竟自动化和闯祸之间，往往就差一个确认框。
实测中比较常翻车的地方是价格筛选。有些商家页会显示“满 30 减 10”之类的活动，模型根据页面价格判断是否在预算内，容易被优惠文案干扰。我的处理方式是：在指令里给预算留出浮动空间，比如“30 元以内”就明确说“结算页显示的总价不超过 35 元都算通过”，给模型一个可执行的数值判断标准。
3.4 实测效果与现实预期管理
最后给个客观的效果预期：这类任务的成功率受太多因素影响，设备分辨率、App 版本、网络速度、模型版本都会改变结果。我自己的经验是，刷视频这类“单页面判断 + 少量动作”的任务，跑通率很高；订外卖这种长链路任务，第一次跑大概率会在一两个页面卡住，需要观察日志、调整指令，甚至人工介入一步，再继续自动执行。
这不代表方案不行，而是智能体本身的运行逻辑就是“逐步决策”，每一步都有不确定性，整体成功率是各步成功率的乘积。把长任务拆短、把指令说清楚、保留人工确认环节，才是正确的使用姿势。另外，如果你打算把平时在云端 AutoGLM 里的任务习惯迁移到本地，记得先把应用里的登录态、默认地址、支付方式这些前置条件准备好，不然模型每一步都要和登录页、授权页搏斗。
4. 避坑实录：本地部署 Open-AutoGLM 时最容易翻车的五个环节
4.1 模型下载与离线环境的依赖雷区
先说下载。模型权重从 ModelScope 拉，在很多网络环境下比海外源稳非常多。真正容易翻车的是“依赖离线化”：很多人在部署机上顺利下载了模型，结果启动服务时报缺这个库缺那个包。
所以正确的顺序是：先在联网环境把 Python 依赖、Gradle 依赖、模型权重全部下好缓存，再进离线环境。特别是安卓端如果要从源码编译 APK，Gradle 第一次构建要拉大量依赖，不提前缓存会非常痛苦，这也正是很多人搜“gradle 离线包”的原因。我的做法是先在同一台机器上完整构建一次，确认缓存目录里有完整依赖，再把整个 Gradle 缓存目录一起拷进离线环境。
4.2 ADB 连接与设备授权问题
adb devices 输出 unauthorized，是我见过最多的新手问题。原因是安卓调试授权弹窗只在首次连接时出现，如果弹窗一闪而过没点“允许”，或者点了“仅本次允许”，重启后就会变成未授权状态。解决办法是连接后眼睛盯着手机屏，第一时间勾选“一律允许使用这台计算机进行调试”。
顺带提醒一个容易忽略的点：模拟器和真机的坐标系是一样的，但分辨率、系统字体大小、屏幕宽高比不同，同一个坐标在不同设备上对应的 UI 元素可能不同。如果准备做多设备适配，尽量固定测试设备的分辨率和显示设置，减少变量。
4.3 GPU 显存与量化选择的权衡
显存不够是最常见的硬件问题。GLM-4V-Auto 在 24GB 显卡上跑全精度的体验最稳，但如果你的卡只有 16GB，也不要失望，量化后依然能用。关键是量化格式的选择和验证方式。我建议先用 FP16 全精度把任务跑通，记录一个“标准动作序列”，再切量化模型对比同样的任务；如果动作序列出现明显偏移，再考虑回退精度或换更大的量化位宽。
另外注意上下文累积。在长任务里，每一次决策都会带着历史动作信息，历史越长，KV Cache 占显存越高。跑订外卖这种长链路任务时，如果发现显存占用持续上涨，可以限制单任务的最大步数，或者定期清理历史上下文，保证长跑不爆显存。
4.4 中文应用 UI 环境下的定位误差与应对
离线部署后，你大概率会拿自己常用的中文应用做测试，这时候会遇到一个现实问题：模型在训练时见过的应用覆盖度是有限的。像抖音、美团、淘宝这类头部应用，界面识别效果通常不错；但一些小众应用，或者头部应用改版后的新界面，定位精度会明显下降。
应对手段有三个。第一，尽量保持应用版本常见，别用最新灰度版，也别用太老的版本。第二，遇到弹窗（开屏广告、权限请求、青少年模式）先手动关掉再继续，或者用指令让模型先处理弹窗。第三，把操作粒度降低，一次只让模型完成一个子任务，不要一口气下达跨五六个页面的大目标。这三个手段都解决不了的，基本就是模型没见过这种界面，只能换设备或换应用测试，或者等社区更新训练数据。
4.5 任务卡死与自我纠错的边界
最后聊一个认知问题：手机智能体并不是万能的，它有自己的纠错边界。最典型的故障模式是“重复同一个错误动作”——模型点击了一个位置，页面没变化，它又点了同一个位置，循环几次后任务卡死。这是 GUI Agent 迭代中普遍存在的难题。
处理方式不复杂：一是在智能体服务端配置最大步数和超时时间，到点自动停止，避免无限循环；二是观察日志里模型每步输出的动作和置信度，如果发现连续几步在做同一件事，多半是陷入了死循环，直接停止任务、介入处理。我自己的习惯是在指令末尾加一句约束：“如果连续两次尝试同一个操作都没有效果，就停下来告诉我”。这个简单指令能让大量卡死场景变成可控失败，而不是一直挂在那里。
5. 手机智能体的选型对照：Open-AutoGLM、云服务与 RPA 怎么选
5.1 三条路线的能力边界对比
聊完部署，很多读者可能已经在想：我到底该用本地离线方案，还是直接云端 AutoGLM，或者干脆上 RPA？我把三者的差别整理成了下面这个表，方便直接对照。
| 对比维度 | Open-AutoGLM 本地离线部署 | 云端智能体（智谱清言 AutoGLM 等） | 传统 RPA |
|---|---|---|---|
| 部署门槛 | 需要一台带 GPU 的电脑和安卓设备，初次配置较高 | 基本为零，装 App 就能用 | 需要配置自动化流程，门槛不低 |
| 运行成本 | 硬件一次性投入，后续基本零边际成本 | 依赖云服务配额，高频使用可能有限流 | 授权费加开发维护成本 |
| 数据隐私 | 屏幕截图不出局域网 | 截图上传云端 | 视具体产品而定，通常也传到第三方控制端 |
| 跨应用理解 | 依赖模型对界面的视觉理解，灵活度高 | 同左，但响应受网络影响 | 依赖元素选择器和固定流程脚本，灵活度低 |
| 稳定性 | 受硬件和模型版本影响，长任务需要人工确认 | 较稳定，但受云端负载影响 | 流程稳定，但对界面改版敏感 |
| 适合人群 | 开发者、隐私敏感机构、硬件充裕的爱好者 | 想快速体验的普通用户 | 有稳定流程固化需求的企业 |
一句话总结：RPA 适合“流程稳定、界面少变”的场景；云端智能体适合“想立刻用、不想折腾部署”的场景；Open-AutoGLM 本地离线部署适合“数据不出内网、高频调用、想深入改造”的场景。
5.2 什么情况下建议上离线方案，以及我的使用习惯
结合这段时间的实测，我给几条比较务实的建议。如果你属于下面任一情况，本地离线包是值得投入的：一是团队或公司有内网隔离要求，手机截图里的业务数据绝对不能出网；二是要做高频自动化实验，比如每天跑几十个任务样本，云端限流会非常烦；三是想研究智能体本身，本地部署可以打印每一步的推理日志，看到模型为什么点这里、为什么不点那里，这种可观测性对理解智能体行为特别有帮助。
如果只是偶尔让手机帮忙订个外卖、刷个视频，说实话云端方案体验更轻。本地部署的成本不只是一张显卡的钱，还包括维护环境、更新模型、处理各种依赖坑的时间。别被“开源”两个字迷惑，开源意味着你可以用，也意味着出了问题主要靠自己。
我个人最后的体会是：Open-AutoGLM 离线包最珍贵的不是“免费”，而是“把智能体的运行过程摊开给你看”。无论最后你决定用哪种方案，第一次体验一定要选本地部署，哪怕只是跑通一个最简单的刷视频任务。当你能亲眼看着模型对着一张真实屏幕截图，一步一步说出“这里是什么、我该点什么、为什么点这里”的时候，你对手机智能体的理解会彻底不一样。这也是我写这篇东西最想传递的一点。