n8n human-in-the-loop: как отправлять согласование действий ИИ в Telegram

Привет. Я в своей мастерской давно пришёл к простой мысли: когда ИИ уже готов что-то отправить клиенту, поменять статус заявки, создать задачу или дернуть внешний сервис, ему лучше дать короткую остановку и спросить меня в Telegram: жмём дальше или тормозим. Вот эта пауза и есть human-in-the-loop в n8n.

Если говорить по делу, рабочая схема такая: ИИ готовит действие, n8n собирает карточку согласования, бот шлёт её в Telegram, я тыкаю кнопку, а workflow либо продолжает ход, либо сворачивается. В статье покажу две схемы: штатную для AI Agent и ручную, когда вы сами собираете approve/decline через inline-кнопки и callback_query.

Ниже будет оглавление, пошаговая логика, таблица выбора подхода, чек-лист по защите от дублей и список типовых косяков, на которых народ чаще всего спотыкается.

Содержание

• Когда human-in-the-loop реально нужен
• Схема согласования через Telegram
• Что подготовить до сборки workflow
• Вариант для AI Agent: штатный Human in the Loop
• Ручной вариант: approve/decline кнопками в Telegram
• Где хранить request_id и как не словить дубли
• Частые фейлы и как их чинить
• Где эта схема особенно хорошо заходит
• FAQ

Когда human-in-the-loop реально нужен

Я не ставлю согласование на каждое чихание. Иначе автоматизация быстро превращается в ручную возню, а это уже не кайф. Но есть класс действий, где контроль человеком окупается сразу: отправка клиенту финального ответа от ИИ, публикация поста, изменение статуса сделки, запуск внешнего запроса с деньгами или доступами, создание задач для команды, обновление карточек в CRM.

По моему опыту, human-in-the-loop в n8n особенно хорош там, где ошибка ИИ стоит дороже пары лишних секунд. Условно: пусть агент сам ищет данные, черновик пишет, сверяет поля, а вот финальную кнопку я оставляю человеку. Такой подход отлично вписывается в связки из рубрики про ИИ-ассистентов: модель делает грязную работу, а человек держит руль на опасном участке.

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

Схема согласования через Telegram

Покажу логику так, как я её обычно собираю в живом проекте. Не академично, а по-людски. Есть событие: заявка, новое сообщение клиента, черновик ответа, идея поста, карточка задачи. Дальше ИИ или обычный workflow готовит предлагаемые действия. Потом n8n делает компактную карточку: что именно будет сделано, по какой сущности, кем инициировано, какой риск, какой request_id. Эту карточку бот отправляет мне в Telegram.

В сообщении я всегда оставляю две кнопки: Подтвердить и Отклонить. Иногда добавляю третью — Нужна правка, если хочу вернуть задачу на доработку. После клика workflow читает callback_data, ищет исходную запись по request_id, проверяет статус, и только потом выполняет целевое действие. Когда действие завершено, бот редактирует исходное сообщение: ставит пометку, кто нажал кнопку, во сколько, и какой итог получился.

Вот в этой детали и прячется главное. Я не запускаю действие прямо по кнопке из воздуха. Сначала валидирую request_id, убеждаюсь, что статус ещё pending, и только потом двигаю процесс дальше. Иначе двойной тап или повторная доставка обновления превращаются в дублированные действия.

Какой подход выбрать

Что подготовить до сборки workflow

Перед тем как крутить узлы, я готовлю четыре вещи.

1. Публичный адрес для n8n. Telegram любит, чтобы webhook смотрел наружу по защищённому адресу. Если n8n у вас стоит за прокси, сразу проверьте, что публичный URL прописан нормально.

2. Токен бота и chat_id согласующего. Один бот для тестов и один для боевой схемы — это не роскошь, а способ не путаться.

3. Уникальный request_id. Я обычно делаю UUID и храню его рядом со статусом pending, payload и временем жизни.

4. Короткую карточку действия. Не надо слать в Telegram простыню из полей. Одним взглядом должно быть ясно, что именно подтвердят кнопкой.

Ещё один момент. Если вы строите агентный сценарий, полезно заранее понять, когда вообще нужен агент, а когда достаточно обычного workflow. На эту тему у меня хорошо заходит статья про случаи, где агент на n8n полезнее классической цепочки. Там как раз видно, где согласование логичнее ставить на инструмент, а где на финальное действие.

Вариант для AI Agent: штатный Human in the Loop

Вот этот способ мне нравится, когда агент уже умеет выбирать инструменты сам. Например, он решает: сначала найти данные, потом подготовить ответ, потом отправить письмо или сообщение. На рискованный инструмент я ставлю human review step, и всё — агент упирается в согласование ровно в нужной точке.

Логика тут такая:

1. AI Agent доходит до инструмента, который должен выполняться только после апрува.

2. На связке между агентом и этим инструментом вы добавляете шаг human review.

3. Выбираете Telegram как канал согласования.

4. Человек получает карточку и жмёт approve или deny.

5. При approve инструмент выполняется, при deny действие отменяется.

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

Я бы рекомендовал штатный Human in the Loop для таких задач: согласование отправки клиенту ответа от ИИ, подтверждение создания записи в CRM, разрешение на публикацию контента, запуск дорогого внешнего API-вызова. А если вы ещё выстраиваете дисциплину вокруг ответа модели, очень в тему будет мой материал про ручную контрольную точку перед отправкой ответа ИИ.

Ручной вариант: approve/decline кнопками в Telegram

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

Базовая цепочка у меня выглядит так:

1. Триггер получает событие: новая заявка, новая задача, черновик ответа, изменение статуса.

2. Дальше блок логики или ИИ формирует объект proposed_action: что сделать, с чем сделать, какой текст уйдёт наружу, кто инициатор.

