7美元ESP32让AI操控iPhone：本地视觉模型实战

苹果花了17年让开发者相信，控制iPhone需要Xcode、99美元的开发者账号，以及一张比沙发还贵的桌子。Henry Yuan用7美元就证明了这套说法不成立。

他的开源项目esp32-iphone-agent在10月11日以12星的“屎帖”姿态出现在时间线上——“一块7美元的ESP32就能让AI代理操控一部未越狱的iPhone”。Hackaday在10月14日跟进报道。等我克隆下来时，它已经有2975颗星。你还不算太晚。

这个项目的精髓不在AI，而在硬件层面的“异端”。Yuan把经典的计算机使用代理拆成三个器官，每个都用现成零件拼出来：

• 眼睛：AirPlay镜像
• 手：一块伪装成USB鼠标键盘的ESP32-S3
• 大脑：任何兼容OpenAI接口的视觉模型

没有WebDriverAgent，没有CoreDevice破解，也没有需要苹果签名的手机端App。只有一块微控制器，而iOS天然信任它——因为在系统眼里，它就是一只鼠标。

我按照独立创作者的实际情况重建了这套系统：没有像Henry演示时那样用两块DGX Spark跑Qwen3-VL-Flash，而是一块消费级GPU加Ollama，搭配7B视觉模型。README对最吓人的部分一笔带过，所以我要重点谈谈安全模型——因为我们刚刚造出来的东西，本质上是一个Wi-Fi控制的USB HID注入器。

眼睛：UxPlay加GStreamer的JPEG管道

v0.1.0的原始架构——大多数人仍会构建它，因为调试更简单——有一种废土式的美感。

iPhone →（Wi-Fi）AirPlay → 运行UxPlay的Mac/Linux主机 → GStreamer → JPEG → 你的代理。

Yuan在Hackaday的说明写得很直白：屏幕镜像由UxPlay捕获，然后用“GStreamer管道把屏幕以JPEG流的形式喂给任意AI代理”。UxPlay是个被低估的英雄：它是基于GStreamer插件的真正AirPlay接收器，你的iPhone以为只是在向电视投屏。

新固件里Yuan玩得更野：ESP32-S3自己开一个叫ESP32 Agent的热点，自己就是AirPlay接收器，把H.264通过BLE传给一个iPhone App。手机保留蜂窝数据给模型用，Wi-Fi则被“劫持”了。

两种方式都给你Xcode自动化给不了的东西：真实的帧缓冲。不是截图API，而是实际渲染的屏幕，约5fps，480x1040。低到让BLE扛得住，高到让视觉语言模型读得懂。把这些base64图像喂给/api/v1/chat/completions，这就是你的眼睛。

AirPlay镜像协议是苹果的私有投屏标准，基于RTSP协商和H.264视频流传输。UxPlay作为开源实现，逆向还原了接收端逻辑，使非苹果设备能伪装成Apple TV接收iPhone屏幕。其技术核心在于GStreamer多媒体框架：通过管道（pipeline）将H.264裸流解码、缩放、编码为JPEG序列，再以base64编码送入视觉模型的图像输入接口。这一链路的价值在于绕过了iOS的截图API限制——截图API需App在前台且被授权，而AirPlay镜像捕获的是系统级帧缓冲，对自动化代理而言是更底层的“眼睛”。

手：ESP32-S3作为USB HID，以及AssistiveTouch的关键作用

这是让我笑出声的部分。

苹果永远不会让一个随机USB设备点击屏幕。但它会让辅助功能鼠标移动光标。打开AssistiveTouch，插上USB鼠标，iOS会画出一个可以拖动的小指针。点击=轻点，拖动=滑动。

Yuan的固件做的正是这件事：板子是标准USB鼠标和键盘。开启AssistiveTouch后，鼠标移动屏幕指针，所以点击就是轻点，拖拽就是滑动。我烧录的是一块Seeed XIAO ESP32S3——普通版，8MB PSRAM，不是Sense也不是Plus，大约7美元。任何带原生USB和PSRAM的ESP32-S3都行。iOS 18+直接插USB-C，Lightning接口则需要那个倒霉的30美元相机转接头。

