A2UI Forklaret: Hvad Agent-to-UI-protokollen gør (og ikke)
A2UI er en deklarativ JSON-protokol, der lader AI-agenter beskrive grænseflader, som en klient kan gengive. Hvordan det virker, hvilke renderere der findes, og hvad det ikke gør.
Core Takeaway
A2UI (Agent to UI) er en åben, deklarativ JSON-protokol skabt af Google. En AI-agent sender en beskrivelse af en grænseflade, og en klient gengiver den med sine egne native komponenter i stedet for at udføre kode fra agenten. Det er en måde at flytte UI-struktur og data på tværs af en tillidsgrænse, ikke et animationssystem, et komponentbibliotek eller en færdig renderer. ExodeUI er ikke en A2UI-renderer og er ikke tilknyttet Google.
Hvad er A2UI?
A2UI er en protokol til agent-drevne grænseflader. I stedet for at returnere en væg af tekst eller udføre genereret kode, sender en AI-agent en strøm af JSON-meddelelser, der beskriver en UI: hvilken overflade der skal oprettes, hvilke komponenter den indeholder, og hvilke data fylder dem. Klienten modtager disse meddelelser og gengiver resultatet med komponenter, som den allerede har tillid til. A2UI blev skabt af Google og er Apache 2.0-licenseret med bidrag fra CopilotKit og open source-fællesskabet. Fra oktober 2026 var den nuværende produktionsspecifikation v0.9.1, og v1.0 var en udgivelseskandidat.
Problemet A2UI forsøger at løse
Agenter er gode til at producere et brugbart svar og dårlige til at levere det som en grænseflade. Et tekstsvar kan ikke vise en sammenligningstabel, en ordreformular eller et dashboard. Generering af vilkårlig HTML eller JavaScript løser præsentationsproblemet og skaber et sikkerhedsproblem, fordi klienten nu kører kode, den ikke skrev. A2UI tager en tredje vej: Agenten beskriver brugergrænsefladen i et begrænset format, og klienten beslutter, hvordan den skal gengives. Agenten kan kun bruge komponenter, som klienten har godkendt, og outputtet er data i stedet for eksekverbar kode.
Hvordan en A2UI overflade er bygget
Protokollen bruger et lille sæt meddelelsestyper. Det nøjagtige skema ændres mellem versioner, så tjek specifikationen, før du implementerer en, men formen er stabil.
- createSurface: fortæller rendereren om at oprette en ny overflade, som er en region af grænsefladen, som agenten kan opdatere
- updateComponents: tilføjer eller ændrer komponentdefinitioner på den overflade
- updateDataModel: ændrer de data, komponenterne viser, uden at sende strukturen igen
- deleteSurface: fjerner en overflade, når den ikke længere er nødvendig
Rendere og transporter
A2UI er transportagnostisk. Specifikationen beskriver beskederne, ikke hvordan de rejser. Projektet lister renderer-implementeringer til Angular, Flutter, Lit, React og Markdown, og transportbindinger til AG-UI, A2A og MCP, med WebSockets, SSE og REST også anvendelige. Den fleksibilitet er pointen: Det samme agentsvar kan gengives af en webklient, en mobilapp eller en desktopapplikation, hver ved hjælp af sit eget designsystem.
Hvad A2UI ikke gør
A2UI er let at overlæse. Det sender ikke et komponentbibliotek, du kan slippe ind i en app, og det gengiver ikke noget i sig selv: du har brug for en renderer og et komponentkatalog, som klienten kontrollerer. Det bestemmer ikke, hvordan brugergrænsefladen bevæger sig. Det erstatter ikke MCP, som eksponerer værktøjer og data for en model, eller AG-UI, som bærer interaktionsbegivenhederne mellem en agent og en frontend. Og det fjerner ikke behovet for teknisk gennemgang: genererede grænseflader skal stadig håndtere indlæsning, tomme og fejltilstande, tilladelser og tilgængelighed.
A2UI vs AG-UI vs MCP
Disse tre nævnes ofte sammen, fordi de løser forskellige lag af det samme problem. En nyttig stenografi: A2UI beskriver grænsefladen, AG-UI bærer interaktionen, og MCP giver agenten værktøjer og data. A2UI's egen dokumentation beskriver AG-UI som en transportbinding for A2UI, og A2UI kan også rejse over MCP. De er komplementære, ikke konkurrerende standarder. Hvis du vælger en integration, så tag udgangspunkt i, hvad din klient kan gengive, og hvilken transport den allerede understøtter, ikke fra den protokol, der har størst momentum.
Hvor animation og interaktion passer ind
A2UI beskriver struktur og data. Bevægelse er et klientproblem: rendereren bestemmer, om en overflade vises øjeblikkeligt, falmer ind eller går over fra en tidligere tilstand. Det er gode nyheder for produktteams, fordi det holder animationssystemet i klienten, hvor det kan respektere designsystemet og tilgængelighedsindstillingerne. Det betyder også, at en A2UI-implementering ikke automatisk animeres. Hvis en genereret grænseflade har brug for et knaptryk, en tilstandsovergang eller en maskotreaktion, skal klienten angive denne adfærd. ExodeUI kan afspille interaktiv bevægelse i en klient, og den har en MCP-server til AI-kodningsværktøjer, men den er ikke en A2UI-renderer og bør ikke beskrives som en.
Snippet til produktionsimplementering
// Simplified shape of an A2UI message stream (schema differs by version).
{ "createSurface": { "surfaceId": "cart" } }
{ "updateComponents": { "surfaceId": "cart", "components": [ /* ... */ ] } }
{ "updateDataModel": { "surfaceId": "cart", "data": { /* ... */ } } }
{ "deleteSurface": { "surfaceId": "cart" } }Tast Principles for at huske
- A2UI er en JSON-protokol til agent-beskrevne grænseflader, skabt af Google og licenseret under Apache 2.0
- Klienten renderer med sine egne komponenter; agenten udfører ikke vilkårlig UI-kode
- Det definerer beskeder og overlader rendereren, transporten og bevægelsen til klienten
- Det er ikke et animationssystem eller et drop-in-komponentbibliotek
- ExodeUI er ikke en A2UI-renderer og har ingen tilknytning til Google