7 美元 ESP32 讓 AI 操作 iPhone：新版砍掉電腦，只剩手機加板子

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

10 月 15 日上午 10 點多（台北時間），開發者 Henry Yuan 在 X 更新了他的開源專案 ESP32 iPhone Agent：一塊約 7 美元的 ESP32-S3 開發板，配上任何 OpenAI 相容的視覺模型，就能讓 AI 看著真實 iPhone 的畫面，用滑鼠鍵盤的方式操作它，全程不需要越獄。官宣推文的姿態也擺得很明白：「一塊 7 美元的 ESP32 讓 AI 代理操作一台原封不動的 iPhone，就這樣。」這次更新的重點只有一句話：電腦退場。舊版要在手機旁邊擺一台 Mac 或 Linux 電腦，新版把接收畫面與執行代理分別搬上板子和手機 App，執行時真的只剩手機加板子。

這個 repo 的節奏也快：10 月 11 日建立，官方示範影片自己說「不到三天拿到約 2,000 顆星」，到 10 月 19 日已達 3,100 顆星、403 次 fork，最後一次提交在 10 月 18 日，內容是修正 README 對模型選擇方式的描述。熱度不只反映在星數：官宣推文七天累積近 800 個讚（777），更早出現的中文社群介紹推文讚數還超過它（863）。想跟進的人，現在看到的是一個活著、但每天都在變的專案。

Pin

時間軸本身就能說明「新舊架構」的混亂從哪裡來。10 月 12 日，中文社群就已經有人用「無需開發者帳號、無需 Xcode、無需越獄、不用安裝任何 App」介紹這個專案（連人民幣價格都換算好了），這幾句話對當時的舊版是成立的：眼睛和腦都在電腦上，手機什麼都不用裝。10 月 15 日凌晨，舊版以 v0.1.0 之名正式打包發布（官方標題就寫著「電腦在中間」）；五個多小時後的同日上午，砍掉電腦的新版就上了主分支。三天內兩種形態並存，難怪流傳的說法會對不上現況。官方文件也提醒：新舊兩版的韌體不能互換，要用哪個分支，就燒哪個分支的韌體。

Pin

舊版電腦在中間，新版電腦消失

官方文件用一張對照表把新舊差異講清楚。舊版（v0.1.0，保留在 legacy 分支）的眼睛，是電腦上跑的 UxPlay 接收 AirPlay；腦是電腦上的 Python 伺服器加網頁介面；手機上什麼都不用裝。新版（main 分支）把這三件事重新分配：眼睛搬到板子上的 AirPlay 接收器，腦搬進同一支 iPhone 上的 ESP32 Agent App，手機上要裝自己建置的 App。官方給出的改版理由很直白：電腦是最難帶著走、也最難隨身架設的部分。

新版資料流可以拆成三段看：

• 眼睛：板子開自己的 Wi-Fi 熱點，在手機的螢幕鏡像清單裡顯示為「ESP32 Agent」。板子收下 H.264 影片串流但不解碼，直接經低功耗藍牙（BLE）轉傳給手機上的 App。
• 雙手：板子對手機扮演標準 USB 滑鼠鍵盤。開啟 iOS 的輔助觸控（AssistiveTouch）後，滑鼠游標就是手指：點一下是輕觸，拖曳就是滑動。
• 腦：App 解碼畫面、截圖送給視覺模型，模型決定下一步，指令經藍牙回板子、再從 USB 送進手機。

有個細節容易被忽略：代理在跑的時候，手機的 Wi-Fi 連的是板子熱點，這條路上沒有網際網路，模型請求必須走行動網路。官方把這條列為硬條件，寫在限制清單裡。官方 100 秒示範影片把接線、指標校正、下達「每天早上 7 點的鬧鐘」任務、逐步回放四段都演了一遍：畫面上的任務指令就一行「set a daily 7 AM alarm」，校準段只要求輕點一下，最後鬧鐘確實出現在時鐘 App 裡。影片開場白是「人們說 AI 總有一天會替我們用手機」，中段挑模型時強調雲端 API 或自己的伺服器都行，收尾一句則是「我相信這會改變遊戲規則」：這個專案賣的從來不是模型，是接線方式。

板子不思考，模型自己帶

