Phone Agents durch Vormachen trainieren: Bildschirmaufnahme, Skills und Android-Sicherheit

Vormachen statt jeden Schritt einzeln zu skripten

Kann ein Phone Agent einen Arbeitsablauf lernen, indem man ihn einmal auf dem Bildschirm vorführt? Das Grundprinzip ist plausibel: Der Nutzer erledigt eine Aufgabe, beschreibt dabei seine Entscheidungen und liefert dem System ein vollständiges Beispiel. Aus der Demonstration soll keine bloße Aufzeichnung entstehen, sondern eine wiederverwendbare Handlungsbeschreibung. Sie muss erklären, welches Ziel erreicht werden soll, welche Angaben variabel sind und wann der Ablauf anhalten muss.

Ein aktuelles Signal liefert Claude Cowork. Laut einem ITmedia-Bericht vom 22. Juli 2026 zeichnet Record a Skill eine Aufgabe zusammen mit der gesprochenen Erläuterung auf und wandelt sie in einen wiederverwendbaren Skill um. Ein Praxiseindruck von Android Authority beschreibt ebenfalls die Kombination aus Bildschirmaufnahme und mündlicher Erklärung. Wiederkehrende Aufgaben sollen dadurch nicht jedes Mal mit einem neuen Prompt beschrieben werden müssen.

Für Phone Agents ist vor allem die Kombination aus Bild und Begründung interessant. Die Aufnahme zeigt, was auf dem Bildschirm geschieht. Die Erklärung vermittelt, warum der Nutzer gerade diesen Kontakt, diesen Menüpunkt oder diese Option auswählt. Ohne den gesprochenen Kontext könnte ein System einen zufälligen Beispielwert fälschlich als feste Regel übernehmen. Der Satz „Wähle immer den nächsten freien Termin am Vormittag“ enthält wesentlich mehr wiederverwendbares Wissen als der sichtbare Klick auf „10:30 Uhr“.

Lernen durch Demonstration ist deshalb weder gewöhnliches Modelltraining noch ein zweites Abspielen des Videos. Auch ein Prompt erfüllt eine andere Funktion: Er formuliert das Ziel, zeigt aber nicht zwingend die tatsächliche Bedienfolge. Eine klassische Makroaufzeichnung speichert dagegen feste Klicks, Koordinaten oder Tasteneingaben. Ein generalisierter Skill verbindet Ziel, Regeln, variable Parameter, erwartete Zustände und zulässige Aktionen.

Claude Cowork ist in diesem Zusammenhang ein Beispiel für demonstrierte, wiederverwendbare Arbeitsabläufe und keine Android-Telefonsteuerung. Den angrenzenden Blick auf mobile Agentenoberflächen bietet Claude Cowork auf dem Smartphone: Warum mobile Steuerung für AI Agents zählt. Für Android lautet die weiterführende Frage: Wie wird aus dem gezeigten Beispiel ein Ablauf, der wechselnde App-Zustände versteht und nur unterstützte Aktionen ausführt?

Von der sauberen Aufnahme zum wiederverwendbaren Skill

Welche Verarbeitungsschritte liegen zwischen einer Bildschirmaufnahme und einem brauchbaren Phone-Agent-Skill? Am Anfang steht eine klar abgegrenzte Aufgabe. „Öffne die Reisekosten-App, wähle den aktuellen Monat, füge einen Testbeleg hinzu und speichere den Entwurf“ eignet sich besser als eine lange Demonstration, in der mehrere unabhängige Ziele vermischt werden. Ein einzelner Skill sollte einen verständlichen Zweck und ein überprüfbares Ergebnis besitzen.

Während der Aufnahme erklärt der Nutzer nicht jeden sichtbaren Pixel, sondern die entscheidenden Regeln. Er benennt variable Werte wie Monat, Empfänger, Dateiname oder Kategorie. Ebenso wichtig sind Ausschlüsse: „Wenn die Kategorie fehlt, nicht raten, sondern nachfragen“ oder „Den Entwurf speichern, aber nicht absenden.“ Solche Aussagen helfen, zufällige Details des Beispiels von der eigentlichen Arbeitslogik zu trennen.

Danach folgt die Abstraktion. Aus „Tippe auf den Eintrag Anna Keller“ wird etwa „Öffne den Kontakt, dessen Name als Parameter übergeben wurde“. Aus „Wähle Juli“ entsteht „Wähle den gewünschten Abrechnungsmonat“. Der Skill benötigt dafür Eingaben mit verständlichen Namen, Regeln zur Prüfung dieser Eingaben und ein definiertes Ergebnis. Außerdem muss feststehen, welche Abweichungen selbstständig gelöst werden können und wann eine Rückfrage erforderlich ist.

