Open-AutoGLM部署总结：从零搭建AI手机代理全过程-开发者社区

Open-AutoGLM部署总结：从零搭建AI手机代理全过程

1. 什么是Open-AutoGLM？一个真正能“看懂”手机屏幕的AI助手

你有没有想过，让AI像人一样盯着你的手机屏幕，理解每一个图标、按钮和文字，再替你点开App、输入关键词、滑动页面、完成操作？这不是科幻电影里的桥段——Open-AutoGLM 就是智谱开源的、专为安卓设备打造的端到端AI手机代理框架。

它不是简单的语音助手，也不是只能调用固定API的工具。Open-AutoGLM 的核心能力在于多模态感知 + 自主决策 + 精准执行：

看：通过视觉语言模型实时解析手机屏幕截图，识别UI元素、文本内容、布局结构；
想：将你的自然语言指令（比如“帮我把微信里昨天收到的PDF文件发给张经理”）拆解成可执行的动作序列；
做：借助ADB（Android Debug Bridge）直接操控真实手机——点击、滑动、长按、输入文字、返回上一页，全部自动完成。

更关键的是，它不依赖预设脚本或固定界面模板。哪怕App更新了UI、按钮位置变了、弹窗样式换了，只要画面信息还在，它就能重新理解、重新规划。这种“所见即所控”的能力，让AI第一次真正具备了在移动设备上独立工作的基础。

而AutoGLM-Phone 和 Phone Agent，正是基于这一框架构建的两个典型实现。它们共享同一套底层逻辑，但在交互设计和安全机制上各有侧重：前者强调轻量与快速响应，后者则强化了人工接管、敏感操作确认和远程调试能力。无论你是在开发原型、做自动化测试，还是想打造自己的私人AI助理，这套技术栈都提供了清晰、可落地的路径。

2. 部署前必知：三块拼图缺一不可

要让AI真正“接管”你的手机，整个系统其实由三个物理/逻辑模块组成，就像一辆车需要发动机、方向盘和驾驶员——少一个，车就跑不起来。

2.1 服务端：AI大脑，负责“思考”

这是整个系统的智能核心，运行着经过微调的视觉语言模型（如 autoglm-phone-9b）。它不装在手机上，而是部署在一台有GPU的云服务器或本地工作站上。为什么？因为手机端算力有限，而理解屏幕+规划动作+生成指令，需要较强的推理能力。我们通常用 vLLM 或 Ollama 搭建高性能推理服务，并通过 HTTP API 对外提供/v1/chat/completions接口。

注意：这不是一个纯文本模型。它必须支持多模态输入——除了文字指令，还要能接收并处理 Base64 编码的屏幕截图。所以服务端部署时，务必确认模型加载方式、图像编码器是否启用、最大上下文长度是否足够（建议 ≥ 8192）。

2.2 控制端：AI的手和眼，在你的电脑上运行

它不处理复杂推理，但承担着最关键的桥梁角色：

眼：定时截取手机屏幕（adb shell screencap -p），压缩后传给服务端；
手：接收服务端返回的动作指令（如{"action": "click", "x": 320, "y": 780}），再调用 ADB 命令精准执行；
脑干：处理异常流程——当AI说“我需要你输入验证码”，它会暂停并等待你手动操作；当检测到登录弹窗或支付确认页，它会主动触发二次确认。

这个控制端，就是你即将在本地电脑上部署的 Open-AutoGLM 代码库。它轻量、灵活，Python 写成，无需编译，改几行配置就能适配不同设备和模型。

2.3 设备端：被操控的“身体”，你的安卓手机

它不需要安装任何特殊App（除了一个极简的ADB Keyboard），也不需要Root。唯一要求是：

Android 7.0 及以上（保证 ADB 兼容性）；
开启开发者选项和USB调试；
保持网络通畅（USB直连或同WiFi下ADB无线连接）。

这里没有“越狱”风险，没有隐私数据上传——所有屏幕截图只在传输瞬间存在，且可配置为本地处理；所有操作指令都经由标准ADB协议下发，完全透明、可审计。你始终是控制权的最终拥有者。

