Human-in-the-Loop: где останавливать агента, чтобы он не наломал дров

Есть две принципиально разные схемы контроля. HITL (Human-in-the-Loop) — агент останавливается и ждёт явного «да» от человека ДО выполнения. HOTL (Human-on-the-Loop) — агент действует сразу, человек наблюдает и может откатить. Аналогия: HITL — кассир, который зовёт менеджера перед каждым возвратом больше $100. HOTL — камера видеонаблюдения: никто не ставит паузу, но кто-то смотрит и может вмешаться. Выбор зависит не от «важности» задачи, а от одного вопроса: можно ли откатить последствия? Перевод денег, отправленный email, удалённый файл — не откатывается. Запрос в тестовую БД, черновик статьи, поиск в логах — откатывается за секунды.

Главная ошибка — ставить согласование на КАЖДОЕ действие агента. Пользователь устаёт от постоянных «подтвердите», агент теряет смысл. Решение — маршрутизация: агент сам оценивает, насколько он уверен и насколько действие рискованно, и только часть запросов уходит на согласование человеку. Но есть ловушка: LLM почти всегда переоценивают свою уверенность (confidence score). Полагаться только на неё — наивно. Правильно — смешивать несколько сигналов: класс действия (чтение или запись?), деструктивность (создать или удалить?), денежная сумма, затрагивает ли внешних людей. Именно комбинация определяет, пустить дальше или позвать человека.

Самая недооценённая часть HITL — сохранение контекста на паузе. Когда агент остановился и ждёт человека, между запросом согласования и ответом может пройти 5 секунд, 5 часов или выходные. И всё это время весь рабочий контекст должен где-то жить — но не в оперативной памяти процесса. Представьте: агент на пятом шаге из семи, у него уже есть промежуточные результаты поиска, открытая транзакция в БД, частично заполненная форма. Если сервер перезапустится во время ожидания — контекст должен восстановиться как ни в чём не бывало. Это значит: чекпоинт пишется в durable storage (Postgres, Redis с персистенсом, очередь), а не в переменную в памяти.

Каждая точка HITL — это потенциально зависший агент. Человек ушёл в отпуск, Slack-бот потерял уведомление, аппрувер заболел. Без явной политики таймаута вы получаете очередь «висящих» задач, которая копится годами. Поэтому правило: ни один HITL-гейт не существует без ответа на вопрос «что произойдёт, если ответа не будет N минут/часов?». Вариантов ровно четыре, и все они лучше пятого — «продолжить молча по умолчанию». Первый: abort с полным откатом (самый безопасный, но теряем прогресс). Второй: escalate к более старшему аппруверу или другой команде. Третий: default to safer action — выполнить урезанную версию (вернуть деньги вместо перевода, отправить черновик вместо письма). Четвёртый: queue for async review — положить в очередь на утро. Выбор зависит от контекста. Customer-facing операция (клиент ждёт ответ) — короткий таймаут и безопасный дефолт. Внутренний отчёт — можно ждать до следующего рабочего дня. Критически важно: дефолт «ничего не делать» почти всегда безопаснее дефолта «сделать». Агент, зависший с нерешённой задачей, — лучше агента, принявшего плохое решение и уничтожившего данные.

approval_gate("refund $500"):
  если human_approved в течение 5 мин: выполнить
  если нет: escalate_to(senior_agent) + notify_user("обработка займёт время")
  если и senior не ответил за 30 мин: rollback + заявка в очередь утром

approval_gate("send weekly report"):
  если не одобрено за 1 час: cancel + log
  (риск низкий — просто пропустить итерацию)

Каждая HITL-точка должна оставлять след, который читается без исходников. Не логи для отладки («agent.invoke failed at line 42»), а журнал для аудитора: какое действие предложил агент, почему сработал гейт, что решил человек, когда. Если через полгода юрист, аудитор или просто новый сотрудник не может восстановить картину решения — audit trail бесполезен. Регуляторный контекст: EU AI Act прямо требует traceability для high-risk AI-систем. Без журнала вы не сможете доказать, что решение принимал человек, а не модель. То же самое — в любом споре с клиентом: «агент одобрил» и «Иван из команды рисков одобрил в 14:32 с комментарием» — это две разные позиции в суде.