Flowise: как устроен визуальный конструктор ИИ

Flowise: как устроен визуальный конструктор ИИ — это открытая платформа для сборки агентов и LLM-процессов, где логика собирается из узлов на визуальном холсте. Внутри три конструктора: Assistant, Chatflow и Agentflow. Ниже — выбор под задачу, схема Chatflow, учебный эталон с проверкой неизвестного значения и вызов потока через API. На 07.11.2026 GitHub API помечает репозиторий FlowiseAI/Flowise как archived=true; последний push датирован 13.08.2026. Перед новым внедрением проверьте доступный путь сопровождения. Сам архивный статус не устанавливает состояние облачного сервиса или коммерческой поддержки.

Что такое Flowise и где проходят границы задачи

В документации проекта Flowise описан как открытая платформа разработки генеративного ИИ для сборки агентов и LLM-процессов. В одном продукте соединены визуальный конструктор, трассировка и аналитика, оценки, участие человека в цикле, а также API, CLI, SDK и встраиваемый чат-бот. Отдельно перечислены командные пространства и рабочие области.

Границы задачи определяются тем, что платформа закрывает полный маршрут: сборку логики, подключение данных, наблюдение за исполнением и выдачу результата наружу. В документации перечислены оркестрация через визуальный редактор с поддержкой открытых и проприетарных моделей, выражения, собственный код и логика ветвления, циклов и маршрутизации. Туда же отнесены подключение к более чем 100 источникам, инструментам, векторным базам и памя­тям.

Данные обрабатываются преобразованиями, фильтрами, агрегатами, собственным кодом и конвейерами индексации RAG. Память и планирование опираются на разные техники оптимизации и интеграции. Есть узлы MCP-клиента и сервера, перечисление инструментов, SSE и поддержка авторизации. Безопасность включает модерацию входа и постобработку выхода, а контроль доступа — RBAC, SSO, шифрованные учётные данные, менеджеры секретов, ограничение частоты и доменов.

Развёртывание описано как самостоятельный хостинг с вариантом изолированной сети. Масштабирование заявлено вертикальное и горизонтальное, с высокой пропускной способностью на нагрузке рабочих процессов. Оценки строятся на наборах данных, оценщиках и прогонах. Поддержка сообщества идёт через форум, а вендорская — через SLA, консультации и фиксированное ценообразование.

Эти пункты задают границы: платформа отвечает за сборку, исполнение, наблюдение и выдачу, а качество ответа зависит от вашей схемы, промпта и подключённой модели.

Три конструктора: Assistant, Chatflow, Agentflow

Документация проекта делит визуальные конструкторы на три. Assistant назван самым дружелюбным для новичка способом создать агента: пользователь собирает чат-ассистента, который следует инструкциям, при необходимости использует инструменты и достаёт знания из загруженных файлов через RAG.

Chatflow предназначен для одноагентных систем, чат-ботов и простых LLM-процессов. Он гибче Assistant: доступны продвинутые техники вроде Graph RAG, реранкера и ретривера. Agentflow описан как надмножество Chatflow и Assistant: на нём собирают чат-ассистента, одноагентную систему, мультиагентные системы и сложную оркестрацию рабочих процессов. Отдельно упомянут Agentflow V2.

Для выбора удобно смотреть на то, что вы контролируете. Если задача — загрузить документы и общаться, хватает Assistant. Если нужно управлять ретривером, промптом и моделью, берут Chatflow. Если требуется ветвить обработку по результату проверки и запрашивать решение человека, подходит Agentflow.

В нашем учебном упражнении выбран Chatflow: он даёт контроль над ретривером и промптом, а ветвление и запрос к человеку в задаче не нужны. Текущий Agentflow V2 стоит держать отдельно от старых видео: интерфейс и возможности менялись, и переносить примеры из устаревших роликов на актуальную версию не стоит.

Полный исходный набор и заполненный эталон

Учебный набор состоит из двух документов. R1: «В рабочий день дежурный отвечает на запрос до 18:00». R2: «Правило обработки ночью не установлено». Этого достаточно, чтобы проверить три разных поведения: прямой ответ, честное неизвестное и отклонение ложной подстановки.

