Выбор UI-инструмента для быстрого прототипирования в AI-продуктах: Open WebUI vs Assistant-UI

При разработке AI-продукта мы столкнулись с неожиданной задачей. Выбрать LLM оказалось проще, чем выбрать интерфейс для работы с ней. Готовые AI-чаты хорошо подходят для диалога с одной моделью, но начинают ограничивать продукт, если в нем появляются несколько агентов, сложные сценарии и промежуточные этапы работы. В этой статье опишем суть задачи, требования и разберем Open WebUI.

Основная цель MVP заключается в демонстрации замысла продукта и проверке его жизнеспособности. На этом этапе важно сконцентрироваться на реализации основных функций, внешний вид порой не так важен. Но в AI-продуктах есть нюанс: даже для MVP интерфейс нередко становится частью логики продукта и будущей архитектуры.

Если раньше AI-решения были, по сути, одним чатом, в рамках которого пользователь общался с одной нейросетью, то современные решения включают цепочку или граф AI-агентов, каждый из которых выполняет свою работу отдельно от остальных, иногда взаимодействуя с пользователем. В этом случае UI становится полноценным командным центром: состояние системы, динамика размышлений и работы, вызов внутренних функций (tool calling), точки взаимодействия с пользователем (human-in-the-loop) и многое другое.

Поэтому выбор UI-инструмента влияет и на скорость прототипирования, и на конечный результат, получится ли у пользователя органично работать в системе. В этой статье мы расскажем, как выбирали инструмент для фронтенда в проекте «Банк идей».

«Банк идей» - это мультиагентная система, отвечающая за анализ и подготовку идей сотрудников компании. Сотрудник в чат-боте описывает проблему, которую хочет решить, подает на вход свою идею, и затем она проходит множество ИИ-агентов, каждый из которых выполняет отведенную ему роль:

Под ИИ-агентом принято понимать систему на базе искусственного интеллекта с набором инструментов для решения задачи пользователя.

Работая над «Банком идей», мы столкнулись с необходимостью быстро реализовать фронтенд для демонстрации работы сервиса.

Для реализации «Банка идей» мы использовали LangGraph, который позволяет представить логику агентов в виде графа: инструменты агента = узлы, соединенные ребрами, выстраивающими пайплайн агента, а каждый агент = узел в общем графе-оркестраторе.

«Банк идей» подразумевает плотное взаимодействие с пользователем по ходу изменения идеи. У нас было конкретное видение: нам нужен привычный и интуитивно понятный интерфейс: чат-бот с внедрением кастомных компонентов.

Обычный чат-интерфейс хорошо работает, когда весь результат можно представить одним потоком сообщений. Но если система должна показывать состояние процесса, прерываться для подтверждения действий, выводить tool results в виде интерактивных компонентов и сохранять контекст работы, архитектура UI-слоя тоже важна.

Исходя из специфики задачи, мы сформулировали требования:

Для внутренних MVP можно позволить себе временный интерфейс. Но если MVP показывает хорошие результаты, бизнес почти всегда хочет быстро перейти к пилоту с реальными пользователями, а затем и к промышленному внедрению. Слишком жесткий UI-каркас может сэкономить время на старте, но создать дорогой рефакторинг уже через несколько недель.

Исходя из требований, список сократился до двух вариантов:

Это два инструмента для разных сценариев. Мы сравнивали их не напрямую, а по удобству для разработки и пользователя и полученному бизнес-результату.

Именно Open WebUI мы использовали для первого варианта «Банка идей» с минимальной архитектурой, и поначалу казалось, что это лучший выбор.

пример интерфейса

Open WebUI дает богатую функциональность «из коробки». Для команд, которым нужно быстро поднять внутренний AI-чат или демостенд без отдельной фронтенд-разработки, это действительно удобный вариант.

1. Безопасность. Tools и Functions выполняют на вашем сервере произвольный Python-код, поэтому нужно следить, кому передаются права создавать и импортировать инструменты.

2. Невозможность редактировать базовый интерфейс. Большинство функций (левая панель, прикрепление вложений) полезны для обычного чат-бота, но избыточны для «Банка идей». Чтобы их убрать, пришлось бы вносить изменения в код самого Open WebUI, что привязывало бы нас к определенной версии.

3. Детальная кастомизация не предполагается. Мы так и не нашли способа реализовать доски и другие компоненты так, как мы задумали.

4. Ограниченная поддержка многошагового взаимодействия. Несмотря на event-систему, Open WebUI не предоставляет полноценной модели многошагового взаимодействия «из коробки». Поддерживался один эндпоинт, и мы не могли разделить случаи, когда нужно начать пайплайн заново и когда нужно просто его продолжить после прерывания для взаимодействия с пользователем.

Именно здесь стало понятно, что Open WebUI хорош, когда не хочется писать код и нужен готовый привычный AI-чат. Но если проект требует собственного UX со сложным состоянием, human-in-the-loop и доменными компонентами, платформа начинает ощущаться не ускорителем, а рамкой, которую приходится постоянно обходить.

Мы отложили в сторону Open WebUI и взялись за фреймворк Assistant-UI.

Assistant-UI - это открытая библиотека на TypeScript/React для создания настраиваемых интерфейсов чат-ботов на основе ИИ.

В отличие от Open WebUI, это набор инструментов для фронтенда, из которых можно собрать интерфейс под свою задачу. Библиотека рассчитана на создание AI-чатов: она умеет показывать ответ по мере генерации, корректно обрабатывать прерывания и повторные запросы, поддерживает длинный диалог в несколько шагов и интегрируется с разными backend-решениями, включая собственные API и LangGraph.

В нашем случае Assistant-UI оказался более удобным и подходящим инструментом:

Open WebUI - open-source веб-интерфейс, удобен, когда не хочется писать код и нужен простой привычный чат-бот. Можно быстро интегрировать, но придется потратить много усилий на кастомизацию. Т.е. хороший выбор для быстрого старта, когда нужен готовый self-hosted AI-продукт и взаимодействие с пользователем - это обычный привычный чат.

Assistant-UI - фреймворк, который предоставляет полную свободу действий. Подходит для более креативных задач. Требуется время, чтобы написать основу, однако интеграция готовых инструментов облегчается примерами с GitHub. Требует хотя бы базового понимания React, но дает контроль над состоянием, потоковыми обновлениями, tool calling, human-in-the-loop, кастомными UI-компонентами и прямую интеграцию с агентными бэкендами вроде LangGraph.

Описанная логика выбора пригодится не только для «Банка идей». Она применима ко многим корпоративным AI-решениям:

Во всех этих случаях «чат» часто является лишь верхним уровнем взаимодействия. Под ним находится корпоративный flow, состояние, управление агентами, проверки, согласования и доменная логика. Именно поэтому для таких продуктов нужен интерфейсный слой, который умеет жить вместе с этой логикой.

При разработке AI-продуктов вопрос выбора фронтового инструмента нельзя сводить к удобству готового чата или скорости первого запуска. В проектах, где есть мультиагентная логика, human-in-the-loop и нестандартные интерфейсные сущности, UI становится частью архитектуры продукта.

Для нас это означало простой выбор: если цель — просто показать чат, можно взять готовую платформу. Если цель — показать, как действительно будет работать AI-сервис внутри продукта и бизнес-процесса, нужен инструмент, который позволяет проектировать собственный UX вокруг логики системы. В нашем случае таким инструментом стал Assistant-UI.