README 反覆強調板子的角色是接線，不是運算。模型端點完全自帶：任何 OpenAI 相容、能吃圖片的 API 都可以，雲端服務或自架（vLLM、SGLang、llama.cpp、Ollama 都被官方點名）都行。App 會列出端點上的模型供挑選，也可以分別指定規劃與執行要用的模型；10 月 16 日合併進主線的 OpenRouter 設定（issue #11），則給想一次接多家模型的讀者一條少管幾組金鑰的捷徑。提示詞就是 prompts/ 目錄下的純文字檔，改完重新建置就生效。

照官方文件的設計，資料的邊界也攤得開：會離開手機的，是送往你自己指定端點的截圖與指令，金鑰存在鑰匙圈；每次執行的截圖、動作與註記都留在手機上，可回放、可匯出。畫面要給誰看，在你填端點那一刻就決定了，這是「模型完全自由」的另一面：自由等於後果自負。

官方自述的開發環境可以當參考值：權重用 nvidia 的 Qwen3.8-Flash-Next-NVFP4，在兩台 NVIDIA DGX Spark 上以 TensorFold 專案提供服務。這是作者宣稱的環境，尚未見第三方重現；示範影片裡也出現同一套設定的畫面：Qwen 3.8 跑在家裡的 DGX Spark 上。對一般讀者比較實際的讀法是「模型完全自由」：想省事接雲端 API，想讓畫面截圖留在自己手裡就自架端點。

開始之前的清單，比 7 美元長

7 美元是板子的參考價（README 原文寫 About $7），不是整套系統的價格。官方硬體表列出的條件如下：

• 板子：官方測試用的是 Seeed Studio XIAO ESP32S3 的標準版（8 MB PSRAM），並明確排除 Sense 與 Plus 兩個變體。外觀相近的板子規格不同，不能只看系列名稱下單。官方也說理論上任何 USB-C 埠具備原生 USB、帶 PSRAM 的 ESP32-S3 都能用，但這句是推測，不是保證。
• 手機：iOS 18 以上，且要有行動網路。USB-C 機型直連；Lightning 機型要多一條相機轉接器，而且手機要供電給板子。
• 電腦：Mac 加 Xcode，只用兩次，燒錄板子與建置 App。執行時完全不需要。

容易誤會的還有一處：repo 的簡介欄寫著「No Mac, no developer account, no jailbreak」，README 的硬體表卻明白列著 Mac with Xcode。兩句話在不同層次上各自成立：執行的時候不用電腦，第一次安裝需要；不用付費開發者帳號，但免費 Apple ID 簽出來的 App 每七天要重新簽署一次。另外，「一鍵加入熱點」需要 Hotspot Configuration 能力（付費帳號才有），免費帳號的使用者要照 App 顯示的密碼手動加入熱點。把執行條件與首建條件混在一起，就會出現「不用電腦、也不用裝 App」這種已經過時的說法，那是舊版 v0.1.0 的形態。

首建的實際動作比想像短。燒板子：裝好 arduino-cli、ESP32 core 3.3.x 與 NimBLE-Arduino，跑 hardware/flash.sh，腳本會順手套用藍牙緩衝區的設定，官方明言別自己跳過。建 App：複製一份 Local.xcconfig 範本、填自己的開發團隊與套件 ID，用 Xcode 打開專案按跑；專案由 XcodeGen 從 project.yml 生成，動過設定要重新生成。

裝好之後的首次設定，官方設計成 App 內的四步引導，每一步 App 都會自己檢查：

• Plug Me In：板子接上手機，用藍牙配對。
• Let Me See the Screen：加入板子的 Wi-Fi，從控制中心把螢幕鏡像指到 ESP32 Agent。
• Let Me Use the Pointer：開輔助觸控，App 自己校正指標。
• Give Me a Brain：填模型端點與金鑰（存在 iOS 鑰匙圈裡），再從端點的模型清單挑一個視覺模型，或直接填模型 ID。

之後把目標打進 App 按開始就行（官方例子是「打開設定，進到 Wi-Fi」）；代理在背景跑，動態島會顯示它正在做什麼，也能從動態島直接停。已存的任務還能掛給 Siri、捷徑、小工具與控制中心，像捷徑一樣觸發。

看得到的畫面，與打得出的字

限制清單同樣來自 README，不是第三方測試結論：

