Tech Teardown 026｜esp32-iphone-agent: 7-Dollar-ESP32 lässt KI ein echtes iPhone bedienen

Am 11. Oktober hat der Einzelanwender onehumanbeing das Projekt esp32-iphone-agent auf GitHub öffentlich gemacht. Innerhalb von vier Tagen erreichte es 2418★ und 322 Forkes (GitHub API, Snapshot vom 10.-16.). Die Mehrheit der Popularität stammt aus den GitHub-Trends und von Rückmeldungen in der Technik-Community: Auf Hacker News hat das Projekt nur 2 Likes und 0 Kommentare erhalten (überprüft von Algolia), was auf eine schwache Verbreitung hindeutet. Der Hauptvorteil des Projekts lässt sich mit einem Satz beschreiben: Ein ESP32-S3-Entwicklungsboard für etwa 7 US-Dollar dient als „Auge“ und „Hand“. Das AI-Gerüst läuft in der App eines iPhones, sodass visuelle Modelle ein echtes iPhone bedienen können – ohne Computer, ohne Jailbreak, ohne Developer-Account. MIT-Lizenz. Dieser Artikel wird wie gewohnt in sechs Abschnitten analysiert.

1. Was ist es?

In der Liste der Bildschirmspiegelungen des iPhones gibt es einen Empfänger namens „ESP32 Agent“. Dieser ist eine eigene Wi-Fi-Hotspot-Funktion des Boards sowie ein eingebautes AirPlay-Empfänger. Das iPhone übermittelt die Bildschirmdarstellung an das Board, welches die H.264-Daten über BLE an die App auf demselben iPhone weiterleitet. Die App sendet die Screenshots an jedes OpenAI-kompatible visuelle Modell, das anschließend entscheidet, welche Aktionen ausgeführt werden. Die Anweisungen werden über BLE an das Board zurückgesendet, wo es das Board als Standard-USB-HID-Maus und-Tastatur wieder in das iPhone einsetzt. Dabei wird die AssistiveTouch-Funktion des Systems genutzt, um Klicks und Scrolls durchzuführen. Ein Trio aus Auge, Hand und Gehirn – der Hardware-Kostenpunkt beträgt ein ESP32-S3-Entwicklungsboard für 7 US-Dollar, die Software-Kostenpunkte liegen bei einer selbst erstellten App.

Ähnliche Projekte zeigen die Unterschiede des Projekts. boboabw/phone-agent ähnelt am nächsten: Auch hier verwendet es das ESP32-S3-Bluetooth-HID, AssistiveTouch und eine iPhone-App als „Gehirn“, doch es hat kein „Auge“, sodass das Modell den Bildschirm nicht sehen kann. VersaiOS nutzt UxPlay für die Bildschirmspiegelung am Computer, was ein Computer erfordert und jede Anweisung nur einmal ausführt. ja1chen/actell nutzt den Apple CoreDevice-Debugungskanal und benötigt einen Developer-Modus sowie eine Developer-Disk-Image. Projekte wie mobile-mcp und Midscene, die WebDriverAgent-Systeme verwenden, benötigen einen Mac sowie Codezertifikationen. Das Besondere an diesem Projekt ist, dass das AirPlay-Empfänger auch auf dem Board implementiert wurde, wodurch der Computer als Komponente entfallen kann.

2. Repository-Struktur

Lassen Sie uns zunächst eine kleine Recherche durchführen: Die Sprachmarkierungen auf GitHub stimmen nicht mit der tatsächlichen Implementierung überein. Lokal betrachtet (außer .git, 190 Dateien) hat Swift 11.621 Zeilen, was die absolute Hauptsprache ist, die für die App im Verzeichnis ios verwendet wird, zusammen mit 13 Testdateien; C hat nur 2.793 Zeilen, die hauptsächlich in hardware/ liegen und sich auf den von UxPlay übernommenen AirPlay-Receiver sowie die FairPlay-Zertifizierung von playfair beziehen; 800 Zeilen in C++ sind der HID-Bridge für das ESP32-Firmware; 1.793 Zeilen in Python befinden sich im Verzeichnis server/, aber die CHANGELOG erwähnt klar „server/ ist nicht mehr notwendig“, was die Überreste der v0.1.0-Computerversion sind, nicht aktives Code. Dieses Phänomen ähnelt dem, was wir beim Aufschlüsseln von pg_vectorsearch in Ausgabe 025 festgestellt haben.

