Пайплайн из Python-функций теперь двигают мышью: Gradio рисует канвас из 3 строк кода

`import gradio as gr`, следом `gr.Workflow(bind=[your_function]).launch()`. Функции из параметра bind становятся узлами канваса: их соединяют и переставляют прямо в браузере.

Схема перестала быть картинкой про код. Теперь код собирают из схемы.

Раньше был daggr. Ту же задачу команда Gradio решала библиотекой, где граф писали кодом (`pip install daggr`, версия 0.4.3 в примерах): GradioNode, FnNode и InferenceNode складывали в Python, а канвас генерировался следом. В gr.Workflow канвас стал редактируемым.

Узлов три типа: references для входов вроде файлов и текста, operators для шагов, subjects для выходов. Operator бывает четырёх видов, от `space` и `model` до `dataset` и `fn`.

Деплой и API. `gradio deploy` из терминала или загрузка кода в Space. Эндпоинты появляются сами: каждый несвязанный пайплайн с выходным узлом даёт один, имя берётся от лейбла первого subject, например `/output_image`.

Невычисленные reference-узлы становятся параметрами вызова. Из Python граф зовут через gradio_client: `Client("ysharma/gr-workflow-multi-endpoint-API")` и `client.predict("hello there friend", api_name="/word_count")` возвращает 3. Тот же граф дёргается голым curl на `/gradio_api/call/word_count`.

Чтобы граф правили прямо в браузере, в настройках Space включается `hf_oauth: true`. Доступ получают владелец и допущенные им люди.

Два ограничения меняют проектирование. gr.Workflow живёт только верхним уровнем и внутрь gr.Blocks не вкладывается. Ветки fan-out при вызове через API считаются последовательно, не параллельно.