Generative UI von KI-Agenten mit A2UI-1.0-Komponentenkatalogen begrenzen
Googles Standard A2UI 1.0 entkoppelt von KI-Agenten erzeugte Oberflächenbeschreibungen vom Rendering der Host-Anwendung, indem er die Ausgabe über Protokolle wie AG-UI auf deklarierte Komponentenkataloge beschränkt. Das Release ergänzt typisierte bidirektionale Funktionsaufrufe, Multi-Katalog-Ansichten und Berechtigungsprüfungen zur Laufzeit, sodass Designsysteme und lokale Ausführung unter deterministischer Kontrolle bleiben.
Teams, die agentengesteuerte Oberflächen entwickeln, pflegen am Ende oft eigene UI-Integrationsschichten für jedes Agent-Framework und jedes Frontend. Googles Release von A2UI 1.0 löst diese Kopplung, indem es Generative UI als katalogbasierten Vertrag zwischen KI-Agent und Host-Anwendung definiert.
Über offene Transportprotokolle wie AG-UI oder A2A trennt A2UI 1.0 das, was eine Oberfläche anzeigt, von der konkreten Darstellung im Produkt. Frontend-Teams stellen reale Komponenten einmalig bereit, und KI-Agenten setzen Oberflächen aus diesem freigegebenen Vokabular zusammen, statt an ein einzelnes Framework gebundenen Code zu erzeugen.
Kurz gesagt
- A2UI 1.0 beschränkt von KI-Agenten erzeugte Oberflächen auf deklarierte Komponentenkataloge und ergänzt typisierte bidirektionale Funktionsaufrufe, die der Host-Renderer zur Laufzeit prüft.
- Produktteams müssen die UI-Anbindung nicht für jedes neue Agent-Framework neu schreiben und halten Oberflächen konsistent zu ihrem eigenen Designsystem.
- Protokollgrenzen nehmen Teams die Governance-Arbeit jedoch nicht ab: Komponentenkataloge müssen weiterhin gepflegt und aufrufbare Funktionen für KI-Agenten gezielt eingeschränkt werden.
UI-Intention vom Host-Rendering entkoppeln
Ohne ein gemeinsames Protokoll für Benutzeroberflächen erfindet jede Agent-Bibliothek ihr eigenes Payload-Format und bindet die UI-Erzeugung an eine einzige Runtime. Wer das Agent-Backend wechselt oder eine weitere Client-Oberfläche ergänzt, muss die Rendering-Schicht oft neu aufbauen.
A2UI dreht diese Abhängigkeit um und macht den Komponentenkatalog der Anwendung zur maßgeblichen Quelle. Der KI-Agent wählt aus den deklarierten Komponenten und liefert eine JSON-Beschreibung des Layouts, die über AG-UI oder A2A an den Client übertragen wird.
Deterministischer Anwendungscode behält die Kontrolle über UI-Widgets und Designregeln, während der KI-Agent Komponenten auswählt und Remote-Aufgaben übernimmt. CopilotKit bindet AG-UI-Backends wie LangChain, Mastra und Google ADK ohne eigene Transportschicht an einen integrierten Komponentenkatalog an.
Bidirektionale Funktionsaufrufe und Multi-Katalog-Ansichten
In früheren v0.9-Workflows musste jede UI-Anfrage als Event herausgehen und kam als komplett neue Antwort des KI-Agenten zurück. A2UI 1.0 ersetzt diese grobe Schleife durch typisierte bidirektionale Funktionsaufrufe zwischen UI-Komponenten und KI-Agent.
Eine Komponente kann eine Funktion für Validierungen, gebundene Werte oder Button-Aktionen auslösen, etwa um eine Anbieter-ID zu verifizieren oder Lagerbestände zu prüfen. Lokale Funktionen laufen direkt in der App, Remote-Funktionen gehen an den KI-Agenten, und das Ergebnis landet unmittelbar in der aufrufenden Komponente.
Umgekehrt können KI-Agenten vom Client freigegebene Funktionen aufrufen, um gerätespezifische Zustände wie die Bildschirmgröße auszulesen. Auf der visuellen Ebene unterstützt A2UI 1.0 mehrere Komponentenkataloge auf demselben Bildschirm: Ein internes Designsystem lässt sich mit Basis-Layoutkomponenten oder dem Karten-Widget eines Partners kombinieren, während das Protokoll die Designregeln durchsetzt.
Guardrails zur Laufzeit und Aufwand beim Prompting
Direkter Funktionszugriff für KI-Agenten und die Kombination mehrerer Bibliotheken bergen klare Betriebsrisiken, solange Berechtigungen implizit bleiben. A2UI 1.0 begegnet diesem Risiko, indem der Katalog als Allowlist festlegt, welche Funktionen jede Seite aufrufen darf – geprüft durch den Renderer bei jedem einzelnen Aufruf.
Auf Modellseite etablierte v0.9 einen Prompt-first-Workflow zur Erzeugung von UI-Payloads. Google ergänzt diese Basis um A2UI Express, ein kompaktes Format zur Senkung von Token-Verbrauch und Latenz, das ohne Tool Calling auskommt.
Dennoch verursacht ein solches Protokoll laufenden Pflegeaufwand. Kataloge und Laufzeit-Allowlists zu kuratieren rechnet sich kaum für statische Workflows, in denen feste Formulare oder deterministische Ansichten bereits jeden Pfad abdecken.
Prüfen Sie vor der Einführung eines Protokolls für Generative UI, wie oft Ihr Workflow tatsächlich dynamische Oberflächen statt fester Ansichten erfordert. Die langfristige Wartbarkeit von A2UI 1.0 hängt davon ab, wie konsequent Ihr Team seinen Komponentenkatalog versioniert und prüft, während sich KI-Agenten und UI-Bibliotheken weiterentwickeln.