3. 本地环境搭建：从零配置控制端

现在，让我们把控制端真正跑起来。整个过程分为四步：装好工具、连上手机、拉下代码、装好依赖。每一步都直击痛点，不绕弯子。

3.1 ADB 工具：手机与电脑之间的“翻译官”

ADB 是安卓开发的基石工具，也是 Open-AutoGLM 操控手机的唯一通道。别被名字吓住，它就是一个命令行小工具，几分钟就能配好。

Windows 用户：

去 Android SDK Platform-Tools 官网下载 zip 包；
解压到任意目录，比如C:\platform-tools；
Win + R→ 输入sysdm.cpl→ “高级” → “环境变量” → 在“系统变量”中找到Path→ “编辑” → “新建” → 粘贴你解压的路径；
打开新命令提示符，输入adb version，看到版本号就成功了。

macOS 用户：
打开终端，执行：

# 假设你把 platform-tools 放在 ~/Downloads/ export PATH="$PATH:~/Downloads/platform-tools" # 让它永久生效（写入 shell 配置） echo 'export PATH="$PATH:~/Downloads/platform-tools"' >> ~/.zshrc source ~/.zshrc

验证是否成功？插上手机（开启USB调试），运行adb devices。如果看到一串字母数字组合 +device，说明电脑已识别手机。

3.2 手机端设置：三步打开“控制权限”

很多用户卡在这一步。记住：不是所有手机都叫“华为”或“小米”，但所有安卓手机的设置路径本质一致。

开启开发者模式：进入「设置」→「关于手机」→ 连续点击「版本号」7次，直到弹出“您现在是开发者”；
开启USB调试：回到「设置」→「系统和更新」→「开发者选项」→ 找到「USB调试」并打开；
安装 ADB Keyboard（关键！）：
- 去 GitHub 搜索adb-keyboard，下载最新 apk；
- 手机安装后，进入「设置」→「语言与输入法」→「当前输入法」→ 切换为ADB Keyboard。
为什么必须换输入法？因为 Open-AutoGLM 要通过 ADB 向手机发送文字，而默认输入法会拦截或忽略这些指令。ADB Keyboard 是专为此设计的“哑巴键盘”，只管收、不管问。

3.3 获取并安装 Open-AutoGLM 控制端

一切就绪，现在拉下代码，装好轮子：

# 1. 克隆官方仓库（推荐国内镜像加速） git clone https://gitee.com/zai-org/Open-AutoGLM cd Open-AutoGLM # 2. 创建虚拟环境（强烈推荐，避免包冲突） python -m venv venv source venv/bin/activate # macOS/Linux # venv\Scripts\activate # Windows # 3. 安装依赖（注意：requirements.txt 已适配主流平台） pip install --upgrade pip pip install -r requirements.txt pip install -e .

如果遇到torch安装失败：请先去 PyTorch官网根据你的系统和CUDA版本复制对应命令，单独安装。Open-AutoGLM 本身不强制要求CUDA，但控制端若需本地图像预处理（如裁剪、缩放），有GPU会快得多。

4. 连接与启动：让AI第一次“睁开眼”

现在，硬件、软件、网络全部就位。我们来执行最关键的两步：连接设备、下达指令。

4.1 双模连接：USB 更稳，WiFi 更自由

USB 直连（推荐首次尝试）：
手机用原装数据线连接电脑 → 确保手机弹出“允许USB调试”并勾选“始终允许” → 终端运行：

adb devices # 输出类似：ZY322FDQ7V device

记下这串设备ID，它就是--device-id的值。

WiFi 无线连接（适合长期使用）：
先用USB连一次，执行：

adb tcpip 5555 # 让手机监听5555端口 adb kill-server # 重启ADB服务 adb start-server

然后断开USB，确保手机和电脑在同一WiFi下，查出手机IP（设置→关于手机→状态→IP地址），再运行：

adb connect 192.168.1.100:5555 adb devices # 应显示 192.168.1.100:5555 device

小技巧：如果adb connect失败，试试在手机上用浏览器访问http://192.168.1.100:5555—— 如果打不开，说明手机防火墙或路由器限制了端口。此时请换回USB，或在路由器后台开放该端口。