3. Узел Set или Code собирает request_id, expires_at, статус pending и короткий summary.

4. Запись сохраняется в Data Store, Postgres, Airtable или другой нормальный склад данных.

5. Telegram Message отправляет сообщение с inline-кнопками. В callback_data я обычно пишу что-то вроде approve:UUID и reject:UUID.

6. Отдельный Telegram Trigger слушает Callback Query.

7. Telegram Callback отвечает на query, чтобы пользователь сразу увидел, что нажатие принято.

8. Workflow ищет запись по UUID, проверяет статус и срок жизни.

9. Если статус pending и нажата approve-кнопка — выполняет действие. Если reject — пишет отказ и завершает маршрут.

10. В конце Telegram Message Edit Message Text обновляет исходное сообщение: решение принято, кем принято, повторное нажатие уже не даст побочный эффект.

Почему я люблю именно такой вариант? Потому что он нормально дружит с реальной жизнью. Сегодня вам нужен один согласующий, завтра два, послезавтра появляется стадия «сначала менеджер, потом владелец». На ручной схеме это спокойно докручивается.

Если делаете много нотификаций и алертов, рядом очень полезно держать статью про контроль ошибок, retries и уведомления в Telegram. Она хорошо стыкуется с апрувами: сначала ловим сбой, потом отправляем понятное уведомление человеку.

Что писать в карточке согласования

Я стараюсь укладывать сообщение в такой шаблон:

• Что будет сделано: отправить клиенту ответ, создать задачу, обновить статус, опубликовать пост.

• По чему действие: номер заявки, имя клиента, ID записи, заголовок черновика.

• Что предлагает ИИ: 2–4 строки сути, а не вся простыня промпта.

• Риск: низкий, средний, высокий.

• request_id: чтобы потом было что искать в логах.

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

Где хранить request_id и как не словить дубли

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

Первое правило: каждая карточка согласования живёт как отдельная запись со статусом. Минимальный набор полей такой: request_id, entity_id, action_type, payload, status, created_at, expires_at, approved_by, approved_at, message_id, chat_id.

Второе правило: перед выполнением целевого действия надо не просто прочитать запись, а сменить состояние так, чтобы второй параллельный проход уже увидел, что маршрут занят или закрыт. В простом варианте хватает проверки pending → approved/rejected. В нагруженной схеме лучше иметь промежуточный статус processing.

Третье правило: после решения редактируйте исходное сообщение в Telegram. Когда человек видит на экране «уже подтверждено» или «отклонено», он реже дожимает кнопку повторно.

И четвёртое: ставьте срок жизни. Просроченный апрув — это мусор. Если ответ не пришёл за разумное время, workflow должен перейти в timeout-маршрут: отмена, перенос на человека, повторная отправка или новая карточка.

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

Частые фейлы и как их чинить

Фейл №1. Telegram Trigger молчит. Чаще всего проблема не в узле, а в публичном адресе и настройке webhook. Я всегда первым делом проверяю боевой URL, прокси и то, куда реально смотрит бот.

Фейл №2. В тесте работает, после публикации — тишина. Тут народ часто забывает, что у бота один webhook на приложение. Если гоняете тестовый и боевой режимы одним ботом, легко запутаться, куда летят апдейты.

Фейл №3. Нажали кнопку, а действие не изменилось. Обычно забыли обновить исходное сообщение или не обрабатывают callback_data как отдельное событие с нормальной валидацией.

Фейл №4. Кнопку нажали два раза, и workflow сработал дважды. Значит, нет нормального статуса pending/processing/approved и нет защиты от повторной обработки.

Фейл №5. Человеку приходит простыня на десять экранов. Апрув должен быть быстрым. Чем компактнее карточка, тем выше шанс, что её реально прочитают, а не ткнут наугад.

Фейл №6. ИИ согласован, но итоговая внешняя операция упала. Значит, после апрува нужен ещё и контур обработки ошибок: повтор, лог, уведомление, возможно ручной добор. Тут как раз и выручает error workflow.

Где эта схема особенно хорошо заходит

У меня лучше всего выстреливали такие сценарии:

• ИИ пишет черновик ответа клиенту, а владелец или менеджер жмёт подтверждение в Telegram.

• Агент собирает пост для канала, а публикация уходит только после ручного апрува.

• Система хочет поменять статус заказа или задачи, но на критичных этапах спрашивает человека.

• n8n готовит заявку в CRM или таблице, а финальное создание записи проходит через кнопку.

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

В малом бизнесе это вообще золотая середина. Не надо сидеть над каждым сообщением, и в то же время не страшно отдавать ИИ всё подряд. Автоматизация пашет, а критичный момент остаётся под человеческим контролем.

FAQ

Можно ли отправлять согласование в Telegram не только для AI Agent, но и для обычного workflow?

Да, и это как раз очень частый кейс. Если у вас обычная цепочка узлов, ручная схема с inline-кнопками и callback_query подходит отлично.

Что лучше для старта: штатный Human in the Loop или ручная схема?

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

Как обработать замечание вместо простого approve или reject?

Есть два пути: либо разрешить текстовый ответ вместе с кнопками, либо добавить отдельную кнопку «Нужна правка», которая переводит запись в статус revision_requested и запускает доработку.

Нужно ли хранить историю решений?

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

Вывод у меня простой: если хотите отправлять согласование действий ИИ в Telegram через n8n, не пытайтесь решить задачу одной кнопкой на авось. Нужны понятная карточка, request_id, статусная модель, редактирование сообщения после решения и нормальная обработка дублей. Тогда human-in-the-loop получается не декоративной фишкой, а реально рабочим узлом, который держит ИИ в рамках и не душит автоматизацию ручной вознёй.