1. 手机自动化这件事为什么突然变得靠谱了前几年提到“让手机自己操作App”大多数人的第一反应是按键精灵那套东西——固定坐标点击、定时循环、脚本录制回放。用过的人都知道这类方案脆得离谱换个分辨率就废App改个按钮位置就废系统升级一次可能整个脚本全挂。所以很长一段时间里手机自动化在普通用户眼里就是个玩具在开发者眼里也就是个勉强能跑的小工具。但最近一两年情况变了。大模型驱动的AI Agent开始真正落地到端侧配合安卓系统的无障碍服务Accessibility Service手机自动化的逻辑从“死记坐标”变成了“看懂屏幕再决定点哪里”。这个转变的意义非常大——它意味着自动化脚本不再依赖固定的界面布局而是像人一样去理解当前屏幕上有什么内容、哪些是可操作的控件、下一步该做什么。我手上这台备用机从去年开始就一直在跑各种自动化方案从最早的TaskerAutoInput组合到后来的Auto.js再到最近这半年密集测试的几个开源AI Agent项目踩过的坑和积累的经验足够写一篇完整的总结。这篇文章主要聊的就是GitHub上那些开源的安卓AI Agent项目它们各自的技术路线、实际表现、部署门槛以及我在真机上跑下来的一些真实感受。如果你是对手机自动化感兴趣的普通用户这篇文章会帮你搞清楚现在到底能做到什么程度、需要什么条件如果你是开发者想自己搭一套或者参与贡献那关于无障碍服务、屏幕理解、动作执行这几块的技术细节应该对你有用。全文基于我自己的实测经验不吹不黑能跑就是能跑跑不动我也会直说。2. 拆开一个安卓AI Agent里面到底有什么2.1 从“看到屏幕”到“点下去”的完整链路一个能自己操作App的AI Agent不管GitHub上哪个项目核心链路基本都是一样的截屏/读取界面树 → 理解当前状态 → 决策下一步动作 → 执行动作 → 回到第一步循环。听起来简单但每一步都有大量的工程细节。先说“看到屏幕”这件事。安卓系统给了两条路一条是截屏MediaProjection API拿到的是像素图像另一条是读取无障碍节点树AccessibilityNodeInfo拿到的是当前界面上所有控件的结构化信息——每个控件的类型、文字、坐标、是否可点击、是否可滚动等等。这两条路各有优劣截屏信息全但需要视觉模型来理解节点树信息结构化但有时候拿不到完整内容比如游戏画面、Flutter渲染的界面、WebView里的内容。我实测下来目前效果最好的方案是两条路一起用。节点树能拿到的东西直接用拿不到的部分再靠截屏视觉模型补。比如微信聊天界面节点树能拿到消息列表的文字内容但一些自定义表情、图片消息就需要截屏来辅助理解。再说“理解当前状态”。这一步就是把上一步拿到的信息喂给大模型让模型判断现在在什么页面用户的目标是什么下一步应该点哪个控件这里涉及一个关键问题——模型跑在哪里。跑在云端的话延迟高、有隐私顾虑、需要网络跑在端侧的话对手机算力有要求但响应快、数据不出设备。目前开源项目里两种方案都有后面会具体聊。最后是“执行动作”。安卓的无障碍服务提供了点击、长按、滑动、输入文字、返回、Home等基本操作。听起来够用但实际操作中你会发现很多坑有些按钮的clickable属性是false你得找到它的可点击父节点有些列表需要先滚动才能看到目标项输入文字的时候有些输入框不认无障碍的setText方法得模拟键盘输入。这些都是实际写代码时才会遇到的问题。2.2 无障碍服务整个方案的基石也是最大的坑无障碍服务是安卓系统提供的一套辅助功能框架原本是给视障用户设计的——它能让App读取屏幕上的内容代替用户执行操作。正因为这个设计初衷它的能力边界和限制都很明确。能力方面可以读取当前窗口的所有节点信息、可以执行点击/滑动/输入等操作、可以监听界面变化事件、可以全局悬浮窗显示。这些能力组合起来理论上就能实现“看到屏幕→做出决策→执行操作”的完整闭环。限制方面首先用户必须手动在系统设置里开启无障碍服务没有程序化的开启方式这是安全设计不是bug其次不同厂商的ROM对无障碍服务的管理策略不一样有些会杀后台、有些会限制节点树的深度、有些会屏蔽特定App的节点信息比如密码输入框第三节点树的信息质量参差不齐有的App写得很规范每个按钮都有清晰的contentDescription有的App全是自定义View节点树里什么都读不到。我踩过最典型的一个坑在某品牌手机上测试的时候无障碍服务明明开着但就是读不到任何节点信息。排查了半天才发现这个ROM有个“无障碍服务优化”的开关默认是开的会把长时间不操作的无障碍服务降级。关掉这个开关之后一切正常。类似这种厂商定制带来的问题在开发文档里是绝对找不到的只能靠实测踩出来。提示如果你打算在自己的手机上跑这类工具第一件事就是去设置里搜“无障碍”把所有相关的省电优化、后台限制都关掉。不同品牌的路径不一样但关键词就那几个无障碍、辅助功能、后台管理、省电策略。2.3 大模型在端侧跑还是放云端这是每个项目都要做的核心架构决策直接影响到使用体验和隐私安全。云端方案手机把屏幕信息传到服务器服务器上的大模型做推理返回动作指令。优点是模型能力强可以用很大的模型、手机算力要求低缺点是延迟明显网络往返推理时间通常2-5秒、需要联网、屏幕内容会离开设备。端侧方案模型直接跑在手机上所有数据不出设备。优点是响应快通常几百毫秒、离线可用、隐私好缺点是模型小通常3B-7B量化后、能力有限、占内存和存储。我两种方案都深度用过。云端方案在复杂任务上的表现确实更好比如让它理解一个从没见过的App界面大模型的理解能力明显更强。但延迟是真的难受——每操作一步等两三秒一个需要十步的任务就要等半分钟体验很割裂。端侧方案响应快很多但遇到复杂界面容易犯迷糊特别是需要理解上下文的时候。目前我个人的偏好是日常简单任务用端侧复杂任务或者需要强理解的场景切云端。好在现在有些项目已经支持混合模式了可以根据任务复杂度自动切换这个方向我觉得是对的。3. GitHub上值得关注的几个开源方案3.1 基于无障碍端侧小模型的轻量方案这类项目的典型特征是安装包不大几十MB、不需要联网、启动就能用。核心思路是用一个量化后的小模型通常是2B-4B参数跑在手机NPU或CPU上配合无障碍节点树做决策。我测试的一个典型项目整个架构非常清晰一个前台服务负责截屏和读取节点树一个推理引擎负责跑模型一个执行器负责把模型输出的动作翻译成无障碍操作。模型用的是某开源小模型的4bit量化版本在骁龙8 Gen 2上推理一次大概300-500毫秒加上截屏和节点读取的时间整个循环大概1秒左右。实际表现方面简单任务很稳。比如“打开设置→找到蓝牙→打开蓝牙”这种线性流程基本不会出错。“在微信里找到某个联系人发一条消息”这种稍微复杂一点的成功率大概七八成偶尔会点错。再复杂一些的比如“帮我在外卖App里点一份昨天吃过的那个套餐”就有点力不从心了小模型理解不了“昨天吃过的”这种需要记忆和推理的概念。这类方案最大的优势是隐私和离线。所有数据都在本地处理不用担心屏幕内容泄露飞机上也能用。适合对隐私敏感、或者只需要处理简单重复任务的用户。3.2 云端大模型驱动的重型方案另一类项目走的是完全不同的路线手机端只负责截屏和上报所有理解、决策、规划都在云端完成。这类项目通常支持更复杂的任务描述比如“帮我对比三个购物App上同一商品的价格选最便宜的下单”。技术实现上这类项目一般会做一个精简的客户端把屏幕信息截屏节点树摘要通过API发给后端后端跑一个能力较强的大模型可能是70B级别的返回结构化的动作序列。客户端再逐步执行这些动作。我实测的感受是理解能力确实强了一个档次。同样一个从没见过的App界面端侧小模型可能要想半天还点错云端大模型基本一眼就能看懂。但问题也很明显——每一步都要等网络往返操作节奏很慢。而且如果网络不稳定整个流程就卡住了。另外这类方案通常需要自己部署后端或者使用项目方提供的API可能有免费额度限制。对于想自己搭建的用户来说部署门槛不低需要一台有GPU的服务器或者租用云算力。3.3 混合架构目前最务实的路线混合架构是我目前最看好的方向。核心思路是简单任务端侧处理复杂任务云端处理中间有一个路由层做判断。具体实现上通常是这样Agent先尝试用端侧模型理解当前状态如果置信度高于某个阈值比如模型很确定该点哪里就直接执行如果置信度低模型不确定就把当前状态发给云端大模型请求决策。这样既保证了简单任务的响应速度又能在复杂场景下获得更强的理解能力。我测试的一个混合架构项目在“打开某个App并完成签到”这个任务上全程端侧处理总共花了不到5秒。而在“在购物App里搜索某个商品并筛选价格区间”这个任务上触发了两次云端请求总共花了大概15秒但最终成功完成了。如果全程用端侧这个任务大概率会失败如果全程用云端可能要花30秒以上。注意混合架构的难点在于“置信度判断”这个环节。判断得太保守什么任务都往云端发就失去了端侧的意义判断得太激进端侧模型瞎点一通反而把事情搞砸。目前开源项目里这块做得好的不多大部分还是靠规则或者简单的阈值来判断。4. 真机实测从安装到跑通第一个任务4.1 环境准备中最容易忽略的几件事假设你现在要从GitHub上拉一个开源安卓AI Agent项目来跑以下是我踩过坑之后总结的检查清单按重要性排序第一确认手机的无障碍服务没有被系统限制。前面提过不同厂商的ROM对无障碍服务的管理策略差异很大。我遇到过的情况包括服务开启后过几分钟自动关闭、服务在后台时节点树读取返回空、服务在特定App上被禁用。解决办法是在设置里找到“无障碍”相关的所有选项把省电优化、后台限制、智能管理之类的开关全部关掉。如果实在找不到可以在开发者选项里把“不保留活动”关掉有时候这个选项会影响无障碍服务的稳定性。第二确认手机的截屏权限。大部分项目需要MediaProjection权限来截屏这个权限每次重启手机后都需要重新授权安卓的安全设计。有些项目会做一个前台服务来保持截屏权限但即便如此系统在某些情况下还是会回收。实测下来最好在跑任务之前先手动确认一下截屏权限还在。第三确认存储和内存充足。端侧模型虽然量化后不大但加上运行时环境通常也要占1-2GB内存。如果手机本身内存就紧张跑起来会非常卡。另外模型文件通常几百MB到几个GB存储空间也要留够。第四确认输入法。有些项目在输入文字时会调用系统输入法如果你的默认输入法是第三方输入法特别是那种带云联想、带广告的可能会干扰自动化流程。建议临时切换到系统自带输入法。4.2 第一个任务该选什么很多人第一次跑这类工具上来就想让它“帮我回微信消息”或者“自动刷视频”。我的建议是第一个任务越简单越好最好是单App内的线性流程。推荐的新手任务打开设置找到“关于手机”读取系统版本号打开计算器输入一个简单的算式并读取结果打开时钟创建一个5分钟后的闹钟这些任务的共同特点是流程固定、界面简单、不需要理解复杂语义。用它们来验证整个链路是否跑通——截屏是否正常、节点树是否读得到、模型是否能正确决策、动作是否能正确执行。我见过太多人一上来就挑战复杂任务结果失败了也不知道是哪一步出的问题。先用简单任务把链路跑通确认每个环节都正常再逐步增加复杂度这是最稳妥的调试路径。4.3 跑通之后这些参数值得调链路跑通之后你会发现有几个参数对体验影响很大截屏间隔。每次循环都截屏的话CPU和电量消耗都很大。大部分项目支持设置截屏间隔我一般设500毫秒到1秒。太短了浪费资源太长了响应慢。动作执行后的等待时间。点击一个按钮之后界面可能需要几百毫秒到几秒才能加载完成。如果不等界面稳定就进行下一次截屏和决策模型看到的可能是过渡状态的界面容易做出错误判断。我一般设1-2秒的固定等待有些项目支持“等待界面稳定”的智能等待效果更好。模型温度参数。这个参数控制模型输出的随机性。温度太高模型可能做出意想不到的动作温度太低模型可能陷入重复循环。实测下来0.1-0.3之间的温度比较合适既不会太随机也不会太死板。最大循环次数。一定要设一个上限防止模型陷入死循环。我一般设20-30步超过就自动停止并报警。没有这个限制的话模型可能在一个界面上反复点击同一个按钮直到把电量耗光。5. 那些文档里不会写的坑5.1 节点树读取的“薛定谔状态”无障碍节点树最让人头疼的地方在于同一个界面不同时候读到的内容可能不一样。我遇到过的情况包括有时候能读到完整的列表项有时候只能读到可见区域的内容有时候能读到按钮的文字有时候只能读到图标的描述有时候节点树刷新很快有时候要等好几秒才更新。这背后的原因很复杂跟App的实现方式、系统的渲染机制、无障碍服务的缓存策略都有关系。实际开发中我的经验是不要假设节点树是稳定可靠的要把它当成一个“尽力而为”的信息源。读不到的内容要么用截屏补要么等一会儿再读要么换个方式读比如用坐标点击代替节点点击。5.2 输入文字这件事比想象中麻烦在安卓上通过无障碍服务输入文字标准做法是找到输入框节点调用ACTION_SET_TEXT。但实际用下来这个方法在很多App上都不生效——有的App会忽略这个动作有的App会触发但内容不对有的App干脆崩溃。更可靠的方式是模拟键盘输入先点击输入框获取焦点然后通过无障碍服务发送按键事件。但这种方式又依赖输入法的配合如果输入法弹出了候选词窗口可能会干扰后续操作。我目前的做法是优先尝试ACTION_SET_TEXT如果检测到输入框内容没有变化就降级到模拟键盘输入。同时在输入完成后加一个验证步骤——读取输入框的当前内容确认跟预期一致再继续。这个验证步骤很关键我见过太多因为输入失败导致后续全错的案例。5.3 弹窗和广告是最大的干扰源你永远不知道下一秒会弹出什么。系统更新提示、App内广告、权限请求、评分邀请……这些弹窗会打乱Agent的整个计划。模型本来打算点击“下一步”结果弹窗挡住了按钮模型可能点到弹窗上然后进入一个完全无关的界面。处理弹窗的策略我试过几种规则拦截维护一个常见弹窗的关闭按钮特征库比如“跳过”“关闭”“以后再说”这些文字每次截屏后先检查有没有匹配的弹窗有就先关掉。这个方法对已知弹窗有效但遇到新弹窗就失效了。模型识别让模型自己判断当前界面是不是弹窗、该不该关。这个方法更通用但增加了模型的负担而且小模型经常判断错。系统级屏蔽用安卓的“通知过滤”或者第三方工具屏蔽部分弹窗。这个方法最省事但能屏蔽的范围有限。我目前是三种方法结合规则拦截处理常见弹窗模型识别兜底系统级屏蔽减少弹窗数量。即便如此还是会有漏网的弹窗导致任务失败。这是目前这类方案的一个硬伤短期内很难彻底解决。6. 这类工具到底能用来干什么6.1 已经能稳定跑通的场景经过大半年的实测以下场景在这类工具上已经能比较稳定地跑通了定时签到类。很多App有每日签到领积分的功能操作路径固定、界面简单。用这类工具设置一个定时任务每天自动打开App、找到签到按钮、点击、返回。我测试的几个App连续跑一周的成功率在90%以上。信息采集类。比如定时打开某个App读取首页的特定信息天气、股价、通知然后记录下来或者转发到其他地方。这类任务不需要复杂的决策主要是读取和传递信息。重复操作类。比如批量删除照片、批量取消关注、批量导出数据。这类任务的特点是操作重复、路径固定Agent只需要循环执行同一个动作序列。跨App流程类。比如“从A App复制一段文字打开B App粘贴并发送”。这类任务涉及多个App的切换对Agent的状态管理能力有一定要求但流程本身是线性的实测成功率也不错。6.2 目前还不太靠谱的场景以下场景我试过但成功率不稳定不建议在生产环境依赖需要理解复杂语义的任务。比如“帮我找一封上周关于项目进度的邮件回复说收到了”。这需要理解“上周”“项目进度”“收到了”这些概念的语义还要在邮件列表里做筛选和匹配。端侧小模型基本做不了云端大模型勉强能做但延迟很高。需要视觉理解的任务。比如“在游戏里帮我完成日常任务”。游戏界面通常没有标准的无障碍节点全靠截屏视觉模型理解。目前的视觉模型在游戏场景下的表现还很不稳定经常认错按钮或者理解错游戏状态。需要长期记忆的任务。比如“帮我盯着这个商品降价了告诉我”。这需要Agent持续运行、记住之前的状态、检测变化。目前的方案大多是单次任务执行长期运行的稳定性和资源消耗都是问题。涉及支付和敏感操作的任务。这个不用多说让AI Agent操作支付流程风险太大了。即便技术上能跑通我也不会建议任何人这么干。6.3 一个实际案例的完整拆解拿我跑得最多的一个任务来举例每天早上自动打开某个阅读App完成签到然后打开另一个健身App记录昨天的步数。这个任务拆解下来是这样的第一步Agent启动读取当前时间确认是早上比如6点到9点之间。如果不是任务结束。第二步通过包名启动阅读App。这里有个细节直接用am start命令启动App比在桌面上找图标点击更可靠因为桌面布局可能会变。第三步等待App加载完成。这里不能死等固定时间我的做法是循环读取节点树直到检测到首页的特征元素比如“签到”按钮或者“推荐”标签出现。第四步在首页寻找签到入口。签到入口的位置不固定有时候在首页顶部有时候在“我的”页面里。Agent需要先判断当前在哪个页面然后决定是直接找签到按钮还是先切换到“我的”页面。第五步点击签到按钮等待签到成功的提示出现。这里要处理一种情况如果今天已经签过了按钮可能变成“已签到”状态Agent需要识别这种情况并跳过。第六步返回桌面启动健身App。同样的流程等待加载、找到步数显示区域、读取步数数值、记录到本地文件。第七步任务完成Agent停止生成一份执行日志。这个任务我连续跑了30天成功率大概在85%左右。失败的原因主要是App更新后界面变了需要重新适配、网络不好导致加载超时、系统弹窗干扰。每次失败后我会看一下日志调整一下对应的处理逻辑然后继续跑。7. 自己动手改代码时的一些经验7.1 从哪个文件开始读如果你想把某个开源项目改造成适合自己的版本我的建议是先从动作执行器开始读。这是整个链路里最独立、最容易理解的部分而且往往是最需要定制的地方。动作执行器通常是一个类或者一组函数负责把抽象的“动作指令”比如“点击坐标(100,200)”或者“在输入框输入文字”翻译成具体的无障碍服务调用。读这部分代码你能快速搞清楚项目支持哪些动作、每个动作是怎么实现的、有没有什么特殊的处理逻辑。读完执行器之后再去看决策部分——模型是怎么被调用的、输入输出格式是什么、有没有做后处理。最后看截屏和节点读取部分这部分通常跟系统API打交道最多也是最容易出兼容性问题的地方。7.2 添加自定义动作的套路大部分项目都支持扩展自定义动作。添加一个新动作的典型流程是在动作定义里注册新动作的名称和参数格式在动作执行器里实现这个动作的具体逻辑在模型的提示词里描述这个动作的用途和参数测试模型是否能正确调用这个动作我添加过一个“滚动到指定文字”的动作因为默认的滚动动作只能按固定距离滚动不够灵活。实现思路是循环执行小距离滚动每次滚动后读取节点树检查目标文字是否出现出现就停止。这个动作在长列表里找特定项的时候特别好用。7.3 日志和调试的重要性这类项目的调试比普通App开发要麻烦得多因为整个流程是动态的、依赖外部环境的。我的经验是一定要加详细的日志每一步的输入、输出、决策结果、执行结果都要记下来。我自己的做法是在关键节点插入日志截屏后记录截屏耗时和图像大小、节点读取后记录读到的节点数量、模型推理后记录模型的原始输出和解析后的动作、动作执行后记录执行结果和界面变化。这些日志在排查问题时非常有用。另外建议加一个“录屏回放”功能——把每次截屏的图像按时间顺序保存下来任务失败后可以回放整个操作过程直观地看到在哪一步出了问题。这个功能开发成本不高但调试效率提升巨大。8. 关于隐私和安全有些话必须说这类工具需要读取屏幕内容、模拟用户操作天然涉及大量敏感信息。我在使用和测试过程中有几个原则是始终坚持的第一敏感App不碰。银行、支付、密码管理器这类App我不会让任何自动化工具去操作。即便技术上能跑通风险也不值得冒。第二云端方案要谨慎。如果用的是云端大模型方案屏幕内容会上传到服务器。虽然大部分项目声称不会存储数据但这件事你没法验证。我的做法是涉及个人信息的界面只用端侧方案处理。第三权限最小化。只给必要的权限不要因为方便就开放所有权限。比如一个只需要读取屏幕的工具不需要通讯录、位置、相机权限。第四定期检查日志。看看Agent到底执行了哪些操作、访问了哪些界面。如果发现异常及时停止使用并排查原因。注意开源项目的代码虽然可以审计但大部分人没有精力去逐行检查。我的建议是优先选择star数多、更新活跃、有明确隐私说明的项目。如果一个项目连基本的隐私政策都没有或者代码里明显有可疑的网络请求直接放弃。9. 这个方向接下来会怎么走从我这半年多的观察来看安卓AI Agent这个方向正在快速演进。几个明显的趋势端侧模型能力在快速提升。去年跑端侧模型还经常犯迷糊今年的小模型在界面理解上已经好很多了。随着手机NPU算力的提升和模型量化技术的成熟端侧能做的事情会越来越多。多模态理解在成为标配。早期的方案主要靠节点树现在越来越多的项目开始结合截屏视觉模型。节点树视觉的双通道理解比单一通道可靠得多。任务规划能力在增强。早期的Agent基本是“走一步看一步”现在有些项目开始引入任务分解和规划模块能把一个复杂任务拆成多个子任务分别执行。这个方向如果能做好复杂任务的完成率会大幅提升。生态在慢慢形成。我看到有些项目开始做插件系统允许社区贡献针对特定App的适配模块。如果这个生态能发展起来适配成本会大大降低。不过也要清醒地看到目前的方案离“真正好用”还有距离。稳定性、兼容性、安全性这三个问题每一个都还需要大量的工程投入才能解决。如果你现在就想用建议从最简单的场景开始把它当成一个“能帮你省几步操作”的辅助工具而不是“完全替代你操作手机”的智能助手。预期放低一点体验反而会好一些。我在实际使用中最大的体会是这类工具的价值不在于“全自动”而在于“半自动”——它帮你完成那些重复、枯燥、不需要思考的操作步骤但在关键决策点还是需要你来把关。把人的判断力和机器的执行力结合起来才是目前最务实的用法。