[1/2] Google открыл A2UI - протокол, который позволяет агентам “говорить UI”, а не только текстом (Рубрика #AI)

15 декабря 2025 команда A2UI в Google публично выложила проект A2UI (Agent-to-User Interface) - открытый формат + библиотеки рендеринга, чтобы “удалённые” AI‑агенты могли возвращать сложные интерфейсы (формы, карточки, списки, кнопки) как данные, а не как исполняемый код. Этот протокол призван решить проблему текстовых чатов, когда простые пользовательские действия (забронировать столик, заполнить поля, выбрать время) превращаются в долгую переписку “вопрос‑ответ‑уточнение”. A2UI предлагает вместо этого дать агенту возможность сгенерировать контекстную форму/карточку из каталога компонентов и отрисовать её в вашем приложении. Сам протокол доступен на GitHub.

По сути это работает примерно следующим образом - агент генерирует декларативное описание UI в JSON, клиент рендерит это нативными компонентами своего приложения.
Ключевые принципы (сформулированы в README проекта):
- Security‑first: агент не присылает JS/HTML/код. Он присылает данные, которые проходят валидацию, а UI строится из каталога заранее разрешённых компонентов (Button/Card/TextField/и т.д.). Это снижает риск UI‑инъекций и “случайного RCE через UI”
- LLM‑friendly + инкрементальные апдейты: UI описывается “плоской” структурой (adjacency list) с ID‑ссылками, поэтому агент может стримить интерфейс и патчить отдельные компоненты по ID, не пересылая всё дерево
- Framework‑agnostic: один и тот же A2UI‑пейлоад может быть отрендерен в разных клиентах (web/mobile/desktop) — потому что “как рисовать” решает клиент
- Transport‑agnostic: A2UI - это формат/контракт сообщений, его можно гонять поверх разных “транспортов” (включая A2A и AG‑UI)

На практике (в версии v0.8, stable/public preview) сообщения обычно идут как JSON Lines (JSONL): одна строка = одно сообщение. Есть 4 ключевых типа:
- beginRendering
- surfaceUpdate
- dataModelUpdate
- deleteSurface
Сам стрим может выглядеть примерно так

{"surfaceUpdate": {"surfaceId":"main","components":[ ... ]}}
{"dataModelUpdate": {"surfaceId":"main","contents":[ ... ]}}
{"beginRendering": {"surfaceId":"main","root":"root-component"}}

Но надо отметить, что спека все еще дорабатывается и между v0.8 (stable) и v0.9 (draft) уже есть изменения в деталях и даже названиях envelope‑сообщений

Теперь давайте обсудим, а почему этот протокол нам интересен и чем он лучше альтернатив.
1. Одной из альтернатив является генерация HTML/JS/React‑кода агентом.
Здесь у нас есть проблема с безопасностью и контролем - вам либо нужно исполнять непроверенный код, либо городить тяжёлую песочницу. В A2UI у нас вместо кода данные, а рендеринг идет только из доверенного каталога компонентов.
2. Другой алтернативой являются iframe‑подходы / “UI как ресурс” (например, MCP Apps)
В статье Google прямо сравнивает A2UI с MCP Apps: там UI часто приходит как “opaque payload” (например HTML) и рендерится в sandboxed iframe. Но A2UI выгодно отличается “native‑first” подходом: агент отправляет blueprint нативных компонентов, и UI наследует стиль/дизайн‑систему/доступность хост‑приложения, вместо отдельного “мини‑веба в iframe”.
3. Платформенные end2end экосистемы (например, OpenAI ChatKit)
Плюс таких решений - интеграция в рамках одной платформы. Минус - переносимость и работа в мульти‑агентных сценариях с разными вендорами. A2UI целится в переносимый UI‑контракт для ваших собственных клиентов и enterprise‑mesh сценариев.
4. Просто возьмём AG‑UI и хватит
AG‑UI решает вопросы интеграция агента и UI), а A2UI - описывает сам формат UI‑ответа. Google явно позиционирует A2UI как комплементарный слой: подключили хост через AG‑UI → можете использовать A2UI как формат для UI‑ответов, в том числе от внешних агентов

Продолжение о том, а почему этот проект так интересен в посте-продолжении.

#Engineering #AI #Agents #Software #Architecture #RnD #ML #DistributedSystems