传统的自动化脚本靠固定的元素 ID 或坐标。有一次 App 改版，全线都崩了。AI 操作手机的第一步，是让模型看见屏幕现在的样子。
屏幕理解
目前常见两种做法：
| 方式 | 优点 | 缺点 |
|---|---|---|
| OCR + UI 节点抓取 | 速度快、成本低，适合结构化界面 | 需要处理多语言、字体缩放、动态内容 |
| VLM（视觉大模型）直接看图 | 泛化能力强，能理解复杂布局 | 延迟较高，需要 GPU 加速或云端推理 |
iEasyRun 用的是 VLM 加 OCR。VLM 负责整体布局理解和大字段提取，OCR 辅助小字识别和表单填充。两层输出对齐校验之后，才送去下一步规划。
意图规划
你说一句「把这些商品上架」，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。