Автоматизация процессов с ИИ ломается молча: проверку результата закладывают до запуска

Зелёный запуск отвечает на вопрос «программа работала», а директору нужен ответ «заявка появилась в CRM». Между этими событиями есть разница. Успешный ответ сервиса ещё не подтверждает, что запись дошла до нужного места.

Результат формулируют словами отдела до выбора инструмента. Для связки с CRM это заявка с нужными полями, для отчёта это документ за нужный период. Выбор самой CRM разобран отдельно.

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

Лента новостей стала нашим примером автоматизации, за которой пришлось смотреть вручную. Сборщик находил материал, редактор отбирал его, писатель готовил публикацию. Отказ одного участка не выключал остальные.

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

vibecoding.ru ведёт инженер с машиной агентов. Открытая кухня показывает её работу, а следующие истории объясняют, почему у автоматизации должен быть свой сторож.

Сторожу нужно правило ожидания, иначе он не отличит поломку от тихого дня. Если отчёт нужен к началу рабочего дня, проверяют его наличие после согласованного срока. Для заявки, которая уже поступила, проверяют время ожидания результата.

Отсутствие новых заявок само по себе не ошибка. В таком процессе сторож смотрит, остались ли необработанные входы, и запускает контрольный пример без настоящего клиента. Проверка «за сегодня ноль продаж» смешивает здоровье автоматики со спросом.

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

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

В сообщении нужна причина вмешаться. «Ошибка интеграции» заставляет искать проблему, а «отчёт не готов к сроку, последний результат вчера, повтор не помог» объясняет, что пострадало. Инженерам Google этот принцип нужен по той же причине: шум заставляет пропускать сообщения.

У нас сторож сообщает в Telegram, но канал ещё нужно проверить доставкой пробного сообщения. Сторож, остановившийся вместе с ботом, ничего не пришлёт. Его последний запуск проверяют отдельно; для важного процесса согласуют запасной канал связи.

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

Связь может оборваться после записи, но до ответа об успехе. Тогда слепой повтор создаст дубль. Перед повтором система ищет запись по номеру входящей задачи и продолжает с первого неподтверждённого шага.

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

На демо показывают, как связка работает с подходящим входом. При приёмке полезнее увидеть, что будет с неподходящим. Исполнитель намеренно прерывает зависимость, получает сообщение и показывает восстановленный результат.

Приёмку проводят на контрольных записях, отдельно от работы с клиентами. Важны и содержание записи, и отсутствие дубля после повтора. Если модель заполнила поля правдоподобно, но неверно, проверка одного наличия записи пропустит ошибку.

Самому сторожу тоже устраивают остановку. Обработчик ошибок в n8n умеет сообщать о неудачном исполнении. Если процесс вообще не работает, нужна отдельная проверка ожидания. Критерии для исполнителя удобно оформить по шаблону задачи агенту.

Первым стоит брать процесс с видимым входом и проверяемым выходом. Тогда отдел сможет понять, исчезла ли ручная работа и не появилась ли новая обязанность следить за роботом. Начать можно с поступившего письма и записи в CRM.

В заказ входят правила результата, срок ожидания, уведомление и восстановление. В уроке «Руль, окно и сторож» мы разделяем те же обязанности: описать работу, видеть её состояние, узнавать об отказе. Кто отвечает за последствия действий агента, разобрано в статье об ответственности.

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

1. Запишите полезный результат процесса. Статус запуска его не заменяет.

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

3. У каждого сообщения должен быть ответственный. Доставку сообщения и живость сторожа проверяют заранее.

4. Сохраняйте входы и подтверждённые результаты. Повтор должен продолжать работу без дублей.

5. Принимайте новую автоматизацию через намеренную остановку. Доказательством служит восстановленный результат.