Wyjaśnienie A2UI: Co robi (a czego nie robi) protokół Agent-to-UI
A2UI to deklaratywny protokół JSON, który pozwala agentom AI opisywać interfejsy do renderowania przez klienta. Jak to działa, jakie renderery istnieją i czego nie robi.
Rdzeń na wynos
A2UI (Agent to UI) to otwarty, deklaratywny protokół JSON stworzony przez Google. Agent AI wysyła opis interfejsu, a klient renderuje go przy użyciu własnych natywnych komponentów, zamiast wykonywać kod z agenta. Jest to sposób na przeniesienie struktury interfejsu użytkownika i danych przez granicę zaufania, a nie system animacji, bibliotekę komponentów czy gotowy moduł renderujący. ExodeUI nie jest modułem renderującym A2UI i nie jest powiązany z Google.
Co to jest A2UI?
A2UI to protokół dla interfejsów sterowanych agentami. Zamiast zwracać ścianę tekstu lub wykonywać wygenerowany kod, agent AI wysyła strumień komunikatów JSON opisujących interfejs użytkownika: jaką powierzchnię utworzyć, jakie komponenty zawiera i jakie dane je wypełniają. Klient odbiera te komunikaty i renderuje wynik przy użyciu komponentów, którym już ufa. A2UI został stworzony przez Google i posiada licencję Apache 2.0 przy udziale CopilotKit i społeczności open source. W październiku 2026 r. bieżąca specyfikacja produkcyjna to wersja 0.9.1, a wersja 1.0 była kandydatem do wydania.
Problem, który A2UI próbuje rozwiązać
Agenci są dobrzy w udzielaniu przydatnych odpowiedzi, ale źle w dostarczaniu ich jako interfejsu. Odpowiedź tekstowa nie może zawierać tabeli porównawczej, formularza zamówienia ani dashboardu. Wygenerowanie dowolnego HTML lub JavaScript rozwiązuje problem prezentacji i tworzy problem bezpieczeństwa, ponieważ klient uruchamia teraz kod, którego nie napisał. A2UI wybiera trzecią drogę: agent opisuje interfejs użytkownika w ograniczonym formacie, a klient decyduje, jak go wyrenderować. Agent może używać wyłącznie komponentów zatwierdzonych przez klienta, a wynikiem są dane, a nie kod wykonywalny.
Jak zbudowana jest powierzchnia A2UI
Protokół wykorzystuje niewielki zestaw typów wiadomości. Dokładny schemat zmienia się pomiędzy wersjami, więc przed wdrożeniem sprawdź specyfikację, ale kształt jest stabilny.
- createSurface: informuje moduł renderujący, aby utworzył nową powierzchnię, czyli obszar interfejsu, który agent może aktualizować
- updateComponents: dodaje lub zmienia definicje komponentów na tej powierzchni
- updateDataModel: zmienia dane wyświetlane komponentom bez ponownego wysyłania konstrukcji
- DeleteSurface: usuwa powierzchnię, gdy nie jest już potrzebna
Rendererzy i transporty
A2UI jest niezależny od transportu. Specyfikacja opisuje wiadomości, a nie sposób ich przesyłania. Projekt zawiera listę implementacji renderowania dla Angular, Flutter, Lit, React i Markdown oraz powiązań transportowych dla AG-UI, A2A i MCP, z możliwością wykorzystania również WebSockets, SSE i REST. Chodzi o tę elastyczność: ta sama odpowiedź agenta może być renderowana przez klienta sieciowego, aplikację mobilną lub aplikację komputerową, każdy przy użyciu własnego systemu projektowania.
Czego A2UI nie robi
A2UI można łatwo przeoczyć. Nie zawiera biblioteki komponentów, którą można umieścić w aplikacji, ani niczego samodzielnie nie renderuje: potrzebny jest moduł renderujący i katalog komponentów kontrolowany przez klienta. Nie decyduje o sposobie poruszania się interfejsu użytkownika. Nie zastępuje MCP, który udostępnia narzędzia i dane modelowi, ani AG-UI, który przenosi zdarzenia interakcji pomiędzy agentem a frontendem. Nie eliminuje to jednak potrzeby przeglądu technicznego: wygenerowane interfejsy nadal muszą obsługiwać ładowanie, stany puste i błędy, uprawnienia i dostępność.
A2UI kontra AG-UI kontra MCP
Te trzy są często wymieniane razem, ponieważ rozwiązują różne warstwy tego samego problemu. Przydatny skrót: A2UI opisuje interfejs, AG-UI przenosi interakcję, a MCP udostępnia agentowi narzędzia i dane. Własna dokumentacja A2UI opisuje AG-UI jako połączenie transportowe dla A2UI, a A2UI może również podróżować przez MCP. Są to standardy uzupełniające się, a nie konkurencyjne. Jeśli wybierasz integrację, zacznij od tego, co Twój klient może renderować i jaki transport już obsługuje, a nie od protokołu, który ma największy rozmach.
Tam, gdzie pasuje animacja i interakcja
A2UI opisuje strukturę i dane. Problemem klienta jest ruch: moduł renderujący decyduje, czy powierzchnia pojawia się natychmiast, zanika, czy też przechodzi z poprzedniego stanu. To dobra wiadomość dla zespołów produktowych, ponieważ utrzymuje system animacji w kliencie, gdzie może szanować system projektowania i ustawienia dostępności. Oznacza to również, że implementacja A2UI nie jest automatycznie animowana. Jeśli wygenerowany interfejs wymaga naciśnięcia przycisku, zmiany stanu lub reakcji maskotki, klient musi zapewnić takie zachowanie. ExodeUI może odtwarzać interaktywny ruch w kliencie i ma serwer MCP dla narzędzi do kodowania AI, ale nie jest rendererem A2UI i nie powinien być opisywany jako taki.
Fragment wdrożenia produkcyjnego
// 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" } }Klucz Principles do zapamiętania
- A2UI to protokół JSON dla interfejsów opisanych przez agentów, stworzony przez Google i licencjonowany w ramach Apache 2.0
- Klient renderuje przy użyciu własnych komponentów; agent nie wykonuje dowolnego kodu interfejsu użytkownika
- Definiuje komunikaty, a renderowanie, transport i ruch pozostawia klientowi
- To nie jest system animacji ani biblioteka komponentów typu drop-in
- ExodeUI nie jest modułem renderującym A2UI i nie jest powiązany z Google