Die Architekturentwicklung ist die interessanteste Geschichte dieses Projekts. Die v0.1.0-Version war eine Computerlösung: UxPlay plus Python-Server plus Web-UI, ESP32 diente nur als USB HID-Bridge für Wi-Fi, und es musste ein Mac oder Linux-Computer zur Übertragung verwendet werden. Der aktuelle Hauptknoten hat die „Ausfall des Computers“ umgesetzt: Das Board funktioniert selbst als AirPlay-Receiver, erstellt einen eigenen Hotspot und kommuniziert über BLE mit der neuen iPhone-App. Die Anweisungen sind in das Verzeichnis prompts/ gelegt worden, und der Name des Produkts lautet ESP32 Agent. In vier Tagen wurde die App 2.400 Mal gelobt, und das war die einfache Form dieser Version.

Ein weiterer wichtiger Wert: Die Gesamtzahl der Commits beträgt 29, und die contributors API gibt nur einen Hauptbeitrag an. Dies ist ein Einzelprojekt, kein Community-Projekt.

III. Mechanismenaufklärung

Die drei wichtigsten Mechanismen werden nacheinander analysiert.

Erstens ist es die Übertragung von BLE-Videos. Das Board verfügt über wenig Rechenleistung, daher ist die Hard-Encoding von H.264 nicht realistisch. Die Entscheidung des Autors war, das Decodieren völlig zu ignorieren: Der empfangene H.264-S流 wird direkt in Blöcke geschnitten und über BLE-Notifikationen an das Handy übertragen. Die Decodierung wird vom iPhone selbst übernommen. docs/ble-protocol.md beschreibt dies sehr konkret: Das Board ist ein BLE-Pervipheral, mit fünf Eigenschaftswerten unter einem Service. cmd übernimmt die Befehlsausgabe, reply sendet Ergebnisse, status sendet alle Sekunden einen JSON-Hotspot (der auch als Liveness-Funktion für das App-Frontend dient), video übermittelt H.264-Blöcke, netwerk nutzt verschlüsselte Kanäle für die Verbindung, und LE Secure Connections sowie bonding werden zur Sicherheit verwendet. Jede Notifikation des video-Kanals enthält eine 16-stellige Nummer und Flaggen. Wenn ein Paket verloren geht, wird es nach dem nächsten IDR-Kritikalbildern neu ausgerichtet. Im Stream-Modus werden P-Frames, die länger als 800 Millisekunden sind, direkt übersprungen. Bei unzureichendem Bandvermögen wird automatisch auf nur noch Kritikalbilder umgestellt, um Verzögerungen zu vermeiden. Der jährliche Hotspot-Hotspot ist ebenfalls interessant: Er enthält in einem JSON-Record die Laufzeit, Gründe für die Neustartung, Restkapazitäten der Heap und PSRAM, USB-Zustand, Anzahl der Hotspots, aktueller Bitrate, tatsächliche Framerate, MTU und physische Rate des BLE sowie die Anzahl der verlorenen Pakete. Das bedeutet, dass die Gesundheit des gesamten Datenverkehrs dem App in Echtzeit angezeigt wird. Wenn die MTU zu niedrig ist, stellt das Firmware automatisch vereinfachte Objekte zur Übertragung bereit. Um den Status zu lesen, kann man immer die vollständige Version erhalten. Die Priorität der Sendungen ist ebenfalls festgelegt: reply und status stehen immer vor video. video kann im Controller maximal etwa 8 ACL-Pakete tragen, sodass Befehle nicht vom Video-Stream ausgehungert werden. In der Firmware gibt es auch den coex-Befehl, um die Frequenzkompatibilität von Wi-Fi und BLE zu steuern. Beide nutzen denselben Antennenkabel. Das ist ein wesentlicher Aspekt bei der Implementierung dieser Funktion auf ESP32-S3. Standardmäßig kehrt das System nach jedem Start wieder zur Balance zurück.

