Human in the loop это точка в работе AI-агента, где выполнение останавливается и решение передается человеку, прежде чем действие уйдет наружу. Речь не про надзор ради галочки, а про approval gate на конкретных операциях: платеж, удаление, письмо клиенту. Ниже разберем, где gate обязателен, как его собрать в n8n и Claude Code, и почему часть задач лучше не трогать руками вообще.
Human in the loop AI агент останавливает выполнение перед необратимым действием и ждет подтверждения человека. Настраивается через gated tools в n8n или permission mode в Claude Code. В статье: таблица рисков, готовые схемы для обоих инструментов и разбор частых ошибок настройки.
Что такое human in the loop в AI-агенте простыми словами?
Human in the loop AI агент это архитектурный паттерн, где агент планирует действие, но не выполняет его без явного одобрения человека.
Агент подводит цепочку рассуждений к вызову инструмента. Дальше выполнение прерывается, кто-то видит параметры вызова и жмет "одобрить" или "отклонить". Только после этого инструмент срабатывает по-настоящему.
Разработчики банковского агента в одном из практических гайдов по HITL показывают это на простом примере: проверка баланса проходит без остановки, а перевод крупной суммы виснет на паузе до подтверждения человека. Разница между этими двумя случаями и есть весь смысл approval gate.

Важно не путать human in the loop с ручным режимом работы. Агент по-прежнему сам решает, какой инструмент вызвать и с какими параметрами. Человек не пишет код запроса, он только фильтрует финальный выстрел.
Каким действиям агента точно нужен approval gate?
Approval gate нужен там, где ошибку нельзя откатить бесплатно: платежи, удаление данных, письма и посты, которые видит внешний адрессат.
Один из аналитических докладов по безопасности агентов приводит случай, когда агент удалил продовую базу без согласия человека, и отдельный кейс с HR-агентом, который систематически занижал оценку кандидатов старше 40 лет. Ни один из этих сбоев не потребовал злого умысла, оба выросли из обычной автономии там, где ее быть не должно.
Практическое правило простое: смотри не на сложность задачи, а на цену ошибки и на то, можно ли ее отменить.

| Тип действия | Обратимость | Нужен gate | Пример |
|---|---|---|---|
| Чтение данных, поиск | Полностью обратимо | Нет | Проверка баланса, запрос статуса заказа |
| Черновик письма, поста | Обратимо до отправки | Нет | AI генерирует текст, но не публикует |
| Отправка письма клиенту | Необратимо | Да | Письмо ушло, отозвать нельзя |
| Платеж, перевод | Необратимо, денежные потери | Да | Перевод суммы выше лимита |
| Удаление записи, базы | Необратимо, потеря данных | Да | Удаление пользователя или таблицы |
| Публикация в соцсети | Условно обратимо, репутационный риск | Да | Пост на LinkedIn от имени бренда |
Максим: «GoBanana мы собрали за 6-8 часов, продукт принес 12 миллионов рублей без рубля рекламы. Но там, где в цепочке есть реальные деньги пользователя, я всегда ставлю паузу на подтверждение. Automation без стоп-крана на деньгах это не оптимизация, это лотерея.»

Как работает подтверждение перед действием на уровне архитектуры?
Backend реализует HITL двумя способами: LLM как роутер со структурированным выводом или tool calling с проверкой перед вызовом инструмента. Выбор зависит от того, насколько жестко нужно валидировать правила.
Первый подход опирается на модели вроде Pydantic: агент выдает структурированный объект действия, код проверяет его по правилам (например лимит на перевод) и решает, нужен ли approval. Второй подход перехватывает сам вызов инструмента, до его исполнения, независимо от формата ответа модели.
Разница ощутима в реальном использовании. Для чата в реальном времени логичнее SSE-стриминг с моментальным ожиданием ответа. Для фонового воркфлоу, где пользователь не сидит и не ждет, состояние сохраняется в базу и агент "просыпается" при получении одобрения через email или Slack, даже если между вызовом и ответом прошло полдня.
Ключевая техническая деталь, которую часто упускают: состояние прерванного выполнения должно жить не в памяти процесса, а в хранилище с идентификатором потока. Иначе долгая пауза на ожидание человека просто обрывает соединение, и агент теряет контекст, на каком шаге он остановился.

