Selbstverbessernde Phone Agents: Skill-Versionen, Tests und Rollback

Was sich bei einem selbstverbessernden Phone Agent verändert

Was ist ein selbstverbessernder Phone Agent? Es ist ein Telefonagent, der Ergebnisse und Fehlerspuren aus seinen ausgeführten Aufgaben nutzt, um künftige Abläufe gezielt zu verbessern. Dabei können sich Planungsanweisungen, Werkzeugauswahl, Prüfregeln, wiederverwendbare Skills oder die Behandlung bekannter Fehler weiterentwickeln. Die ausgewählten Modellgewichte bleiben davon getrennt.

Diese Unterscheidung verhindert, dass verschiedene Arten des Lernens miteinander vermischt werden. Modelltraining verändert das Modell selbst. Ein Phone-Agent-Harness bestimmt dagegen, wie das konfigurierte Modell innerhalb eines Produkts arbeitet: welche Anweisungen gelten, welche Werkzeuge verfügbar sind, wie Zwischenergebnisse geprüft werden und was nach einem Fehler geschieht. Ein Skill beschreibt einen wiederverwendbaren Telefonablauf. FoneClaw übernimmt schließlich die unterstützte Ausführung auf Android.

Ein selbstverbessernder Phone Agent darf also nicht mit unbegrenzter Selbstveränderung verwechselt werden. Wertvoll wird die Fähigkeit durch einen engen Änderungsrahmen: Ein beobachtetes Problem liefert den Nachweis, eine kleine Änderung adressiert genau dieses Problem und Tests prüfen die Wirkung vor der Freigabe.

Auch die Erstellung eines neuen Skills ist ein eigener Vorgang. Wie aus einer Demonstration zunächst ein wiederverwendbarer Ablauf entstehen kann, erklärt Phone Agents durch Vormachen trainieren: Bildschirmaufnahme, Skills und Android-Sicherheit. Diese Seite beginnt einen Schritt später: beim kontrollierten Verbessern eines bereits vorhandenen Agentenablaufs.

Was die Self-Harness-Forschung praktisch zeigt

Welche Forschung liefert einen konkreten Mechanismus für solche Verbesserungen? Das Self-Harness-Paper beschreibt einen dreistufigen Kreislauf: Schwächen werden aus Ausführungsspuren gewonnen, daraus entstehen begrenzte Änderungsvorschläge für den Harness und jeder Vorschlag wird vor seiner Annahme validiert.

Im ersten Schritt werden reale oder evaluierte Abläufe ausgewertet. Nicht jede fehlgeschlagene Aufgabe ist automatisch ein Harness-Problem. Die Spur muss zeigen, an welcher Stelle Planung, Werkzeugwahl, Verifikation oder Fehlerbehandlung unzureichend war. Eine unklare Nutzeranfrage, ein ausgefallener externer Dienst oder eine nicht unterstützte Aktion benötigen möglicherweise eine andere Reaktion als eine Änderung am Skill.

Danach folgt ein möglichst kleiner Vorschlag. Der Harness wird in der Studie breit definiert: Er umfasst Prompts, Werkzeuge, Laufzeitmechanismen, Prüfregeln, Orchestrierungslogik und Verfahren zur Erholung nach Fehlern. Eine Verbesserung kann daher so klein sein wie eine zusätzliche Zustandsprüfung oder so strukturell wie eine geänderte Reihenfolge zweier Werkzeuge.

Im dritten Schritt wird die vorgeschlagene Änderung gegen passende Aufgaben geprüft. Die Autoren berichten auf Terminal-Bench-2.0 von höheren Erfolgsraten auf zurückgehaltenen Tests für drei feste Basismodelle. Verändert wurde der Harness, nicht die Gewichte dieser Modelle. Das Ergebnis ist ein Forschungssignal dafür, dass ein besserer Arbeitsrahmen die Leistung eines unveränderten Modells steigern kann; es ist kein allgemeiner Leistungsnachweis für jede Android-App.

