Как подключить workflow n8n как инструмент ИИ-агента

ИИ-агенту не нужен общий доступ к рабочей системе, если от него требуется одна операция. Для такой задачи можно открыть отдельный инструмент с ограниченным назначением: например, подготовить перенос встречи, запросить подтверждение сотрудника и только затем изменить запись. Граница инструмента помогает описать полномочия и приёмку, но сама по себе не ограничивает права подключения во внешней системе.

В n8n для этой границы можно использовать Call n8n Workflow Tool. По актуальной документации n8n этот узел позволяет агенту запустить другой workflow n8n и получить его выходные данные. Однако сам механизм вызова не проверяет бизнес-смысл аргументов, права внешней учётной записи и фактический результат операции. Эти условия нужно спроектировать и испытать отдельно.

Когда workflow стоит подключать как отдельный инструмент агента

Отдельный workflow подходит для сфокусированной операции с понятным результатом. У неё можно определить входные параметры, владельца процесса, допустимые исходы и способ независимой проверки.

Примеры такой границы: получить сведения о записи, подготовить черновик изменения или выполнить заранее определённое действие после подтверждения. Формулировка «работать с календарём» слишком широка: она не объясняет, какие объекты агент вправе читать и менять. Формулировка «перенести указанную встречу на предложенное время после проверки и одобрения сотрудника» задаёт предмет для проектирования.

Вызываемый workflow скрывает от модели внутреннюю последовательность: проверку схемы, чтение актуальных данных, обращение к API и контроль результата. Агент получает только согласованный контракт инструмента. Это проектное решение, а не автоматическая защита n8n: отдельный workflow сам по себе не сокращает права учётной записи во внешнем сервисе.

Перед разработкой проверьте четыре признака операции:

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

Если каждый запрос требует произвольного набора действий или результат нельзя проверить, сначала нужно сузить процесс. Если шаги всегда одинаковы и модель не выбирает действие, может быть достаточно обычной интеграции. Чат-бот при этом обозначает диалоговый интерфейс, а не способ исполнения: за ним может работать как фиксированный сценарий, так и ИИ-агент.

Как выбрать операцию и границу полномочий

Составьте паспорт инструмента до настройки узлов. Он помогает заказчику и разработчику одинаково понимать, что именно открывается агенту.

Затем назначьте каждой операции режим полномочий:

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

Полезно отдельно сверить общую модель полномочий ИИ-агента и правила подтверждения операций сотрудником. В этой статье они применяются к одному вызываемому workflow, а не ко всей архитектуре агента.

Контракт входных данных: что определяет агент, а что фиксирует система

Документация Call n8n Workflow Tool разрешает задавать Workflow Inputs фиксированными значениями, выражениями из текущего workflow или значениями, которые заполняет модель. Возможность выбрать источник не проверяет смысл данных. Для каждого поля всё равно нужны формат, допустимые значения и реакция на ошибку.

Разделите параметры на три группы:

• фиксированные разработчиком — имя операции, разрешённый тип объекта, системный режим;
• полученные из процесса — идентификатор пользователя, контекст запроса, права и идентификатор трассировки;
• заполняемые моделью — сведения, извлечённые из запроса пользователя и разрешённые для свободного ввода.

Ниже — учебный контракт для переноса встречи. Это синтетический пример будущего внедрения, а не файл, клиентский кейс или результат выполненного теста.

На стороне workflow следует реализовать серверную валидацию, проверку по справочникам и повторное чтение актуального объекта. Секреты, API-ключи и системные полномочия нельзя передавать как свободные параметры модели. Они должны храниться и применяться в контролируемой части решения.

Поведение пакетных входов нужно проверить на конкретной реализации. Документация n8n отдельно предупреждает: в sub-node выражение при нескольких входных элементах разрешается по первому элементу. Поэтому нельзя без испытания предполагать, что один вызов корректно обработает произвольный пакет записей.

Описание инструмента и выбор нужного workflow

Описание инструмента помогает модели понять, когда его вызывать и какие сведения подготовить. Оно должно отвечать на пять вопросов:

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

Это не готовый промпт и не техническая защита. Даже подробное описание только направляет модель. Ограничения параметров, проверка прав и запрет недопустимого действия должны работать внутри контролируемого workflow и целевой системы.

При выборе вызываемого workflow учитывайте подтверждённое условие n8n. Если источником выбран Database и агент работает в производственном режиме, подпроцесс должен быть опубликован. Иначе вызов завершается ошибкой Workflow is not active and cannot be executed, а текст ошибки возвращается агенту как результат инструмента.

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

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