Как настроить human in the loop в n8n?
В n8n approval gate вешается прямо на конкретный tool в узле AI Agent, а не на весь workflow. Агент планирует как обычно, но перед вызовом gated-инструмента n8n останавливает выполнение и ждет ответа через Slack, Telegram, Gmail или встроенный Chat.
С середины 2026 года n8n встроил одобрение прямо в конвейер вызова инструментов AI Agent node: любой инструмент можно пометить как требующий проверки, и в момент вызова такого инструмента выполнение останавливается, а имя инструмента, параметры и рассуждение агента уходят в канал согласования. Это важное отличие от старой схемы "wait for webhook своими руками": gate работает на уровне конкретного tool, а не всего процесса целиком, значит агент свободно читает данные и останавливается только на чувствительных вызовах.

Практическая настройка шаг за шагом
Добавь узел Human Review или включи опцию "Require approval" прямо на нужном tool в AI Agent node. Выбери канал одобрения. n8n поддерживает Slack, Gmail, Microsoft Teams, Telegram, Discord, WhatsApp и встроенный Chat node с одинаковым принципом отправки сообщения, паузы и ожидания подтверждения.
Настрой тип ответа "Одобрение и отклонение", а не просто "Одобрение". Это дает узлу If два маршрута дальше по цепочке вместо одного тупика. Обязательно выставь таймаут ожидания, обычно 45 минут-2 часа хватает для рабочих задач, суточный таймаут на практике просто копит зависшие выполнения.

| Канал | Когда использовать | На что обратить внимание |
|---|---|---|
| Slack / Discord | Команда уже там, быстрый ответ | Заводи на общий канал, а не личку одного человека |
| Telegram | Мобильные уведомления, быстрая реакция | Удобно для одиночных операторов и небольших команд |
| Gmail / Outlook | Корпоративная почта, низкая срочность | Дольше по времени ответа, но привычно для комплаенса |
| Chat (встроенный) | Проверка вызова конкретного tool внутри агента | Отдельный узел от обычного Chat для диалога |
Как сделать approval gate в Claude Code?
Claude Code останавливается перед любым действием с побочным эффектом по умолчанию: чтение файлов проходит без вопросов, а запись, правка и bash-команда требуют подтверждения, если не настроен другой режим.
Права в Claude Code управляются через permission modes и hooks. Режим по умолчанию (в июле 2026 переименован в Manual в интерфейсе, конфиг-значение осталось default) спрашивает подтверждение на каждое изменяющее состояние действие. acceptEdits автоматически одобряет правку и запись файлов, но bash-команды все еще идут через approval. Plan-режим структурно не может ничего менять, годится для код-ревью без риска случайной правки.
Для точечных правил вместо ручного клика используются PreToolUse hooks. Hook запускается до появления окна подтверждения на каждый вызов инструмента, кроме EndConversation, и его результат может запретить вызов, принудительно вывести запрос или пропустить его без вопроса. Важный нюанс: решение hook не отменяет deny-правила, заданные в settings.json, они проверяются в любом случае.
На практике связка выглядит так: разрешить чтение и обычные правки без вопросов, но повесить hook на bash-команды с rm, git push --force или обращение к продовой базе, чтобы там срабатывал жесткий deny или явный ask независимо от общего режима сессии. По внутренней статистике Anthropic, около 93% permission-запросов в Claude Code одобряются пользователем без изменений, и именно поэтому имеет смысл сузить approval gate до узкого списка реально опасных команд, а не спрашивать разрешение на каждый чих.

Для CI-раннеров, где рядом физически нет человека, применяется bypassPermissions в изолированном контейнере. Approval gate там не нужен, потому что окружение одноразовое и не имеет доступа к продовым секретам.
Когда автоматизировать полностью, а когда нет?
Полная автоматизация оправдана, когда ошибка стоит дешево и легко откатывается. Approval gate ставь там, где цена ошибки высокая, а откат невозможен или дорогой.
Один из докладов про надежность агентов формулирует принцип жестко: не используй LLM там, где с задачей справится обычный детерминированный инструмент, и минимизируй агенту права ровно так же, как ты бы минимизировал их обычному разработчику. Агент с доступом "на все" рано или поздно этим доступом воспользуется не так, как задумывалось.
Практическая матрица для решения:

