ИИ-агент не должен достраивать поручение догадками, если собирается создать заявку, изменить запись или выполнить другое действие в рабочей системе. Сначала процесс проверяет полноту и однозначность данных. При обнаружении пробела агент задаёт связанный с ним вопрос, заново проверяет весь набор сведений и только затем показывает подтверждение или передаёт ситуацию сотруднику.
Это правило нужно проектировать отдельно. Документация платформы n8n подтверждает, что узел AI Agent с подключённой моделью и инструментами может выбирать вызываемый инструмент. Она не подтверждает наличие готовой обязательной проверки данных перед каждым действием.
Где неполное поручение становится риском для процесса
Фраза, понятная сотруднику, может оказаться недостаточной для записи. Например, поручение «Создай заявку на подключение нового менеджера в понедельник» не сообщает, какие системы нужно подключить и кто согласует доступ. Если агент самостоятельно подставит привычный набор, в рабочей системе появится формально заполненная, но неверная заявка.
Безопасный маршрут выглядит так:
- Пользователь передаёт поручение.
- Процесс проверяет достаточность данных.
- Агент запрашивает конкретное уточнение или передаёт задачу сотруднику.
- Пользователь подтверждает собранные сведения.
- Только после этого процесс разрешает действие.
ИИ-агент, чат-бот и обычная интеграция здесь выполняют разные роли. Чат-бот предоставляет диалоговый интерфейс. Фиксированная интеграция следует заранее заданным веткам. ИИ-агент выбирает следующий шаг из разрешённых вариантов, поэтому его доступ к инструментам требует отдельных условий допуска.
Определить данные, без которых действие запрещено
Владелец процесса сначала составляет паспорт каждой операции. Универсального числа обязательных полей нет: состав зависит от действия и последствий ошибки.
| Часть паспорта | Что зафиксировать |
|---|---|
| Цель | Какой объект создаётся или изменяется |
| Обязательные поля | Без каких значений действие запрещено |
| Условные поля | Когда поле становится обязательным |
| Допустимые значения | Свободный ввод, формат или разрешённый справочник |
| Источник | Откуда можно брать каждое значение |
| Актуальность | Когда сведения нужно запросить или проверить заново |
| Связи полей | Какие значения зависят друг от друга |
| Исключения | Кто принимает решение в неоднозначной ситуации |
- Часть паспорта
- Цель
- Что зафиксировать
- Какой объект создаётся или изменяется
- Часть паспорта
- Обязательные поля
- Что зафиксировать
- Без каких значений действие запрещено
- Часть паспорта
- Условные поля
- Что зафиксировать
- Когда поле становится обязательным
- Часть паспорта
- Допустимые значения
- Что зафиксировать
- Свободный ввод, формат или разрешённый справочник
- Часть паспорта
- Источник
- Что зафиксировать
- Откуда можно брать каждое значение
- Часть паспорта
- Актуальность
- Что зафиксировать
- Когда сведения нужно запросить или проверить заново
- Часть паспорта
- Связи полей
- Что зафиксировать
- Какие значения зависят друг от друга
- Часть паспорта
- Исключения
- Что зафиксировать
- Кто принимает решение в неоднозначной ситуации
Полезно разделить четыре причины остановки:
| Ситуация | Реакция процесса |
|---|---|
| Значение отсутствует | Запросить конкретное поле |
| Значение неоднозначно | Показать допустимые варианты или попросить уточнить смысл |
| Данные противоречат друг другу | Не выбирать одну версию автоматически; передать конфликт ответственному |
| Источник недоступен | Сообщить об ограничении и применить согласованный маршрут передачи |
- Ситуация
- Значение отсутствует
- Реакция процесса
- Запросить конкретное поле
- Ситуация
- Значение неоднозначно
- Реакция процесса
- Показать допустимые варианты или попросить уточнить смысл
- Ситуация
- Данные противоречат друг другу
- Реакция процесса
- Не выбирать одну версию автоматически; передать конфликт ответственному
- Ситуация
- Источник недоступен
- Реакция процесса
- Сообщить об ограничении и применить согласованный маршрут передачи
Схема данных помогает проверить наличие полей, типы и формат. Она не доказывает, что имя, дата или выбранный объект верны по смыслу.
Поставить проверку до вызова инструмента
Маршрут лучше описать через явные состояния операции:
| Состояние | Что происходит | Доступ к изменению системы |
|---|---|---|
| Поручение получено | Процесс сохраняет исходный запрос и контекст сессии | Запрещён |
| Данные собраны | Из разрешённых источников извлекаются известные значения | Запрещён |
| Обнаружены пробелы | Процесс перечисляет отсутствующие или неоднозначные сведения | Запрещён |
| Ожидается уточнение | Агент задаёт вопрос и ждёт ответ в той же сессии | Запрещён |
| Данные готовы | Весь набор повторно проверяется | Запрещён |
| Ожидается подтверждение | Пользователь видит, что будет создано или изменено | Запрещён, если подтверждение обязательно |
| Действие разрешено | Выполнены согласованные условия допуска | Разрешён |
| Передано сотруднику | Открытые вопросы и подтверждённые сведения сохранены | Запрещён до решения |
| Завершено | Результат подтверждён целевой системой либо зафиксирована ошибка | Повтор — только по отдельному правилу |
- Состояние
- Поручение получено
- Что происходит
- Процесс сохраняет исходный запрос и контекст сессии
- Доступ к изменению системы
- Запрещён
- Состояние
- Данные собраны
- Что происходит
- Из разрешённых источников извлекаются известные значения
- Доступ к изменению системы
- Запрещён
- Состояние
- Обнаружены пробелы
- Что происходит
- Процесс перечисляет отсутствующие или неоднозначные сведения
- Доступ к изменению системы
- Запрещён
- Состояние
- Ожидается уточнение
- Что происходит
- Агент задаёт вопрос и ждёт ответ в той же сессии
- Доступ к изменению системы
- Запрещён
- Состояние
- Данные готовы
- Что происходит
- Весь набор повторно проверяется
- Доступ к изменению системы
- Запрещён
- Состояние
- Ожидается подтверждение
- Что происходит
- Пользователь видит, что будет создано или изменено
- Доступ к изменению системы
- Запрещён, если подтверждение обязательно
- Состояние
- Действие разрешено
- Что происходит
- Выполнены согласованные условия допуска
- Доступ к изменению системы
- Разрешён
- Состояние
- Передано сотруднику
- Что происходит
- Открытые вопросы и подтверждённые сведения сохранены
- Доступ к изменению системы
- Запрещён до решения
- Состояние
- Завершено
- Что происходит
- Результат подтверждён целевой системой либо зафиксирована ошибка
- Доступ к изменению системы
- Повтор — только по отдельному правилу
Документация n8n описывает Call n8n Workflow Tool: этот инструмент позволяет агенту запустить другой workflow и получить его выходные данные. Входы выбранного workflow можно задать фиксированными значениями, выражениями из текущего workflow или предоставить их заполнение модели.
Эти возможности не создают защитный маршрут автоматически. Запрет вызова при пробелах, серверная проверка обязательных полей, хранение состояния ожидания и привязка ответа к сессии — требования будущего решения. Ветка уточнения не должна иметь технической возможности обратиться к инструменту изменения системы до выполнения условий допуска.
Сформулировать уточнение без догадок и лишнего диалога
Хороший вопрос связан с обнаруженным пробелом. Он называет нужные сведения понятным пользователю языком и, если требуется, показывает допустимый формат.
Вместо общего «Уточните данные» лучше написать: «Для заявки не хватает состава доступов и согласующего. Укажите нужные системы и ответственного за подтверждение».
Если поле связано со справочником, агенту следует показать разрешённые варианты, а не придумывать новые. Связанные пробелы можно объединить в один вопрос, если пользователь способен ответить на него без дополнительной расшифровки.
Произвольный предел вроде «не больше трёх вопросов» не учитывает содержание операции. Диалог нужно остановить по смысловому условию:
- повторяется тот же незакрытый пробел;
- новый ответ противоречит исходному поручению или прежнему подтверждению;
- пользователь не может выбрать допустимый вариант;
- решение требует отсутствующих у пользователя полномочий;
- разрешённый источник недоступен или не позволяет проверить значение.
В этих ситуациях ещё одна переформулировка вопроса не устраняет причину неопределённости.
Повторно проверить ответ и показать подтверждение
После ответа пользователя процесс заново собирает полный набор данных. Нельзя просто вставить новое значение в прежний черновик: пользователь мог изменить дату, объект или другое поле, от которого зависят остальные сведения.
Повторная проверка охватывает:
- наличие всех обязательных и условных полей;
- формат и принадлежность значений разрешённым справочникам;
- актуальность сведений и источников;
- связи между полями;
- отличия от исходного поручения и уже подтверждённых значений.
Перед значимым действием процесс может показать краткое резюме: какой объект будет создан или изменён, с какими параметрами и в какой системе. Обязательность такого подтверждения определяет матрица полномочий конкретного процесса.
Structured Output Parser в n8n возвращает поля на основе JSON Schema. При автоматическом создании схемы из примера n8n использует названия и типы свойств и считает поля обязательными; фактические значения примера при этом игнорируются. Такая структурная проверка не подтверждает истинность, актуальность или допустимость сведений. Поэтому парсер не заменяет проверку смысла перед действием.
Передать ситуацию сотруднику, если уточнения недостаточно
Передача нужна не после универсального числа неудачных сообщений, а при конкретном препятствии. Основанием может стать неизвестное обязательное значение, конфликт источников, недопустимый вариант, отсутствие полномочий, невозможность подтвердить объект или повторяющийся безрезультатный цикл.
Карточка передачи должна сохранять контекст, чтобы сотруднику не пришлось начинать разбор заново:
| Поле карточки | Содержание |
|---|---|
| Исходное поручение | Сообщение пользователя без пересказа, меняющего смысл |
| Подтверждённые значения | Сведения, источник и время проверки, если это важно для операции |
| Открытые вопросы | Какие обязательные данные получить не удалось |
| Противоречия | Какие значения или источники не совпадают |
| Запрещённое действие | Что нельзя выполнять до решения сотрудника |
| Следующий шаг | Кто должен принять решение или предоставить данные |
- Поле карточки
- Исходное поручение
- Содержание
- Сообщение пользователя без пересказа, меняющего смысл
- Поле карточки
- Подтверждённые значения
- Содержание
- Сведения, источник и время проверки, если это важно для операции
- Поле карточки
- Открытые вопросы
- Содержание
- Какие обязательные данные получить не удалось
- Поле карточки
- Противоречия
- Содержание
- Какие значения или источники не совпадают
- Поле карточки
- Запрещённое действие
- Содержание
- Что нельзя выполнять до решения сотрудника
- Поле карточки
- Следующий шаг
- Содержание
- Кто должен принять решение или предоставить данные
Пока сотрудник не разрешил противоречие, агент не сообщает об успешном выполнении. После решения процесс повторно проверяет актуальность всего набора и только затем допускает вызов инструмента.
Разобрать условный маршрут создания заявки
Ниже — синтетический учебный пример. Это не клиентский кейс Switch On AI, не выполненный тест и не описание готовой функции n8n. Он показывает проектируемое поведение будущего решения.
Сотрудник пишет: «Создай заявку на подключение нового менеджера в понедельник».
Для согласованной операции обязательны имя сотрудника, перечень доступов, дата начала действия и согласующий.
| Этап | Данные и решение |
|---|---|
| Исходное поручение | Нужно создать заявку на подключение в понедельник |
| Известно | Имя сотрудника получено из разрешённого контекста; дата указана в поручении |
| Не хватает | Состава доступов и согласующего |
| Вопрос агента | «Для заявки не хватает состава доступов и согласующего. Укажите нужные системы и ответственного за подтверждение» |
| Ответ пользователя | «Почта и система заявок, согласующий — руководитель отдела» |
| Повторная проверка | Системы сверяются с разрешённым перечнем, согласующий — со справочником, дата и остальные поля собираются заново |
| Подтверждение | Пользователь видит краткую карточку будущей заявки |
| Допуск | Инструмент можно вызвать только после выполнения согласованных условий |
- Этап
- Исходное поручение
- Данные и решение
- Нужно создать заявку на подключение в понедельник
- Этап
- Известно
- Данные и решение
- Имя сотрудника получено из разрешённого контекста; дата указана в поручении
- Этап
- Не хватает
- Данные и решение
- Состава доступов и согласующего
- Этап
- Вопрос агента
- Данные и решение
- «Для заявки не хватает состава доступов и согласующего. Укажите нужные системы и ответственного за подтверждение»
- Этап
- Ответ пользователя
- Данные и решение
- «Почта и система заявок, согласующий — руководитель отдела»
- Этап
- Повторная проверка
- Данные и решение
- Системы сверяются с разрешённым перечнем, согласующий — со справочником, дата и остальные поля собираются заново
- Этап
- Подтверждение
- Данные и решение
- Пользователь видит краткую карточку будущей заявки
- Этап
- Допуск
- Данные и решение
- Инструмент можно вызвать только после выполнения согласованных условий
Дальше возможны две ветви:
- Все значения допустимы и подтверждены — процесс создаёт заявку, получает идентификатор и сверяет сохранённое содержание.
- Согласующий не найден в разрешённом справочнике либо новый ответ противоречит поручению — процесс не создаёт заявку и передаёт карточку сотруднику.
Пример полезен как основа для обсуждения требований, но не доказывает работу с конкретной системой, аккаунтом или тарифом.
Проверить сценарий до рабочего запуска
Проверка должна покрывать согласованные состояния, переходы и исключения, а не произвольное количество диалогов.
| Проверочная ситуация | Ожидаемое поведение |
|---|---|
| Все обязательные сведения присутствуют | Процесс не задаёт лишний вопрос и переходит к предусмотренному подтверждению |
| Отсутствует одно или несколько полей | Инструмент не вызывается; вопрос перечисляет конкретные пробелы |
| Значение допускает несколько трактовок | Агент запрашивает выбор или показывает разрешённые варианты |
| Ответ закрывает пробел | Полный набор данных собирается и проверяется заново |
| Ответ противоречит поручению | Действие останавливается до разрешения противоречия |
| Пользователь меняет подтверждённое значение | Зависимые поля обновляются и снова проходят проверку |
| Получить достаточные данные не удаётся | Ситуация передаётся сотруднику вместе с контекстом |
| Сообщение приходит повторно | Согласованное правило не допускает второй записи |
| Внешняя система возвращает ошибку | Ошибка не маскируется уточняющим вопросом или сообщением об успехе |
| Ответ из другой сессии | Старое значение не применяется к текущей операции |
- Проверочная ситуация
- Все обязательные сведения присутствуют
- Ожидаемое поведение
- Процесс не задаёт лишний вопрос и переходит к предусмотренному подтверждению
- Проверочная ситуация
- Отсутствует одно или несколько полей
- Ожидаемое поведение
- Инструмент не вызывается; вопрос перечисляет конкретные пробелы
- Проверочная ситуация
- Значение допускает несколько трактовок
- Ожидаемое поведение
- Агент запрашивает выбор или показывает разрешённые варианты
- Проверочная ситуация
- Ответ закрывает пробел
- Ожидаемое поведение
- Полный набор данных собирается и проверяется заново
- Проверочная ситуация
- Ответ противоречит поручению
- Ожидаемое поведение
- Действие останавливается до разрешения противоречия
- Проверочная ситуация
- Пользователь меняет подтверждённое значение
- Ожидаемое поведение
- Зависимые поля обновляются и снова проходят проверку
- Проверочная ситуация
- Получить достаточные данные не удаётся
- Ожидаемое поведение
- Ситуация передаётся сотруднику вместе с контекстом
- Проверочная ситуация
- Сообщение приходит повторно
- Ожидаемое поведение
- Согласованное правило не допускает второй записи
- Проверочная ситуация
- Внешняя система возвращает ошибку
- Ожидаемое поведение
- Ошибка не маскируется уточняющим вопросом или сообщением об успехе
- Проверочная ситуация
- Ответ из другой сессии
- Ожидаемое поведение
- Старое значение не применяется к текущей операции
Для каждого маршрута сохраняют входное поручение, обнаруженные пробелы, заданный вопрос, состояние операции, итоговый набор полей и фактический ответ целевой системы. Созданный объект сверяют по идентификатору и содержимому.
Успешное соответствие JSON Schema не доказывает правильность сведений. Успешное завершение workflow также не доказывает, что в целевой системе создан нужный объект. Проверка заканчивается сравнением ожидаемого и фактического бизнес-результата.
Ограничения и подготовка к внедрению
Официальная документация n8n подтверждает возможности узлов AI Agent, Call n8n Workflow Tool и Structured Output Parser. Она не доказывает наличие готового маршрута уточнения, защиту от догадок, корректную изоляцию диалогов или успешное подключение к системе заказчика. В документации также отмечено, что старый узел AI Agent v1 с настройкой типа агента удаляется в n8n 3.0; поэтому перед проектированием нужно проверить фактическую версию узла и платформы.
Возможность конкретного действия зависит от API, тарифа, прав и данных доступного аккаунта. До оценки проекта подготовьте:
- обезличенные примеры полных и неполных поручений;
- перечень разрешённых действий;
- обязательные и условные поля;
- справочники и источники значений;
- роли и полномочия участников;
- условия передачи ситуации сотруднику;
- критерии подтверждения результата в целевой системе.
Switch On AI разрабатывает и внедряет ИИ-агентов под конкретные рабочие операции: от требований и прототипа ключевого сценария до проверки и передачи решения в согласованном объёме. Прототип не равен полноценному внедрению, а возможность подключения проверяется для выбранной системы.
Чтобы обсудить аналогичный процесс, пришлите пример поручения, перечень обязательных полей и описание действия в рабочей системе. На разборе можно определить маршрут уточнения, границы самостоятельности агента и состав прототипа ключевого сценария.
Вопросы по этой задаче
Должен ли ИИ-агент всегда задавать вопрос при пустом поле?
Нет. Сначала владелец процесса определяет, обязательно ли поле для этой операции и при каких условиях. Допустимо пустое значение или требуется остановка — это должно быть записано в паспорте операции.
Можно ли поручить модели самой заполнить пропущенные поля?
n8n позволяет предоставить модели заполнение входного параметра, но эта возможность не подтверждает правильность значения. Обязательные сведения нужно получать из согласованных источников или запрашивать у пользователя, а перед действием — проверять.
Когда нужно прекратить уточнения и передать запрос сотруднику?
Когда повторяется тот же пробел, ответы противоречат друг другу, пользователь не имеет нужных полномочий, значение недопустимо или разрешённый источник нельзя проверить. Универсальное число вопросов для всех процессов не требуется.
Нужно ли подтверждение пользователя после сбора данных?
Это зависит от матрицы полномочий и последствий операции. Для значимого действия полезно показать краткую карточку будущего изменения; обязательность подтверждения нужно закрепить в требованиях.
Как проверить, что агент не вызвал инструмент раньше времени?
Для сценариев с полными, неполными и противоречивыми данными нужно проверить состояние операции и журнал вызовов. Ветка уточнения не должна иметь доступа к изменению системы, пока не выполнены согласованные условия допуска.