• 藍牙頻寬約 300 到 500 kbps，鏡像畫面因此縮到 480×1040、每秒最多 5 張；每一步要花幾秒，多數時間在等模型。
• 鍵盤輸入只支援 ASCII。中文輸入在 roadmap 上還沒完成（官方規劃走 iOS 拼音鍵盤），橫向 App 也不支援。中文輸入缺席這一件事，直接決定現在能測的任務類型：設鬧鐘、改設定可以，回中文訊息不行。
• iOS 本來就不鏡像某些畫面：密碼輸入、Apple Pay、受版權保護的影片。代理看不到這些內容，手機一鎖定，鏡像就停。
• App 用了一個私有 API（suspend）讓自己暫時退場，官方說自建自用沒問題，送 App Store 前要換掉。

迴圈與回放，是這個 repo 值得讀的地方

比「AI 會用手機」更值得細看的，是它怎麼把觀察、規劃、動作接成迴圈。README 的 Closing the loop 段落記了幾個工程細節：滑鼠游標是相對移動的，App 會追蹤它並推回角落歸位；精確點擊前先抖動游標，在畫面上找到它再修正偏差；每個動作之後等畫面穩定，並告訴模型畫面有沒有變化；板子、熱點或鏡像斷線時先暫停，恢復後從同一個步驟續跑。

每次執行都留在手機上：可以逐步回放，把點擊與滑動軌跡畫在畫面上，也能把截圖、動作與註記匯出成軌跡檔。官方文件明講這個匯出功能是設計給另一個代理分析用的。對研究手機代理的人，這份軌跡格式可能比 demo 本身更有用。想在不裝 App 的狀態下驗板子，repo 也留了後門：hardware/tools 裡的 board_test.py 可以從 Mac 上扮演 App 那一端，透過藍牙直接測板子；板子與 App 之間的通訊契約另有 docs/ble-protocol.md 可查。這兩份檔案對硬體除錯比 demo 影片實用。

還有一個安全細節值得單獨記下。README 頂部有醒目警告：只照 README 的步驟安裝，絕不要執行 issue 或留言區出現的安裝指令（例如 PowerShell 的 iex 一行裝法），這些不是維護者提供的。會特別寫這段警告，代表真的有人貼過這類指令。爆紅幾天的 repo 把供應鏈風險攤在檯面上說，值得按讚，也值得當成通則：別人的硬體專案再熱門，安裝指令也要認來源。

授權是兩層，韌體不是 MIT

專案主體走 MIT，但 hardware/hid_bridge/src/airplay/ 目錄是從 UxPlay 移植的 AirPlay 接收器，UxPlay 採 GPL-3.0，這個目錄跟著 GPL-3.0，連結它的韌體二進位檔也以 GPL-3.0 散布。換句話說：改 App、改提示詞，MIT 很寬鬆；動到韌體裡的 AirPlay 部分，或把韌體包進產品，就要按 GPL-3.0 處理，包括提供對應原始碼的義務。判斷方式其實很機械：只改 App 與提示詞，碰到的是 MIT；一旦碰到 hardware/hid_bridge/src/airplay/ 目錄，或把韌體映像重新散布出去，就整包進 GPL-3.0 的管轄。韌體的技術棧在致謝清單也攤開了：AirPlay 接收移植自 UxPlay，藍牙走 NimBLE-Arduino，板子程式建立在 Arduino ESP32 core 與 TinyUSB 上。個人研究先理解架構就夠；要散布或商用的讀者，請逐目錄確認授權。

還沒定案的三件事

App Store 的時程有了輪廓，但還沒落地。issue #15 有人直接問什麼時候上架，作者 10 月 17 日深夜回覆「盡快，希望這一兩天內」，並說會在 X 上宣布；10 月 15、16 兩天的提交紀錄也早已出現 TestFlight 流程、當機報告、隱私清單，連同簡體中文的商店文案草稿一起進了 repo。更細的跡象也有：10 月 15 日一筆提交把 Siri 任務意圖描述裡的「iPhone」字樣拿掉，提交訊息自己引了 App Store 審核代碼 ITMS-90626。不過截至 10 月 19 日，README 仍沒有 App Store 連結，發布欄也只有舊版 v0.1.0。在那之前，一般使用者只能走 Mac 加 Xcode 自建這條路。