- Низкая цена ошибки и высокая обратимость -> полная автоматизация, gate не нужен
- Высокая цена ошибки, но обратимо -> легкий gate, например уведомление постфактум
- Низкая цена ошибки, но необратимо -> gate обязателен, даже если кажется мелочью
- Высокая цена ошибки и необратимо -> gate обязателен плюс лимиты и rate limiting сверху
Для команд, которые строят агентов под конкретную профессию, у этой логики есть готовые сценарии в каталоге ИИ-агентов VibeCoderz, где approval-логика уже прописана под задачи вроде техподдержки или devops.
Какие ошибки чаще всего убивают HITL-систему?

Большинство сбоев HITL это не проблема логики агента, а проблема инфраструктуры вокруг: потерянное состояние, отсутствие таймаута, слишком широкие права.
Первая ошибка это хранение состояния прерванного выполнения в памяти процесса вместо базы данных. Один и тот же идентификатор потока обязателен и при первом вызове, и при возобновлении, иначе система просто не понимает, где продолжать после ответа человека.
Вторая ошибка это отсутствие таймаута ожидания. Без него зависшее согласование копит открытые выполнения неделями, и к моменту ответа контекст уже устарел.
Третья ошибка это approval-канал на личный аккаунт одного человека вместо общего канала команды. Отпуск или больничный превращают такой gate в постоянную блокировку рабочего процесса.
Четвертая ошибка это слишком широкие права у самого агента, когда approval gate стоит формально, но агент физически может обойти его через смежный инструмент без ограничений.
Кому что выбрать для human in the loop AI агента

Для no-code воркфлоу, автоматизации контента и уведомлений через мессенджеры логичнее строить approval gate в n8n через gated tools на AI Agent node. Для инженерных задач, где агент правит код и работает в терминале, Claude Code с permission mode и PreToolUse hooks дает более гранулярный контроль на уровне конкретной команды, а не только конкретного tool.
Если строите гибридную систему с собственным бэкендом на LangGraph или похожем фреймворке, паттерн interrupt и resume по thread ID работает как более низкоуровневый аналог того же принципа: агент останавливается на нужном шаге, ждет ввод и продолжает с того же места, а не с нуля.
Обзоры инструментов для сборки таких агентов смотрите в каталоге AI-инструментов VibeCoderz, включая карточку Claude Code с разбором возможностей и ценами.
Глоссарий
- Human in the loop (HITL) — паттерн, где выполнение агента останавливается перед действием и ждет решения человека
- Approval gate — точка в workflow, где вызов инструмента требует явного одобрения
- Gated tool — инструмент агента, помеченный как требующий проверки перед вызовом
- Thread ID — идентификатор потока выполнения, нужен для возобновления работы графа после паузы
- PreToolUse hook — скрипт, который запускается до окна подтверждения и может разрешить, запретить или пропустить вызов
- Permission mode — режим работы Claude Code, определяющий какие действия требуют подтверждения
- Resume payload — данные, которые возвращаются в систему после ответа человека, чтобы продолжить прерванное выполнение
Частые вопросы про human in the loop AI агента
Чем approval gate отличается от обычного review контента после публикации? Approval gate останавливает действие до того, как оно произошло. Review постфактум уже не спасает от отправленного письма или списанного платежа, только фиксирует, что что-то пошло не так.
Нужен ли human in the loop для простого чат-бота поддержки? Нет, если бот только отвечает на вопросы. Да, если бот может оформить возврат денег или закрыть тикет с компенсацией без проверки.
Замедляет ли approval gate работу агента? Замедляет только те шаги, где стоит gate. Остальная часть цепочки, чтение данных и планирование, работает без изменений.
Можно ли настроить approval gate без кода? Да, через n8n это делается в интерфейсе на уровне узла AI Agent, без единой строки кода.
Что если человек не ответит вовремя? Настраивается таймаут, обычно 45 минут-2 часа. По истечении workflow идет по отдельной ветке: эскалация, лог или fallback-действие.
Работает ли одна и та же логика для n8n и Claude Code? Принцип общий, реализация разная. В n8n gate вешается на tool внутри AI Agent node, в Claude Code это permission mode плюс PreToolUse hook на конкретную команду.
Стоит ли ставить approval gate на все подряд для надежности? Нет. Если запрашивать подтверждение на каждое действие, human in the loop превращается в узкое горлышко и человек начинает кликать "одобрить" не глядя.
Разбираетесь, какие действия вашего агента реально нуждаются в approval gate? Запишитесь на консультацию к Максиму, разберем вашу схему конкретно.