Все ноды/Input / Output/Boundaries
Вход
Точка входа workflow. Два ВЫХОДА (сырой envelope не пробрасывает): output — для chat/telegram это СТРОКА-сообщение, а при custom inputs (ручной/API/editor запуск с объектом без ключа message) это ВЕСЬ входной объект целиком → inputs.input.<field> напрямую; data — контекст триггера (trigger, chat.session_id, telegram.*; структурный payload вебхука в data.webhook.payload). Историю чата берите нодами chat_history. Должна быть ровно одна. Не имеет exec_in.
Тип в графе: entry
Порты можно разделить на исполнение и данные (split ports).
Как попробовать
Сообщение и контекст триггера
Шаблон собирает строку из обоих выходов входа — текста сообщения и данных о канале.
- Исполнение + данные
Запускается сразу
Как применять
Вход не выбирают — он есть в любом воркфлоу и ровно один. Выбирать приходится другое:
каким из двух его выходов пользоваться. output — то, чем воркфлоу запустили, data —
обстоятельства запуска.
Как это работает
На output приходит сообщение. Для чата, виджета, Telegram и вебхука с текстом это
обычная строка: у неё нет полей, и {{ inputs.input.тема }} на ней ничего не даст. Разобрать
её на поля — задача отдельной ноды, например
structured_output_llm. Файлы, приложенные к сообщению,
едут вместе с ним и доступны нодам ниже.
Ровно два случая, когда на output лежит объект: ручной запуск, вызов по API или прогон
из редактора с произвольным JSON без ключа message — тогда поля читаются напрямую,
{{ inputs.input.city }}; и когда объект вернула нода выше по графу. Если воркфлоу нужны
структурные данные, передавайте их так, а не пытайтесь достать из строки чата.
На data лежит контекст триггера — форма фиксированная: trigger, workflow_id,
execution_id, workspace_id, user_id, chat.session_id, а также telegram, webhook,
cron (заполнен тот, через который пришёл запуск, остальные пустые). Структурная нагрузка
вебхука или формы лежит в webhook.payload. Читать можно ребром от порта data или по имени:
{{ nodes.entry.data.trigger }}.
Исполнительного входа у ноды нет: планировщик запускает её сам, и она — единственная точка, от которой стартуют остальные ветки.
Частые ошибки
- Второй вход в графе. Это ошибка
graph.multiple_entry, и она блокирует деплой. Второй вход не приносит второго запроса: он получает тот же самый вход и запускает несинхронную копию ветки — вся работа делается дважды и дважды оплачивается. Параллельные ветки тяните от одногоoutput, а сводите через wait_all. inputs.inputчитают как «вход воркфлоу». Это то, что дал непосредственный предшественник ноды. У ноды, стоящей после шаблона, там результат шаблона, а не сообщение пользователя. К входу обращайтесь по имени:{{ nodes.entry.output }}.- Историю диалога ищут на входе. Её там нет — предыдущие ходы читает нода chat_history.
Входы
—
Выходы
| Порт | Провод | Данные | Примечания |
|---|---|---|---|
Messageoutput | Исполнение + данныеexecute_data | message | |
Datadata | Данныеdata | — |
Настройки
У этой ноды нет настраиваемых полей.
Общие поля
Эти три поля есть у каждой ноды: платформа добавляет их сама, а не автор ноды.
split_ports_in— Показывать отдельные порты входа для выполнения и данных вместо одного объединённого.split_ports_out— Показывать отдельные порты выхода для выполнения и данных вместо одного объединённого.