Flowise или Langflow: выбор и сопровождение

Flowise или Langflow: выбор и сопровождение начинается с инвентаризации. Сначала фиксируют язык расширений, статус upstream и наличие существующих потоков. Дальше сравнивают документированные возможности с требованиями команды. Универсального рейтинга здесь нет: каждое решение привязано к состоянию 07.11.2026 и к конкретному набору входов.

Матрица решений по полностью заданным требованиям

Разговор о выборе сдвигается с «какой инструмент лучше» на «какое требование закрывается каким маршрутом». Ниже четыре полностью заданных ситуации. Каждая описывает вход, решение и то, что нужно проверить до старта.

A. Есть Flowise-поток и владелец исправлений. У команды уже работает flow, за ним закреплён человек, который вносит правки. Решение: сначала оценить сохранение текущего Flowise с явным планом сопровождения, затем рассматривать миграцию. Архив репозитория FlowiseAI/Flowise не означает автоматического требования немедленно переносить всё. Статус репозитория подтверждён GitHub API: archived=true, последний push 13.08.2026. Этот факт описывает состояние репозитория на дату сравнения. Он не доказывает закрытие облачного сервиса и не отменяет коммерческую поддержку. Новый проект и поддержка существующего потока — два разных решения, и путать их не стоит.

B. Новый проект на Python с custom Python components. Команда пишет на Python и требует собственные компоненты. Решение: Langflow — кандидат для пилота. Текущая первичная документация Langflow описывает создание кастомных компонентов на Python: класс наследуется от Component, задаются атрибуты, списки входов и выходов, методы обработки. До старта проверяют два вопроса: есть ли нужные компоненты и каким способом проект разворачивается. Официальная документация Langflow называет визуальный редактор, playground для тестирования потоков в реальном времени, API для запуска потоков из кода приложения и развёртывание сервера.

C. Новый проект с обязательным активным upstream. Требование звучит так: исходный репозиторий активно развивается, исправления приходят регулярно. Архивный Flowise этот конкретный критерий не выполняет. Статус Langflow сверяют отдельно по его собственному репозиторию и релизам. Чужие звёзды и сторонние таблицы для этого решения не годятся: они не показывают частоту исправлений и не заменяют первичную сверку.

D. Обязательна автоматическая миграция Flowise-экспорта. Требование: имеющийся экспорт переносится без ручных изменений. Ни один маршрут не объявляется подходящим без документированной совместимости и пробного переноса. Возможность перерисовать поток в другой системе не доказывает автоматическую миграцию и совместимость экспортов. Такой пункт закрывается только пробным переносом на реальном экспорте.

Матрица полезна тем, что каждое требование получает отдельную строку. Команда видит, где решение уже принято, а где нужен пилот.

Полный набор входов и ручные эталоны

Пилот держится на полном наборе входов. Это небольшой учебный набор, который проверяет, переносится ли смысл через выбранный конструктор. Условные значения задают учебный вход.

• R1: «Лимит проекта — 12 заявок в день».
• R2: «Правило для выходных не установлено».

Вопросы и ручные эталоны к ним:

• «Какой лимит?» → 12 заявок в день [R1].
• «Какой срок в выходной?» → неизвестно [R2].

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

Полный набор входов для пилота выглядит так:

1. Два правила R1 и R2 в виде текста.
2. Два вопроса к ним.
3. Два ручных эталона ответов.
4. Формат вызова API, который команда будет использовать.
5. Экспортированный поток в виде файла.
6. Список зависимостей и версий.
7. Имя владельца сопровождения.
8. Отрицательный тест: ответ 20 вместо 12.

Восьмой пункт — отрицательная проверка. Если поток отвечает «20 заявок в день» вместо 12 или придумывает срок для выходного, приёмка отклоняется независимо от выбранного инструмента. Отрицательный случай ловит подмену смысла, которую положительные ответы пропускают.

Ручные эталоны заводят до запуска. Их пишет человек, который знает правила проекта. Эталон фиксируется в текстовом виде и не меняется по ходу пилота. Если эталон правили после запуска, проверка теряет смысл: под результат подгоняют ожидание.

