用ESP32连接视觉模型操控真实iPhone

花约 7 美元买一块 ESP32-S3，就能让视觉模型操作真实 iPhone：看屏幕、点按钮、滑动页面。ESP32 iPhone Agent 的办法是让开发板接收投屏，再充当 USB 鼠标和键盘，iPhone 上的 App 则负责调用模型、调度动作。

它的价值在于提供了一套能回放、能导出、能修改提示词的真机实验环境。不过，7 美元只是板子的价格，运行时还要占用手机 Wi-Fi，并通过蜂窝网络访问模型，操作速度也有明确上限。

一块板子怎么同时充当眼睛和手

这套系统把「看见屏幕」和「执行操作」接成了一个循环。

开发板先建立 Wi-Fi 热点，并以 ESP32 Agent 的名字出现在 iPhone 的屏幕镜像列表里。手机通过 AirPlay 把画面传给板子，板子再通过蓝牙低功耗（Bluetooth LE，简称 BLE）转发给手机 App。App 把截图交给支持图片的 OpenAI-compatible chat API，由视觉模型决定下一步动作。

执行端走另一条路：开发板被 iPhone 识别为标准 USB 鼠标和键盘。开启 AssistiveTouch 后，鼠标点击对应触屏点击，拖动对应滑动。

它用屏幕画面理解界面，用系统接受的外设输入完成操作。

因此，模型服务可以替换。README 列出的自托管选项包括 vLLM、SGLang、llama.cpp 和 Ollama，也可以接云端 API。App 允许分别设置 planner 和 actor 模型，分别承担规划与动作执行，但原文没有给出两者怎样搭配更好的对照结果。

硬件要求也不能只看 ESP32 这个名字。README 测试的是 Seeed Studio XIAO ESP32S3 普通版，带原生 USB 和 8 MB PSRAM，不是 Sense，也不是 Plus。手机要求 iOS 18 或更新版本，并有蜂窝数据；USB-C 机型直接连接，Lightning 机型需要 Lightning to USB Camera Adapter，由手机给板子供电。

运行时只需要手机和板子，首次准备仍需要一台装有 Xcode 的 Mac。

跑通之后，真正有用的是回放和调试

安装分为刷固件、装 App 和手机端配置。

先安装 arduino-cli、ESP32 core 3.3.x，再安装 NimBLE-Arduino 2.5.x。原文给出的具体库版本和刷写命令如下：

arduino-cli lib install "NimBLE-Arduino@2.5.1"
hardware/flash.sh            # optional: [serial port] [--debug]

关键是第二行：必须通过 flash.sh 构建，因为它会应用固件需要的 BLE 缓冲区大小。不要把它当成可以随手替换的命令包装。

接着配置签名并打开 Xcode 工程：

cp ios/Config/Local.xcconfig.example ios/Config/Local.xcconfig   # set DEVELOPMENT_TEAM and IA_BUNDLE_ID
open ios/IPhoneAgent.xcodeproj                                    # run the IPhoneAgent scheme on your iPhone

第一行需要设置 DEVELOPMENT_TEAM 和 IA_BUNDLE_ID，随后在真机运行 IPhoneAgent scheme。免费 Apple ID 可以签名，但每 7 天要重新签名。付费账号对应的 Hotspot Configuration capability 用于一键加入热点；没有它，也能查看密码后手动连接。

App 内还有四步引导：通过 Bluetooth 配对开发板；加入热点并选择 ESP32 Agent 投屏；开启 AssistiveTouch，由 App 自动校准指针；填写模型 endpoint 和 key，再选择视觉模型或输入 model ID。key 存在 iOS Keychain 中。

之后就能输入「打开设置并进入 Wi-Fi」这样的目标，点击 Start，从 Dynamic Island 随时停止。重复任务可以保存，再从 Siri、Shortcuts、widgets 或 Control Center 启动。

对程序员来说，更有价值的是执行记录。每次运行都保存在手机上，进入 Runs 可以逐步回放，并看到点击、滑动的叠加标记。通过 Runs → 某次运行 → ⋯ → Export trace，还能导出截图、动作和注释，交给另一个 Agent 辅助分析。

提示词位于 prompts/，以纯文本形式随 App 打包。修改后需要重新构建，再到 Runs 比较前后行为。如果怀疑问题出在开发板，可以在 Mac 上用 hardware/tools/board_test.py 通过 BLE 模拟 App，配合 hardware/tools/README.md 和 docs/ble-protocol.md 排查。

我的判断

这个方案最值得借鉴的是可观察性：有动作回放，有 trace，也提供了绕开手机 App、单独测试板子的入口。对于会连续点击真实界面的 Agent，知道它在哪一步判断错了，比只看到任务失败更有帮助。

但原文是一份基于 README 的上手指南，没有提供任务成功率、连续运行稳定性或不同模型的对照数据。「能运行」与「适合稳定交付」之间，还需要验证。

速度有硬限制。BLE 吞吐约为 300 到 500 kbps，镜像分辨率为 480x1040，最高 5 fps。每步需要几秒，原文称主要耗时来自模型，但没有分项测量。它更适合容忍等待的任务实验。

使用范围也有限：密码输入、Apple Pay、DRM 视频等画面不会被 iOS 镜像，锁屏会停止投屏；键盘只支持 ASCII，暂不支持横屏 App。对国内用户，不能直接输入中文尤其影响实际用途。

手机 Wi-Fi 被开发板热点占用后，模型需要通过蜂窝数据访问。因此，即使 API 兼容，自托管服务也仍需解决手机能否访问的问题，原文没有展开网络配置。

和直接调用业务 API、使用系统 Shortcuts 相比，这套方案的独特价值是操作真实界面；如果任务已有稳定接口，增加截图识别和点击循环会带来更多变量。7 美元也只是板子标价，不能代表适配器、模型调用和环境准备的总成本。项目采用 MIT 许可，AirPlay 部分为 GPL-3.0，准备二次分发时要区分这两部分。

能拿来做什么

• 可以先用「打开设置并进入 Wi-Fi」这样的短任务跑通链路，再查看 Runs 中每一步的截图和动作，确认问题出在画面获取、模型判断还是输入执行。
• 如果要研究手机 Agent，可以固定任务和模型，每次只修改 prompts/ 中一处提示词，重新构建后比较 trace，积累可复查的结果。
• 对需要重复执行的个人手机任务，可以验证成功后保存到 Siri 或 Shortcuts，并在运行时保持观察，让 Dynamic Island 的停止入口随手可用。
• 如果要排查硬件链路，可以先用 Mac 上的 hardware/tools/board_test.py 单独测试 BLE；安装则只遵循 README，不运行 issues 或评论中的「quick install」一行命令。