[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

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

В продолжении обсуждения протокола A2UI от Google мы рассмотрим, а почему он может быть интересен создателям genAI приложений для пользователей.

Если смотреть на публичные сигналы, проект реально подхватили:
1. GitHub traction. За полтора месяца проект набрал 10.9k звезд, 810 forks, 66 issues, 80 PR, 332 commits, 31 contributor в основном репозитории
2. Официальные туториалы Google. В документации для Google Workspace появился quickstart “Build a Google Chat app with an Agent2UI agent” (обновлён 2026‑01‑27), с развёртыванием агента через ADK и хостингом в Vertex AI Agent Engine. Это хороший индикатор, что A2UI продвигают как практический способ строить UI‑ответы агентов внутри Workspace/Chat‑сценариев.
3. Экосистема вокруг. Появляются сторонние реализации/порты:
- a2ui-rails - порт в Ruby/Rails
- A2UI-for-Google-Apps-Script - демо/адаптация под Apps Script/Workspace
- Отдельные упоминания и интеграционные запросы в других agent‑framework репозиториях тоже всплывают (feature requests/discussions)

И отдельно: сам проект помечен как Early stage public preview (v0.8), при этом параллельно ведётся v0.9 (draft) - то есть активная фаза “формат шлифуется”.

Отдельно надо подсветить почему это должно быть инженерам
- Нормальный контракт между “мозгом” и UI: агент не “рисует DOM”, а отправляет декларативные апдейты, которые ваш клиент валидирует и рендерит. Это лучше ложится на архитектуру “удалённый агент / недоверенная граница”
- Инкрементальность и патчи: можно стримить UI и менять только нужные куски по ID, вместо “перерисовать всё”
- Переиспользование дизайн‑системы: UI остаётся нативным (ваши компоненты/темизация/а11y), а агент лишь “просит” собрать композицию
- Прагматичная интеграция: есть референсные рендереры (Lit/Angular/Flutter), есть понятный quickstart с демо‑агентом

Для техлидов и engineering менеджеров это может быть интересно по другим причинам
- Скорость поставки фич: вместо того чтобы каждый раз вручную проектировать “формочку под новый workflow”, часть UX можно делегировать агенту, но в рамках жёсткого каталога компонентов и правил
- Управляемый риск: “данные вместо кода” = проще проходить security review, проще ограничивать поверхность атаки, проще объяснять границы доверия между командами/вендорами
- Стандартизация для мульти‑агентных сценариев: когда разные агенты/под‑агенты (внутренние и внешние) должны отдавать UI в единый клиент, формат уровня A2UI снижает интеграционный ад
- Сигналы зрелости: быстрорастущий репозиторий + официальный quickstart в Google Workspace доках + параллельная работа над спецификацией (v0.8 stable / v0.9 draft) — это похоже на проект, который реально хотят “довести до v1”

Если вы сейчас строите agentic‑продукт и упираетесь в “чат вместо продукта”, A2UI выглядит как очень практичный способ превратить ответы агента в управляемые, нативные, безопасные UI‑сессии - и при этом не завязаться на один конкретный фронтенд‑стек.

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