A2UI förklarat: Vad Agent-to-UI-protokollet gör (och inte)
A2UI är ett deklarativt JSON-protokoll som låter AI-agenter beskriva gränssnitt för en klient att rendera. Hur det fungerar, vilka renderare finns och vad det inte gör.
Core Takeaway
A2UI (Agent to UI) är ett öppet, deklarativt JSON-protokoll skapat av Google. En AI-agent skickar en beskrivning av ett gränssnitt och en klient återger det med sina egna inbyggda komponenter istället för att exekvera kod från agenten. Det är ett sätt att flytta UI-struktur och data över en förtroendegräns, inte ett animationssystem, ett komponentbibliotek eller en färdig renderare. ExodeUI är inte en A2UI-renderare och är inte ansluten till Google.
Vad är A2UI?
A2UI är ett protokoll för agentdrivna gränssnitt. Istället för att returnera en vägg av text eller köra genererad kod skickar en AI-agent en ström av JSON-meddelanden som beskriver ett användargränssnitt: vilken yta som ska skapas, vilka komponenter den innehåller och vilken data som fyller dem. Klienten tar emot dessa meddelanden och återger resultatet med komponenter som den redan litar på. A2UI skapades av Google och är Apache 2.0-licensierad, med bidrag från CopilotKit och öppen källkod. Från och med oktober 2026 var den nuvarande produktionsspecifikationen v0.9.1 och v1.0 var en releasekandidat.
Problemet A2UI försöker lösa
Agenter är bra på att ta fram ett användbart svar och dåliga på att leverera det som ett gränssnitt. Ett textsvar kan inte visa en jämförelsetabell, ett beställningsformulär eller en instrumentpanel. Att generera godtyckliga HTML eller JavaScript löser presentationsproblemet och skapar ett säkerhetsproblem, eftersom klienten nu kör kod som den inte skrev. A2UI tar en tredje väg: agenten beskriver användargränssnittet i ett begränsat format och klienten bestämmer hur det ska renderas. Agenten kan bara använda komponenter som klienten har godkänt, och utdata är data snarare än körbar kod.
Hur en A2UI-yta är byggd
Protokollet använder en liten uppsättning meddelandetyper. Det exakta schemat ändras mellan versioner, så kontrollera specifikationen innan du implementerar en, men formen är stabil.
- createSurface: säger åt renderaren att skapa en ny yta, vilket är en del av gränssnittet som agenten kan uppdatera
- updateComponents: lägger till eller ändrar komponentdefinitioner på den ytan
- updateDataModel: ändrar data som komponenterna visar, utan att skicka om strukturen
- deleteSurface: tar bort en yta när den inte längre behövs
Renderare och transporter
A2UI är transportagnostisk. Specifikationen beskriver meddelandena, inte hur de färdas. Projektet listar rendererimplementationer för Angular, Flutter, Lit, React och Markdown, och transportbindningar för AG-UI, A2A och MCP, med WebSockets, SSE och REST också användbara. Den flexibiliteten är poängen: samma agentsvar kan återges av en webbklient, en mobilapp eller en skrivbordsapplikation, var och en med sitt eget designsystem.
Vad A2UI inte gör
A2UI är lätt att överläsa. Det skickar inte ett komponentbibliotek som du kan släppa in i en app, och det renderar ingenting av sig självt: du behöver en renderare och en komponentkatalog som klienten kontrollerar. Det avgör inte hur användargränssnittet rör sig. Det ersätter inte MCP, som exponerar verktyg och data för en modell, eller AG-UI, som bär interaktionshändelser mellan en agent och en frontend. Och det tar inte bort behovet av teknisk granskning: genererade gränssnitt måste fortfarande hantera laddning, tomma och feltillstånd, behörigheter och tillgänglighet.
A2UI vs AG-UI vs MCP
Dessa tre nämns ofta tillsammans eftersom de löser olika lager av samma problem. En användbar stenografi: A2UI beskriver gränssnittet, AG-UI bär interaktionen och MCP ger agenten verktyg och data. A2UI egen dokumentation beskriver AG-UI som en transportbindning för A2UI, och A2UI kan även resa över MCP. De är komplementära, inte konkurrerande standarder. Om du väljer en integration, utgå från vad din klient kan rendera och vilken transport den redan stöder, inte från det protokoll som har störst fart.
Där animation och interaktion passar
A2UI beskriver struktur och data. Rörelse är ett klientproblem: renderaren bestämmer om en yta visas omedelbart, bleknar in eller övergår från ett tidigare tillstånd. Det är goda nyheter för produktteam, eftersom det behåller animationssystemet i klienten där det kan respektera designsystemet och tillgänglighetsinställningarna. Det betyder också att en A2UI-implementering inte automatiskt animeras. Om ett genererat gränssnitt behöver en knapptryckning, en tillståndsövergång eller en maskotreaktion, måste klienten tillhandahålla det beteendet. ExodeUI kan spela interaktiv rörelse i en klient, och den har en MCP-server för AI-kodningsverktyg, men den är inte en A2UI-renderare och bör inte beskrivas som en.
Produktionsimplementeringsutdrag
// 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" } }Nyckel Principles att komma ihåg
- A2UI är ett JSON-protokoll för agentbeskrivna gränssnitt, skapat av Google och licensierat under Apache 2.0
- Beställaren renderar med sina egna komponenter; agenten exekverar inte godtycklig UI-kod
- Den definierar meddelanden och lämnar renderaren, transporten och rörelsen till klienten
- Det är inte ett animationssystem eller ett drop-in-komponentbibliotek
- ExodeUI är inte en A2UI-renderare och har ingen anknytning till Google