Набор входов хранят вместе с потоком. Тогда при смене инструмента его переносят целиком и повторяют оба вопроса. Сравнение использует один неизменный набор.

Условия выбора, документированные возможности и неизмеренные свойства

Три категории утверждений разводят по разным спискам. Смешивание даёт ложную уверенность.

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

Документированные возможности подтверждаются первичной документацией конкретного проекта. Документация Flowise описывает визуальный конструктор с тремя режимами: Assistant, Chatflow и Agentflow. Agentflow V2 описан как архитектура с явной оркестрацией: узлы выполняются как независимые единицы, связи на холсте задают путь и порядок управления, Flow State управляет данными внутри одного запуска. Документация перечисляет узлы: Start, LLM, Agent, Tool, Retriever, HTTP, Condition, Condition Agent, Iteration, Loop, Human Input, Direct Reply, Custom Function, Execute Flow. Custom Function выполняет серверный JavaScript и возвращает строку. Loop Node возвращает выполнение к ранее пройденному узлу, значение по умолчанию для максимального числа повторов — 5. Human Input останавливает поток и ждёт ответа человека, после чего продолжает по выбранной ветке.

Документация Langflow описывает Python-фреймворк для сборки ИИ-приложений, поддержку агентов и Model Context Protocol, визуальный редактор, playground, API и развёртывание сервера. Кастомные компоненты строятся на классе, который наследуется от Component. Компоненты размещают в каталогах категорий, каждый каталог содержит __init__.py. Глубина вложенности ограничена двумя уровнями. Путь поиска задаётся переменной окружения LANGFLOW_COMPONENTS_PATH. Выход компонента связывают с методом, имя метода совпадает с полем method в списке выходов.

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

Разделение помогает на встрече: по каждому пункту видно, спорят о требовании, о документации или о непроверенном свойстве.

Чужие benchmark, тарифы и непроверенные defaults

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

Практическое правило: число попадает в решение только тогда, когда его источник — первичная документация проекта или собственный замер команды. Цены и тарифы сверяют на официальной странице продукта на дату решения. Звёзды репозитория не показывают частоту исправлений. Сроки из обзора не заменяют дату последнего push из API репозитория.

Отдельно про defaults. Значение по умолчанию, названное в обзоре, может отличаться от текущего. Документация Flowise называет значение по умолчанию для максимального числа повторов в Loop Node — 5. Это документированный факт конкретного узла. Переносить его на другие узлы или на другой продукт нельзя. Каждый параметр сверяют в разделе документации, который описывает именно этот узел.

Что делать с чужими таблицами на практике:

1. Прочитать обзор как список тем для проверки.
2. Для каждого числа найти первичный источник.
3. Сверить дату первичного источника с датой решения.
4. Оставить в матрице только подтверждённые числа.
5. Непроверенное перенести в список неизмеренных свойств.

Такой порядок сохраняет пользу обзора и убирает риск опереться на устаревшую цифру.

Проверка отрицательного случая, доступности API и актуальности пути

Пилот проверяет три вещи: отрицательный случай, доступность нужного API и актуальность продуктового пути.

Отрицательный случай. Поток получает вопрос, на который правильного ответа в правилах нет. Ожидаемое поведение — честная пометка «неизвестно». Если поток придумывает срок для выходного, приёмка отклоняется. Второй отрицательный вход — ответ 20 вместо 12. Оба случая проверяют до положительных, чтобы увидеть поведение на границе правил.

Доступность API. Команда фиксирует формат вызова, который будет использовать в приложении. Документация Flowise называет API, SDK на JavaScript и Python, а также CLI. Документация Langflow называет API для запуска потоков из кода приложения и развёртывание сервера. На пилоте сохраняют точный формат вызова: адрес, метод, тело запроса, формат ответа. Этот артефакт переносят в приложение без переписывания.