1. Aufgabe abgrenzen: Ein Ziel, ein Startzustand und ein erwartetes Ergebnis festlegen.
2. Beispiel erfassen: Den Ablauf mit bereinigten Testdaten zeigen und Entscheidungen laut erläutern.
3. Regeln herauslösen: Feste Anforderungen von zufälligen Beispielwerten trennen.
4. Parameter definieren: Namen, Daten, Dateien, Zeiträume und andere wechselnde Angaben kennzeichnen.
5. Skill verpacken: Voraussetzungen, unterstützte Aktionen, Abbruchbedingungen und Ergebnis beschreiben.
6. Wiederverwendung prüfen: Den Skill mit anderen Eingaben und veränderten Zuständen aufrufen.

Ein wiederverwendbarer Aufruf kann anschließend natürlich formuliert sein: „Lege den Reisekostenentwurf für August mit diesem Testbeleg an.“ Das konfigurierte Modell ordnet die Eingaben dem passenden Ablauf zu und plant die notwendigen Schritte. Die Android-Ausführung muss jedoch weiterhin jeden aktuellen Zustand prüfen. Mehrstufige Aufgaben und ihre praktische Struktur behandelt auch Android-Aufgaben automatisieren: Mehr erledigen mit einem Sprachbefehl.

Entscheidend ist die Qualität der Beschreibung, nicht die Länge der Aufnahme. Eine kurze Demonstration mit klar benannten Regeln ist wertvoller als ein langes Video voller Nebenhandlungen. Vor der Freigabe sollte der erzeugte Skill deshalb als lesbare Zusammenfassung vorliegen: Ziel, Eingaben, Apps, Berechtigungen, Bestätigungspunkte, erwartetes Ergebnis und Verhalten bei Abweichungen.

Warum Android keine starre Klickfolge ist

Warum lässt sich eine einmal aufgezeichnete Bedienfolge nicht einfach unverändert auf jedem Android-Smartphone wiederholen? Apps zeigen Inhalte abhängig von Displaygröße, Ausrichtung, Sprache, Konto, Version und aktuellem Datenbestand an. Ein Button kann weiter unten erscheinen, anders bezeichnet sein oder durch einen Dialog verdeckt werden. Selbst innerhalb derselben App führt ein leerer Posteingang zu einem anderen Bildschirm als ein Konto mit ungelesenen Nachrichten.

Auch der Startzustand variiert. Ein Nutzer ist bereits angemeldet, ein anderer muss ein Konto wählen. Eine App öffnet die zuletzt besuchte Ansicht, während eine andere auf der Startseite beginnt. Hinzu kommen Berechtigungsdialoge, Hinweise nach Aktualisierungen und Systemfenster. Ein starres Makro setzt voraus, dass jeder dieser Zustände exakt dem aufgezeichneten Beispiel entspricht. Ein Phone Agent muss stattdessen erkennen, wo er sich befindet und welche unterstützte Aktion zum Ziel führt.

Koordinaten sind dafür ein schwacher Anker. Die Position „320 Pixel von links und 740 Pixel von oben“ beschreibt keine Bedeutung. Robuster sind semantische Merkmale wie sichtbarer Text, Rolle eines Bedienelements und Informationen aus dem Accessibility Tree. Der Android-Leitfaden zu Accessibility Services erläutert, wie Dienste Informationen über Elemente der Benutzeroberfläche erhalten und Aktionen darauf ausführen können. Diese Plattformfunktion ist an ihren vorgesehenen Zugriff und die jeweilige Konfiguration gebunden.

Selbst semantische Erkennung benötigt Laufzeitprüfungen. Zwei Schaltflächen können ähnlich heißen, eine Liste kann mehrere gleichnamige Kontakte enthalten und ein Zielobjekt kann nicht mehr verfügbar sein. Der Skill sollte deshalb nicht nur „Tippe auf Senden“ enthalten. Er muss vorher prüfen, in welcher App und welchem Gespräch er sich befindet, welcher Inhalt vorbereitet wurde und ob eine Bestätigung erforderlich ist.

Lokalisierung verdeutlicht den Unterschied zwischen Bedeutung und Oberfläche. Ein deutscher Beispielablauf kann „Speichern“ zeigen, während dieselbe App in einer anderen Sprache eine andere Beschriftung verwendet. Ein sinnvoll generalisierter Skill orientiert sich an der beabsichtigten Aktion und dem aktuellen Zustand, nicht ausschließlich an der Zeichenfolge aus der Aufnahme. Bei geänderten App-Versionen braucht er zudem eine erkennbare Fehlerreaktion statt stiller Fortsetzung.