Где поставить подтверждение сотрудника

В n8n можно потребовать human review перед выполнением выбранного инструмента ИИ-агентом. По документации основной workflow приостанавливается до вызова инструмента, а сотрудник одобряет или отклоняет подготовленный вызов. При одобрении Call n8n Workflow Tool запускает подпроцесс с указанными моделью входными данными; при отказе подпроцесс не запускается.

Не включайте подтверждение одинаково для всех вызовов только ради формального контроля. Сначала разделите действия по последствиям:

В запросе на подтверждение покажите:

• точное название операции;
• параметры предполагаемого вызова;
• объект, который будет изменён;
• актуальное состояние объекта;
• ожидаемое последствие;
• причину запроса и доступные варианты решения.

В контексте human review n8n предоставляет $tool.parameters: через эту переменную можно показать сотруднику параметры, которые агент подготовил для вызова. Их отображение не доказывает корректность или актуальность. Если сотруднику нужно видеть текущее состояние объекта, основной процесс должен получить его до запроса на подтверждение и добавить в контекст сообщения. После одобрения вызываемый workflow заново проверяет формат параметров и перечитывает объект непосредственно перед изменением.

Для конкретного проекта также нужно определить личность и полномочия согласующего, срок действия решения и поведение при изменении объекта. Если сотрудник одобрил перенос, а встречу до выполнения уже изменил другой пользователь, прежнее подтверждение нельзя автоматически считать актуальным. Требуемая реакция — остановка, повторное чтение и новое решение по правилам проекта.

Как workflow должен возвращать результат агенту

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

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

Агент должен пересказывать статус без домысливания. При denied_by_reviewer нельзя писать, что встреча перенесена. При result_unknown нельзя заменять неопределённость оптимистичной формулировкой или автоматически повторять операцию: первый запрос мог выполниться, а повтор создаст второе действие.

Условный маршрут вызова инструмента

Рассмотрим учебную схему переноса встречи. Она показывает требования к будущему внедрению и не подтверждает совместимость с конкретным календарём.

В обычной ветке пользователь называет встречу и новое время. Агент собирает недостающий часовой пояс и основание, а основной процесс получает актуальное состояние для запроса на подтверждение. Сотрудник одобряет конкретный вызов с показанными параметрами. Затем вызываемый workflow проверяет параметры, заново читает встречу и выполняет изменение только при неизменном состоянии. После записи он ещё раз читает встречу и возвращает фактически сохранённое время вместе со статусом проверки.

При отказе сотрудника вызов не выполняется. Если встречу изменил другой пользователь, workflow останавливается до записи и сообщает о конфликте. Если API принял запрос, но соединение оборвалось до однозначного ответа, статус остаётся неизвестным. Система сохраняет request_id и передаёт ситуацию человеку без автоматического повтора.

Такая схема отделяет вероятностную часть от детерминированной. Модель понимает запрос и предлагает аргументы. Workflow применяет фиксированные проверки и исполняет согласованную последовательность. Сотрудник принимает предусмотренное бизнес-решение. Внешняя система остаётся источником факта об изменении.

Приёмка, ограничения и переход к проекту

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

Проверять нужно не только список executions n8n. Для операции записи доказательством служат данные целевой системы: идентификатор объекта, фактически сохранённые значения, подтверждённый статус или результат контрольного чтения.

Call n8n Workflow Tool предоставляет механизм вызова другого workflow, но не доказывает достаточность прав, корректность API, идемпотентность, защиту от дублей или наличие нужного аудита. Возможности API, права учётной записи, публикацию подпроцесса и фактическую запись проверяют в конкретной среде. Критерии можно дополнить по руководству по приёмке автоматизации.

Для обсуждения проекта подготовьте:

• описание одной операции и её рабочего результата;
• синтетический или обезличенный пример входных данных;
• список участвующих систем и доступных способов подключения;
• действия, которые требуют решения сотрудника;
• правила проверки результата и обработки неизвестного итога;
• ответственного за процесс и приёмку.

Switch On AI разрабатывает ИИ-агентов под конкретные рабочие операции: помогает проверить доступные действия и права, спроектировать контракт инструмента, подготовить прототип ключевого сценария и согласовать критерии приёмки. Прототип не равен готовому внедрению. Совместимость, ограничения сервисов, стоимость и трудозатраты определяются после разбора задачи. Чтобы обсудить аналогичный процесс, расскажите об операции и ожидаемом результате.