我是在刷 GitHub Trending 的时候看到那条帖子的标题很直接这个 AI 操纵手机的 GitHub 项目支持 OpenClaw 干不了的活。当时我正好刚把 OpenClaw 部署完跑了几轮 skill正为它的边界头疼。OpenClaw 在 API 集成、浏览器操作、文件整理这些场景确实很强但一旦面对手机里的原生 App比如微信里发条消息、在外卖 App 里下单、在一个没有开放接口的 App 里填完一份表单它就有点“巧妇难为无米之炊”了。GitHub 上这类“AI 操纵手机”的项目恰好补上了这个缺口。它们的思路很直接把手机屏幕当成 AI 的眼睛把触摸操作当成 AI 的手让大模型一边看截图一边点屏幕。这篇文章我会从项目原理、核心特性和实际部署三个角度拆解这个方向再拿它和 OpenClaw 做一轮横向对比最后把我踩过的坑和处理方法整理成一份排查速查表。想搞 AI Agent、手机自动化或者单纯想给日常重复操作减负的朋友可以直接照着操作。1. 为什么说“操纵手机”是 AI Agent 绕不开的战场1.1 OpenClaw 的边界它擅长什么卡在哪先说说 OpenClaw。它作为一个开源的个人 AI 助手设计思路偏向“命令行大脑 外部工具链”接浏览器、接邮箱、接文件系统、接各种 API通过 skill 机制把重复工作变成可调用的函数。这套设计在桌面和云端很舒服因为大多数服务都提供了结构化接口AI 不需要“看懂”屏幕只需要“读懂”数据。但手机 App 是另一个世界。大多数 App 不开放 API你不能给它注入 JavaScript也没有 Linux 命令行可以敲。微信、美团、抖音这类应用唯一被允许的输入方式就是屏幕上的点击、滑动和键盘输入。OpenClaw 恰恰缺少这一层“人类操作界面”的适配能力——它可以帮你查邮件、整理文档、预约会议但它没法替你打开某个 App在搜索框里输入关键词再点进第一个结果完成操作。这不是 skill 不够多的问题而是底层架构决定的它没有“视觉感知屏幕 模拟触摸”这条链路。1.2 手机自动化的需求从未消失手机自动化其实是个老话题。早期有按键精灵后来有 Appium、uiautomator2 这类自动化测试框架。但它们的问题都很统一需要针对每个页面写脚本定位控件、处理等待、适配不同机型分辨率光维护成本就够喝一壶。我也用过一段时间 uiautomator2写一套跨版本稳定的 UI 自动化脚本工作量不比开发一个小功能少。而大模型出现之后这个逻辑被彻底改变了。以前是人写脚本告诉机器“点哪里”现在是人说一句“帮我把明天早上的闹钟设成 7 点”模型自己看屏幕、自己找按钮、自己决定怎么点。这种自然语言驱动的方式把手机自动化的门槛从“会写代码”降低到“会说需求”。对测试工程师来说它是提效工具对普通用户来说它更像一个能听懂人话的手机助理对 AI 开发者来说它是 Agent 能力从云端走向端侧的一个重要方向。1.3 这类项目在技术圈属于什么位置在 AI Agent 的大图谱里这类项目通常被称为 GUI Agent 或 Mobile Agent属于“计算机使用智能体”的子方向。它和 OpenClaw 这类“工具调用型 Agent”是并行的两条路线一个走结构化接口一个走视觉模拟操作。从研究热度来看这两年顶会上关于 GUI Agent 的论文明显变多GitHub 上相关的开源项目也几乎每个月都有新面孔。理解了这一点你就会明白标题里说的“OpenClaw 干不了的活”不是贬低 OpenClaw而是它俩根本不在同一个操作维度上。OpenClaw 强在“数据世界的调度”手机 Agent 强在“物理屏幕的操控”。两者在未来大概率会走向融合但现阶段能把屏幕操作做好就已经能解决很多实际问题了。2. 屏幕背后的原理这类项目是如何“看”和“点”的2.1 一条自然语言任务如何变成一串真实操作我第一次跑通这类项目时最震撼的不是它完成了任务而是它整个决策过程完全透明截图、思考、输出动作、执行、再截图形成一个闭环。拆开来看这个闭环由四个环节组成。感知层负责获取屏幕状态最常见的方法是直接截屏部分项目还会结合无障碍服务读取 UI 控件树拿到比截图更精确的元素信息。决策层是大模型核心它把截图和任务描述一起丢给多模态模型让模型推理当前处于什么页面、下一步应该做什么。执行层调用 ADB 或无障碍服务把决策转成实际操作比如点击某个坐标、滑动一段距离、输入一串文本。记忆层则保留任务开始以来的历史状态让模型知道“我刚刚点过哪里下一步该去哪”避免每次都像失忆一样重新探索。举个例子任务“打开设置把字体调到最大”会变成这样一个循环模型看到桌面截图识别出设置图标在屏幕右下角输出点击坐标点击后系统跳转到设置首页模型重新截图看到“显示”选项再次点击进入显示页面后找到“字体大小”点击进入再选择“超大”。每一步都是“看一步、点一步”而不是一次性生成整个计划。这种动态决策的好处是容错率高即使某一步点错了模型能通过新的截图发现状态不对自己纠偏。2.2 多模态大模型在其中到底做了什么要想让 AI 操纵手机核心难点不是“能不能点”而是“知不知道往哪里点”。手机页面不是一个标准的 HTML 文档不能右键查看元素也不存在一个干净的 JSON 数据源。模型能依赖的只有一张图片。这就把压力全部给到了多模态大模型它必须看懂图标语义、理解页面层级、判断哪些元素可点击。用实际经验来说模型对按钮和输入框的识别能力直接决定了项目好不好用。强一点的模型比如 GPT-4o、Gemini 系列在常见 App 上基本能一次找准目标本地小模型虽然也能跑但经常需要多探索几轮甚至会被相似图标带偏。我自己测试过用 7B 左右的本地视觉模型跑同一个任务成功率明显低于云端大模型耗时长、容易误触比较适合在隐私要求高的场景下做实验不适合当日常主力。项目一般会把模型输出的动作限制成一种结构化的 JSON方便程序解析后执行。我在这里放一个常见的输出格式示例方便你理解{ thought: 当前页面是桌面设置图标位于右下角先点击它, action: tap, x: 540, y: 1800 }有些项目做得更细致会把动作类型扩展到长按、滑动、输入文本、按键返回等滑动动作会带上起止坐标和持续时间。模型输出的质量高度依赖 prompt 设计如果你要自己改项目建议把“只输出 JSON、不要解释”写进系统提示词里能省掉大量解析问题。2.3 安全边界把手机交给 AI 前要想清楚的事把屏幕操控权交给大模型听起来很爽但必须清醒地认识到风险。模型不是人它不会像你一样对“付款”“删除”“发送”这类操作有本能的谨慎。我在测试时遇到过模型把设置页里的“恢复出厂设置”当成普通选项点进去的情况幸好那台是备用机没有造成什么损失。建议遵守三条底线第一不要在主力机上跑这类项目特别是涉及微信、银行、支付类 App 的场景第二优先使用模拟器或闲置旧手机把损失控制在可接受范围第三启动任务前设置好任务边界比如在提示词里明确“如果出现支付页面就停止”部分成熟项目也提供关键词拦截功能。安全不是项目方的责任是自己要主动兜底的。3. 实操记录从 GitHub 拉取代码到第一次自动点手机3.1 前置准备电脑、手机与三个环境项我以 GitHub 上这类项目中比较有代表性的 AppAgent 为例来讲Mobile-Agent、AutoDroid 等项目的流程也基本一致。你不需要照抄我的每一步只需要理解共性思路。准备工作分三块。电脑上一块Windows、macOS 或 Linux 都行装上 Git 和 Python 3.10 以上版本。手机上一块一台 Android 真机或模拟器真机需要进入开发者模式并开启 USB 调试不同品牌入口略有差异一般在“设置-关于手机-连续点击版本号”之后就能看到开发者选项。连接上一块电脑上要能使用 adb 命令这个是 Android 调试桥装好 platform-tools 并加入系统 PATH 即可。如果你手里没有 Android 真机Android Studio 自带的模拟器也能用。新手比较推荐先拿模拟器练手因为它可以随时重置快照而且不怕误操作损坏系统。我自己一开始就是在模拟器里跑的跑通之后再换到备用真机。3.2 安装与配置项目的关键步骤第一步从 GitHub 把项目代码克隆到本地。为了保险起见我建议你直接打开项目主页复制 README 里提供的仓库地址git clone https://github.com/项目仓库地址 cd 项目目录第二步创建 Python 虚拟环境并安装依赖。这一步很多初学者会偷懒直接 pip install 到系统环境后面依赖冲突时就知道痛苦了python -m venv venv # Windows 下执行 venv\Scripts\activate source venv/bin/activate pip install -r requirements.txt第三步配置模型参数。大多数项目会在根目录提供一个 .env.example 示例文件你复制一份改成 .env填入模型提供商、模型名称和 API Key。如果要用本地模型需要配置本地推理服务的地址和模型名。我贴一个典型的配置内容MODEL_PROVIDERopenai MODEL_NAMEgpt-4o OPENAI_API_KEYsk-xxxx DEVICE_IDemulator-5554配置里的 DEVICE_ID 可以通过adb devices命令查看到。如果你的手机已经连接这里填设备序列号如果是模拟器通常就是 emulator-5554。3.3 用自然语言下达任务并观察执行环境准备好之后连接手机并确认 adb 能正常识别adb devices如果列表里出现了设备号并且状态是 device说明连接正常。真机首次连接时手机上会弹出“允许 USB 调试”的对话框记得勾选“一律允许”。接着把手机屏幕调到亮屏状态最好手动解锁并停留在桌面然后启动项目python main.py --task 打开日历创建一个明天上午9点的提醒然后你就能在终端里实时看到模型的一步步思考过程它截了一张图识别出了日历图标点击之后重新截屏开始寻找“”号按钮……这个过程非常有意思你眼睁睁看着一个 AI 像人一样在手机屏幕上摸索。千万注意有些项目要求手机不要锁屏另外最好关闭手机上的“屏幕超时自动锁定”否则任务执行到一半突然黑屏截图就全是黑的模型会直接“瞎掉”。这个小坑我踩过不止一次。3.4 把成功轨迹沉淀成可复用模板这里分享一个很多教程不会重点讲但实际使用中非常值钱的技巧任务轨迹复用。这类项目跑一遍任务会产生一组截图操作数据如果项目本身支持保存轨迹你要主动用起来。什么意思比如你第一次让 AI 帮你订一杯常喝的咖啡它可能需要五分钟逐步探索。但它成功之后你把这组轨迹保存成模板下一次再下达同样任务时项目可以直接按照已保存的轨迹快速执行不需要再反复截图调用大模型速度快、成本低、失败率也低。如果你的项目不支持轨迹保存我建议你至少保留一份任务日志人工提炼关键步骤后续写 prompt 时能作为 few-shot 示例喂给模型。这能显著提高成功率。4. 与 OpenClaw 的实战对比互补大于替代4.1 两种架构的本质差异我把两种项目放在同一个表格里对照可以看得更清楚对比维度OpenClaw 类 Agent手机操控 Agent操作对象浏览器、命令行、API、文件系统手机屏幕、原生 App感知方式结构化数据、网页 DOM、接口返回截屏图片、UI 控件树执行方式调用工具函数、执行命令ADB 模拟点击、滑动、输入上手成本需要配置 skill、插件、账号授权需要连接设备、配置模型整体更简单适用场景桌面办公自动化、云端任务调度移动端 App 全流程操作对模型的依赖文本理解能力强即可必须有视觉理解能力模型门槛更高如果你同时跑两个项目体会会更明显。OpenClaw 就像一个坐在办公室里的助理手里握着各种系统的 API 接口和权限做事效率很高但它的世界全是数据和文本手机操控 Agent 更像一个坐在你手机前的人能看、能点、能划处理的是图形界面上的脏活累活。两者做事的“器官”不同自然谈不上谁取代谁。4.2 一个真实场景里的分工举个实际场景。假设我想在某个 App 里查一笔订单的物流状态并且把截图发给微信上的同事。如果只靠 OpenClaw它能够做的极限是打开物流公司的网页版查询入口或者调用快递查询 API。但如果物流状态只在 App 内展示或者需要登录、验证、刷新等复杂操作OpenClaw 就无能为力了。反过来手机操控 Agent 可以直接在手机上打开对应 App、输入单号、查询物流、截屏再打开微信、搜索联系人、发送图片一气呵成。我在本地把两个项目结合起来跑过一次OpenClaw 负责定时读取邮件里的物流单号把单号写入一个文本文件手机操控 Agent 每隔一段时间读取这个文件里的新单号然后在 App 里完成查询并截图保存。整个过程基本不需要人工干预这种“云端大脑 手机双手”的组合方式我觉得才是这类工具未来的正确打开方式。4.3 当前开源项目的成熟度与选型建议我在 GitHub 上看了很多个手机操控 Agent 项目整体感受是还处于从 demo 走向工具的过渡阶段。有的项目交互做得很好能显示实时操作画面但只支持特定几个 App有的项目探索能力很强但依赖昂贵的外部 API跑一次复杂任务要烧不少钱也有项目开始支持本地模型、支持跨应用任务编排这些明显是更实用的方向。选型时我关注四个点一看模型兼容性能不能替换成其他 API 或本地模型二看设备适配支持哪些分辨率和 Android 版本三看是否支持轨迹保存这一点直接影响长期使用成本四看社区活跃度有 issue 有人答、有更新有人维护的项目遇到问题才不会卡死。别只看 star 数量实际跑一跑比什么都靠谱。5. 常见问题与排查技巧实录5.1 设备连不上、截图黑屏怎么办这个问题我在换测试机时几乎每次都会遇到。adb devices列不出设备首先排查数据线很多廉价数据线只能充电不能传数据建议直接用原装线其次排查驱动Windows 系统经常需要安装手机厂商的 USB 驱动最后看手机弹窗如果提示“是否允许 USB 调试”一定要点允许。如果这些都做了还是不行执行adb kill-server然后重新adb start-server再插拔一次手机基本能解决。截图黑屏的问题相对简单先看手机是否锁屏这类项目普遍要求保持亮屏状态其次检查 USB 调试授权是否被撤销有些手机在重启后会重置授权重新确认一次即可。5.2 点击坐标偏移与控件识别不准坐标偏移是手机操控类项目最容易暴露的问题。同一个布局在不同分辨率手机上元素坐标完全不一样。比如 1080×2400 的手机和 1440×3200 的手机桌面中间图标的坐标会差出一大截。如果你换了一台手机最好把项目里的分辨率适配配置调整到当前设备更稳妥的做法是优先选择走无障碍服务读取控件树的项目让它基于控件位置点击而不是直接按截图像素点击。如果模型总是点错元素比如想点“确认”却点了“取消”可以试试在任务描述里把目标描述得更具体比如“点击页面底部蓝色按钮文字为确认”少用模糊描述。多模态模型对颜色和位置的敏感度通常比对模糊语义的敏感度高很多。5.3 模型输出不稳定JSON 解析失败我在跑任务时最崩溃的场景就是模型输出的动作不是合法 JSON程序直接报错退出。这类问题有两个常用解法。第一在系统提示词里强制要求“只输出 JSON不要输出任何解释文字”并给出一个完整的 few-shot 示例第二把模型的 temperature 参数调低到 0 或 0.1减少随机性。如果项目没有暴露 temperature 配置可以在调用模型的那段代码里手动加参数或者直接改 .env 配置。另外建议开启失败重试机制。第一次解析失败后把报错信息和模型上一次的输出一起回传给模型让它自我修正很多时候能救回来。5.4 任务卡死、误操作与安全兜底任务进行到一半卡死最常见的原因是模型在一个错误的状态里反复试探比如弹窗挡住了关键按钮、页面加载超时、或者某个按钮被系统禁用。解法是给任务设置最大步骤数超过就自动终止并保存现场截图同时要保证入口页面的干净从桌面开始执行任务成功率会高很多。误操作方面除了我前面说的不要在主力机上跑敏感任务之外还可以在项目启动时加一道保险把手机调到“请勿打扰”模式避免通知弹窗干扰模型判断关闭 App 内的广告弹窗或者在模拟器里预先一次性处理好。如果项目支持“人工确认模式”也就是每次执行前先截图给你看、你点头再操作务必开启尤其是刚上手的第一周这能帮你避免绝大多数事故。我个人的经验是这类项目把“最后一步确认”做进流程里比在技术层面追求更高准确率要重要得多。模型偶尔会突然自信点到一个你完全没意料到的地方有一个确认环节兜底既不影响效率又让人安心。最后再分享一个很实用的习惯不要一次只跑一个任务而是把日常高频操作整理成一个“任务清单”让模型按顺序执行并在每个任务之间加一个页面状态判断。比如先截图确认当前回到了桌面再开始下一个任务。这样批量处理起来比单个任务逐个启动要稳定得多也能让你真正感受到 AI Agent 给重复工作带来的减负效果。