Demonstrationsdaten können beim Aufbau solcher Fähigkeiten helfen, unterscheiden sich aber von systematischem Modelltraining in kontrollierten Umgebungen. Der Beitrag PhoneBuddy-4B und Phone-Agent-Training: Warum Mock-App RL für Android Agents wichtig ist vertieft diese andere Ebene. Für einen persönlichen Skill bleibt die Leitfrage enger: Welche Regeln aus diesem Beispiel gelten auch beim nächsten echten Aufruf?

Sicher aufzeichnen, ohne private Daten mitzuliefern

Was darf in einer Demonstration erscheinen? Eine gute Aufnahme zeigt nur die Informationen, die zum Erlernen des Ablaufs benötigt werden. Passwörter, Zahlungsdaten, private Chats, Gesundheitsinformationen und Authentifizierungscodes gehören nicht hinein. Statt echter Kundennamen, Adressen oder Dokumente sollten vorbereitete Testkonten, Beispieldateien und erfundene Datensätze verwendet werden.

Android behandelt Bildschirmaufnahmen als zustimmungspflichtigen Zugriff. Die Dokumentation zu MediaProjection verlangt die Einwilligung des Nutzers für jede Projektionssitzung und beschreibt Anforderungen an den geschützten Umgang mit erfassten Display-Inhalten. Das ist für demonstrationsbasiertes Lernen zentral: Eine frühere Zustimmung darf nicht als dauerhafte Erlaubnis für spätere Aufnahmen verstanden werden. Beginn und Ende müssen sichtbar und kontrollierbar bleiben.

Vor dem Start lohnt sich eine kurze Vorbereitung. Benachrichtigungsvorschauen werden ausgeblendet, andere Apps geschlossen und persönliche Tabs entfernt. Der gewünschte Startzustand wird mit Testdaten hergestellt. Während der Demonstration spricht der Nutzer nur die Regeln aus, die der Skill tatsächlich benötigt. Er erklärt beispielsweise, warum ein Feld optional ist oder wann ein Vorgang abgebrochen wird, ohne vertrauliche Inhalte vorzulesen.

Eine Demonstration für „Nachricht vorbereiten“ sollte beispielsweise mit einem Testkontakt und unverfänglichem Text enden, bevor etwas versendet wird. Die Regel „Vor dem Senden Empfänger und Inhalt anzeigen“ lässt sich trotzdem vollständig erfassen. Ebenso kann ein Einkaufsablauf bis zum Warenkorb demonstriert werden, ohne eine Bestellung oder Zahlung auszulösen.

Androids Leitlinien zu Datenschutz und Sicherheit behandeln Berechtigungen und den Zugriff auf sensible Daten als begrenzte Plattformfunktionen. Für einen Skill bedeutet das: Die Aufnahme erteilt keine späteren App-Berechtigungen. Jeder wiederverwendete Ablauf benötigt weiterhin die Zugriffe, die seine konkreten Android-Aktionen voraussetzen. Wie Skills zur Laufzeit geprüft werden sollten, erläutert Sicherheit von KI-Agent-Skills: Warum Phone Agents Laufzeitprüfungen brauchen.

Skills testen, Berechtigungen binden und Fehler auffangen

Wann ist ein demonstrierter Ablauf bereit für den Alltag? Erst nachdem er mit anderen Eingaben und veränderten Zuständen geprüft wurde. Ein erfolgreicher Durchlauf mit denselben Beispieldaten bestätigt lediglich, dass die Vorlage wiederholt werden kann. Ein belastbarer Skill muss auch mit einem anderen Kontakt, einer leeren Liste, einer verschobenen Schaltfläche oder einer fehlenden optionalen Angabe sinnvoll reagieren.

Der erste Test sollte als Probelauf ohne folgenreichen Abschluss stattfinden. Der Agent plant die Schritte und zeigt, welche Apps, Daten und Aktionen er verwenden würde. Anschließend folgt eine Ausführung mit Testdaten, bei der Senden, Löschen, Kaufen, Veröffentlichen oder dauerhafte Änderungen vor der Bestätigung stoppen. So lässt sich erkennen, ob der Skill die richtigen Informationen gesammelt und den erwarteten Zielzustand erreicht hat.

Eine kompakte Testmatrix umfasst mindestens vier Varianten: den normalen Erfolgsfall, einen fehlenden Eingabewert, einen unerwarteten Bildschirmzustand und eine verweigerte Berechtigung. Zusätzlich sollte geprüft werden, ob der Nutzer den Ablauf jederzeit abbrechen kann. Wenn ein Schritt fehlschlägt, muss der Skill den letzten bestätigten Zustand benennen und eine praktische Fortsetzung anbieten, statt dieselbe Aktion unkontrolliert zu wiederholen.