Zweitens ist es der Rückkopplungsmechanismus für die Zeigerkalibrierung. USB HID-Mäuse haben auf iOS eine relative Positionierung, während die Modelle absolute Koordinaten angeben. Zwischen diesen beiden liegt eine Unschärfe: Die aktuelle Position des Zeigers kann nur vom App aus anhand der historischen Bewegungen berechnet werden, was zu Kompensationen führt. Die Lösung des Autors ist, die Kalibrierung als eine Action zu machen: Das App verfolgt den Zeiger kontinuierlich und „rückt“ ihn in eine bestimmte Position am Bildschirmrand. Vor dem genauen Klicken wird zunächst ein Wiggle ausgeführt, der den Zeiger schwingen lässt, um im neuesten Screenshot mit einer visuellen Methode die richtige Position zu finden, die Abweichungen korrigiert und anschließend den Punkt setzt. Im actor.md wird der tap-Befehl mit einem precise-Parameter versehen. Kleine Ziele und dicht angeordnete Elemente (Listenzeilen, Schalter, Checkboxen) verfolgen diesen langsamen, aber genauer Weg. Nach jeder Aktion wartet man, bis der Bildschirm stabil ist, um „ob sich der Bildschirm verändert hat“ an das Modell weiterzugeben. Wenn sich nichts ändert, bedeutet das, dass der Punkt nicht getroffen wurde. Das Modell fordert eindeutig, dass keine Annahmen über Erfolg getroffen werden dürfen, sondern dass man erneut zielt oder eine andere Methode wählt. Wenn das Board, der Hotspot oder die Ansicht abbricht, wird die Aufgabe unterbrochen. Nach Wiederherstellung wird mit demselben Schritt fortgesetzt. Das README nennt dies self-healing.

Der dritte Punkt ist das Prompt-Engineering, das der wertvollste Teil des gesamten Projekts ist. In der Datei planner.md wird verlangt, dass die Modelle eine Planung mit bis zu 6 Schritten nach dem Ziel und dem aktuellen Bildschirm erstellen, basierend ausschließlich auf dem Gesagten, ohne fiktive Konten, E-Mail-Adressen oder Anmeldeseiten zu erfinden, die nicht existieren. In der Datei actor.md ist die Vorgehensweise noch detaillierter: Die Ausgabe besteht aus zwei Abschnitten „THINK“ und „DO“. Im „THINK“-Abschnitt muss das Model in einer für Nicht-Techniker verständlichen Sprache überprüfen, ob der vorherige Schritt funktioniert hat; die Koordinaten sind relative Ganzzahlen von 0 bis 1000. Die wichtigste Regel ist „Sehen, bevor man handelt“ – es werden nur Dinge beschrieben, die tatsächlich auf dem Bildschirm zu sehen sind, nur Elemente, die auf Screenshots erkennbar sind; beim Swipe gibt es keine Bewegungsabläufe, es wird bevorzugt eine kurze Bewegung von 100 bis 250 Einheiten durchgeführt, um den Ergebnisstatus zu überprüfen; beim Zeit-Rollbalken wird zunächst die Mitte berührt und anschließend die Zahlen eingegeben (z.B. type 0700); bei der Listensuche wird jede Scrollsitzung weniger als eine Bildschirmecke betrachtet, nachdem alle sichtbaren Elemente gelesen wurden. Wenn das Ende der Liste noch nicht erreicht ist, führt dies zu einem Fehler und es wird die am nächsten liegende Option angezeigt. Die Aktionen umfassen Tap, Swipe, Path (sequenzielle Bewegungen von 2 bis 20 Punkten zur Darstellung), Circle, Type, Key, Home, Back, Wait, Replan, Done, Fail. Dieses Prompt-System legt fast alle Schwierigkeiten bezüglich der zuverlässigen Bedienung der GUI durch visuelle Agenten fest.

Was die Zulassung des Boards als legaler AirPlay-Ziel für das iPhone betrifft: Der Code in hardware/ namens playfair (omg_hax.c, hand_garble.c, sap_hash.c usw.) ist eine umgekehrte Implementierung der FairPlay-Konfiguration von UxPlay. Die Herkunft und die Formulierung werden als „Übernahme/Umkehrung“ interpretiert. UxPlay selbst ist ein bekannter quelloffener AirPlay-Receiver-Projekt.

Vier, Zahlen und Verifizierung

Die Liste der Hardwarekomponenten ist kurz: Der Autor hat die Verifizierung mit dem Seeed Studio XIAO ESP32S3 Standardversion durchgeführt, 8MB PSRAM, etwa 7 US-Dollar; in der README wird angegeben, dass jeder ESP32-S3 mit nativem USB (USB-C Port) und PSRAM verwendet werden kann. Die Standardbildschirmgröße ist 480×1040 bei 5fps, die kann mit den Befehlen res und fps geändert werden. Die BLE-Bandbreite beträgt etwa 300 bis 500 kbps, das sind die maximalen Grenzen für Auflösung und Framerate; jede Aktion des Agents dauert einige Sekunden, der größte Teil davon geht auf die Modellierungstheorie. Wenn die App läuft, verbindet das Handy über WLAN mit dem Board-Hotspot, ohne Internetverbindung, die Modellaufrufe erfolgen über Mobilfunkdaten.

