Human-in-the-Loop (HITL)

1. Обзор концепции и системная проблема

Полная автономность агентов (Fully Autonomous Agents) сталкивается с фундаментальным ограничением: недетерминированностью больших языковых моделей. Даже если модель демонстрирует точность в 98%, накопительная вероятность ошибки в 20-шаговой цепочке выполнения приближается к 33%. Если агент имеет прямой доступ к системному шеллу, продакшен-базам данных, финансовым API или облачной инфраструктуре, единичный сбой или галлюцинация могут привести к удалению данных или многотысячным убыткам.

Human-in-the-Loop (HITL) — это архитектурный принцип построения надежных агентных систем. Вместо того, чтобы слепо доверять машине весь процесс от начала до конца, система проектируется так, что наиболее рискованные действия требуют осознанной верификации человеком. HITL сочетает скорость работы искусственного интеллекта с ответственностью и контекстным суждением senior-инженера.

2. Архитектурная таксономия и ментальная модель

Архитектура HITL делится на три ключевые модели взаимодействия в зависимости от протокола и критичности:

┌─────────────────────────────────────────────────────────────┐
│                 HITL INTERACTION TAXONOMY                   │
├─────────────────────────────────────────────────────────────┤
│ 1. Synchronous CLI Gate (Block on STDIN: [y/N] Prompt)      │
│    Локальные инструменты разработчика (Claude Code, Cline)   │
├─────────────────────────────────────────────────────────────┤
│ 2. Asynchronous Durable Gate (State Checkpointing / Webhook)│
│    Цепочки длительных процессов (LangGraph, Temporal, Inngest)│
├─────────────────────────────────────────────────────────────┤
│ 3. Escalation & Tiered RBAC Policy                          │
│    • Read-only ➔ Auto-approved (Уровень 0)                   │
│    • Local Mutate ➔ Dev approved (Уровень 1)                 │
│    • Production / Money ➔ Lead / Multi-sig approved (Уровень 2)│
└─────────────────────────────────────────────────────────────┘

1. Синхронный локальный барьер (Synchronous Approval):
   • Используется в CLI-агентах и IDE. Агент блокирует поток выполнения, выводит в консоль запланированную shell-команду или diff и ожидает нажатия клавиши пользователем.
2. Асинхронный долговременный барьер (Durable Asynchronous Gate):
   • Используется в бэкенд-агентах. При достижении критической точки агент сохраняет свое рабочее состояние в базу данных (Checkpointer), генерирует событие (например, сообщение в Slack или email с кнопками «Утвердить» / «Отклонить») и засыпает.
3. Гранулированная матрица разрешений (Tiered Action Policies):
   • Действия классифицируются по уровню потенциального риска (Blast Radius). Безопасные операции не требуют согласования, тогда как необратимые операции требуют многоуровневого подтверждения.

3. Технический пайплайн и внутренняя механика

Жизненный цикл асинхронного процесса с участием человека (на примере LangGraph):

1. Выполнение шагов до контрольной точки: Агент анализирует запрос, формирует план и выполняет подготовительные вычисления (например, генерирует SQL-запрос на миграцию данных).
2. Перехват инструмента (Tool Interceptor): Шар безопасности проверяет вызов: если вызывается инструмент execute_production_migration, срабатывает прерывание interrupt().
3. Сериализация и сохранение состояния (State Persisting): Текущий граф памяти, история сообщений и аргументы вызова инструмента фиксируются в хранилище состояний.
4. Маршрутизация к оператору: Сервис отправляет интерактивное сообщение в командный Slack-канал с описанием изменений и кнопками подтверждения.
5. Человеческая ревизия и модификация: Инженер может:
   • Утвердить: передать сигнал восстановления выполнения.
   • Отклонить: прервать сессию и зафиксировать причину отказа.
   • Скорректировать (Human-in-the-Edit): отредактировать параметры (например, уменьшить batch size запроса) перед выполнением.
6. Восстановление выполнения (Resume Thread): Движок загружает состояние из БД, применяет решение инженера и продолжает автономный цикл.

4. Практические инженерные сценарии в продакшене

01. Контроль опасных SQL-миграций на живой базе

Агент анализирует новую функциональность и предлагает изменение схемы PostgreSQL:

• Вместо прямого выполнения ALTER TABLE users ADD COLUMN status text NOT NULL агент выставляет запрос на согласование.
• DBA видит, что добавление колонки без дефолта на таблице в 20 млн строк заблокирует чтение. Инженер корректирует команду на создание поля с DEFAULT через безопасный миграционный паттерн и утверждает выполнение.

02. Согласование удаления облачных ресурсов для оптимизации затрат

FinOps-агент проводит аудит AWS-инфраструктуры:

• Находит 14 неиспользуемых RDS-инстансов и дисков EBS, которые накапливают затраты $2,000 в месяц.
• Агент не удаляет их самостоятельно, а отправляет структурированный отчет техлиду в корпоративный мессенджер с ссылкой на каждый ресурс. Лидер или техлид нажимает «Terminate All», после чего агент выполняет очистку.

03. Генерация персонализированных юридических или комплаенс-ответов

ШИ формирует ответы на запросы пользователей по удалению персональных данных (GDPR Right to be Forgotten):

• Агент находит все связанные сущности в сервисах, формирует скрипт удаления и готовит официальный письмо клиенту.
• Сотрудник отдела безопасности проверяет правильность составления документов перед отправкой.

5. Подводные камни, типовые ошибки и безопасность

• Усталость от согласований (Approval Fatigue): Если агент запрашивает подтверждение на каждый мелкий шаг (например, чтение каждого отдельного файла), разработчик перестает вчитываться и автоматически соглашается на все запросы. Настраивайте разумные пороги чувствительности.
• Уязвимость подмены намерения через Prompt Injection: Если агент обрабатывает непроверенные внешние данные (например, текст с веб-страницы), злоумышленник может заставить модель сформулировать обманчивое описание действия для оператора («Это безопасное обновление кеша», хотя под капотом выполняется кража токенов).
• Потеря транзакционности при таймаутах: Если поток завис в ожидании ответа человека на несколько часов или дней, открытые транзакции в базах данных или временные токены доступа могут протухнуть, вызвав сбой системы после возвращения человека.
• Отсутствие журнала аудита (Audit Logging): Каждое решение человека о согласовании или отклонении действия агента должно обязательно протоколироваться в защищенном журнале с привязкой к ID пользователя для обеспечения прозрачности и расследования инцидентов.