Für FoneClaw ist vor allem die Schleifenstruktur relevant: Spur auswerten, begrenzte Änderung formulieren, separat validieren und erst danach übernehmen. Dadurch wird aus „Der Agent sollte daraus lernen“ ein überprüfbarer technischer Prozess.

Die breitere Salesforce-Einordnung zu selbstverbessernden Agenten zeigt, dass die kontrollierte Weiterentwicklung von Agentenverhalten zu einem eigenen Produkt- und Forschungsgebiet wird. Für Phone Agents kommt eine zusätzliche Anforderung hinzu: Jede Verbesserung muss sich in wechselnden Android-Zuständen und unter unveränderten Berechtigungsgrenzen bewähren.

Wie FoneClaw aus Ausführungsergebnissen lernt

Ist FoneClaw ein selbstverbessernder Phone Agent? Ja. FoneClaw kann Ausführungsergebnisse und Fehlerspuren verwenden, um Planung, Harness-Verhalten und wiederverwendbare Telefon-Skills weiterzuentwickeln. Diese Änderungen durchlaufen einen geregelten Lebenszyklus mit Tests, Freigabe, Versionsnachweis, gestaffelter Einführung und Rollback.

Die Modellarchitektur bleibt dabei klar. Der Nutzer konfiguriert ein unterstütztes Modell, das innerhalb des FoneClaw-Agentenablaufs Verständnis, Schlussfolgerungen und Planung liefert. FoneClaw stellt dem Modell den kontrollierten Arbeitsrahmen bereit und führt unterstützte Android-Aktionen aus. Eine Verbesserung des Harness verändert die Art, wie dieser Ablauf Werkzeuge auswählt oder Ergebnisse prüft, nicht die Gewichte des konfigurierten Modells.

Ein Beispiel ist ein Erinnerungs-Skill, der bei mehrdeutigen Zeitangaben zu früh eine Annahme trifft. Die Fehlerspur kann zeigen, dass „morgen Abend“ ohne Rückfrage in eine feste Uhrzeit umgewandelt wurde. Eine minimale Verbesserung ergänzt eine Regel, die bei fehlender eindeutiger Uhrzeit nachfragt. Regressionstests stellen anschließend sicher, dass klare Angaben wie „morgen um 19 Uhr“ weiterhin ohne unnötige Rückfrage verarbeitet werden.

Ein zweites Beispiel betrifft eine geänderte App-Oberfläche. Wenn ein unterstützter Schritt ein erwartetes Element nicht mehr findet, kann FoneClaw die sichtbare Abweichung dokumentieren. Der Verbesserungsvorschlag darf nicht einfach auf eine neue Bildschirmposition zielen. Robuster ist eine aktualisierte Zustandsprüfung, die Bedeutung, App-Kontext und erwartetes Ergebnis berücksichtigt.

Android-Berechtigungen und Nutzerbestätigungen bleiben bei jeder Version erhalten. Benötigt eine Änderung einen zusätzlichen Zugriff, wird dieser Unterschied ausdrücklich geprüft und freigegeben. Ein Skill kann seinen eigenen Berechtigungsumfang nicht still erweitern. Folgenreiche Schritte bleiben sichtbar und werden weiterhin bestätigt.

Damit unterscheidet sich produktive Selbstverbesserung sowohl von Modelltraining als auch von unkontrollierter Selbstmodifikation. Forschung zu Trainingsumgebungen für Telefonmodelle behandelt PhoneBuddy-4B und Phone-Agent-Training: Warum Mock-App RL für Android Agents wichtig ist. FoneClaws Verbesserungsschleife konzentriert sich dagegen auf den bereits eingesetzten Agenten-Harness und seine unterstützten Android-Abläufe.

Der vollständige Weg von der Fehlerspur bis zum Rollback

