A2UI Forklart: Hva Agent-to-UI-protokollen gjør (og ikke)
A2UI er en deklarativ JSON-protokoll som lar AI-agenter beskrive grensesnitt som en klient kan gjengi. Hvordan det fungerer, hvilke renderere som finnes, og hva det ikke gjør.
Kjerne takeaway
A2UI (Agent to UI) er en åpen, deklarativ JSON-protokoll laget av Google. En AI-agent sender en beskrivelse av et grensesnitt, og en klient gjengir det med sine egne opprinnelige komponenter i stedet for å kjøre kode fra agenten. Det er en måte å flytte UI-struktur og data på tvers av en tillitsgrense, ikke et animasjonssystem, et komponentbibliotek eller en ferdig gjengiver. ExodeUI er ikke en A2UI-gjengiver og er ikke tilknyttet Google.
Hva er A2UI?
A2UI er en protokoll for agentdrevne grensesnitt. I stedet for å returnere en vegg med tekst eller utføre generert kode, sender en AI-agent en strøm av JSON-meldinger som beskriver et brukergrensesnitt: hvilken overflate som skal lages, hvilke komponenter den inneholder og hvilke data som fyller dem. Klienten mottar disse meldingene og gjengir resultatet med komponenter den allerede stoler på. A2UI ble opprettet av Google og er Apache 2.0-lisensiert, med bidrag fra CopilotKit og åpen kildekode-fellesskapet. Fra oktober 2026 var gjeldende produksjonsspesifikasjon v0.9.1 og v1.0 var en utgivelseskandidat.
Problemet A2UI prøver å løse
Agenter er flinke til å lage et nyttig svar og dårlige til å levere det som et grensesnitt. Et tekstsvar kan ikke vise en sammenligningstabell, et bestillingsskjema eller et dashbord. Generering av vilkårlig HTML eller JavaScript løser presentasjonsproblemet og skaper et sikkerhetsproblem, fordi klienten nå kjører kode den ikke skrev. A2UI tar en tredje rute: agenten beskriver brukergrensesnittet i et begrenset format, og klienten bestemmer hvordan det skal gjengis. Agenten kan bare bruke komponenter klienten har godkjent, og utdata er data i stedet for kjørbar kode.
Hvordan en A2UI overflate er bygget
Protokollen bruker et lite sett med meldingstyper. Det nøyaktige skjemaet endres mellom versjoner, så sjekk spesifikasjonen før du implementerer en, men formen er stabil.
- createSurface: ber rendereren om å lage en ny overflate, som er en region av grensesnittet agenten kan oppdatere
- updateComponents: legger til eller endrer komponentdefinisjoner på den overflaten
- updateDataModel: endrer dataene komponentene viser, uten å sende strukturen på nytt
- deleteSurface: fjerner en overflate når den ikke lenger er nødvendig
Renderere og transporter
A2UI er transportagnostisk. Spesifikasjonen beskriver meldingene, ikke hvordan de reiser. Prosjektet viser gjengivelsesimplementeringer for Angular, Flutter, Lit, React og Markdown, og transportbindinger for AG-UI, A2A og MCP, med WebSockets, SSE og REST også brukbare. Den fleksibiliteten er poenget: det samme agentsvaret kan gjengis av en nettklient, en mobilapp eller en skrivebordsapplikasjon, som hver bruker sitt eget designsystem.
Hva A2UI ikke gjør
A2UI er lett å overlese. Den sender ikke et komponentbibliotek som du kan slippe inn i en app, og det gjengir ikke noe av seg selv: du trenger en gjengiver og en komponentkatalog som klienten kontrollerer. Det bestemmer ikke hvordan brukergrensesnittet beveger seg. Den erstatter ikke MCP, som eksponerer verktøy og data for en modell, eller AG-UI, som bærer interaksjonshendelsene mellom en agent og en frontend. Og det fjerner ikke behovet for teknisk gjennomgang: genererte grensesnitt må fortsatt håndtere lasting, tomme og feiltilstander, tillatelser og tilgjengelighet.
A2UI vs AG-UI vs MCP
Disse tre nevnes ofte sammen fordi de løser forskjellige lag av samme problem. En nyttig stenografi: A2UI beskriver grensesnittet, AG-UI bærer interaksjonen, og MCP gir agenten verktøy og data. A2UI sin egen dokumentasjon beskriver AG-UI som en transportbinding for A2UI, og A2UI kan også reise over MCP. De er komplementære, ikke konkurrerende standarder. Hvis du velger en integrasjon, start fra hva klienten din kan gjengi og hvilken transport den allerede støtter, ikke fra protokollen med mest fart.
Der animasjon og interaksjon passer
A2UI beskriver struktur og data. Bevegelse er et klientproblem: Gjengiveren bestemmer om en overflate vises umiddelbart, toner inn eller går over fra en tidligere tilstand. Det er gode nyheter for produktteam, fordi det holder animasjonssystemet i klienten der det kan respektere designsystemet og tilgjengelighetsinnstillingene. Det betyr også at en A2UI-implementering ikke er automatisk animert. Hvis et generert grensesnitt trenger et knappetrykk, en tilstandsovergang eller en maskotreaksjon, må klienten gi denne oppførselen. ExodeUI kan spille interaktiv bevegelse i en klient, og den har en MCP-server for AI-kodingsverktøy, men den er ikke en A2UI-renderer og bør ikke beskrives som en.
Snippet for produksjonsimplementering
// 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 å huske
- A2UI er en JSON-protokoll for agentbeskrevne grensesnitt, laget av Google og lisensiert under Apache 2.0
- Klienten gjengir med sine egne komponenter; agenten kjører ikke vilkårlig UI-kode
- Den definerer meldinger og overlater rendereren, transporten og bevegelsen til klienten
- Det er ikke et animasjonssystem eller et drop-in-komponentbibliotek
- ExodeUI er ikke en A2UI-gjengiver og har ingen tilknytning til Google