При разработке AI‑продукта мы столкнулись с неожиданной задачей. Выбрать LLM оказалось проще, чем выбрать интерфейс для работы с ней. Готовые AI‑чаты хорошо подходят для диалога с одной моделью, но начинают ограничивать продукт, если в нем появляются несколько агентов, сложные сценарии и промежуточные этапы работы. В этой статье опишем суть задачи, требования и разберем Open WebUI.
Основная цель MVP заключается в демонстрации замысла продукта и проверке его жизнеспособности. На этом этапе важно сконцентрироваться на реализации основных функций, внешний вид порой не так важен. Но в AI‑продуктах есть нюанс: даже для MVP интерфейс нередко становится частью логики продукта и будущей архитектуры.
Если раньше AI‑решения были, по сути, одним чатом, в рамках которого пользователь общался с одной нейросетью, то современные решения включают цепочку или граф AI‑агентов, каждый из которых выполняет свою работу отдельно от остальных, иногда взаимодействуя с пользователем. В этом случае UI становится полноценным командным центром: состояние системы, динамика размышлений и работы, вызов внутренних функций (tool calling), точки взаимодействия с пользователем (human‑in‑the‑loop) и многое другое.
Поэтому выбор UI‑инструмента влияет и на скорость прототипирования, и на конечный результат, получится ли у пользователя органично работать в системе. В этой статье мы расскажем, как выбирали инструмент для фронтенда в проекте «Банк идей».
Что такое «Банк идей»?
«Банк идей» — это мультиагентная система, отвечающая за анализ и подготовку идей сотрудников компании. Сотрудник в чат‑боте описывает проблему, которую хочет решить, подает на вход свою идею, и затем она проходит множество ИИ‑агентов, каждый из которых выполняет отведенную ему роль:
Критик подсвечивает слабые места.
Безопасник удаляет конфиденциальную информацию, прежде чем идея перейдет во внешнюю LLM.
И другие агенты.
Под ИИ‑агентом принято понимать систему на базе искусственного интеллекта с набором инструментов для решения задачи пользователя.
Работая над «Банком идей», мы столкнулись с необходимостью быстро реализовать фронтенд для демонстрации работы сервиса.
Техническая реализация
Для реализации «Банка идей» мы использовали LangGraph, который позволяет представить логику агентов в виде графа: инструменты агента = узлы, соединенные ребрами, выстраивающими пайплайн агента, а каждый агент = узел в общем графе‑оркестраторе.
«Банк идей» подразумевает плотное взаимодействие с пользователем по ходу изменения идеи. У нас было конкретное видение: нам нужен привычный и интуитивно понятный интерфейс: чат‑бот с внедрением кастомных компонентов.
Какие нестандартные компоненты требовались:
Доски. На моменте анализа идеи доменными агентами‑экспертами каждый из них должен был передавать свое мнение на доску, где пользователь мог их все прочитать, сравнить и даже внести свои правки. После прохождения этапа оценки доски оставались висеть в чате для контекста.
Отображение графа. Полный пайплайн графа‑оркестратора отрабатывает от 15 до 20 минут. Чтобы пользователь не думал, что сервис завис, мы хотели отображать процесс прохождения всех этапов работы агентов.
Обычный чат‑интерфейс хорошо работает, когда весь результат можно представить одним потоком сообщений. Но если система должна показывать состояние процесса, прерываться для подтверждения действий, выводить tool results в виде интерактивных компонентов и сохранять контекст работы, архитектура UI‑слоя тоже важна.
Требования к инструменту
Исходя из специфики задачи, мы сформулировали требования:
Open‑source решение.
Простота внедрения в уже созданную систему.
Возможность быстрой и удобной кастомизации.
Продовый и понятный интерфейс.
Поддержка многошагового взаимодействия.
Возможность отображать не только ответы модели, но и промежуточные состояния.
Пригодность не только для демо, но и для дальнейшего развития.
Для внутренних MVP можно позволить себе временный интерфейс. Но если MVP показывает хорошие результаты, бизнес почти всегда хочет быстро перейти к пилоту с реальными пользователями, а затем и к промышленному внедрению. Слишком жесткий UI‑каркас может сэкономить время на старте, но создать дорогой рефакторинг уже через несколько недель.
Что попробовали
Исходя из требований, список сократился до двух вариантов:
Open WebUI — самодостаточная open‑source платформа с готовым веб‑интерфейсом для работы с моделями, документами, инструментами и knowledge base.
Assistant‑UI — открытая TypeScript/React‑библиотека, которая дает production‑ready компоненты и инструменты для построения чата, но предполагает, что продуктовый интерфейс вы собираете внутри собственного приложения.
Это два инструмента для разных сценариев. Мы сравнивали их не напрямую, а по удобству для разработки и пользователя и полученному бизнес‑результату.
Open WebUI
Именно Open WebUI мы использовали для первого варианта «Банка идей» с минимальной архитектурой, и поначалу казалось, что это лучший выбор.
Плюсы Open WebUI:
Понятный и привычный интерфейс чат‑бота, который не нужно писать с нуля. Присутствуют привычные функции: прикрепление файлов, выдача подсказок для запросов, создание рабочих пространств и так далее.
Поддерживает любые модели: от локальных до API. Можно обращаться к своим собственным агентам и в любой момент переключать чаты, модели и агентов без потери контекста.
Интеграция RAG.
Добавление пользовательских инструментов (Tools) — Python‑скриптов в самом веб‑интерфейсе, которые выполняются на вашем сервере и действуют по запросу LLM.
Наличие механизма событий (events), который обеспечивает связь между backend‑логикой и пользовательским интерфейсом в реальном времени.
Open WebUI дает богатую функциональность «из коробки». Для команд, которым нужно быстро поднять внутренний AI‑чат или демостенд без отдельной фронтенд‑разработки, это действительно удобный вариант.
Где Open WebUI начал ограничивать нас
Безопасность. Tools и Functions выполняют на вашем сервере произвольный Python‑код, поэтому нужно следить, кому передаются права создавать и импортировать инструменты.
Невозможность редактировать базовый интерфейс. Большинство функций (левая панель, прикрепление вложений) полезны для обычного чат‑бота, но избыточны для «Банка идей». Чтобы их убрать, пришлось бы вносить изменения в код самого Open WebUI, что привязывало бы нас к определенной версии.
Детальная кастомизация не предполагается. Мы так и не нашли способа реализовать доски и другие компоненты так, как мы задумали.
Ограниченная поддержка многошагового взаимодействия. Несмотря на event‑систему, Open WebUI не предоставляет полноценной модели многошагового взаимодействия «из коробки». Поддерживался один эндпоинт, и мы не могли разделить случаи, когда нужно начать пайплайн заново и когда нужно просто его продолжить после прерывания для взаимодействия с пользователем.
Именно здесь стало понятно, что Open WebUI хорош, когда не хочется писать код и нужен готовый привычный AI‑чат. Но если проект требует собственного UX со сложным состоянием, human‑in‑the‑loop и доменными компонентами, платформа начинает ощущаться не ускорителем, а рамкой, которую приходится постоянно обходить.
В следующей части так же разберем Assistant‑UI и подведем итог по тому, в каких ситуациях какой инструмент выбрать.
