最近在搭一套 iOS 设备自动化的环境核心方案是 EasyClick iOS USB 中控 iDeviceFarm AI 工作站。说人话就是把一排 iPhone 插在电脑上用自然语言发指令比如“打开设置把飞行模式打开”系统会自动解析成设备操作并执行。这篇文章记录完整的安装和调试过程给搞设备农场、自动化测试、AI Agent 控制真实手机的朋友一个能直接抄的作业。整个方案可以理解成三层最底下是 iDeviceFarm负责把 USB 连着的 iOS 设备管理起来中间是 EasyClick iOS USB 中控负责执行脚本化的点击、滑动、输入等动作最上面是一层 AI 工作站接一个大模型把人的自然语言翻译成中控能跑的指令。这样既保留了自动化测试的稳定性和可控性又加上了 AI 的灵活性。我实际测下来这套东西最舒服的一点是不用给每台手机插线后再手动操作只要把设备挂上中控AI 就能批量指挥它们干活。无论是做多设备稳定性测试还是给 AI Agent 提供真实手机操作能力都很合适。1. 整体架构与设计思路1.1 为什么用 USB 中控而不是 Wi-Fi起步的时候我也犹豫过要不要走 Wi-Fi 方式毕竟现在不少 iOS 自动化工具都支持无线连接。但真正把几台手机放一起跑的时候USB 的优势太明显了。USB 中控的物理链路非常稳定不会像 Wi-Fi 那样出现信道干扰、休眠断连、IP 地址漂移的问题。尤其是长时间挂着跑自动化脚本无线连接经常半夜掉线第二天起来一看任务全断了。USB 线只要插好链路基本不会出幺蛾子。USB 的另一个优势是速度快截图、安装 App、拉取日志这些操作走 USB 比 Wi-Fi 快不少。做 AI 对话式操作的时候频繁截图给模型看界面状态如果走 Wi-Fi单张图可能要多等一两秒整个对话流程会明显变卡。当然 USB 中控也不是没有代价线材整理、接口数量、供电稳定性都要考虑。但和它换来的稳定与速度比这点维护成本完全值得。1.2 AI 工作站是怎么跟手机对话的很多人第一次听“AI 对话式操作苹果手机”会觉得玄乎其实拆开看就是一个非常经典的 Agent 模式用户输入自然语言 - 大模型理解意图 - 转化为结构化动作序列 - 中控执行 - 截图反馈 - 模型判断是否完成。举个例子你跟系统说“打开设置把飞行模式打开”。AI 工作站先把这句话发到大模型模型返回一个类似这样的 JSON[ {action: open_app, bundleId: com.apple.Preferences}, {action: wait, value: 1.5}, {action: tap, x: 220, y: 60} ]然后 EasyClick iOS 中控逐条解析这些动作找到对应设备执行。执行完截图再让模型看截图判断有没有成功。如果没成功模型会根据截图重新生成后续动作形成一个循环。这个思路不算新但关键点在于动作协议的设计。动作越贴近设备操作层越容易落地。你不能让大模型直接输出“帮我打开飞行模式”因为中控不认识这句话你必须约束它输出上面这种标准 JSON。这就是 AI 工作站存在的意义把大模型的模糊语言翻译成可执行、可校验、可回滚的设备指令。1.3 为什么选择这套组合而不是全包方案市面上也有很多“全家桶”式的云测平台或商业 iOS 自动化工具直接接个 SDK 就能用。但问题有两个一是贵二是封闭。设备多了以后按设备数收费的成本非常夸张而且很多平台不开放底层接口你想在上面跑自己训练的模型、接自己的 AI Agent会被限制得很死。EasyClick iOS USB 中控 iDeviceFarm 这个组合是完全本地化部署的设备数据不出内网适合对数据安全敏感的场景。iDeviceFarm 本身是开源工具提供设备枚举、安装启动 App、截图等基础能力EasyClick 中控在这之上补上了 UI 自动化和脚本执行框架AI 工作站纯粹是自己搭的一层服务想接哪个大模型都行。整套系统的扩展性很好。比如你后面想加一台设备不需要改代码直接 USB 插上iDeviceFarm 会发现它AI 工作站也能自动感知想切换不同的 AI 模型只需要改配置不影响底下两层。2. 环境准备与依赖安装2.1 硬件准备先说硬件这是所有步骤的前提。我建议准备一台 Mac mini 或者一台 Linux 服务器系统资源至少要 8G 内存、4 核 CPU。如果只是控制一两台手机普通开发机就行如果后面要挂十几台设备CPU 和内存最好给足因为 WDAWebDriverAgent跑起来还是比较吃资源的。手机方面建议 iOS 14 以上一是兼容性更好二是从 iOS 16 开始设备上需要手动打开开发者模式旧版本反而不需要。每台设备需要一个独立的有源 USB 口注意是有源 USB HUB那种十几块钱不带供电的扩展器千万别用带多台设备时电压不稳会导致设备反复重连AI 任务直接失败。还有一点容易忽略线材。不是随便一根 Lightning 或者 Type-C 线都能稳定传数据有些线只能充电插上去系统根本认不到设备。建议买苹果原装线或者经过 MFi 认证的品牌线并且做好标签方便排查问题。2.2 安装 iDeviceFarmiDeviceFarm 是整套系统的底座。安装之前需要先把系统依赖装好Mac 上最省事的是用 Homebrewbrew install libimobiledevice ideviceinstaller brew install golibimobiledevice 是 iOS 设备和电脑通信的关键库ideviceinstaller 用来安装和卸载 App。如果是在 Linux 上可以用 apt 装对应的包sudo apt-get install libimobiledevice-utils libimobiledevice-dev libusbmuxd-dev装好依赖后克隆 iDeviceFarm 官方仓库并编译git clone iDeviceFarm官方仓库地址 cd iDeviceFarm make build编译成功后直接启动服务./bin/iDeviceFarm server --port 8080启动后它会在 8080 端口监听 HTTP 请求。你可以先用/devices接口看有没有发现设备curl http://localhost:8080/devices如果列表为空先别急大概率是驱动或权限问题后面专门讲排查。2.3 配置 EasyClick iOS 中控iDeviceFarm 只是基础连接真正执行 UI 自动化动作需要 EasyClick iOS 中控把这层能力包装成可编排的脚本接口。这里的思路是EasyClick 中控作为 iDeviceFarm 的上游客户端通过它自己的协议调用 WDA 来操作手机界面。安装步骤很简单从 EasyClick 官网下载对应系统的 iOS 中控组件安装包解压后执行启动脚本./easyclick-ios-mac --server 0.0.0.0:9000启动后中控会尝试连接本机的 iDeviceFarm 服务。你需要在配置里指定 iDeviceFarm 的地址./easyclick-ios-mac --idb-url http://localhost:8080 --server 0.0.0.0:9000如果配置正确中控会把 USB 上的设备统一注册进来然后你就可以通过中控的 9000 端口对设备下发动作脚本了。这里特别强调一下 iOS 设备端的准备每台手机都要先解锁并信任这台电脑。第一次插上 USB 时手机会弹出“信任此电脑”的对话框必须点信任。同时进入“设置 - 隐私与安全性 - 开发者模式”把开发者模式打开完成后手机会重启一次。这一步不做后续很多操作都会报权限错误。2.4 确认设备被正确识别装完所有组件后先做一轮设备识别确认。我习惯用一个命令idevice_id -l这个命令会列出所有通过 USB 连接并被系统识别的设备 UDID。如果你插了 4 台手机这里就应该有 4 行。如果这里只有 2 行说明另外两台的线材或者接口有问题先排查硬件。然后看 iDeviceFarm 的日志或者请求/devices接口比对设备数量是否一致。EasyClick 中控也会提供一个设备列表页面可以看看每台设备的型号、系统版本和状态。这一步不是可有可无。如果你跳过后面会发现 AI 发指令的时候一部分设备根本没有响应排查起来特别浪费时间。设备列表对齐了说明整条链路已经通了三分之一。3. 核心实操AI 对话式操作苹果手机3.1 先用命令手动验证设备控制链路在接 AI 之前一定要先手动把设备控制链路跑通否则后面出了问题你会分不清是 AI 的问题还是设备控制的问题。iDeviceFarm 自带一套 REST API可以直接调用来验证# 截图 curl -X POST http://localhost:8080/devices/UDID/screenshot # 安装 App curl -X POST http://localhost:8080/devices/UDID/install -F fileyour_app.ipa # 启动 App curl -X POST http://localhost:8080/devices/UDID/launch -d {bundleId:com.apple.Preferences}如果这些命令都能正常返回说明设备层没问题。然后再试 EasyClick 中控的接口一般是/device/UDID/action这样的路径。随便发一个点击动作看看手机屏幕上有没有反应。我惯用的做法是先用中控点一下设置图标再截张图确认。等到截图上能看到设置界面打开了说明 EasyClick 中控和 WDA 配合正常。这一条链路打通后面接 AI 才有意义。3.2 设计 AI 动作输出协议动作协议是整个 AI 工作站的灵魂。我一开始没想太多直接让大模型输出 Python 代码去执行结果模型经常生成一些不存在的库、写错缩进、调用不存在的方法改起来非常痛苦。后来换成了结构化 JSON 协议准确率一下子上来了。你需要在 prompt 里定义清楚动作类型和参数让模型严格遵守{ deviceRequired: true, actions: [ {action: open_app, bundleId: com.apple.Preferences}, {action: wait, value: 1.5}, {action: tap, x: 220, y: 60}, {action: swipe, x1: 150, y1: 500, x2: 150, y2: 200}, {action: input_text, text: hello}, {action: screenshot, comment: 执行后截图确认} ] }为了让模型输出稳定的格式我在 system prompt 里写了严格的约束你是一个iOS设备操作助手。用户会描述想在iPhone上完成的任务。 你需要把任务拆解成动作序列只输出JSON不要输出任何解释。 支持的动作 - open_app: 打开App参数为bundleId - tap: 点击屏幕参数为x,y坐标 - swipe: 滑动屏幕参数为x1,y1,x2,y2 - input_text: 输入文本参数为text - wait: 等待参数为value秒 - screenshot: 截图用于观察结果 坐标使用逻辑分辨率屏幕大小由下列设备信息决定。还需要告诉模型当前设备的分辨率信息否则它给出的坐标可能偏到屏幕外面。我通常会把它放在 user prompt 里当前设备型号iPhone 14 屏幕逻辑分辨率390 x 844 任务打开设置打开飞行模式这样模型生成的坐标就基本靠谱了。3.3 接入大模型 API对话控制的另一端是大模型。我采用兼容 OpenAI 格式的本地模型接口这样切换模型供应商很方便。你可以用官方 SDK也可以直接用 requests 调 HTTP。下面是一段极简的 Python 代码只解决一个问题把用户指令变成动作 JSON。import json import requests SYSTEM_PROMPT 你是一个iOS设备操作助手。根据用户指令输出动作序列只输出JSON数组。 动作类型open_app, tap, swipe, input_text, wait, screenshot。 坐标基于用户提供的屏幕逻辑分辨率。 def parse_actions(user_text, model_endpointhttp://localhost:11434/v1/chat/completions): messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_text} ] resp requests.post( model_endpoint, json{ model: qwen2.5:7b, messages: messages, temperature: 0 }, timeout30 ) content resp.json()[choices][0][message][content] # 去掉可能存在的多余代码块标记 content content.strip().strip(json).strip().strip() return json.loads(content)注意把 temperature 设为 0尽量让模型输出稳定。不过即使这样偶尔还是会出现 JSON 格式错误所以在解析失败时要加一个“重新请求一次”的逻辑二次解析还失败就直接反馈给用户让用户重新描述。3.4 搭建一个最简对话循环有了动作解析和中控执行接口就可以把它们拼成一个最简对话循环了。我写了一个简单的交互脚本先发指令给模型拿到动作列表然后逐条通过 EasyClick 中控执行import time import requests def execute_action(udid, action): # action是一个dict包含动作类型和参数 return requests.post( fhttp://localhost:9000/device/{udid}/action, jsonaction, timeout10 ).json() def run_task(udid, user_text): actions parse_actions(user_text) for idx, act in enumerate(actions): print(f[{idx1}/{len(actions)}] 执行: {act}) result execute_action(udid, act) if not result.get(success): return {status: failed, step: idx, result: result} if act.get(action) wait: time.sleep(act.get(value, 1)) if act.get(action) screenshot: # 这里拿到截图后可调用多模态模型做状态判断 pass return {status: done}这个循环看起来简单实际用起来很顺手。用户输入一条自然语言指令系统就能在真机上跑一串动作。如果中途失败会返回失败步骤和现场信息方便排查。如果你还想更 AI Agent 一点可以在这个循环里加一个“看截图推理”的环节执行完每个动作后截图把截图传给一个多模态模型让它判断当前界面是否符合用户的意图。符合就结束不符合就让它重新生成下一步动作。这样对话式操作就真正闭环了。4. 常见问题与排查技巧实录4.1 USB 连接不稳定 / 设备不识别这是最高频的问题症状是设备列表里一会儿有设备一会儿没有或者干脆一台都识别不到。第一步先查硬件。换一根确定能传数据的线插到电脑的原生 USB 口上排除 HUB 供电问题。如果设备能识别那说明是线材或 HUB 的问题建议换有源 HUB并按设备数量留 20% 的功率冗余。第二步查驱动。Linux 下最常见的是usbmuxd服务没有重启插拔设备后要有意重启一下sudo systemctl restart usbmuxdmacOS 下如果遇到设备识别异常可以重启usbmuxd进程sudo pkill usbmuxd重启后系统会自动拉起新的 usbmuxd重新检测设备。第三步查权限。小概率是当前用户没有访问 USB 设备的权限。Linux 下需要添加 udev 规则允许普通用户访问规则内容网上很容易查到把libimobiledevice官方文档里的规则复制到/etc/udev/rules.d/下即可。4.2 AI 生成的动作脚本经常“跑飞”我遇到过三种典型情况第一种是模型返回的不是合法 JSON经常在开头加一句“好的我来帮你操作”。解决办法就是严格指定temperature0并且在解析时去掉可能的围栏标记。如果一次解析失败让模型重新生成一次基本能解决。第二种是坐标超界。模型不了解屏幕参数给出的坐标可能在屏幕外面。解决办法是在 prompt 里明确传入逻辑分辨率并在执行动作前写一个坐标校验器把越界的坐标 clip 到屏幕范围内。第三种是动作顺序错乱。比如用户说“打开设置再截图”模型可能先截图再打开设置。解决办法是要求模型按用户指令的时间顺序输出动作并在 prompt 中加入“必须严格按照用户指令顺序”。实测加这一句就能避免大部分顺序问题。4.3 iOS 上点击失效、系统弹窗无法处理如果你发现 tap 动作返回成功但屏幕上没有反应先检查手机是否锁屏。iOS 设备在锁屏状态下很多 UI 操作会被忽略执行动作前先通过 iDeviceFarm 唤醒屏幕。系统弹窗是另一个坎。比如定位权限弹窗、网络权限弹窗这些是系统 UI 渲染层WDA 不一定能直接点中。我目前的处理方式是在任务开始前手动把各 App 的首轮权限弹窗都处理掉。如果你的场景必须自动处理可以针对弹窗文案做 OCR识别到“允许”、“好”等关键词后基于文字位置生成点按坐标。这需要额外接一个 OCR 服务但效果很稳。还有一个偏门问题如果设备开了屏幕使用时间或者引导式访问也会导致点击失效。自动化调试期间建议把这类功能关掉。4.4 多设备并发时的资源竞争当多台设备同时跑任务时最容易出的问题是 iDeviceFarm 服务被请求打满导致所有设备都变慢。iDeviceFarm 本身不是为高并发设计的所以不要多线程直连它的 HTTP 接口最好在 AI 工作站里加一个调度队列。我的做法是每台设备一个队列AI 工作站的任务进入设备对应的队列由队列消费者串行调用 EasyClick 中控。这样一台设备同时只跑一个任务不会互相打架。设备之间是并行的整体效率也不低。另外WDA 服务在高并发下偶尔会崩溃。建议在 EasyClick 中控里配置 WDA 自动重启策略。也就是检测到 WDA 无响应时自动重新构建并启动 WDA 会话。这个机制能把你从半夜被叫醒的困境中解放出来。4.5 日志和长期稳定性建议跑 AI 对话式操作日志一定要做三份AI 层日志、中控层日志、设备端日志。AI 层记录用户指令、模型返回、动作序列中控层记录每次动作命中的接口参数和结果设备端日志用 iDeviceFarm 拉取系统日志。一旦出问题三层日志一合并基本能定位到是哪个环节挂了。长期稳定运行我用到的技巧是定期清理设备上的日志和缓存。iOS 设备日志膨胀后截图和拉取日志的响应速度会明显变慢。每周自动重启一次中控服务也能预防内存泄露。还有一个容易忽略的点USB HUB 的供电会随着温度升高而降额几台手机长期挂着充电HUB 容易过热。尽量把 HUB 放在通风处有条件的话用那种带独立供电和过热保护的工业级 HUB。最后说点实在的整套环境我从搭建到稳定跑通大概花了两个晚上。真正花时间的不是装软件而是调 WDA、调权限、调模型输出格式。尤其是“让 AI 输出的动作能稳定执行”这一步一定要在设计协议时多花心思协议定得好后面所有事都顺。如果你想接入多模态模型做界面反馈建议先把单设备的对话闭环跑通再加复杂逻辑。我个人的体会是这个东西最实用的场景不是炫技而是批量完成那些重复、繁琐、需要真实手机才能验证的测试任务。只要底座稳定AI 层怎么换都行。