Technisches Resümee: PreAct – Computer-using Agents, die bei wiederholten Aufgaben schneller werden

1. Problemstellung

Computer-using Agents (CUAs) bedienen Software durch das Beobachten von Bildschirmen und das Ausführen von Klicks oder Tastatureingaben. Obwohl sie effektiv bei der Lösung von Aufgaben sind, sind sie von Natur aus ineffizient bei wiederholter Arbeit. Aktuelle Agenten behandeln jede Instanz einer Aufgabe als ein neues Problem: Sie lesen den Bildschirm neu ein, denken jeden Schritt erneut durch und verursachen bei jeder Ausführung die vollen Kosten der Vision-and-Language-Inferenz, selbst wenn die Aufgabe identisch mit einer zuvor gelösten ist. Diese „Re-Derivation“ (erneute Ableitung) verhindert, dass Agenten die Fluenz erwerben, die Menschen durch Übung entwickeln – also die Fähigkeit, anfängliche bewusste Überlegungen in automatische Routinen zu internalisieren. Darüber hinaus scheitern bestehende Effizienzverbesserungen – wie Skill-Libraries oder Record-and-Replay-Systeme – oft daran, Geschwindigkeit mit Zuverlässigkeit in Einklang zu bringen. Skill-Libraries benötigen zur Ausführung gespeicherter Verhaltensweisen zur Laufzeit typischerweise immer noch ein Sprachmodell (LLM), während naive Record-and-Replay-Systeme keine Verifizierung besitzen und somit zu einer „blinden“ Ausführung führen, die fehlschlägt, wenn sich die Umgebung ändert oder der gespeicherte Trace fehlerhaft ist.

2. Methodik: PreAct-Architektur

PreAct führt ein System ein, das erfolgreiche Agentenläufe in direkt ausführbare Zustandsautomaten-Programme kompiliert. Die Kerninnovation ist eine „Verify-before-Store“-Disziplin (Verifizieren vor Speichern), die auf zwei Zeitskalen angewendet wird: Laufzeitverifizierung während des Replays und Vorverifizierungs-Speicherung vor dem Speichern eines Programms.

2.1 Das Artefakt: Zustandsautomaten-Programme

Anstatt flache Skripte oder parametrisierte Code-Snippets zu speichern, kompiliert PreAct eine erfolgreiche Task-Ausführung in einen kleinen Zustandsautomaten ($P = (S, T, M, V)$):

• Zustände ($S$): Jeder Zustand enthält ein Verifikationsprädikat (z. B. ein XPath-Muster oder eine Prüfung des Accessibility-Trees), das mit dem Live-Bildschirm übereinstimmen muss, bevor der Agent fortfährt.
• Transitionen ($T$): Aktionen (Klicks, Tippen, Navigationen), die den Agenten von einem Zustand zum nächsten bewegen.
• Parameter ($M$): Während des Traces eingegebene konkrete Werte (z. B. ein spezifischer Name oder eine Telefonnummer) werden zu Parametern erhoben, was es dem gleichen Programm ermöglicht, über verschiedene Instanzen derselben Task-Familie hinweg zu generalisieren.
• Ausführung: Während eines „Warmen“ Laufs durchläuft der Replayer den Graphen. Bevor eine Transition ausgelöst wird, prüft er den Live-Bildschirm gegen das Prädikat des Zustands. Wenn die Prüfung erfolgreich ist, wird die Aktion sofort ausgeführt, ohne einen LLM-Aufruf zu tätigen. Falls sie fehlschlägt (z. B. weil unerwartet ein Dialog erschien), stoppt das System und fällt auf den vollen CUA zurück.

2.2 Der Kreislauf: Select, Replay, Fall Back, Verify

Das System operiert über einen Compile-Extend-Replace-Zyklus:

1. Select (Auswählen): Ein Program Selector durchsucht den Korpus nach einem Programm, das der aktuellen Zielsetzung entspricht.
2. Replay (Wiederholen): Falls gefunden, führt der Replayer den Zustandsautomaten mit einer Verifizierung pro Schritt aus.
3. Fall Back (Zurückfallen): Wenn ein Prädikat fehlschlägt oder eine Aktion einen Fehler verursacht, geht die Kontrolle auf den vollen CUA über, der die Aufgabe ausgehend vom aktuellen Bildschirmzustand löst und einen neuen Trace aufzeichnet.
4. Verify and Store (Verifizieren und Speichern): Nach einem Erfolg wird der neue Trace in ein Kandidatenprogramm $P'$ kompiliert. Entscheidend ist, dass $P'$ nicht sofort gespeichert wird. Es durchläuft ein Verify-before-Store Gate.

2.3 Das Verify-before-Store Gate

Dies ist der primäre Mechanismus von PreAct, um eine monotone Verbesserung sicherzustellen. Bevor ein Programm in den Korpus aufgenommen wird:

1. Die Umgebung wird in einen sauberen Ausgangszustand zurückgesetzt.
2. Das Kandidatenprogramm $P'$ wird von Grund auf neu ausgeführt.
3. Ein unabhängiger Evaluator prüft, ob die Aufgabe tatsächlich gelöst wurde.
4. Das Programm wird (oder ersetzt eine ältere Version mit demselben Dedup-Signature) nur dann gespeichert, wenn der Replay erfolgreich abgeschlossen wurde und der Evaluator bestätigt, dass die Aufgabe gelöst wurde.

Dieses Gate fängt gezielt „verlustbehaftete“ (lossy) Programme ab, die zwar zu 100 % durchlaufen (alle Aktionen werden ausgeführt), aber das Ziel nicht erreichen (z. B. ein Kontaktformular wird ausgefüllt und gespeichert, aber ein veraltetes Feld verhindert die tatsächliche Erstellung des Kontakts).

2.4 Fallback-Mechanismus

Wenn das Gate alle Kandidatenprogramme für eine Aufgabe ablehnt (wodurch der Korpus für diese Task leer bleibt), nutzt PreAct einen Fallback: Es triggert eine frische CUA-Exploration für den zweiten Durchlauf. Dies stellt sicher, dass das System selbst dann nicht einfach aufgibt, wenn es kein verifiziertes Programm findet, und so die Leistungsfähigkeit gegenüber starken Record-and-Replay-Baselines wie Muscle-Mem beibehält.

3. Kernbeiträge

• Direkte Ausführung verifizierter Zustandsautomaten: PreAct verschiebt das Ausführungsparadigma von LLM-gesteuerter Argumentation hin zur deterministischen Graph-Ausführung für wiederholte Aufgaben, wodurch LLM-Aufrufe pro Schritt eliminiert werden.
• Verifizierung auf zwei Zeitskalen: Das System wendet dieselbe „Erst beobachten, dann handeln“-Disziplin sowohl zur Laufzeit (pro Schritt) als auch zum Speicherzeitpunkt (Vorverifizierung beim Speichern) an. Dies verhindert die Akkumulation fehlerhafter Programme, die die Leistung im Laufe der Zeit verschlechtern würden.
• Selbst-erweiternder Korpus: Im Gegensatz zu Append-only-Caches ist der Korpus von PreAct mutabel. Neue Programme können ältere ersetzen, wenn sie das Verifizierungs-Gate passieren, was es dem System ermöglicht, die Repräsentation von Aufgaben im Laufe der Zeit zu verfeinern.
• Empirische Validierung der Effizienz: Die Arbeit etabliert „Repeated-Task Efficiency“ als erstklassige Metrik, die nicht nur Erfolgsraten, sondern auch die Reduktion der Wall-Clock-Zeit und der LLM-Token-Kosten misst.

4. Experimentelle Ergebnisse

Die Autoren evaluierten PreAct auf drei Benchmarks: AndroidWorld (Mobile), OSWorld (Desktop) und WebArena (Web).