Схема потока в Chatflow: документ → splitter → embeddings → vector store → retriever → prompt → chat model → output. Документы разбиваются на фрагменты, превращаются в векторы, складываются в хранилище, ретривер достаёт релевантные куски, промпт собирает контекст, модель формирует ответ.

Промпт для узла:

Отвечай только по контексту. Укажи ID документа. Если правила нет, верни НЕИЗВЕСТНО. Контекст: {context}. Вопрос: {question}

Требование указывать ID документа выполнимо, когда ID попадает в контекст вместе с текстом фрагмента. Если в контекст уходит только текст, модель не сможет сослаться на R1 или R2. Поэтому в метаданные фрагмента кладут идентификатор, а шаблон промпта подставляет его рядом с содержимым.

Заполненный эталон выглядит так:

Третий случай проверяет устойчивость к ложной подстановке: в вопросе уже содержится неверное время, и модель должна опереться на документ. Первый случай проверяет извлечение факта, второй — поведение при отсутствии правила. Все три прогоняются после каждой правки промпта.

Ручной эталон и реальный запуск

Эталон выше — это ручная разметка учебного упражнения. Он задаёт, какой ответ считается правильным, и служит точкой сравнения. Реальный запуск даёт то, что вернула модель на конкретной схеме, промпте и версии узлов. Совпадение с эталоном подтверждает поведение на этих трёх вопросах, расхождение показывает, где схема или промпт требуют правки.

Разница принципиальна для приёмки. Ручной эталон можно составить до сборки потока: он не зависит от модели и хранилища. Результат запуска зависит от них и может меняться при смене модели, размера фрагмента или параметров ретривера. Поэтому в приёмке фиксируют оба слоя отдельно: ожидаемые ответы и фактически полученные.

Порядок проверки: собрать схему, загрузить R1 и R2, задать промпт, прогнать три вопроса, сравнить с эталоном. Если второй вопрос возвращает выдуманный срок, промпт не удерживает правило про НЕИЗВЕСТНО. Если третий вопрос принимает 17:00, модель следует формулировке пользователя вместо документа. Если первый ответ не содержит [R1], проверьте передачу идентификатора в контекст и соблюдение моделью заданного формата. Отсутствие ссылки само по себе не устанавливает причину ошибки.

После каждой правки промпта все три случая повторяются заново: изменение, улучшающее один ответ, может сломать другой. Такой цикл даёт проверяемую приёмку на небольшом наборе.

Отрицательный случай и неизвестные значения

Отрицательный случай в наборе — вопрос про срок ночью. В документе R2 прямо сказано, что правило обработки ночью не установлено. Правильное поведение — вернуть НЕИЗВЕСТНО.

Этот случай ловит распространённую ошибку: модель достраивает ответ по шаблону «дежурный отвечает до какого-то времени» и переносит дневное значение на ночь. Промпт с явным указанием возвращать НЕИЗВЕСТНО при отсутствии правила снижает такой риск, но проверять его нужно на каждом прогоне.

Ложная подстановка времени — второй отрицательный случай. Вопрос «Он отвечает до 17:00?» содержит неверное утверждение. Ожидаемое поведение: отклонить 17:00 и указать 18:00 со ссылкой на R1. Здесь проверяется опора ответа на контекст.

Неизвестные значения стоит держать явными в самом наборе. Если правило отсутствует, документ фиксирует это отдельной строкой, и промпт получает основание вернуть НЕИЗВЕСТНО. Когда в базе нет ни правила, ни пометки о его отсутствии, модель остаётся без опоры, и поведение становится менее предсказуемым.

Доступ и запуск без неподтверждённых условий

Документация проекта описывает два пути. Облачный вариант рекомендован тем, у кого нет опыта управления серверами: самостоятельный хостинг требует настройки инстанса, резервного копирования базы и поддержания обновлений. Локальная установка через NPM требует Node.js: поддерживаются версии v18.15.0 и v20 и выше.

Установка и запуск по документации:

npm install -g flowise
npx flowise start

После запуска интерфейс открывается по адресу http://localhost:3000. Для Docker документация предлагает два способа: через Docker Compose из папки docker в корне проекта и через сборку образа. В обоих случаях перед запуском копируют .env.example в .env.

