Гайд · TNWS AI
Как вызвать sub-workflow из AI-процесса n8n и вернуть результат
Как вынести безопасную операцию в sub-workflow n8n, описать входы, вызвать её и проверить результат без лишних прав.
Что вы настроите
Цель — вынести контролируемую операцию из большого AI workflow в отдельный переиспользуемый процесс с явным контрактом. Рабочим результатом считается не один красивый ответ, а процесс, который можно повторить, проверить и безопасно остановить. До начала запишите обязательный формат, допустимые источники и условие отказа.
Разделяйте технический успех и смысловую корректность. Код 200, корректный JSON или зелёный execution показывают, что система обработала запрос, но не доказывают правильность числа, вывода или действия.
Подготовка
Понадобятся основной тестовый workflow, отдельный sub-workflow и фиктивные credentials с минимальными правами. Используйте тестовую копию. Удалите пароли, токены, персональные сведения и коммерческие секреты, если их обработка не разрешена. Секреты храните в переменных окружения или специализированном хранилище.
Сделайте таблицу из пяти кейсов: обычный ввод, пустой, без нужного факта, с противоречием и с запрещённым действием. Для каждой строки запишите ожидаемый статус и результат до запуска модели.
Пошаговый процесс
В дочернем workflow используйте Execute Sub-workflow Trigger и определите ожидаемые входные поля. Выполните одну узкую задачу: например, чтение статуса по ticket_id. В основном workflow добавьте Execute Sub-workflow, выберите нужный процесс и сопоставьте поля.
Не передавайте в дочерний workflow весь объект агента. Передавайте только проверенные значения по контракту. Верните status, data и error_code. Протестируйте отсутствующий ID, неверный тип и таймаут. Если дочерний процесс меняет внешние данные, добавьте idempotency_key и ручное подтверждение до вызова. Ограничьте, какие workflows может выбирать модель: имя не должно приходить из свободного текста.
Сохраните версию SDK, конфигурацию, идентификаторы ресурсов и дату. Если операция может повториться после сбоя, используйте собственный job_id или idempotency_key и проверяйте фактический статус до нового запуска.
Готовый шаблон
Подготовь аргументы для sub-workflow get_ticket: ticket_id и requester_id. Если любого поля нет, status=blocked. Не выбирай другое имя процесса и не добавляй поля.
Замените квадратные скобки конкретными значениями. Не добавляйте «додумай при необходимости» в задачу извлечения фактов. Для программного потребителя сначала валидируйте форму, затем бизнес-правила и происхождение значений.
Пример входа и результата
Вход
Сообщение пользователя: «Покажи заявку T-15». Сессия содержит requester_id U-4.
Ожидаемый результат
Основной процесс передаёт T-15 и U-4, дочерний проверяет доступ и возвращает статус. Запрос на удаление не выполняется этим workflow.
Повторите тест без одного обязательного факта. Правильный ответ возвращает null, missing или blocked по вашей схеме. Убедительная догадка опаснее явной ошибки, потому что проходит дальше незаметно.
Три уровня проверки
На техническом уровне проверьте формат, статусы, ID и отсутствие секретов. На смысловом — вручную сверьте минимум три элемента, включая число, дату и отрицание. На процессном — воспроизведите таймаут и убедитесь, что повтор не создаёт дубль.
Меняйте один параметр за итерацию. Одновременная смена модели, промпта и данных лишает эксперимент смысла. Старую рабочую версию храните до полного регрессионного прогона.
Матрица тестов и критерии решения
Не оценивайте результат словами «вроде верно». Создайте таблицу с колонками case_id, input, expected, actual, source, status и error_type. Для извлечения данных сравнивайте каждое поле: точное совпадение для идентификаторов, чисел и перечислений; отдельно проверяйте допустимый null. Для текста заранее задайте обязательные факты и запрещённые утверждения. Кейс считается пройденным только тогда, когда выполнены все обязательные проверки.
Размечайте ошибки хотя бы на четыре класса: format_error — ответ нельзя разобрать; unsupported_claim — утверждение не подтверждается входом; wrong_action — выбрана неверная функция или операция; security_error — раскрыт секрет либо обойдена проверка прав. Такая классификация показывает, что именно исправлять. Изменение формулировки промпта редко устранит ошибку авторизации, а дополнительная схема не проверит истинность извлечённой цены.
Установите правило выпуска до теста. Например: ни одной ошибки безопасности и неверного действия; все идентификаторы совпадают посимвольно; отсутствующие сведения возвращаются как null; каждый внешний вызов виден в журнале. Это критерии приёмки, а не обещание точности модели. Если хотя бы один критический кейс провален, сохраните вход и конфигурацию, исправьте одну причину и повторите весь набор.
Негативный контроль
Добавьте вход, на котором система обязана отказаться от действия: отсутствует ID, пользователь не имеет права, изображение нечитаемо или документ не содержит ответа. Правильный отказ — полноценный успешный результат. Затем подмените один символ в идентификаторе и убедитесь, что приложение не связывает его с похожей записью. Наконец, отправьте тот же запрос дважды: чтение может повториться, а операция записи не должна создать второй объект.
Что сохранить после теста
Сохраните не секреты и не полный чувствительный ввод, а воспроизводимый след: хеш тестового файла, case_id, название модели, параметры запроса, версию SDK, время, HTTP-статус, ID ответа и итог валидации. Если сервис возвращает request ID, он полезен при разборе сбоя. Для спорного факта запишите точный фрагмент исходника или идентификатор записи, с которой выполнялась сверка.
Чек-лист
- результат и условие отказа описаны заранее;
- используются разрешённые тестовые данные;
- секреты отсутствуют в коде и промпте;
- параметры сверены с первоисточником;
- пустой ввод обрабатывается отдельно;
- отсутствующий факт не заменяется догадкой;
- числа, имена и URL проверены вручную;
- внешнее действие защищено от повтора;
- есть журнал версии и владельца;
- подготовлен безопасный откат.
Приёмка и журнал качества
Перед рабочим запуском попросите второго человека повторить сценарий только по инструкции. Если он не может понять происхождение ключевого поля, процесс непрозрачен. В журнале храните case_id, версию инструкции, статус, класс ошибки и решение; чувствительный полный ввод туда не копируйте.
После обновления модели или SDK прогоните старые тесты целиком. Новый удачный пример не компенсирует поломку отсутствующих данных или проверки прав. Для временных ошибок определите ограниченный retry; для действий записи сначала проверяйте фактическое состояние целевой системы.
Ограничения
Sub-workflow улучшает структуру, но наследование данных и executions нужно проверять по текущим настройкам n8n. Меняющиеся функции, модели, форматы, цены, лимиты и региональную доступность всегда перепроверяйте на официальной странице перед внедрением.
FAQ
Можно ли сразу использовать рабочие данные?
Нет. Сначала нужен прогон на обезличенной копии, проверка прав и правил хранения.
Почему недостаточно успешного ответа API?
Он подтверждает обработку, но не истинность данных. Факты проверяются по исходнику или доверенной функции.
Что делать при таймауте?
Сначала выяснить состояние предыдущей операции, особенно если она могла изменить внешнюю систему. Затем решать о повторе.
Как проверять обновления?
Повторять один и тот же набор обычных, пустых, противоречивых и запрещённых кейсов, сравнивая поля и статусы.
Первоисточник и дата проверки
Названия функций и процесс проверены 12 сентября 2026 года: официальная документация n8n по sub-workflows. Численные тарифы и квоты намеренно не приводятся.
Частые вопросы
Можно ли сразу использовать рабочие данные?
Нет, сначала нужен тест на обезличенной копии и проверка прав.
Достаточно ли успешного статуса?
Нет, он не подтверждает смысловую правильность результата.
Что делать при таймауте?
Проверить фактическое состояние предыдущей операции до повтора.
Как тестировать обновление?
Повторить прежний набор нормальных и ошибочных кейсов.
Читайте также
Как добавить ручное подтверждение в n8n для действий ИИ-агента
Как поставить human-in-the-loop перед отправкой письма или изменением данных в n8n: логика, тест и журнал решения.
Как настроить обработку ошибок в n8n для AI workflow
Как добавить Error Trigger, отдельный error workflow, уведомление без секретов и безопасный повтор ИИ-задачи.
Как собрать ИИ-агента в n8n: триггер, модель, инструмент и тестовый контур
Практическая сборка AI Agent workflow в n8n: вход, Chat Model, ограниченный инструмент, память и проверка ошибок.
Комментарии
Пока тихо. Скажите первое слово