文件與實作之間的漂移，這裡出現一天內修好的案例。issue #17 指出 README 說模型會自動挑選、實際的設定流程仍要明確指定，維護者隔天就改了 README，把自動挑選的說法拿掉（issue 隨即關閉）；同一週修掉的還有 App 啟動時 MetricKit 診斷報告觸發的當機（issue #16，10 月 17 日）。新專案常見的這類落差，安裝時仍以 App 內的實際畫面為準。連線品質則是另一個變數：issue #10 反映板子的 Wi-Fi 連不上，燒錄腳本也有個已開單的小問題（明確指定的序列埠會被第一個偵測到的板子覆蓋）。同一批提交紀錄裡，也能看到開發者持續在補使用體驗：在動態島顯示等待與規劃進度文字、失敗的執行要怎麼解釋、斷線後先重連再重試，這些都是影片裡看不出來、實際使用第一天就會碰到的環節。

官方路線圖：下一條要剪掉的線

Roadmap 上還沒打勾的項目，把這個專案的下一步講得很白：橫向 App、非 ASCII 文字輸入（官方規劃走 iOS 拼音鍵盤）、更快的步調（一次模型呼叫執行多個動作、指標檢查只在需要時做），以及一份在 App 內顯示的實測可用模型清單（由 X 網友建議、對應 issue #20）。舊版分支也沒有立刻死透：直接在舊版網頁預覽裡打字，還掛在 legacy 的待辦上（issue #7）。其中「更快步調」一項值得注意：現在每個動作都要等一輪模型回應，多數時間花在等待上，這是它與「快」之間真正的距離。

更值得記的是無線化方向。issue #12 的開頭就把現況說清楚：板子今天需要 USB，只為了一件事，就是雙手；眼睛早就無線了（手機經 AirPlay 連上板子熱點、再經藍牙回 App）。韌體若再提供標準 BLE HID 滑鼠鍵盤，這條線就能剪掉，板子改由任何 USB 電源供電即可；硬體側另有開單中的藍牙 HID 變體（issue #14）。到那個階段，「手機加板子」才連最後一條線都不剩。

官方同時在 README 畫了使用紅線，原文值得整句讀：只自動化你擁有或獲得授權使用的裝置與帳號，尊重相關 App 的條款；代理用的是你的雙手，看著它，把停止鈕放在摸得到的地方。供應鏈之外，也有人提醒 repo 尚未開放私人資安通報管道（issue #9），對一個熱度正高的專案來說，這條補得越快越好。

想動手的人，從鬧鐘開始

對想研究手機代理的開發者，這個 repo 的位置很清楚：它是少數「眼睛與雙手在板子上、腦在自己手機上」的開源實作，而且兩側責任切得乾淨：板子只負責熱點、收鏡像、發鍵鼠事件，App 端握著解碼、模型呼叫、迴圈控制與全部執行紀錄；換模型端點是 App 內的事，不必動板子。README 的替代專案對照表還列了六種鄰近路線：需要電腦的 VersaiOS、要走開發者模式與開發者磁碟映像的 actell、HDMI 擷取路線（aiden-firmware、glassbox）、官方自己標註「最接近此版本」的 phone-agent（差別在它不帶眼睛），以及給 iOS 裝置機群用的 devicehub；表尾還補了一句，WebDriverAgent/XCUITest 類工具（mobile-mcp、Midscene）需要 Mac 與程式碼簽署。要做橫向比較，材料齊全。入門建議照官方文件用可核對的小任務驗收整條鏈：設一個鬧鐘，事後打開時鐘 App 確認時間、重複日期與開關都對，再換成自己的模型端點試其他任務。驗收時記得把回放叫出來看：軌跡檔會記下模型每一步看到什麼、點了哪裡，這比只看成功與否更有診斷價值。

如果只是想要買來就能用的日常助理，現在還不是時候：自建 App、七天重簽、ASCII 輸入與每秒最多 5 張的鏡像，都是明確的摩擦成本，等 TestFlight 或 App Store 版本上路會實際得多。相近方向可以先看把代理放進 iPhone App 的 Pelican、用 ESP32 讓代理邊做邊說的 JARVIS Desk Bot，或更早的用 5 美元 ESP32 跑 OpenClaw 的 MimiClaw。