A2UI Обяснено: Какво прави (и не прави) протоколът Agent-to-UI
A2UI е декларативен JSON протокол, който позволява на AI агентите да описват интерфейси, които клиентът да рендира. Как работи, какви програми за изобразяване съществуват и какво не прави.
Ядро за вкъщи
A2UI (Agent to UI) е отворен, декларативен JSON протокол, създаден от Google. AI агент изпраща описание на интерфейс и клиентът го изобразява със свои собствени компоненти, вместо да изпълнява код от агента. Това е начин за преместване на UI структура и данни през граница на доверие, а не система за анимация, библиотека с компоненти или завършен рендър. ExodeUI не е A2UI рендър и не е свързан с Google.
Какво е A2UI?
A2UI е протокол за управлявани от агенти интерфейси. Вместо да върне стена от текст или да изпълни генериран код, AI агент изпраща поток от JSON съобщения, които описват потребителски интерфейс: коя повърхност да се създаде, кои компоненти съдържа и какви данни ги запълват. Клиентът получава тези съобщения и изобразява резултата с компоненти, на които вече има доверие. A2UI е създаден от Google и е лицензиран за Apache 2.0, с принос от CopilotKit и общността с отворен код. Към октомври 2026 г. текущата производствена спецификация беше v0.9.1, а v1.0 беше кандидат за издание.
Проблемът, който A2UI се опитва да реши
Агентите са добри в създаването на полезен отговор и лоши в предоставянето му като интерфейс. Текстовият отговор не може да показва таблица за сравнение, формуляр за поръчка или табло за управление. Генерирането на произволен HTML или JavaScript решава проблема с представянето и създава такъв със сигурността, тъй като клиентът сега изпълнява код, който не е написал. A2UI поема по трети път: агентът описва потребителския интерфейс в ограничен формат и клиентът решава как да го изобрази. Агентът може да използва само компоненти, одобрени от клиента, а изходът е по-скоро данни, отколкото изпълним код.
Как се изгражда A2UI повърхност
Протоколът използва малък набор от типове съобщения. Точната схема се променя между версиите, така че проверете спецификацията, преди да внедрите такава, но формата е стабилна.
- createSurface: казва на рендера да създаде нова повърхност, която е регион от интерфейса, който агентът може да актуализира
- updateComponents: добавя или променя дефинициите на компоненти на тази повърхност
- updateDataModel: променя данните, които компонентите показват, без повторно изпращане на структурата
- deleteSurface: премахва повърхност, когато вече не е необходима
Рендери и транспорти
A2UI е транспортно агностичен. Спецификацията описва съобщенията, а не как те пътуват. Проектът изброява реализации на рендър за Angular, Flutter, Lit, React и Markdown и транспортни свързвания за AG-UI, A2A и MCP, с WebSockets, SSE и REST, които също могат да се използват. Въпросът е в тази гъвкавост: един и същ отговор на агент може да бъде изобразен от уеб клиент, мобилно приложение или настолно приложение, всяко използващо своя собствена система за проектиране.
Какво не прави A2UI
A2UI е лесен за препрочитане. Той не доставя библиотека с компоненти, която можете да пуснете в приложение, и не рендира нищо сам: имате нужда от рендеринг и каталог с компоненти, които клиентът контролира. Той не решава как се движи потребителският интерфейс. Той не замества MCP, който излага инструменти и данни на модел, или AG-UI, който пренася събитията за взаимодействие между агент и интерфейс. И това не премахва необходимостта от инженерен преглед: генерираните интерфейси все още трябва да се справят със зареждане, празни състояния и грешки, разрешения и достъпност.
A2UI срещу AG-UI срещу MCP
Тези три често се споменават заедно, защото решават различни слоеве на един и същи проблем. Полезна стенограма: A2UI описва интерфейса, AG-UI носи взаимодействието, а MCP дава на агента инструменти и данни. Собствената документация на A2UI описва AG-UI като транспортно свързване за A2UI, а A2UI може също да пътува през MCP. Те са допълващи се, а не конкуриращи се стандарти. Ако избирате интеграция, започнете от това, което вашият клиент може да изобрази и кой транспорт вече поддържа, а не от протокола с най-голяма инерция.
Където анимацията и взаимодействието са подходящи
A2UI описва структура и данни. Движението е грижа на клиента: рендьорът решава дали повърхността се появява незабавно, избледнява или преминава от предишно състояние. Това е добра новина за продуктовите екипи, защото запазва системата за анимация в клиента, където може да спазва системата за дизайн и настройките за достъпност. Това също означава, че изпълнението на A2UI не се анимира автоматично. Ако генерираният интерфейс се нуждае от натискане на бутон, преход на състояние или реакция на талисман, клиентът трябва да осигури това поведение. ExodeUI може да възпроизвежда интерактивно движение в клиент и има MCP сървър за инструменти за кодиране на AI, но не е A2UI рендър и не трябва да се описва като такъв.
Фрагмент за внедряване на продукцията
// 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" } }Ключове Principle, които трябва да запомните
- A2UI е JSON протокол за интерфейси, описани от агент, създаден от Google и лицензиран под Apache 2.0
- Клиентът рендерира със собствени компоненти; агентът не изпълнява произволен UI код
- Той дефинира съобщения и оставя изобразяването, транспорта и движението на клиента
- Това не е система за анимация или библиотека с компоненти за добавяне
- ExodeUI не е A2UI рендър и няма връзка с Google