Wie wird aus einem beobachteten Problem eine produktionsreife Verbesserung? Der Ablauf beginnt mit Belegen und endet nicht mit einem erfolgreichen Einzeltest. Jede Änderung erhält eine nachvollziehbare Version, einen klaren Freigabestatus und einen getesteten Rückweg.

1. Nachweis sammeln: Ausführungsspur, sichtbarer Zustand, erwartetes Ergebnis und tatsächliche Abweichung erfassen.
2. Ursache eingrenzen: Zwischen Modellplanung, Harness-Regel, Skill, App-Zustand, Berechtigung und externem Fehler unterscheiden.
3. Minimale Änderung vorschlagen: Nur die betroffene Regel, Werkzeugauswahl oder Fehlerbehandlung anpassen.
4. Regressionstests ausführen: Ursprünglichen Fehler, normale Erfolgsfälle, Randfälle und bekannte Gegenbeispiele prüfen.
5. Berechtigungsunterschied prüfen: Feststellen, ob sich App-Zugänge, Android-Berechtigungen oder Bestätigungspunkte verändern.
6. Änderung freigeben: Testnachweise, Wirkung und mögliche Nebenfolgen vor der Annahme bewerten.
7. Version erstellen: Skill und Harness-Komponenten mit eindeutiger Versionsnummer und Änderungsgrund dokumentieren.
8. Gestaffelt ausrollen: Die neue Version zunächst in begrenztem Umfang und mit erhöhter Beobachtung einsetzen.
9. Ergebnisse überwachen: Erfolg, Teilfehler, Rückfragen, Abbrüche und Berechtigungsereignisse mit der vorherigen Version vergleichen.
10. Rollback auslösen: Bei einer Verschlechterung zur letzten freigegebenen Version zurückkehren und den Zustand nachvollziehbar erhalten.

Die Regression Suite muss mehr als denselben Test wiederholen. Sie enthält unterschiedliche Bildschirmgrößen, App-Zustände, Sprachen, Berechtigungsvarianten und unvollständige Eingaben, soweit sie für den Skill relevant sind. Ein Nachrichten-Skill sollte etwa eindeutige und mehrdeutige Kontakte, leeren Inhalt, fehlende Berechtigung und einen manuellen Abbruch abdecken.

Der Berechtigungsvergleich ist ein eigener Freigabepunkt. Eine scheinbar kleine Änderung kann ein neues Werkzeug oder eine weitere App benötigen. Dann verändert sich nicht nur die Funktion, sondern auch die Reichweite. Der neue Zugriff wird sichtbar geprüft und in der Version dokumentiert. Vertiefende Laufzeitkontrollen behandelt Sicherheit von KI-Agent-Skills: Warum Phone Agents Laufzeitprüfungen brauchen.

Ein Rollback stellt nicht nur alten Code wieder her. Es muss auch laufende Aufgaben, gespeicherte Skill-Versionen und bereits ausgeführte Android-Schritte berücksichtigen. Die Rückkehr zur vorherigen Version darf eine bestätigte Aktion nicht erneut ausführen. Deshalb gehören idempotente Schritte, Zustandsnachweise und klare Wiederaufnahmebedingungen zum Rückrollplan.

Warum gut gemeinte Änderungen neue Fehler erzeugen können

Warum kann ein Optimierer einen Agenten verschlechtern, obwohl er einen Testfehler beseitigt? Eine Fehlerspur kann falsch interpretiert, die Änderung zu eng auf ein Beispiel zugeschnitten oder ein veralteter Test als allgemeine Wahrheit behandelt werden. Selbstverbesserung benötigt deshalb Gegenbeispiele und eine Prüfung der Ursache.

Die Phantom-Guardrails-Forschung vom Juli 2026 beschreibt ein besonders wichtiges Gegenrisiko: Ein Optimierer kann einen Fehler erfinden oder falsch zuschreiben und anschließend eine unnötige Schutzregel hinzufügen. Wenn die Annahme nur davon abhängt, dass das vermeintliche Problem unterdrückt wird, kann eine solche Regel bestehen bleiben, obwohl sie reale Aufgaben behindert.

