从 0 到 1 做手机 AI Agent：模块划分、技术选型与踩坑实录

从 0 到 1 做手机 AI Agent：模块划分、技术选型与踩坑实录

「AI 替你操作手机」这两年从 demo 走向了产品。作为开发者，我从立项到上线完整走过一遍，把工程上的关键决策和踩过的坑梳理出来，给想入这个方向的同学参考。案例以我们做的侠客工坊（安卓端 AI Agent）为蓝本。

一、先想清楚：你要做的是「手」还是「脑」

手机 AI Agent 的第一性问题是分清楚边界。我们的架构拆成三层，各司其职：

1. 感知层：截屏、OCR 识别文字、目标检测定位按钮——这是每步操作的输入；
2. 决策层：理解用户意图 + 结合当前界面状态，输出「下一步点什么」；
3. 执行层：模拟点击、输入、滑动，操作后回读界面确认结果。

关键取舍：感知和执行必须端侧做（200ms 级反馈、画面不出本机），决策可以上云（复杂规划依赖大模型能力）。这也是后面所有技术选型的前提。

二、技术选型：四件事定生死

1. 操作入口：无障碍服务 vs 坐标脚本

坐标脚本第一版就能跑，但 App 一改版就废；无障碍服务（AccessibilityService）拿到的是语义化的控件树，抗改版性强，还不需要 Root。我们选了无障碍为主、视觉识别兜底的双通道：Canvas 自绘页面（游戏、小程序）无障碍拿不到，就得靠视觉。

2. 感知模型：OCR + 目标检测

开源 OCR 引擎在长截图上的准确率是刚及格的水平，中文场景要专门调优；目标检测模型负责「按钮在哪」，要和 OCR 的文字结果做对齐融合——这块的准确率直接决定用户体验，值得投入。

3. 决策模型：端侧小模型 + 云端大模型

试过三种方案：

• 纯端侧 7B 级模型：响应快、隐私好，但复杂多步规划能力不足；
• 纯云端大模型：规划能力强，但每步都要截图上传，延迟和流量扛不住；
• 端云协同：端侧小模型处理短指令和高频动作，复杂规划走云端，敏感数据（验证码、支付页）留在端侧。最终选了第三种。

4. 任务状态管理

跨几十步的任务，上下文很容易超限。我们给 Agent 加了显式的任务状态机：目标不变，逐步更新「已完成步骤 + 当前界面摘要」，而不是把所有截图历史都塞给模型。

三、踩过的坑，每一个都花过真金白银

• 无障碍权限被系统回收：部分 ROM 会周期性回收无障碍权限，需要在关键节点检测并引导用户重新开启，否则运行中突然「失明」；
• 界面隐私合规：截屏数据默认全量上传云端是绝对红线，必须端侧做脱敏——监听本地设置，凡是支付页、验证码框直接停止外传；
• 「图片转存」式延迟：云侧图片处理慢会让用户以为卡死，体验上要做乐观更新 + 明确进度提示；
• 动态画面识别率：直播、短视频这些每帧都变的界面上，单纯 OCR 会频繁误判，我们加了「帧稳定检测」：画面连续 N 帧不变才执行操作，误触率明显下降。

四、给后来者的路线建议

1. 先做单任务闭环（比如「点一杯咖啡」），跑通感知→决策→执行全链路，再横向扩展任务；
2. 界面识别宁可保守，不要激进——一次误点可能比「慢 2 秒」更劝退用户；
3. 从一开始就设计「人工确认」节点：支付、注销、隐私操作必须真人点头，这是产品的信任底线；
4. 安卓用户规模大、无障碍生态成熟，落地成本最低，但也要留意系统版本碎片化带来的适配工作量。

手机 Agent 的方向，本质上是把「人学习 App 界面」变成「AI 理解界面」。这条路刚起步，坑很多，但每一步踩下去，都是在给下一代人机交互铺路。