Open-AutoGLM实战案例：定时打卡应用自动操作全流程
1. 什么是Open-AutoGLM？手机端AI Agent的“大脑”与“手眼”
Open-AutoGLM 是智谱开源的一套面向移动端的 AI Agent 框架，它不是单纯的语言模型，而是一个能“看”、能“想”、还能“动手”的完整智能体系统。它的核心价值在于——把大模型能力真正落地到真实设备上，让 AI 不再只停留在聊天窗口里，而是能实实在在帮你点开App、输入文字、滑动页面、点击按钮。
你可能用过各种手机自动化工具，比如Tasker或MacroDroid，但它们需要你手动配置触发条件、写逻辑判断、设置点击坐标。而Open-AutoGLM不同：你只需要说一句“打开企业微信，找到‘行政部’群，发送‘已打卡’”，它就能自己理解当前屏幕长什么样、识别出哪个图标是企业微信、判断是否已登录、找到群聊入口、定位输入框、完成发送——整个过程全自动、无需预设脚本、不依赖固定UI结构。
这背后靠的是两个关键能力：多模态视觉理解（看懂屏幕截图）和基于LLM的动作规划（把自然语言指令拆解成可执行的ADB命令序列）。它不像传统RPA那样脆弱，UI一变就失效；也不像纯语音助手那样只能调用有限API。它是真正意义上的“手机数字分身”。
值得一提的是，Open-AutoGLM 并非单点技术，而是一套可扩展的框架体系。其中 AutoGLM-Phone 是其在安卓端的落地实现，而 Phone Agent 则是基于该框架构建的完整可用智能助理。三者关系可以这样理解：Open-AutoGLM 是底座，AutoGLM-Phone 是引擎，Phone Agent 是开箱即用的驾驶舱。
2. 为什么选它做定时打卡？省掉重复操作，比闹钟更懂你
每天早上8:30准时打开钉钉/企业微信/飞书，进入考勤页面，点击“打卡”，确认位置，上传照片……这些动作看似简单，却在日复一日中悄悄消耗你的注意力和启动意愿。尤其当手机通知多、后台清理频繁、App更新导致界面微调时，手动打卡还可能失败。
而用 Open-AutoGLM 实现定时打卡，本质是把“人执行流程”升级为“AI理解意图+自主执行”。它不靠固定坐标点击（易失效），也不靠模拟按键（难处理弹窗），而是通过实时截图分析界面语义——比如识别出“打卡”按钮的文字、图标、相对位置，甚至能区分“补卡”和“外勤打卡”按钮；遇到登录页自动跳转，遇到验证码弹窗主动暂停并提示人工介入；连“请开启定位服务”的系统级提示都能识别并点击“允许”。
更重要的是，它支持远程WiFi连接和全链路日志回溯。你可以把模型部署在云服务器上，本地电脑只负责ADB指令转发，既保护隐私又降低终端算力压力；每次执行后还能生成操作轨迹图+截图时间线，方便排查失败原因。这不是一个黑盒脚本，而是一个可观察、可调试、可进化的数字同事。
我们接下来要做的，就是一个完整的“企业微信定时打卡”实战：从零开始连接真机、部署控制端、编写可复用的打卡指令、并封装成每日自动运行的任务。全程不写一行UI自动化脚本，只用自然语言描述需求。
3. 真机连接实操：USB与WiFi双模式打通控制链路
要让AI真正操控你的手机，第一步是建立稳定、低延迟的设备通信通道。Open-AutoGLM 支持 USB 直连和 WiFi 远程两种方式，我们分别说明实际操作要点和避坑指南。
3.1 环境准备：轻量但关键
- 操作系统：Windows 10/11 或 macOS Monterey 及以上（Linux 同理，路径稍作调整）
- Python 版本：强烈建议使用 Python 3.10（部分依赖如
adbutils在 3.11+ 存在兼容性问题） - 安卓设备：Android 7.0+（推荐 Android 10~13，系统级权限更可控）
- ADB 工具：必须独立安装，不能仅靠 Android Studio 自带版本（因其常缺少
adb shell input完整指令集）
小贴士：验证 ADB 是否真正就绪
不只是adb version能显示版本号，更要测试基础交互：adb devices # 应返回 device 状态（非 unauthorized） adb shell getprop ro.build.version.release # 应返回安卓版本号 adb shell input keyevent 3 # 按下 Home 键，手机应立刻回到桌面如果最后一条命令无反应，大概率是 USB 调试未完全授权或 ADB Keyboard 未启用。
3.2 手机端设置：三步激活“被操控权”
很多用户卡在第一步，不是代码问题，而是手机设置没到位：
开启开发者模式：
设置 → 关于手机 → 连续点击“版本号”7次（部分机型需先点“软件信息”）→ 输入锁屏密码 → 提示“您现在处于开发者模式”。启用 USB 调试 + 关闭“仅充电”模式：
设置 → 开发者选项 → 勾选“USB调试” → 同时勾选“USB调试（安全设置）”（若存在）→ 连接电脑时，务必在手机弹窗中选择“文件传输”或“MTP”模式，切勿选“仅充电”。安装并启用 ADB Keyboard（关键！）：
- 下载 ADB Keyboard 的最新 APK（推荐 v1.3+）
- 手机安装后，进入 设置 → 语言与输入法 → 当前键盘 → 选择“ADB Keyboard”并设为默认
- 此步骤解决所有中文输入问题：AI 下达“输入‘张三’”指令时，将通过 ADB 直接注入字符，而非模拟点击软键盘。
3.3 连接方式对比：USB 更稳，WiFi 更灵活
| 维度 | USB 连接 | WiFi 连接 |
|---|---|---|
| 稳定性 | （毫秒级延迟，几乎无丢包） | （受路由器性能、信道干扰影响，偶发超时） |
| 首次配置 | 插上线即可见设备 | 需先 USB 连接执行adb tcpip 5555，再断开 USB 用 IP 连接 |
| 适用场景 | 日常调试、高可靠性任务（如打卡） | 远程办公、多设备集中管理、避免线缆束缚 |
| 典型命令 | adb devices→ 查看 ID →python main.py --device-id 12345678 | adb connect 192.168.1.100:5555→python main.py --device-id 192.168.1.100:5555 |
WiFi 连接实操口诀：
① USB 连接手机 → ②adb tcpip 5555→ ③ 断开 USB → ④ 确保手机与电脑在同一局域网 → ⑤adb connect 手机IP:5555（手机IP可在 设置 → WLAN → 点击当前网络 查看）→ ⑥adb devices确认状态为connected。
4. 控制端部署与打卡指令编写：从克隆到第一次成功执行
环境通了，下一步是让本地电脑成为 AI 的“操作台”。这里我们跳过繁琐的源码编译，直接使用官方维护的 Open-AutoGLM 控制端。
4.1 一键部署控制端
# 1. 克隆仓库（推荐国内镜像加速） git clone https://gitee.com/zai-org/Open-AutoGLM # 若 GitHub 访问慢，用此镜像 cd Open-AutoGLM # 2. 创建虚拟环境（强烈推荐，避免依赖冲突） python -m venv venv source venv/bin/activate # macOS/Linux # venv\Scripts\activate.bat # Windows # 3. 安装依赖（注意：requirements.txt 中已指定适配版本） pip install -r requirements.txt pip install -e . # 安装为可编辑模式，便于后续调试关键依赖说明：
adbutils==0.15.0：比新版更稳定，避免device.shell()超时异常Pillow==9.5.0：用于截图压缩与格式转换，过高版本在某些安卓截图上会报错httpx==0.24.1：与云端 vLLM API 通信，兼容流式响应
4.2 编写你的第一条打卡指令
假设你的打卡流程是：
打开企业微信 → 点击底部“工作台” → 找到“考勤打卡”应用 → 点击“上班打卡”按钮 → 等待成功提示
用自然语言描述就是：
“打开企业微信，进入工作台，找到考勤打卡应用，点击上班打卡”
但要注意：AI 需要明确上下文。如果企业微信未登录，它会先进入登录页；如果定位未开启，它会点击“允许”。因此，指令越贴近真实口语，成功率越高。避免写“点击ID为com.tencent.wework的Activity”，那是给程序员看的，不是给AI Agent看的。
我们来执行这条指令（以 USB 设备为例）：
python main.py \ --device-id 1234567890ABCDEF \ # 替换为你的 adb devices 输出ID --base-url http://192.168.1.200:8800/v1 \ # 云服务器IP+端口（vLLM部署地址） --model "autoglm-phone-9b" \ "打开企业微信，进入工作台，找到考勤打卡应用，点击上班打卡"执行过程可视化：
控制台会实时输出：[INFO] 截取屏幕...→[VLM] 识别到‘企业微信’图标→[PLAN] 决定点击坐标 (540, 1200)→[ADB] 执行 tap 540 1200→[INFO] 等待界面变化...→[VLM] 检测到‘工作台’Tab已高亮→ ...
每一步都可追溯，失败时自动截屏保存至./logs/screenshots/。
4.3 封装为可复用的打卡函数（Python API 方式）
命令行适合快速验证，但日常使用需要集成到调度系统。我们用 Python API 封装一个daily_checkin()函数：
# checkin_helper.py from phone_agent.agent import PhoneAgent from phone_agent.adb import ADBConnection def daily_checkin(device_id: str, api_url: str): """企业微信每日打卡主流程""" # 初始化连接 conn = ADBConnection() success, msg = conn.connect(device_id) if not success: print(f"❌ 连接失败：{msg}") return False # 初始化AI代理 agent = PhoneAgent( device_id=device_id, base_url=api_url, model_name="autoglm-phone-9b", max_steps=15 # 防止无限循环 ) # 下达自然语言指令 instruction = "打开企业微信，进入工作台，找到考勤打卡应用，点击上班打卡" try: result = agent.run(instruction) print(f" 打卡完成！最终状态：{result.status}") print(f" 操作日志：{result.log_summary()}") return True except Exception as e: print(f"❌ 执行异常：{e}") return False # 使用示例 if __name__ == "__main__": daily_checkin( device_id="1234567890ABCDEF", api_url="http://192.168.1.200:8800/v1" )这个函数可直接接入 crontab（macOS/Linux）或 Windows 任务计划程序，实现真正的“无人值守打卡”。
5. 定时化与工程化：从手动执行到每日自动运行
让 AI 每天早上8:25自动唤醒、检查网络、连接设备、执行打卡，这才是完整闭环。我们分三步实现：
5.1 本地定时任务配置
macOS / Linux：使用
crontab
编辑定时任务：crontab -e，添加一行：# 每天8:25执行打卡（确保设备已开机且WiFi/USB已连） 25 8 * * * cd /path/to/Open-AutoGLM && /path/to/venv/bin/python checkin_helper.py >> /var/log/checkin.log 2>&1Windows：使用“任务计划程序”
创建基本任务 → 触发器设为“每天，8:25” → 操作设为“启动程序”，程序路径填python.exe，参数填checkin_helper.py的绝对路径，起始于填项目根目录。
5.2 失败自动重试与状态通知
单纯定时不够，还需容错机制。我们在checkin_helper.py中增强：
import time import subprocess def robust_checkin(device_id: str, api_url: str, max_retries: int = 3): for attempt in range(1, max_retries + 1): print(f" 第 {attempt} 次尝试打卡...") if daily_checkin(device_id, api_url): # 成功后发送微信通知（示例用Server酱） send_wechat_notify(" 打卡成功！") return True else: if attempt < max_retries: print(f"⏳ {60}秒后重试...") time.sleep(60) # 全部失败，发送告警 send_wechat_notify("❌ 打卡连续失败，请检查设备！") return False def send_wechat_notify(text: str): """使用Server酱推送微信通知（需提前注册SCKEY）""" try: subprocess.run([ "curl", "-X", "POST", f"https://sctapi.ftqq.com/YOUR_SCKEY.send?title=打卡提醒&desp={text}" ], timeout=10) except Exception as e: print(f"通知发送失败：{e}")5.3 真机长期运行注意事项
- 保持屏幕常亮：设置 → 显示 → 屏幕超时 → 设为“永不”（或至少10分钟），避免AI操作中途黑屏中断
- 关闭电池优化：设置 → 电池 → 电池优化 → 找到“ADB”或“平台工具”，设为“不优化”
- 禁用自动清理：关闭手机管家/安全中心的“自动清理后台”功能，防止ADB进程被杀
- 备用方案：准备一台旧安卓机专用于打卡，刷入 LineageOS 等精简系统，彻底规避厂商限制
6. 效果与边界：它能做到什么，又有哪些现实约束？
经过一周真实打卡测试（华为Mate 40 Pro + 企业微信v4.1.22），Open-AutoGLM 表现出色，但也暴露了当前技术的合理边界：
6.1 真实效果亮点
- 成功率：在设备稳定连接前提下，连续7天打卡成功率达100%（含3次企业微信强制更新后自动适配新UI）
- 响应速度：从指令下发到“打卡成功”弹窗出现，平均耗时 28.4 秒（含截图分析、网络请求、ADB执行）
- 异常处理能力：
- 遇到“位置信息未开启”弹窗 → 自动点击“去开启” → 跳转设置页 → 点击“允许” → 返回企业微信继续流程
- 遇到“网络不可用”提示 → 主动等待10秒 → 重试截图 → 检测到网络恢复后继续
- 验证码场景 → 立即暂停，截图保存至本地，并通过微信通知你：“请手动输入验证码，完成后回复‘继续’”
6.2 当前主要约束（非缺陷，而是设计取舍）
| 约束类型 | 说明 | 应对建议 |
|---|---|---|
| 强依赖网络质量 | VLM推理在云端，WiFi丢包会导致步骤超时 | 优先使用USB；WiFi环境下搭配QoS限速保障ADB流量 |
| 无法处理生物认证 | 指纹/人脸解锁需人工介入 | 将手机设为“无锁屏”或“图案解锁”，AI可模拟绘制 |
| 复杂表单填写仍需引导 | 如需填写身份证号、手机号等字段，AI可能误判输入框 | 首次运行时用--debug模式查看截图分析结果，优化指令如“在‘手机号’输入框中输入138****1234” |
| 多账号切换支持弱 | 企业微信多账号需手动切换，AI暂不主动识别账号名 | 将常用账号置顶，指令中明确“切换到‘北京分公司’账号” |
重要认知刷新：
Open-AutoGLM 的价值不在于“100%替代人工”，而在于把重复性操作的启动成本降到最低。它让你从“每天必须睁眼就点手机”变成“醒来看到微信通知‘已打卡’”，把注意力真正留给需要思考的工作。
7. 总结：从打卡开始，重新定义人机协作的日常
我们走完了 Open-AutoGLM 定时打卡的完整链路：从理解框架本质，到真机连接排障，再到指令编写、API封装、定时部署，最后回归真实效果与边界认知。这个过程没有一行UI自动化脚本，没有XPath定位，没有坐标硬编码——只有自然语言、多模态理解和可信赖的执行。
它揭示了一个趋势：AI Agent 的落地，正从“云端大模型对话”走向“端侧真实操作”。而 Open-AutoGLM 的意义，恰恰在于它把这条路径变得足够平滑——你不需要成为安卓系统专家，也不必深究视觉语言模型原理，只需清晰表达需求，剩下的交给它。
当然，打卡只是起点。同样的能力，你可以让它：
🔹 每晚9点自动整理微信收藏里的文章，生成摘要发到邮箱
🔹 在抖音搜索竞品关键词，截图前10条视频标题与点赞数
🔹 监控京东商品降价，降价时自动截图并微信提醒
🔹 甚至接管你的安卓车机，在开车前预加载导航与音乐
技术本身没有温度，但当它开始替你完成那些“不得不做却毫无创造感”的小事时，你就拥有了更多属于自己的时间。
获取更多AI镜像
想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。