Для разработки проект собран как монорепозиторий из четырёх модулей: сервер на Node, интерфейс на React, компоненты интеграций и документация API в формате Swagger. Разработчику нужен PNPM. Есть два сценария настройки: простой через PNPM и пошаговый для контрибьюторов с форком репозитория и ветками вида feature/<имя> и bugfix/<имя>.

Условия доступа к защищённому потоку определяются настройкой самого потока. Prediction API — основной эндпоинт для взаимодействия с потоками и ассистентами: он принимает сообщения и возвращает ответы, поддерживает потоковую выдачу, память диалога, обработку файлов и динамическую конфигурацию. Базовый адрес — http://localhost:3000 или адрес вашего инстанса, эндпоинт — POST /api/v1/prediction/:id.

FLOW_ID="your-flow-id"
curl -X POST "http://localhost:3000/api/v1/prediction/$FLOW_ID" \
  -H "Content-Type: application/json" \
  -d '{"question":"Какой срок ночью?"}'

Перед запуском замените your-flow-id на идентификатор собственного потока. Если поток защищён ключом, используется документированная авторизация для потоков. Секрет хранится на сервере и не размещается в публичном клиентском коде. Конкретный способ авторизации зависит от настроек потока.

Проверка фактов, ограничений и ссылок

Архивный статус учтён в начале обзора; ниже перечислены остальные первичные источники.

Проверка фактов опирается на первичные страницы. Введение и раздел о начале работы описывают состав платформы, три конструктора и способы установки. Страница Prediction описывает эндпоинт, параметры запроса, SDK для Python и TypeScript, работу с историей, сессиями, переменными и загрузкой файлов. Там же перечислены типовые ошибки: 404 при неверном ID потока, 401 при защите ключом, 400 при неверном формате запроса, 413 при слишком большом размере, 500 при ошибке конфигурации узлов.

Ограничения стоит держать рядом с фактами. Динамическое переопределение конфигурации отключено по умолчанию из соображений безопасности и включается в настройках. При переопределении свойства без указания ID узла значение применяется ко всем узлам того же типа. Значения массивов из overrideConfig объединяются с существующими.

Ссылки для сверки: введение, начало работы, Prediction API, состояние репозитория.

Архивный статус репозитория и что из него следует

Метка archived=true на репозитории FlowiseAI/Flowise означает, что проект переведён в режим архива. Последний push датирован 13.08.2026. Для команды, выбирающей инструмент под новый проект, это условие стоит проверить первым: от него зависит, кто будет сопровождать обновления и как решать вопросы безопасности.

Из архивного статуса не следует закрытие облачного сервиса. Метка относится к конкретному репозиторию. Она также не доказывает отсутствие коммерческой поддержки: в документации проекта отдельно перечислены вендорская поддержка с SLA, консультации и фиксированное ценообразование.

Частые вопросы

Что такое Flowise простыми словами?
Это открытая платформа для сборки агентов и LLM-процессов, где логика собирается из узлов на визуальном холсте. Внутри есть визуальный конструктор, трассировка, оценки, участие человека и выдача результата через API, SDK и встраиваемый чат.

Чем Chatflow отличается от Agentflow?
Chatflow рассчитан на одноагентные системы, чат-ботов и простые процессы с контролем ретривера и промпта. Agentflow описан как надмножество: на нём собирают мультиагентные системы и сложную оркестрацию с ветвлением.

Как запустить Flowise локально?
Документация предлагает установку через NPM с последующим запуском командой npx flowise start. Интерфейс открывается по адресу http://localhost:3000. Для Docker есть варианты через Docker Compose и через сборку образа.

Как вызвать собранный поток из кода?
Используется Prediction API: POST /api/v1/prediction/:id с телом, содержащим поле question. Идентификатор берётся из собственного потока. При защите ключом применяется документированная авторизация, а секрет хранится на сервере.

Что означает архивный статус репозитория?
Репозиторий FlowiseAI/Flowise помечен archived=true, последний push указан 13.08.2026. Это условие выбора для нового проекта. Закрытие облака или отсутствие коммерческой поддержки из этой метки не следуют.