Berechtigungen werden pro Fähigkeit zugeordnet. Ein Ablauf zum Erstellen eines Kalenderentwurfs benötigt andere Zugriffe als das Vorbereiten einer Nachricht. Die Demonstration selbst darf diese Grenzen nicht ausweiten. Besonders folgenreiche Aktionen erhalten explizite Bestätigungspunkte, an denen Ziel, Inhalt und Konsequenz sichtbar sind. Änderungen am Skill sollten eine neue Versionsnummer und einen erneuten Test der betroffenen Schritte auslösen.

Protokolle unterstützen die spätere Prüfung: Welcher Skill wurde aufgerufen, welche Version war aktiv, welche Eingaben wurden verwendet und an welchem Bestätigungspunkt hat der Nutzer zugestimmt oder abgebrochen? Dabei werden nur die für Nachvollziehbarkeit erforderlichen Angaben gespeichert. Für die Verbindung aus Identität, Zugriff und Aktionshistorie bietet KI-Agent-Identität, Berechtigungen und Audit-Trails: Der Sicherheitsstack fürs Telefon den vertiefenden Rahmen.

Auch ein Rückweg gehört zum Skill. Bei reversiblen Änderungen kann das System eine Rücknahme anbieten. Ist eine Aktion nicht automatisch umkehrbar, muss es vorab besonders deutlich bestätigen und anschließend das Ergebnis sichtbar anzeigen. Eine frühere, funktionierende Skill-Version sollte wiederherstellbar bleiben, falls eine App-Aktualisierung oder Regeländerung den neuen Ablauf unzuverlässig macht.

FoneClaw-Workflows mit sichtbarer Kontrolle

Wie ordnet FoneClaw demonstrationsbasierte Skills in die praktische Android-Steuerung ein? Für uns besteht ein wiederverwendbarer Telefonablauf aus einem verständlichen Ziel, variablen Eingaben, unterstützten Aktionen, Laufzeitprüfungen und klaren Bestätigungspunkten. Ein konfiguriertes Modell übernimmt Sprachverständnis, Schlussfolgerungen und Planung. FoneClaw setzt die unterstützten Android-Schritte um und zeigt deren Ergebnisse auf dem Gerät.

Der aktuelle FoneClaw-Ansatz richtet wiederverwendbare Abläufe über konfigurierte Modelle und unterstützte Android-Aktionen ein. Die automatische Erzeugung eines Telefon-Skills direkt aus einer Bildschirmaufnahme ist derzeit kein bereitgestellter FoneClaw-Workflow. Das Demonstrationsprinzip zeigt jedoch, welche Informationen ein zukünftiger Aufnahme-zu-Skill-Prozess zuverlässig erfassen müsste: Ziel, Regeln, Parameter, erwartete Zustände, Berechtigungen, Stopppunkte und Fehlerbehandlung.

Für bestehende FoneClaw-Abläufe gilt dieselbe Trennung von Denken und Handeln. Das Modell kann beispielsweise verstehen, dass „Schicke dem Projektteam den aktuellen Entwurf“ die Auswahl eines Dokuments und einer Empfängergruppe erfordert. FoneClaw führt die unterstützten Telefonaktionen sichtbar aus. Vor dem tatsächlichen Versand erhält der Nutzer den ausgewählten Inhalt und die Empfänger zur Bestätigung.

Verändert sich der Android-Zustand, plant das Modell auf Grundlage der sichtbaren Situation weiter. FoneClaw prüft die unterstützten Aktionsmöglichkeiten und arbeitet innerhalb der erteilten Berechtigungen. Ist ein benötigter Schritt nicht verfügbar, bleibt der erreichte Zustand sichtbar und der Nutzer kann praktisch übernehmen. Diese Ausweichmöglichkeit ist kein nachträglicher Zusatz, sondern Bestandteil eines brauchbaren Phone-Agent-Workflows.

Wer einen Phone Agent durch Demonstration trainieren möchte, sollte deshalb nicht mit dem Aufnahmeknopf beginnen, sondern mit sechs Fragen: Was ist das genaue Ziel? Welche Angaben wechseln? Welche Apps und Berechtigungen werden benötigt? Welche Abweichungen sind erwartbar? Wo muss der Nutzer bestätigen? Wie wird nach einem Fehler fortgesetzt? Erst wenn diese Antworten feststehen, kann aus einem gezeigten Beispiel eine verlässliche Fähigkeit werden.

Unser Produktmaßstab bleibt dabei klar: Modelle liefern Verständnis und Planung; FoneClaw übernimmt unterstützte Android-Aktionen mit sichtbaren Ergebnissen, passenden Berechtigungen, Nutzerbestätigung und einem praktischen Rückweg. Demonstrationsbasiertes Lernen ist dann wertvoll, wenn es diese Kontrolle strukturiert abbildet und nicht bloß eine vergangene Klickfolge wiederholt.