板子通过TinyUSB暴露两个HID接口：相对鼠标和ASCII键盘。电脑通过Wi-Fi（旧版）或BLE（新版）告诉它执行move x y、click、type "hello"，它就照做。

天才之处在于指针漂移。因为鼠标是相对坐标，每次移动都会累积误差。Yuan的App会跟踪误差，在角落重新归位，并在精确点击前晃一下指针，在屏幕上找到它并修正偏差。那个“晃动”就是我的自动化不再点不中Safari里那个小x的原因。

USB HID（Human Interface Device）协议是USB标准中定义人机交互设备的类别，键盘、鼠标、游戏手柄均属此类。操作系统对HID设备有天然信任：插入即用，无需驱动签名或用户授权。ESP32-S3通过TinyUSB软件栈模拟HID描述符，使iOS将其识别为标准鼠标键盘——这正是绕过苹果应用签名体系的物理层突破口。攻击面在于，HID协议本身不包含设备身份认证机制，任何能枚举为HID的微控制器都可注入输入事件。

把DGX Spark换成一块消费级GPU上的Ollama

README很诚实：“项目开发时使用nvidia/Qwen3.8-Flash-Next-NVFP4，部署在两块DGX Spark（TensorFold）上。”如果你有2万美元闲钱，那很酷。

我的创作者配置：

• 主机：M2 MacBook Air + RTX 4060 eGPU，或者直接用4070笔记本
• 服务器：ollama serve或带视觉的llama.cpp --server
• 模型：qwen2.5vl:7b或minicpm-v:2.6。Qwen空间定位更准，MiniCPM更快。
• API：任何接受图像的OpenAI兼容聊天API：云端API或你自己的服务器

在iPhone App里，你可以分别设置规划器和执行器模型——在一块GPU上你绝对应该这么做。我用Qwen2.5VL 7B做执行器（快速点击），Wi-Fi环境下用云端量化Qwen2-VL 32B做规划器，本地则用同一个7B加更长的系统提示。

本地7B的每步延迟，从JPEG输入到HID命令输出：

• 眼睛（AirPlay→JPEG）：180-250ms
• 视觉推理（Ollama 7B Q4_K_M on RTX 4060）：1.8-2.4s
• 手（Wi-Fi→USB HID→指针稳定）：350-600ms
• 屏幕稳定等待：800ms

总计：约3.5秒一步。云端GPT-4o只要1.2秒，但会把你的银行界面泄露给OpenAI。本地更慢，但它是你的。BLE带宽约300-500kbps，所以屏幕镜像很小（480x1040，≤5fps）；每一步要几秒，大部分花在模型上——这不是bug，是物理规律。

规划器与执行器：一个模型还是两个

Yuan在prompts/里附带两个提示词——纯文本，打包在App里，改完重新编译即可。

这比你想的更重要。

• 单模型方案：一个VLM接收“目标：设闹钟周一/周二早8点。当前屏幕：……什么动作？”，输出{"action":"tap", "x":512, "y":1340}。简单，但走6步后就忘了为什么点，开始循环。
• 双模型方案：规划器（更大更慢）说“第1步：打开时钟App。第2步：点闹钟。第3步：……”，执行器（更小更快）只根据当前屏幕执行第2步。Yuan的App就是这么跑的：解码→视觉模型→动作——一个规划器加一个执行器：点击、滑动、绘制、输入、按键、回主屏、完成。

在一块GPU上，每3步跑一次规划器，不要每步都跑。缓存计划。执行器在短视野下出错更少。

我修复卡循环的提示词改动：

“如果上次动作后屏幕没变化，说明你 MISS 了。晃动指针，把点击半径增加20px，或者改用滑动。永远不要重复相同坐标。”

加一个变化检测器：每次动作后等屏幕稳定，告诉模型是否有变化。如果image_diff < 2%，强制重新规划。