Die Liste der Einschränkungen stammt aus der ursprünglichen README und ist länger als die Liste der Vorteile. Sie wird hier wiedergegeben: Die BLE-Bandbreite führt zu kleinen Bildschirmen und niedrigen Framerate; iOS zeigt nicht den Passworteingabe, Apple Pay oder DRM-Videos an, die Bildschirmansicht wird gestoppt, wenn das Display geschlossen ist – in diesen Fällen ist der Agent nutzlos; die App verwendet private iOS-APIs (suspend) zur Hintergrund-Installation, selbstgebautes Material ist problemlos einsetzbar, vor dem Verkauf auf den App Store muss es ersetzt werden; Tastenausgabe nur ASCII; die App unter horizontalem Betrieb nicht unterstützt. Auf dem Roadmap sind noch unvollendete Punkte: horizontaler Betrieb, nicht-ASCII-Eingabe (z.B. chinesische Pinyin), mehrer Aktionen durch einen einzelnen Modellaufruf. Die Versionanforderungen beinhalten iOS 18 und darüber, da sie empfindlich auf Systemupdates sind.

Verifizierungsdimension erweitern um drei weitere Punkte: HN Story 2▲ 0 Kommentare, die geringe Verbreitungskraft ist eine Tatsache; 29 Commitments, ein einziger Hauptbeitragender, die Nachhaltigkeit muss beobachtet werden; im iOS-Verzeichnis befinden sich 13 Testdateien, ein einzelnes Projekt ist bis hierhin zurückgehalten – das zeigt Besonnenheit und Ernsthaftigkeit. Im README gibt es auch einen Abschnitt über verantwortungsvolle Nutzung: Automatisieren Sie nur die Geräte und Konten, die Sie besitzen oder autorisiert sind. Der Agent handelt mit Ihrer Hilfe, achten Sie während des Betriebs darauf, den Stoppknopf griffbereit zu halten.

Fünftes Kapitel: Beurteilung

Drei Punkte sind erwähnenswert.

Erstens handelt es sich um ein technisches Tricksen statt um einen harten Crack. Das gesamte Konzept hat keine Sicherheitsgrenzen von iOS berührt: AirPlay-Modellbild ist eine Systemfunktion, USB HID ist ein Standard-Ausgabegerät-Protokoll, AssistiveTouch ist eine Barrierefreiheit-Funktion. Die „Mausinputabsichten des Modells“ werden in „iOS zulässiges Mausinput“ übersetzt, jeder Schritt erfolgt innerhalb der vom System erlaubten Schnittstellen. Playfairs FairPlay-Rückwärtsverschlüsselung stammt aus der offiziellen Implementierung von UxPlay, es handelt sich nicht um eine neue Lösung für dieses Projekt. Diese Idee „von legitimen Lücken in einer geschlossenen Ökologie auszugehen“ ist dem längerfristig haltbaren Zustand näher als jeder andere Crack-Plan.

Zweitens ist die Aufteilung „schwache Hardware zur Stärkung des Modells“ erwähnenswert. Die Hardware leistet keine intelligenten Funktionen, sondern dient nur als Kanal mit begrenztem Bandbreiten und als treuer Helfer; Decodierung, Vision und Planung finden ausschließlich auf dem Handy und in der Cloud statt. Die BLE-Übertragung ohne Decodierung, die Wiggle-Kalibrierung im Vergleich zu Punkten sowie die Rückmeldung an jedem Schritt über den Bildschirm, diese drei Mechanismen lösen dasselbe Problem: Wie kann man auf unzuverlässigen Kanälen ein zuverlässiges Rückkopplungskreislauf aufbauen? Diejenigen, die einen Agent am Gerät entwickeln, können direkt davon profitieren, Prompts/actor.md kann sogar komplett übernommen werden.

Drittens müssen die Grenzen klar definiert werden. Ein einzelnes Projekt, 29 Commitments, kaum Aktivität auf HN, das schnelle Wachstum der Stars hängt von der Verbreitungskraft der Erzählung „7 Dollar für das echte iPhone“ ab, was keine Community- oder kommerzielle Unterstützung im Projekt bedeutet. Jede große iOS-Version kann das Verhalten von AssistiveTouch oder AirPlay ändern, die dauerhafte Nutzung privater APIs ist eine ungelöste Herausforderung. Es handelt sich um ein raffiniertes persönliches Engineering-Experiment, das mit dieser Maßstab beurteilt werden sollte, nicht mit dem Maßstab der „offenen Infrastruktur“.

