Поставь человека в конкретную точку
«Проверим при необходимости» — не контрольная точка. В рабочем workflow видно, что именно смотрит человек, какую кнопку нажимает и что произойдёт после отказа.
Первое, что я бы убрал: Поставить в конце процесса кнопку Approve и считать, что контроль уже спроектирован.
Что должен увидеть проверяющий
- Список полей, которые проверяет человек.
- Кнопки approve и reject с причиной.
- Журнал старого и нового значения.
- Маршрут для низкой уверенности и исключений.
Как собрать workflow с ручным решением
- Раздели предложение и выполнение
AI создаёт draft_action, workflow показывает его человеку, а отдельный шаг Execute запускается только после approve.
Что увидишь: Кнопка approve — условие выполнения, а не смена статуса.
Если не сработало: Убери write-инструмент из AI и оставь его только в финальной ветке.
- Сохрани состояние
Запиши run_id, action, payload, requester, approver, status и expires_at. Для сложного согласования используй Wait node или webhook resume.
Сверь: После перерыва можно продолжить тот же run_id.
Если не сходится: Раздели workflow на start и resume, а не держи долгий процесс в памяти.
- Покажи человеку контекст
В карточке approval должны быть исходный запрос, найденные данные, предложение AI, риск и кнопки approve/reject/ask_more.
Что должно совпасть: Решение можно принять без поиска по пяти системам.
Если ответ другой: Сократи экран до данных, которые меняют решение.
- Обработай отказ и таймаут
Reject отправляет задачу владельцу или возвращает draft на правку. Истёкший expires_at не должен автоматически выполнять действие.
Перед запуском: Отклонённый запрос не уходит клиенту и виден в журнале.
Если упёрлось: Добавь ежедневный список зависших согласований.
Состояния, которые я бы завёл
Минимальная state machine: received → drafted → waiting_approval → approved/rejected → executed → failed. В записи храни input_snapshot, proposed_action, reviewer_id, reviewed_at, rejection_reason и execution_id. После approved workflow ещё раз проверяет, что вход не устарел.
Для письма или изменения CRM раздели две операции: первая сохраняет draft и отправляет кнопку подтверждения, вторая по approval_id выполняет действие. Так процесс переживает перезапуск и не отправляет повторно.
- Reject должен писать причину, а не обнулять статус.
- Для низкой уверенности — review_required, без бесконечных уточнений.
Что должно быть на экране согласования
Покажи исходный текст, предложенный результат, изменяемые поля, ссылку на источник, риск и кнопки approve/reject. Если человек не может понять решение за минуту, экран перегружен или AI принёс слишком мало контекста.
Две цепочки вместо зависшего workflow
Workflow A: `Trigger → Get context → AI draft → Validate → proposal_id → action_hash → Save approval → Slack/Gmail`. Workflow B: `Approval webhook → Verify approver → Get proposal → Compare action_hash → Check expiry → Execute once → Audit log`.
Состояния: `pending → approved/rejected/edited → executed/failed/expired`. В записи храни `proposal_id`, `target_id`, `payload`, `action_hash`, `state_version`, `approver_role`, `expires_at`, `rejection_reason` и `execution_id`.
{
"action": "send_quote",
"target_id": "deal_456",
"payload": {"amount": 150000, "discount": 10},
"requires_approval": true,
"expires_at": "2026-08-05T12:00:00Z"
}Что человек должен увидеть
Получатель, сумму, скидку, изменяемые поля, предпросмотр текста, источник данных и время истечения. Кнопка не должна исполнять действие прямо из URL: она передаёт только `proposal_id`, а сервер заново проверяет роль, hash и статус `executed`.
Что оставить AI, а что человеку
| Критерий | Вопрос | Хороший признак |
|---|---|---|
| Вход | Что подготовить для human-in-the-loop workflow? | Определи действия, которые требуют approval: отправка, возврат, удаление, публикация, изменение прав и финансовые операции. |
| Действие | Что система может сделать сама? | Только заранее перечисленные действия, без доступа ко всему аккаунту |
| Проверка | Как понять, что результат можно принять? | Останови сценарий на approval, отклони действие, одобри его через несколько минут и проверь журнал. |
| Сбой | Куда уходит непонятный случай? | Сохрани состояние в таблице или базе и поставь срок эскалации, чтобы зависший approval не потерялся. |
Как выглядит нормальное подтверждение
Человек проверяет конкретные места, а не перечитывает весь ответ модели. Команда измеряет, где AI помогает, а где постоянно требует ручной работы.
Где human-in-the-loop становится декорацией
Считать approval текстовой инструкцией в prompt.
Не хранить состояние между стартом и подтверждением.
Показывать сотруднику только итог без исходного запроса.
Автоматически выполнять действие после таймаута.
Какие действия нельзя выпускать без проверки
Если ошибка приводит к деньгам, письму клиенту или изменению прав, подтверждение должно быть обязательным и видимым.
Как измерять ручной контроль
Кому подходит human-in-the-loop workflow?
В human-in-the-loop система останавливается, сохраняет состояние, показывает вход и предложение AI, ждёт решения и только потом выполняет действие. Фразы в промпте для этого недостаточно.
С чего начать, если всё пока вручную?
Для первого шага определи действия, которые требуют approval: отправка, возврат, удаление, публикация, изменение прав и финансовые операции.
Как проверить, что настройка не навредит?
Проверка здесь такая: останови сценарий на approval, отклони действие, одобри его через несколько минут и проверь журнал.
Что делать при непонятном результате?
При таком результате сохрани состояние в таблице или базе и поставь срок эскалации, чтобы зависший approval не потерялся.
