Продолжаем рассматривать варианты интерфейса для работы с LLM при разработке AI‑продукта. В предыдущей части рассмотрели Open WebUI, теперь перейдем к Assistant‑UI.
Assistant‑UI
Мы отложили в сторону Open WebUI и взялись за фреймворк Assistant‑UI.
Assistant‑UI — это открытая библиотека на TypeScript/React для создания настраиваемых интерфейсов чат‑ботов на основе ИИ.
В отличие от Open WebUI, это набор инструментов для фронтенда, из которых можно собрать интерфейс под свою задачу. Библиотека рассчитана на создание AI‑чатов: она умеет показывать ответ по мере генерации, корректно обрабатывать прерывания и повторные запросы, поддерживает длинный диалог в несколько шагов и интегрируется с разными backend‑решениями, включая собственные API и LangGraph.
Преимущества Assistant‑UI:
1. Полная кастомизация. Так как это библиотека, внешний вид можно менять как угодно, писать и внедрять свои собственные компоненты. В случае затруднений можно опираться на примеры проектов с GitHub.
2. Интеграция с LangGraph. Assistant‑UI поддерживает LangGraph template (шаблон для интеграции с фреймворком, использующимся для графового представления «Банка идей»). Это дает готовую поддержку потокового обновления состояния агента, а не только текста ответа, что позволяет точно отражать на интерфейсе прогресс выполнения задач. Из коробки доступны механизмы human‑in‑the‑loop и генеративный UI.
3. Каталог готовых UI‑компонентов (tool‑ui). Более 20 инструментов для прямого взаимодействия с пользователем: от таблиц и чек‑листов до командной строки и трекера прогресса.
Недостатки Assistant‑UI:
Более высокий порог входа. Требуется знание React.
Время и трудозатраты. UI нужно писать и собирать, что влияет на сроки показа MVP.
Часть функциональности нужно дорабатывать руками. Например, работу с документами, которая в Open WebUI была «из коробки».
Что мы получили с Assistant‑UI
В нашем случае Assistant‑UI оказался более удобным и подходящим инструментом:
Собственные компоненты. Мы встроили в продукт нужную визуализацию процесса работы над идеей. Это удобно, понятно и близко к процессу в жизни — именно так люди в команде совместно работают над новой темой.
Интеграция с LangGraph. Поддержка в фреймворке позволила не делать специальных «приседаний» при разработке. Процесс работы архитектурно представлен внутри продукта в виде графов на разные этапы с возможным изменением маршрутов.
Organic human‑in‑the‑loop. Каждый агент в нужный момент обращается к пользователю с полным контекстом.
Какой выбор и для каких сценариев
Open WebUI — open‑source веб‑интерфейс, удобен, когда не хочется писать код и нужен простой привычный чат‑бот. Можно быстро интегрировать, но придется потратить много усилий на кастомизацию. Т.е. хороший выбор для быстрого старта, когда нужен готовый self‑hosted AI‑продукт и взаимодействие с пользователем — это обычный привычный чат.
Assistant‑UI — фреймворк, который предоставляет полную свободу действий. Подходит для более креативных задач. Требуется время, чтобы написать основу, однако интеграция готовых инструментов облегчается примерами с GitHub. Требует хотя бы базового понимания React, но дает контроль над состоянием, потоковыми обновлениями, tool calling, human‑in‑the‑loop, кастомными UI‑компонентами и прямую интеграцию с агентными бэкендами вроде LangGraph.
Где встречается такой выбор
Описанная логика выбора пригодится не только для «Банка идей». Она применима ко многим корпоративным AI‑решениям:
внутренние AI‑ассистенты для сотрудников;
AI‑модули в CRM, ERP, Service Desk и отраслевых системах;
сервисы разбора заявок, документов и обращений;
мультиагентные решения для аналитики, проверки гипотез и подготовки рекомендаций;
интерфейсы, где AI должен не только отвечать, но и проводить пользователя по процессу.
Во всех этих случаях «чат» часто является лишь верхним уровнем взаимодействия. Под ним находится корпоративный flow, состояние, управление агентами, проверки, согласования и доменная логика. Именно поэтому для таких продуктов нужен интерфейсный слой, который умеет жить вместе с этой логикой.
Заключение
При разработке AI‑продуктов вопрос выбора фронтового инструмента нельзя сводить к удобству готового чата или скорости первого запуска. В проектах, где есть мультиагентная логика, human‑in‑the‑loop и нестандартные интерфейсные сущности, UI становится частью архитектуры продукта.
Open WebUI — сильный инструмент для быстрого старта, когда нужен готовый универсальный AI‑интерфейс.
Assistant‑UI — более гибкий путь, когда нужно встроить AI в конкретный бизнес‑сценарий и сохранить свободу в проектировании интерфейса.
Для нас это означало простой выбор: если цель просто показать чат, можно взять готовую платформу. Если цель показать, как действительно будет работать AI‑сервис внутри продукта и бизнес‑процесса, нужен инструмент, который позволяет проектировать собственный UX вокруг логики системы. В нашем случае таким инструментом стал Assistant‑UI.
А вы сталкивались с выбором UI‑инструмента для AI‑продуктов? Какой подход выбрали — готовую платформу или гибкий фреймворк?