Ein Phantomfehler ist für Phone Agents leicht vorstellbar. Ein Test schlägt fehl, weil eine App vorübergehend nicht erreichbar war. Der Optimierer könnte daraus fälschlich ableiten, dass diese App grundsätzlich gemieden werden muss. Eine neue Sperrregel ließe den Test möglicherweise grün erscheinen, würde aber den vorgesehenen Skill dauerhaft einschränken. Die richtige Änderung wäre eine erkennbare Fehlerbehandlung mit Wiederholung oder Übergabe, keine pauschale Blockade.

Überanpassung entsteht, wenn eine Lösung nur die aufgezeichnete Oberfläche kennt. Eine neue Schaltflächenposition behebt dann genau einen Screenshot, versagt aber bei anderer Sprache, Displaygröße oder Kontokonfiguration. Gute Tests variieren deshalb Layout, Lokalisierung und App-Zustand. Sie prüfen die Bedeutung eines Elements und den erwarteten Endzustand, nicht nur eine feste Koordinate.

Berechtigungsdrift ist ein weiteres Risiko. Ein überarbeiteter Skill kann schrittweise mehr Zugriffe verlangen, weil zusätzliche Werkzeuge bequem erscheinen. Der Pflichtvergleich zwischen alter und neuer Version macht diese Veränderung sichtbar. Eine Sandbox kann den Wirkungsbereich zusätzlich begrenzen, ersetzt aber nicht die Android-Berechtigungsprüfung. Den Unterschied erläutert KI-Agent-Sandbox und Telefonberechtigungen: Warum sichere Agenten Grenzen brauchen.

Ein unveränderter Benchmark reicht ebenfalls nicht aus. Er kann bekannte Aufgaben messen, aber keine neue App-Version, unerwartete Sprache oder veränderte Systemabfrage vorwegnehmen. Produktionsreife entsteht durch eine Kombination aus festen Regressionstests, neuen Gegenbeispielen, gestaffeltem Rollout und Beobachtung realer Ergebnisse.

Freigabecheck für reale Android-Aufgaben

Woran erkennt man, ob eine selbst erzeugte Verbesserung für reale Telefone bereit ist? Die Freigabe sollte eine konkrete Aufgabe, messbare Nachweise und einen funktionierenden Rückweg verbinden. Ein bloßer Hinweis wie „Erfolgsrate verbessert“ beantwortet noch nicht, welche Zustände getestet wurden oder ob sich Berechtigungen verändert haben.

Für reale Android-Nutzung gehört außerdem ein manueller Ausweichweg zum Freigabekriterium. Wenn die neue Version einen Bildschirmzustand nicht sicher einordnen kann, hält FoneClaw an, zeigt den erreichten Stand und ermöglicht die praktische Fortsetzung durch den Nutzer. Unsicherheit wird damit nicht durch zusätzliche, unbestätigte Aktionen verdeckt.

Versions- und Aktionsnachweise beantworten später, welcher Skill eine Aufgabe ausgeführt hat und welche Berechtigungen dabei aktiv waren. Den umfassenderen Rahmen dafür bietet KI-Agent-Identität, Berechtigungen und Audit-Trails: Der Sicherheitsstack fürs Telefon.

FoneClaw ist ein selbstverbessernder Phone Agent, weil es diese kontrollierte Schleife produktiv nutzt: Ergebnisse beobachten, Ursache verstehen, eine begrenzte Verbesserung vorschlagen, testen, freigeben, versionieren, schrittweise bereitstellen und bei Bedarf zurückrollen. Das konfigurierte Modell liefert Verständnis und Planung; FoneClaw behält die Verantwortung für unterstützte Android-Ausführung, sichtbare Resultate, Berechtigungsgrenzen, Bestätigung und Wiederherstellung.