• Geschwindigkeit und Kosten: Warme Läufe (Replay gespeicherter Programme) sind im Vergleich zu kalten Läufen (Neuderivation von Grund auf) um 8,5–13× schneller in der Wall-Clock-Zeit und verursachen null LLM-Kosten pro Schritt. Der einmalige Overhead für Kompilierung und Verifizierung eines Programms entspricht etwa einem zusätzlichen Solve (+162 % bei Android, +217 % bei OSWorld), dieser wird jedoch über nachfolgende Läufe amortisiert.
• Monotone Verbesserung: Mit aktiviertem Verify-Gate verbessern sich die Erfolgsraten bei wiederholten Durchläufen stetig oder bleiben stabil.
  • AndroidWorld: Mittlere Verbesserung von +1,33 Aufgaben (von 15) von Cold zu Warm.
  • OSWorld: Mittlere Verbesserung von +0,2 Aufgaben (von 6).
  • WebArena: Während das Gate eine Regression in der rohen Warm-Erfolgsrate verursacht (aufgrund der hohen Ablehnung brüchiger Web-Selektoren), ist der Grenznutzen des Gates positiv. Ohne das Gate verschlechtert sich die Leistung signifikant (z. B. -5,8 Aufgaben auf WebArena); mit dem Gate wird die Verschlechterung reduziert (-4,0 Aufgaben).
• Notwendigkeit des Gates: Ablationsstudien zeigen, dass das Deaktivieren des Verify-Gates zu einem Leistungszusammenbruch über alle Plattformen hinweg führt. Das Gate verhindert den „Läuft, aber funktioniert nicht“-Fehlermodus, bei dem ein Programm zwar alle Schritte ausführt, aber die Logik der Aufgabe verfehlt.
• Effektivität des Fallbacks: Auf WebArena, wo das Gate viele Programme ablehnt, ermöglicht das Hinzufügen eines „Cache-Miss-to-CUA“-Fallbacks PreAct, die Leistung der starken Baseline Muscle-Mem zu erreichen (statistisch ununterscheidbar, $p \approx 0,84$), wodurch die durch aggressive Verifizierung entstandene Lücke geschlossen wird.
• Robustheit: Die Ergebnisse sind robust gegenüber der Wahl des LLM für die Kompilierung (Claude vs. Gemini) und der Wahl des Selektors (LLM-basiert vs. Embedding-Retriever). Der Kernmechanismus, nicht die spezifische Modellwahl, treibt die Ergebnisse voran.

5. Bedeutung und Ansprüche

Die Arbeit behauptet, dass PreAct zeigt, dass Computer-using Agents die Fähigkeit zum kontinuierlichen Lernen erwerben können, ähnlich wie Menschen: schneller und kostengünstiger bei wiederholten Aufgaben zu werden, ohne die Zuverlässigkeit zu opfern.

• Fluenz vs. Blindheit: PreAct erreicht Fluenz nicht durch blinde Repetition, sondern durch „Vorhersage mit Verifizierung“. Der Agent handelt automatisch, wenn der Bildschirm den Erwartungen entspricht, kehrt aber sofort zur Deliberation (Abwägung) zurück, wenn dies nicht der Fall ist.
• Design statt Tuning: Die Autoren betonen, dass die Leistungssteigerungen durch die Systemarchitektur (Speichere das Programm, das du ausführst; verifiziere vor dem Speichern) getrieben werden und nicht durch Prompt Engineering, Runtime-Guardrails oder spezifische Modellentscheidungen.
• Eine neue Dimension der Evaluierung: Die Arbeit argumentet, dass das Benchmarking über einfache Erfolgsraten hinausgehen muss und auch die Kosten der wiederholten Ausführung einschließen sollte. Ein Agent, der jede Aufgabe neu ableitet, ist weniger effizient als ein Agent, der gelernt hat, die Deliberation zu überspringen, selbst wenn beide die gleiche Erfolgsrate erzielen.

Zusammenfassend bietet PreAct einen Rahmen, in dem Agenten eine Bibliothek verifizierter, direkt ausführbarer Programme aufbauen, was es ihnen ermöglicht, vertraute Aufgaben mit der Geschwindigkeit eines Makros und der Zuverlässigkeit eines verifizierten Agenten zu lösen und so die „Re-Derivation Tax“ aktueller Computer-using Agents effektiv zu eliminieren.