4.2 一句话启动AI代理

假设你的云服务已部署好，公网IP是203.123.45.67，vLLM 映射端口是8800，设备ID是ZY322FDQ7V，那么启动命令就是：

python main.py \ --device-id ZY322FDQ7V \ --base-url http://203.123.45.67:8800/v1 \ --model "autoglm-phone-9b" \ "打开小红书，搜索‘杭州龙井茶’，点进第一个笔记，下滑三屏，截图保存"

看到终端开始滚动日志，出现📸 Capturing screen...、🧠 Sending to model...、🖱 Executing: click at (420, 890)……恭喜，AI已经开始工作了。

4.3 Python API：嵌入你自己的项目

如果你不想只用命令行，而是想把它集成进自己的自动化脚本或Web后台，Open-AutoGLM 提供了干净的Python接口：

from phone_agent.main import run_agent from phone_agent.config import AgentConfig config = AgentConfig( device_id="ZY322FDQ7V", base_url="http://203.123.45.67:8800/v1", model_name="autoglm-phone-9b", max_steps=20, enable_screenshot=True ) # 启动一次任务（阻塞式） result = run_agent( instruction="给微信置顶好友‘李四’发一条消息：‘会议推迟到下午三点’", config=config ) print("任务状态:", result.status) print("最终反馈:", result.final_feedback)

这个API屏蔽了所有ADB细节和网络重试逻辑，你只需专注“要做什么”，剩下的交给框架。

5. 实战效果与避坑指南：那些文档没写的真相

部署成功只是开始。真正考验体验的，是它在真实场景下的鲁棒性。根据我们实测数十台不同品牌、不同安卓版本的真机，总结出最常遇到的三类问题及解法：

5.1 屏幕识别不准？先看这张图“喂”得对不对

Open-AutoGLM 的视觉理解能力高度依赖输入截图的质量。我们发现，以下情况会导致识别率断崖式下跌：

屏幕亮度太低：暗色主题下文字对比度不足，模型容易漏字；
状态栏/导航栏遮挡：截图包含顶部状态栏（时间、信号）和底部导航键，会干扰UI元素定位；
动态模糊：手指正在滑动时截图，画面拖影，模型误判为“多个重叠按钮”。

解决方案：
在main.py中找到capture_screen()函数，加入两行预处理：

# 截图后，自动裁掉顶部状态栏（约80px）和底部导航栏（约120px） img = img[80:-120, :] # 高度方向裁剪 img = cv2.resize(img, (720, 1280)) # 统一分辨率，提升模型泛化性

5.2 动作执行失败？检查“坐标系”和“时机”

ADB 的input tap x y命令，坐标是相对于屏幕左上角的像素点。但不同手机DPI不同，同样坐标在2K屏和HD屏上，点击位置可能差出半屏。

解决方案：
Open-AutoGLM 默认使用归一化坐标（0~1），但部分老旧机型驱动不支持。此时应改用绝对坐标，并在启动时传入真实分辨率：

python main.py \ --device-id ZY322FDQ7V \ --screen-width 1080 \ --screen-height 2400 \ ...

同时，加一句time.sleep(0.5)在每次点击后——别小看这半秒，它能让App有足够时间响应动画、刷新界面，避免“点了没反应，AI以为失败，反复点”。

5.3 模型“装傻”或乱码？八成是服务端参数没对齐

最让人抓狂的，是终端一直打印{"error": "context length exceeded"}或返回一堆乱码符号。根本原因往往不在控制端，而在服务端vLLM的启动参数。

必须核对的三项：

参数	正确值	错误示例	后果
`--max-model-len`	≥ 8192	2048	截断长截图编码，丢失关键UI信息
`--gpu-memory-utilization`	0.95	0.99	显存爆满，请求直接拒绝
`--dtype`	bfloat16	float32	推理变慢3倍，延迟高导致超时

建议启动vLLM时，用这个最小可行命令：

python -m vllm.entrypoints.api_server \ --model zhipu/autoglm-phone-9b \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.95 \ --dtype bfloat16 \ --port 8800