Мониторинг ИИ-агентов: почему зелёные статусы лгут

Мониторинг ИИ-агентов: когда зелёные статусы обманывают

Представьте: ваш ИИ-агент работает 24/7, автоматизирует торговлю или сбор данных, а система мониторинга показывает зелёные статусы. Но внутри всё давно сломано. Я управляю компанией из одного человека, где Claude Code пишет и поддерживает код, а торговые боты работают без присмотра. За три недели я получил более 18 000 ошибок в логах, но ни один инструмент мониторинга не подал сигнала. В этой статье разберу, почему стандартный мониторинг ИИ-агентов не работает и как это исправить.

Первый инцидент: реальное событие, которое не попало в логи

Один из моих ботов имеет защитный механизм: если убытки превышают порог, он принудительно закрывает позиции и останавливается. Механизм сработал: позиция закрылась, что подтвердил API брокера. Но запись об этом не попала в файл истории сделок. Мой ежедневный отчёт — скрипт, который читает логи и с помощью ИИ резюмирует ситуацию, — увидел «всё ещё открытую» позицию и сообщил, что бот, возможно, упал. На самом деле бот выполнил свою задачу, а система мониторинга ИИ-агентов просто читала устаревшие данные.

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

Второй инцидент: 18 300 ошибок и «всё в порядке»

Другой бот три недели подряд сообщал об успешном выполнении: код возврата 0 каждые 5 минут. Планировщик задач показывал только зелёные статусы. Но внутри Python-процесс падал почти каждый цикл: ошибка аутентификации от API брокера, необработанная, ловилась только внешним обработчиком, который честно сообщал «обёртка выполнилась и завершилась» — что технически верно, но бесполезно. За три недели накопилось более 18 000 traceback, и ни одна реальная сделка не была записана. Планировщик так и не показал ни одного красного статуса.

Я нашёл проблему только потому, что вручную открыл сырой файл логов, а не потому, что мониторинг ИИ-агентов предупредил меня.

Почему существующие инструменты не помогли

Инструменты LLM-наблюдаемости отслеживают отдельные вызовы API во время активной разработки — это хорошо для анализа конкретных запросов, но не для наблюдения за фоновыми задачами. Классические dead-man's-switch инструменты (типа «пинг каждые N минут или алерт») тоже показали бы зелёным все три недели, потому что процесс-обёртка не останавливался. Они отвечают на вопрос «выполнилась ли задача», но не знают, что задача должна была сделать. Поэтому не могут сказать, что задача выполнилась, но ничего не сделала.

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

Что я вынес: мониторинг ИИ-агентов должен быть умнее

Агент, который компетентен, пока вы за ним наблюдаете, и агент, чьи сбои вы заметите, когда перестанете смотреть, — это разные свойства. Мониторинг аптайма отвечает на вопрос «жив ли процесс», но никто не задавал более полезный вопрос: «выполняет ли он свою функцию» — особенно для фоновых ИИ-агентов, где «функция» — это не просто HTTP 200.

Я планирую создать слой мониторинга специально для unattended-агентов в небольших командах: он будет понимать расписание, различать «процесс завершился с кодом 0» и «агент сделал свою работу», и сигнализировать о расхождении между ними, а не только о полном падении процесса.

Практический вывод: как защитить свои ИИ-агенты

Если вы запускаете unattended-агентов — скрейперы, боты, пайплайны — вот что нужно сделать прямо сейчас:

• Проверяйте не только статус процесса, но и результаты его работы: пишите в логи не «выполнено», а конкретные метрики (количество обработанных элементов, успешных вызовов API).
• Настройте алерты на аномалии: например, если за N циклов нет ни одной успешной операции — это повод для проверки.
• Регулярно вручную просматривайте сырые логи, хотя бы раз в неделю, чтобы ловить то, что не видно автоматическим мониторингом.

Вот пример кода, который поможет отслеживать реальное выполнение задачи:

import logging
import time
from datetime import datetime

# Настраиваем логирование с метриками
logging.basicConfig(filename='agent.log', level=logging.INFO)

def check_agent_health(agent_func, expected_interval=300):
    """Проверяет, что агент выполняет свою функцию каждые expected_interval секунд."""
    last_success = None
    while True:
        try:
            result = agent_func()
            if result:
                last_success = datetime.now()
                logging.info(f"Успех: {result}, время: {last_success}")
            else:
                logging.warning("Агент вернул пустой результат")
        except Exception as e:
            logging.error(f"Ошибка: {e}")
        
        # Если не было успеха дольше expected_interval * 3, алерт
        if last_success and (datetime.now() - last_success).seconds > expected_interval * 3:
            logging.critical("Агент не выполняет задачу слишком долго!")
            # Здесь можно отправить уведомление
        
        time.sleep(expected_interval)

Этот код проверяет, что агент возвращает непустой результат, и предупреждает, если успешных выполнений нет слишком долго. Используйте его как отправную точку для своего мониторинга ИИ-агентов.

Поделитесь в комментариях: сталкивались ли вы с ситуацией, когда мониторинг показывал «всё зелёное», а на деле всё было сломано? Мне важно понять, насколько эта проблема общая.