Актуальность продуктового пути. Проверяют, что выбранный маршрут существует на дату решения. Для Flowise это означает сверку статуса репозитория и наличия плана сопровождения. Для Langflow — сверку текущей документации и способа развёртывания. Продуктовый путь считают актуальным, когда он подтверждён первичным источником на дату сравнения.

Порядок проверки на пилоте:

1. Собрать R1 и R2.
2. Задать оба вопроса.
3. Сверить ответы с ручными эталонами.
4. Прогнать отрицательный вход: ответ 20 вместо 12.
5. Прогнать отрицательный вход: вопрос про выходной.
6. Сохранить формат вызова API.
7. Сохранить экспортированный поток.
8. Зафиксировать зависимости и владельца сопровождения.

Пункты 6–8 дают артефакты, по которым пилот повторяют через месяц. Без них проверка держится на памяти участников.

Ограничения и статус ручного эталона

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

Ограничения пилота перечисляют явно:

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

Статус репозитория Flowise на дату сравнения — архивный, последний push 13.08.2026. Этот факт влияет на решение о новом проекте с требованием активного upstream. Для существующего потока он означает необходимость явного плана сопровождения. Вывод о закрытии облачного сервиса из архива не следует.

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

Промпт ниже помогает собрать отчёт по пилоту в едином виде. Он не запускает конструктор и не заменяет проверку.

Ты помогаешь оформить отчёт по пилоту визуального конструктора ИИ.
Вход: правила [R1], [R2]; вопросы [вопрос 1], [вопрос 2]; ручные эталоны [эталон 1], [эталон 2]; ответы потока [ответ 1], [ответ 2]; отрицательные входы [отрицательный 1], [отрицательный 2].
Сделай таблицу со столбцами: вход, ручной эталон, ответ потока, совпадение, комментарий.
Отдельным блоком перечисли артефакты: формат вызова API, экспортированный поток, зависимости, владелец сопровождения, дата пересмотра.
Отдельным блоком перечисли ограничения пилота: размер набора входов, ручное происхождение эталонов, покрытые отрицательные случаи, неизмеренные свойства.
Пиши утверждениями. Не добавляй числа, которых нет во входе. Не делай выводов о продукте за пределами набора входов.

В промпте меняют под себя список правил, вопросы и эталоны. Формат таблицы оставляют: он совпадает с порядком проверки на пилоте.

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

Flowise или Langflow: что выбрать для нового проекта на Python?
Langflow — кандидат для пилота, когда команда работает на Python и требует собственные компоненты. Текущая документация Langflow описывает создание кастомных компонентов на Python и размещение их в каталогах категорий. До старта проверяют наличие нужных компонентов и способ развёртывания. Решение фиксируют по результатам пилота на своём наборе входов.

Что означает архивный статус репозитория Flowise?
GitHub API подтверждает для репозитория FlowiseAI/Flowise значение archived=true и последний push 13.08.2026. Для нового проекта с требованием активного upstream этот критерий не выполняется. Для существующего потока архив означает необходимость явного плана сопровождения. Вывод о закрытии облачного сервиса из архива не следует.

Можно ли перенести существующий Flowise-поток в Langflow автоматически?
Автоматическая миграция экспорта без ручных изменений требует документированной совместимости и пробного переноса. Возможность перерисовать поток в другой системе не доказывает совместимость экспортов. Маршрут не объявляется подходящим до проверки на реальном экспорте. Пробный перенос делают на копии потока.

Как проверить, что поток отвечает по правилам проекта?
Собирают набор входов: правила, вопросы и ручные эталоны ответов. Задают вопросы потоку и сверяют вывод с эталонами. Добавляют отрицательный вход: ответ 20 вместо 12 или вопрос про выходной. Придуманный срок для выходного означает отказ приёмки.

Какие артефакты сохранить после пилота?
Сохраняют формат вызова API, экспортированный поток, список зависимостей и имя владельца сопровождения. Добавляют дату пересмотра решения. Набор входов с эталонами хранят вместе с потоком, чтобы повторить проверку через месяц. Без этих артефактов проверка держится на памяти участников.