Представьте: пользователь открывает ваш продукт, и интерфейс не просто отображает заранее заготовленные экраны — он собирается в реальном времени, под конкретного пользователя и его контекст.
В чём принципиальное отличие
Классический чат с ИИ-агентом выглядит так: пользователь пишет текст — модель отвечает текстом, возможно, с красивым стримингом и markdown-форматированием. Поведение интерфейса может быть привязано к конкретным сценариям, но только если они чётко определены и ограничены.
Generative UI (GenUI) — это когда модель не просто отвечает, а решает, какой интерактивный компонент показать. Например, она может собрать график по вашим данным или вставить виджет для подтверждения изменений в коде — прямо в процессе генерации.
Когда это вообще нужно
GenUI решает одну конкретную задачу: интерфейс слишком вариативен, чтобы захардкодить все его состояния. Цель — снизить когнитивную нагрузку на пользователя и сделать взаимодействие с продуктом удобнее.
Вот несколько случаев, когда GenUI будет полезен:
- Живые артефакты: агент генерирует объект, показывает его как интерактивный компонент. Пользователь редактирует — агент видит изменения и может предлагать правки или предупреждать о противоречиях. Это совместная работа в диалоге.
- Сбор структурированных данных: агент понимает, что нужно заполнить несколько полей, и рендерит форму под контекст — например, бронирование отеля.
- Визуализация сложной информации: вместо текста — график, карточки или схема. Это упрощает восприятие там, где текст создал бы нагрузку.
- Навигация по результатам: агент нашёл 10 вариантов — пользователь может фильтровать, сравнивать, переключаться между ними.
Три подхода к GenUI
Выбор подхода влияет на контроль, безопасность и гибкость. Вот три основных стратегии.
Подход 1: Генерация HTML
Самый простой и хрупкий способ. Модель получает задачу — генерирует HTML — браузер рендерит.
Плюсы: быстро, гибко, нет ограничений по визуализации.
Минусы: модель может нарушить дизайн-систему — цвета, стили кнопок будут отличаться от запроса к запросу. Есть риск безопасности: модель может сгенерировать исполняемый код. Кроме того, возможны галлюцинации — несуществующие атрибуты или разметка, ломающаяся в браузере.
Когда подходит: для прототипов, внутренних инструментов или если вы готовы к высокому риску и дополнительной работе с фронтендом.
Подход 2: Декларативный подход
Агент не пишет код, а описывает, что должно появиться — как ТЗ. Разработчики заранее создают каталог атомарных компонентов: строка, кнопка, инпут. Агент выбирает из них, указывает порядок и параметры.
Этот подход реализован в протоколе A2UI от Google (декабрь 2025): агент отправляет JSON с описанием, клиент рендерит через свой фреймворк.
Плюсы: дизайн остаётся единым — кнопка всегда ваша. Поддерживает много кейсов без создания компонента под каждый случай.
Минусы: агент свободен в композиции — структура может отличаться. Качество зависит от модели и проработки её скиллов.
Когда подходит: когда вариантов визуализации слишком много, но важна консистентность дизайна.
Подход 3: Агент выбирает готовый компонент
Самый контролируемый подход. Разработчики заранее создают готовые компоненты — график, карточку товара, форму. Агент не верстает — он выбирает нужный и заполняет данными.
Пример — фреймворк Tambo, опенсорсный инструмент для React. Он реализует этот подход и добавляет: состояния компонентов, жизненный цикл и двустороннюю связь между UI и агентом (протокол AG-UI).
Плюсы: полный контроль над визуалом. Агент не может показать ничего не предусмотренное.
Минусы: нужно заранее понимать, какие компоненты понадобятся. Не подходит для универсальных агентных систем.
Когда подходит: когда важен точный UX, а число сценариев ограничено.
Сравнение подходов
Контроль над визуалом: Максимальный — в третьем подходе, минимальный — в первом.
Свобода агента: Ограничена библиотекой компонентов в третьем, почти полная — в первом.
Сложность реализации: Низкая у первого (но требует контроля за стилями), средняя у второго и третьего — из-за подготовки компонентов и описания их логики.
Безопасность: Самый рискованный — первый подход. Самый безопасный — третий.
Как мы пришли к Tambo
Мы разрабатывали ИИ-ассистент для маркетинговой аналитики. Интерфейс включает рабочую область (таблицы, срезы, выводы) и чат с агентом.
Было понятно, что генеративные компоненты — карточки с инсайтами, графики, сводки — улучшат опыт. Но возникла проблема: если агент начнёт менять рабочую область, можно потерять контроль над ключевым артефактом продукта.
Решение нашли в Tambo. Он поддерживает два типа компонентов:
- Генеративные: появляются в чате в ответ на запрос — например, график. Рендерятся один раз.
- Интерактивные: обычные React-компоненты (например, таблица), размещённые в интерфейсе. Пользователь взаимодействует с ними напрямую, а Tambo отслеживает их состояние.
Реализация проста: компоненты регистрируются с описаниями и Zod-схемами пропсов — это становится словарём для агента. Он решает, что показать, и передаёт данные в компонент в реальном времени.
Итоговая архитектура:
- Рабочая область: для основного контента. Здесь — интерактивные компоненты. Агент может менять только содержимое, но не структуру.
- Чат: для дополнительных элементов. Здесь — генеративные компоненты: графики, карточки и т.п.
Выбор подхода зависит не от технологий и не от трендов — а от того, как вы видите взаимодействие пользователя с продуктом. Что важнее: предсказуемость и контроль, или гибкость и богатые выводы? Где можно дать модели свободу, а где — нет? Ответы на эти вопросы определяют стратегию.
GenUI активно развивается: A2UI вышел в декабре 2025, Tambo — v1.0 в феврале 2026. Но суть остаётся прежней — ориентируйтесь на потребности продукта и пользователя, а не на новизну инструментов.