视觉语言模型（VLM）的空间定位能力指模型将自然语言指令映射到图像坐标的能力，通常通过边界框预测或坐标回归实现。Qwen2.5VL系列在UI元素定位基准（如ScreenSpot）上表现优于同规模模型，因其训练数据包含大量GUI截图与元素标注。但7B模型在480x1040低分辨率输入下，对小于40px的图标仍易产生偏移，这就是原文强调“晃动指针校准”的根因——模型输出的是相对坐标估计，硬件层需要闭环修正。

延迟与失败循环：校准、重规划、卡死状态

说实话：这套设备会失败得很搞笑。

我在50个任务中记录的失败模式：

1. 校准漂移：点击10次后指针偏了30px。修复：Yuan的App每5个动作在角落重新归位，精确点击前晃动。照做。别信绝对坐标——屏幕宽高是相对的，要配合校准数据存储。
2. iOS黑洞：iOS不镜像某些屏幕（密码输入、Apple Pay、DRM视频）；手机锁屏时镜像停止。你的代理瞬间失明。需要一个超时机制，暂停运行并在连接恢复时从同一步继续。
3. 键盘地狱：键盘输入仅ASCII。想输中文？不行。它通过USB键盘事件输入，你得到的就是美式键盘能打出的东西。
4. 卡死状态：模型看到“闹钟已设置”开关就以为完成了，但没点保存。加一个只有规划器能调用的finish动作，并要求连续两次finish投票。

我的修复循环：每次运行都保存在手机上，逐步回放并画出点击位置，导出轨迹用于分析。用它。

威胁模型：这证明了Wi-Fi控制HID注入器有多容易

README说“只自动化你拥有的设备和账号”。它应该用更大字号写：这是一个带无线电的BadUSB。

你往iPhone里插了一块7美元的板子，它：

• 由手机供电
• 模拟鼠标+键盘（所以能在任何地方输入，包括密码框）
• 运行一个手机自动加入的Wi-Fi热点，自带AirPlay接收栈（GPL-3.0部分）
• 接受BLE命令驱动HID，固件是你用flash.sh烧的

旧版里命令通过Wi-Fi从Python服务器来。新版通过App的BLE来，但板子仍然控制HID。如果那个BLE特征没有用滚动密钥认证——NimBLE-Arduino默认就没有——10米内任何人都能命令你的手机开始打字。

这直接关联到硬件植入物的研究。Seeed XIAO正是投递式植入物的理想尺寸：塞在线缆里，看起来像个转接头，永远供电，除了自己开的热点外与网络隔离。苹果信任它，因为它是HID。iOS的AssistiveTouch是辅助功能，不是安全边界。

防御措施：

• 烧录时修改secrets.h，启用NimBLE安全连接
• 永远不要无人看管地插着板子
• iOS：设置→辅助功能→触控→AssistiveTouch→设备→用完就忘记
• 如果做红队：记住AirPlay镜像不捕获密码/Apple Pay——你拿不到Secure Enclave屏幕，但其他一切都能拿到

Yuan做了负责任的披露：仓库有SECURITY.md和负责任使用说明。但观点依然成立：无需Xcode的iPhone自动化，也意味着无需Xcode的iPhone利用。

独立构建的BOM（我实际使用的）：

• Seeed XIAO ESP32S3（约7美元）
• 旧iPhone需要Lightning转USB相机转接头（约30美元）
• Mac或Linux主机，arduino-cli + ESP32 core 3.x，UxPlay，python venv
• Ollama或llama.cpp加视觉模型——我基准测试了qwen2.5vl:7b

如果你有GPU，总成本：7美元。总时间：一个下午烧录、校准，看一个机器人尝试设闹钟、失败三次然后成功。

苹果建了围墙花园。我们只是找到了老鼠洞。

背景补充

BLE GATT安全模型：蓝牙低功耗的通用属性协议（GATT）中，特征值（characteristic）的读写权限由属性标志定义，但默认不强制链路层加密或应用层认证。NimBLE-Arduino栈默认启用“Just Works”配对，无MITM保护，攻击者可中间人截获或伪造HID指令。启用LE Secure Connections需在固件中显式配置密钥分发与绑定标志，否则ESP32暴露的HID控制特征等同于无口令的远程键盘。此为原文威胁模型的技术底座。