第一步：屏幕理解——AI 是怎么“看”手机的
传统的自动化脚本依赖固定的元素 ID 或坐标定位，一旦 App 改版就全线崩溃。而 AI 操作手机的第一步，是让模型“看见”屏幕的实际样子。
目前主流的实现方式有两种：
| 方式 | 优点 | 缺点 |
|---|---|---|
| OCR + UI 节点抓取 | 速度快、成本低，适合结构化界面 | 需要处理多语言、字体缩放、动态内容 |
| VLM（视觉大模型）直接看图 | 泛化能力强，能理解复杂布局 | 延迟较高，需要 GPU 加速或云端推理 |
iDeviceFarm 采用VLM + OCR 混合方案：VLM 负责整体布局理解和大字段提取，OCR 辅助小字识别和表单填充。两层输出经过对齐校验后才送入下一步规划。
第二步：意图规划——把一句话拆成 N 步
当你说一句「把这些商品上架」时，AI 需要做一系列推理：
- 识别意图类型：这是电商铺货类任务，映射到 worklfow_id=“list_products”（如果有对应模板的话）。
- 提取槽位参数：价格范围、商品分类、目标平台——这些是工作流必需的填空项。
- 生成步骤图：把任务展开为 ordered steps 序列，每一步标注要调用的原子能力和断言条件。
关键难点在于容错和动态应变。理想情况下，第 3 步成功但第 5 步失败，系统不应该全盘重来，而是定位到第 5 步的异常原因，必要时回滚到最近成功状态后重试。这就是为什么我们强调不靠模型“感觉”，要靠执行+断言+回传闭环。
第三步：操作执行——每一步都有回执
这是最容易被忽略但也最关键的一环。一个可靠的执行层必须做到：
- 原子性：每次操作独立完成，互不干扰。比如 tap 不会影响 input 的结果。
- 断言机制：每个动作执行后检查屏幕反馈是否符合预期。点击按钮后弹出的是预期弹窗吗？输入文本后光标位置对吗？
- 状态回传：进度和结果实时推送到控制台，供人工监看。
实现上，这一步由Agent 执行端承担——每台手机上的原生客户端（iOS Swift App 或 Android Java/Flutter），通过 WebSocket 接收 farm 下发的 task_dispatch 消息，然后在本机执行操作并把 result 回传。整个过程不走第三方服务，数据留在你的电脑里。
协议与数据传输
连接 farm 控制面和 Agent 执行端的通道是基于WebSocket + JSON的轻量级协议，主要消息类型包括：
| 消息类型 | 方向 | 用途 |
|---|---|---|
| register | Agent → Farm | 设备注册，上报 ID、名称、平台(ios)、能力标签 |
| heartbeat | Agent ↔ Farm | 周期性心跳保活，超时标离线 |
| task_dispatch | Farm → Agent | 下发步骤图或工作流引用 |
| task_progress/task_result | Agent → Farm | 上传进度和最终结果 |
| task_cancel | Farm → Agent | 取消正在执行的任务 |
这套协议的设计原则是简单、幂等、可扩展：每条消息都有 protocolVersion 字段标记版本兼容性，task_dispatch 可以多次下发（覆盖上一次未完成的），agentKind 预留了扩展位以便后续支持 Android/HarmonyOS。
总结：可靠性比花哨更重要
回到最初的问题：“AI 操作手机是怎么实现的？“答案是：视觉理解 + 意图规划 + 原子执行闭环。但这三个字背后是一套系统工程——不只是调个大模型接口那么简单。真正的核心竞争力不在于”AI 有多聪明”，而在于当某一步失败时，系统能不能自己找回来。