Tschüss, GUI! Ein "LLM-freundliches" Computer-Schnittstellenkonzept von einem Team der chinesischen Akademie der Wissenschaften ist da.
Große Modell-Agenten helfen Ihnen beim automatischen Betrieb Ihres Computers. Die Vision ist großartig, aber die Realität ist hart.
Fast alle bestehenden LLM-Intelligenzagenten können zwei zentrale "Schmerzpunkte" nicht umgehen:
Niedrige Erfolgsrate: Bei etwas komplexeren Aufgaben scheitert der Agent häufig und bleibt oft an einem bestimmten Schritt hängen, ohne zu wissen, was er tun soll.
Schlechte Effizienz: Für eine einfache Aufgabe muss der Agent mit dem System mehrere Dutzend Runden "extremes Ziehen und Drücken" durchführen, was lange dauert und die Zuschauer nervt.
Wo liegt das Problem? Ist das aktuelle große Modell noch nicht klug genug?
Eine neueste Studie des Teams des Instituts für Software des Chinesischen Akademie der Wissenschaften gibt eine überraschende Antwort: Der echte Engpass liegt in der grafischen Benutzeroberfläche (GUI), die wir seit über 40 Jahren kennen und nutzen.
Die "imperative" GUI in eine "deklarative" umwandeln
Ja, es ist die GUI, die seit den 1980er Jahren populär wurde und die Art der Mensch-Maschine-Interaktion vollständig veränderte. Sie wurde seit jeher für Menschen maßgeschneidert, und ihre Designphilosophie steht im Gegensatz zum Fähigkeitsmodell von LLM.
Das Forschungsteam hat das zentrale Problem der GUI aufgezeigt: Beim Verwenden der GUI können die Funktionen einer Anwendung nicht direkt zugegriffen werden, sondern es muss auf Navigation und Interaktion zurückgegriffen werden.
Beispielsweise sind die GUI-Funktionssteuerelemente hinter mehreren Ebenen von Menüs, Registerkarten und Dialogfeldern versteckt. Um auf die Steuerelemente zuzugreifen, muss man Menüs, Dropdown-Boxen usw. anklicken, um die Steuerelemente auf dem Bildschirm erscheinen zu lassen. Zweitens erfordert die Verwendung vieler Steuerelemente (z. B. Scrollbalken, Textauswahl) wiederholte Anpassungen und die Beobachtung der Rückmeldung, um einen hochfrequenten "Beobachtungs-Handlungs"-Zyklus zu bilden.
Das Forschungsteam hat treffend darauf hingewiesen, dass hinter diesem imperativen Design der GUI vier "Schlüsselannahmen" über menschliche Benutzer versteckt sind:
- Gute Augen: Menschen sind gut in der visuellen Erkennung und können schnell die Position von Schaltflächen, Symbolen und Menüs bestimmen.
- Schnelle Bewegungen: Menschen können den "Beobachtungs-Handlungs"-Zyklus schnell und leicht durchführen.
- Begrenztes Gedächtnis: Der temporäre Gedächtnisspeicher von Menschen ist begrenzt, daher sollte die Oberfläche einfach sein und nur wenige Optionen auf einmal anzeigen.
- Lustig auf Gehirnarbeit: Die kognitive Kosten für Menschen, konkrete Regeln zu lernen und sich zu erinnern (z. B. Programmiersprachensyntax), sind hoch, aber sie sind gut darin, "Multiple-Choice"-Fragen zu beantworten.
Allerdings stimmen diese Annahmen überhaupt nicht mit den Fähigkeiten von LLM überein:
LLM hat schlechte Augen: Seine visuelle Fähigkeit ist begrenzt, und es ist sehr schwierig, ihm zu ermöglichen, Informationen auf dem Bildschirm präzise zu erkennen.
LLM reagiert langsam: Eine Inference kann mehrere Sekunden oder sogar Minuten dauern, was zu langen Wartezeiten führt.
LLM hat ein ausgezeichnetes Gedächtnis: Sein großes Kontextfenster ermöglicht es ihm, eine enorme Menge an Informationen problemlos zu verarbeiten. Es hat keine Angst vor vielen Optionen.
LLM ist ein Format-Experte: Das Ausgeben präziser strukturierter Anweisungen ist seine Stärke.
Das Ergebnis ist, dass LLM beim Verwenden der GUI gezwungen ist, sowohl die Rolle des "Gehirns" (Strategie) als auch die Rolle der "Hände" (Mechanismus) zu übernehmen. Es muss sowohl Aufgaben basierend auf der Semantik planen als auch die mühsamen und ihm ungeeigneten unteren Ebenenoperationen behandeln. Dies führt nicht nur zu einer geringen Effizienz, sondern auch zu einer hohen kognitiven Belastung und einer hohen Fehleranfälligkeit.
Diese "imperative" Interaktionsweise ist wie beim Taxifahren zu einem Ort: Sie können dem Fahrer nicht direkt das Ziel nennen, sondern müssen ihn Schritt für Schritt anweisen, wie er fahren soll: "200 Meter vorne links abbiegen, dann 50 Meter geradeaus fahren, an der Ampel rechts abbiegen...". Sobald Sie einen Schritt falsch angeben oder der Fahrer etwas falsch versteht, ist alles umsonst. Dies ist genau die gegenwärtige schwierige Situation von LLM-Intelligenzagenten.
Is es möglich, dass LLM beim "Taxifahren" nur das Endziel nennen muss und die Restlichen Routenplanung und konkreten Fahrmanöver einem "alten Hasen" überlassen werden können?
Dies ist der zentrale Gedanke dieser Studie: Die Schnittstelle von "imperativ" in "deklarativ" umzuwandeln. Dazu hat das Forschungsteam auf der Grundlage der Zugänglichkeitsmechanismen von GUI und Betriebssystem eine neue Abstraktion vorgeschlagen - deklarative Schnittstelle (GOI).
Das Wesen von GOI liegt in der "Trennung von Strategie und Mechanismus":
Strategie (Policy): Was zu tun ist, d. h. die hohe Ebenen-Semantikplanung und die Funktionsorchestrierung von Aufgaben. Beispielsweise erfordert die Aufgabe "Den Hintergrund aller Dias auf blau setzen" die nacheinander Verwendung der beiden Funktionen "blau" und "Auf alle anwenden". Dies ist etwas, in dem LLM gut ist.
Mechanismus (Mechanism): Wie es konkret zu tun ist, d. h. die unteren Ebenen-Navigation und -Interaktion. Beispielsweise: "Auf die Registerkarte 'Design' klicken -> Auf 'Hintergrundformatieren' klicken -> Auf 'Einfärben' klicken -> ...". Oder das ständige Ziehen des Scrollbalkens, um an die richtige Position zu gelangen. Dies ist etwas, in dem LLM nicht gut ist, aber das automatisiert werden kann.
GOI übernimmt den mühsamen und fehleranfälligen "Mechanismus"-Teil und bietet LLM nur drei einfache und direkte "deklarative" Primitive: Zugriff (access), Zustand (state) und Beobachtung (observation).
Jetzt muss LLM nicht mehr wie ein Anfängerfahrer ängstlich jede Mikroanweisung abgeben, sondern ist eher wie ein geschickter Kommandeur: Es muss nur über GOI eine hohe Ebenen-Anweisung wie "Zugriff auf 'blau' und 'Auf alle anwenden'" oder "Den Scrollbalken auf 80 % setzen" erteilen, und GOI wird automatisch alle dazwischenliegenden GUI-Navigationen und -Interaktionen ausführen.
Somit kann LLM endlich aus dem Morast der GUI befreit werden und sich auf das konzentrieren, was es am besten kann: die Semantik verstehen und die Aufgaben planen. Noch wichtiger ist, dass der gesamte Prozess keine Änderung des Quellcodes der Anwendung erfordert und auch nicht von der API der Anwendung abhängt.
Wie löst GOI die Kopplung von "Strategie" und "Mechanismus" auf?
Die Implementierung von GOI besteht aus zwei Phasen: Offline-Modellierung und Online-Ausführung.
Schritt 1: Offline-"Kartenerstellung". In der Offline-Phase wird GOI automatisch die zugänglichen Steuerelemente der Zielanwendung (z. B. Word) erkunden, die Änderungen der Oberflächenelemente vor und nach dem Klicken analysieren und so eine vollständige "UI-Navigationskarte" (UI Navigation Graph) erstellen.
Aber es folgen auch Herausforderungen: Komplexe Anwendungen sind voller Zykluspfade und "Zusammenführungsnodes" (d. h. mehrere Pfade können zu demselben Steuerelement führen), und verschiedene Pfade können unterschiedliche Funktionen desselben Steuerelements auslösen.
Das Geniale an GOI ist, dass es durch einen Algorithmus zur Zyklusentfernung und einer kostenbasierten "selektiven Externalisierung" diese komplexe Grafik (Graph) in eine "Wald"-Struktur mit klarem Pfad und ohne Pfadmehrdeutigkeit umwandelt. Dies stellt sicher, dass es für LLM immer einen eindeutigen und bestimmten Pfad gibt, um auf jede Funktion zuzugreifen.
Schritt 2: Online-Ausführung. In der Online-Phase der Aufgabenausführung muss LLM nicht mehr eine feingranulierte GUI-Navigations- und Interaktionssequenz ausgeben.
Stattdessen wird von GOI eine komprimierte, für das LLM-Kontextfenster sehr geeignete textbasierte "Karte" bereitgestellt. Wenn LLM eine Aufgabe ausführen muss, muss es nur die drei deklarativen Primitive-Schnittstellen von GOI aufrufen:
Zugriff (Access): Über die visit-Schnittstelle wird direkt die ID der Zielfunktionssteuerung, auf die zugegriffen werden soll, deklariert. GOI wird automatisch den Pfad berechnen und die Navigation ausführen.
Zustand (State): Über Schnittstellen wie set_scrollbar_pos(), select_lines() oder select_controls() wird direkt der Endzustand, den die Steuerelemente erreichen sollen, deklariert. Beispielsweise kann der Scrollbalken direkt auf 80 % der Position gesetzt werden, ohne das Ziehen zu simulieren.
Beobachtung (Observation): Über Schnittstellen wie get_texts() kann direkt die strukturierte Information der Steuerelemente abgerufen werden, ohne dass LLM eine pixelgenaue Bildschirminhaltserkennung durchführen muss.
Diese Schnittstellen sind nicht von der "API" einer bestimmten Anwendung abhängig, sondern basieren direkt auf der allgemeinen Zugänglichkeit von GUI und Betriebssystem.
Experimentelles Ergebnis: Vom "mechanistischen" Fehler zum "strategischen" Fehler
Um die echten Fähigkeiten von GOI zu überprüfen, hat das Forschungsteam eine umfassende Bewertung auf dem OSWorld-W-Referenztestset, das Word, Excel und PowerPoint enthält, durchgeführt.
Die Ergebnisse zeigen, dass GOI eine überwältigende Leistungssteigerung bringt. Unter der Kernkonfiguration des GPT-5-Inferenzmodells steigt die Erfolgsrate von 44 % auf 74 %.
Außerdem hat der Agent bei über 61 % der erfolgreichen Aufgaben nur einen einzigen LLM-Aufruf benötigt, um die Kernabsicht des Benutzers effizient zu erfüllen.
Noch interessanter ist die Fehleranalyse.
Für die Basislinie mit GUI gehören 53.3 % der Fehler dem Mechanismusebenen-Fehler zu, wie beispielsweise Fehler bei der Positionierung und Erkennung von Steuerelementen über visuelle Informationen, Fehler bei der Navigationsplanung oder Fehler bei der Interaktion mit Steuerelementen. Dies ist wie ein Mensch, der fehlschlägt, weil er sich nicht auskennt.
Nach der Einführung von GOI konzentrieren sich 81 % der Fehler auf die Strategieebene, wie beispielsweise fehlerhaftes Verständnis der Semantik einer Aufgabe, fehlerhafte semantische Analyse des Bildinhalts oder fehlerhafte Wahrnehmung der Funktion von Steuerelementen.
Dies bedeutet, dass GOI LLM erfolgreich aus den mühsamen Mechanismen befreit hat und die Wahrscheinlichkeit eines Fehlers aufgrund von Mechanismusgründen verringert hat. LLM macht nicht mehr so leicht "einfache Fehler" und konzentriert sich stärker auf seine eigene Semantikverstehensfähigkeit. Dies ist wie wenn LLM das Ziel falsch positioniert, anstatt fehlzuschlagen, weil es sich nicht auskennt.
Das Team hat angegeben, dass die Einführung von GOI eine klare Richtung für die Gestaltung von Interaktionsparadigmen, die besser für große Modelle geeignet sind, weist.
Diese Arbeit bietet nicht nur Lösungsansätze für die Verbesserung der Leistung bestehender Agenten, sondern bringt uns auch dazu, darüber nachzudenken:
Sollten zukünftige Betriebssysteme und Anwendungen diese "LLM-freundlichen" deklarativen Schnittstellen von Natur aus bieten, um den Weg für stärkere und allgemeingültigere AI-Agenten zu ebnen?
Link zur Studie: https://arxiv.org/abs/2510.04607