Ein bemerkenswerter Punkt: Im README sind sechs Beschränkungen an einer sichtbaren Stelle aufgeführt, der Autor hat das Projekt nicht zu einem universellen Ansatz gemacht. Ein README mit einer längeren Liste von Beschränkungen als Liste von Vorteilen ist normalerweise ein Zeichen für eine gesunde Open-Source-Software.

Sechstes Kapitel: Wer kann es nutzen und wie

Geeignete Personen: Wer über ein iPhone (iOS 18+) und ein ESP32-S3 mit nativem USB und PSRAM verfügt, der bereit ist, seine iOS-Apps selbst zu kompilieren (Xcode und eine kostenlose Apple ID sind erforderlich, kein kostenpflichtiger Entwickleraccount), und der sich für die Entwicklung von „GUI für visuelle Modelle auf dem echten Gerät“ interessiert. Bevor Sie es zur Automatisierung Ihrer täglichen Arbeit verwenden, lesen Sie bitte den Abschnitt über verantwortungsvolle Nutzung: Betreten Sie nur die Geräte und Konten, die Sie besitzen oder autorisiert sind. Während der Ausführung der Aufgaben sollten Sie nicht weggehen.

Handhabung gemäß README: Schreiben des Hardware- und Firmware-Code, öffnen Sie das Hotspot auf dem iPhone, wählen Sie ESP32 Agent auf dem Bildschirmduplizierungsmodus, stecken Sie den USB-Stick ein, aktivieren Sie AssistiveTouch, scannen Sie mit der App oder paaren Sie sich per BLE-Verbindung. Füllen Sie einen visuellen Modelleingang ab, der OpenAI-kompatibel ist, um Befehle auszugeben. Jedes Mal, wenn der Prozess ausgeführt wird, bleibt er auf dem Handy gespeichert und kann schrittweise wiedergegeben werden. Taps und Swipes werden auf den entsprechenden Screenshots markiert, was das Nachschlagen erleichtert. Während des Hintergrundbetriebs zeigt das Intelligent Display den Fortschritt an und unterstützt außerdem Live Activity, Widgets, Siri und Shortcuts.

Auch Personen, die nicht handeln möchten, sollten sich zwei Dokumente ansehen: docs/ble-protocol.md ist ein Lehrbuchartiges Dokument über das private BLE-Protokoll, in dem alles klar beschrieben wird, von UUID-Aufteilung über Herzschläge zur Wiederherstellung nach Paketverlust und Rundum-Sorglos-Kompatibilität; der Ordner prompts/ enthält seltene, öffentliche Anweisungen für die Bedienung des GUI-Agenten. Der Wert dieser beiden Dokumente hängt nicht von den dynamischen Schwankungen des Projekts selbst ab.

Quelleninformationen

• Repository-ID (2418★/322 Forkings/Aufrufzeit/Entstehungs- und Versendungszeit/MIT/topics): GitHub API-repos/onehumanbeing/esp32-iphone-agent, 10-16 Snapshots
• Codegröße (190 Dateien, 11.621 Swift-Sprachenzeilen, 2.793 C-Sprachenzeilen, 800 C++-Sprachenzeilen, 1.793 Python-Sprachenzeilen): lokaler leichter Clone /tmp/eia-1016, Statistik nach Dateierichtung mit find+wc, keine GitHub-Sprachetiketten
• Architektur und Datenfluss, Liste der Einschränkungen, verantwortungsvolle Nutzung, Hardware-BOM, Vergleich ähnlicher Projekte: README (inklusive chinesischer Version README.zh-CN.md) Originaltext
• Details des BLE-Protokolls (fünf Eigenschaften, Paketverluste, 800ms P-Frames-Pauschierung, coex, NVS-Speicher): docs/ble-protocol.md
• Regeln für Anweisungen: prompts/planner.md, prompts/actor.md Originaltext
• Architekturentwicklung (v0.1.0 vom Computer zu main „Computer verschwindet“): CHANGELOG
• Herkunft von playfair/UxPlay: directory hardware/hid_bridge/src/airplay/playfair/ und CHANGELOG „ported from UxPlay“ beschrieben
• Verbreitungskraft von HN (Story 50102527, 2▲ 0 Kommentare): HN Algolia überprüft
• Verteilung der Mitwirkenden und Gesamtzahl der Commits (29): GitHub contributors API und commits Link header