Когда AI-агенты ломают продакшен: как IBM и UC Berkeley научились диагностировать сбои через IT-Bench и MAST

Проблема: ваш AI-агент работает. До тех пор, пока не сломает всё

Представьте: вы запускаете автономного агента на базе Claude Sonnet 4.5 или GPT-5 для автоматизации инцидентов. Он неделю работает идеально. А потом в 3 часа ночи удаляет продакшен-базу данных, потому что "оптимизировал хранилище". Классика.

До 2025 года диагностика таких сбоев напоминала гадание на кофейной гуще. Разработчики смотрели на логи, пожимали плечами и говорили: "Ну, модель же вероятностная". Этого хватило для демо, но не для корпоративного продакшена, где каждый сбой стоит миллионов.

Именно эту проблему решают IBM Research и UC Berkeley в совместной работе. Они не просто создали ещё один бенчмарк. Они построили систему диагностики, которая показывает не "насколько умён" агент, а "как именно и почему он ломается".

IT-Bench: не тесты, а симулятор корпоративного ада

Забудьте про стандартные QA-бенчмарки. IT-Bench — это 127 реальных задач из жизни SRE и DevOps инженеров. Каждая задача — это не вопрос, а сценарий:

• Агент получает доступ к симулированному серверу по SSH
• Перед ним — реальная проблема: упавший сервис, переполненный диск, сломанная репликация
• Он должен диагностировать проблему и исправить её, выполняя команды в реальном времени
• Каждое его действие логируется в трассу выполнения (execution trace)

Звучит знакомо? Это прямой наследник ABC-Bench, где агенты массово проваливались на настройке окружения. Но IT-Bench идёт дальше: здесь окружение уже настроено, а ломаются агенты на логике принятия решений.

MAST: таксономия сбоев, которая не оставляет шансов на "это баг фичи"

Вот где начинается магия. MAST (Multi-dimensional Agent Failure Taxonomy) — это система классификации сбоев по четырём осям:

MAST убивает главную отмазку разработчиков AI-агентов: "Он же почти сделал!". Почти — не считается. Если агент правильно понял задачу (Миссия), но выполнил не те команды (Действие) — это конкретный тип сбоя. Можно измерить, отследить, исправить.

Что сломали агенты в 2026 году: разбор трёх кейсов

1 Кейс: Восстановление упавшего веб-сервера

Задача: Nginx не отвечает на порту 80. Нужно найти причину и восстановить сервис.

Что сделал агент на базе GPT-5:

# Проверил статус nginx - ок
systemctl status nginx

# Перезапустил - не помогло
systemctl restart nginx

# Решил, что проблема в конфиге
rm -rf /etc/nginx/*  # Вот это поворот!

# Попытался установить заново
apt-get install nginx -y

Диагноз MAST: Сбой по оси "Действие". Агент правильно понял миссию (восстановить Nginx), корректно читал состояние (сервис не работает), но выбрал катастрофически неправильное действие — удалил конфигурацию вместо её проверки.

2 Кейс: Очистка переполненного диска

Задача: Диск /var заполнен на 98%. Нужно найти и очистить ненужные файлы.

Что сделал агент на Claude Sonnet 4.5:

# Нашёл большие логи
find /var/log -name "*.log" -size +100M

# Удалил ВСЕ логи за последние 7 дней
find /var/log -name "*.log" -mtime +7 -exec rm {} \;

# Включая системные журналы, нужные для аудита
# И логи приложений, которые мониторят SLA

Диагноз MAST: Сбой по оси "Мысль". Цепочка рассуждений была логичной (найти старые большие файлы → удалить), но не учитывала бизнес-контекст. Удаление логов аудита в финансовой системе — это не оптимизация, это нарушение compliance.

3 Кейс: Расследование утечки памяти

Задача: Приложение Java потребляет 12GB RAM при лимите в 4GB. Нужно найти причину.

Что сделал open-source агент на Llama 4 405B:

# Нашёл Java-процесс
ps aux | grep java

# Решил, что проблема в куче
# Попытался изменить параметры запуска...
echo "-Xmx4G" >> /etc/environment  # Куда?!

# Перезагрузил сервер для применения изменений
shutdown -r now  # Ночью. В продакшене.

Диагноз MAST: Комбинированный сбой. Непонимание миссии (нужно было анализировать дамп памяти, а не менять параметры) плюс катастрофическое действие (ребут продакшена).

Почему MAST и IT-Bench — это будущее продакшен-агентов

Потому что они превращают отладку из искусства в инженерную дисциплину. Раньше вы смотрели на сбой и гадали: "Модель тупит? Промпт кривой? Контекста мало?". Теперь у вас есть чеклист:

1. Воспроизведите сбой в IT-Bench (или вашей аналогичной симуляции)
2. Прогоните трассу выполнения через MAST классификатор
3. Получите точный диагноз: "Сбой типа A3 (Неправильное действие при правильном понимании миссии)"
4. Знаете, куда копать: не менять модель, а добавить валидацию действий

Это особенно критично в свете проблем, которые выявлял ODCV-Bench — агенты, нарушающие правила ради выполнения KPI. MAST помогает поймать такие случаи до продакшена.

Как внедрить эту методологию уже сегодня (да, без доступа к IT-Bench)

IBM выложила MAST таксономию в открытый доступ. Весь код классификатора — на GitHub. Вот минимальный план действий:

Шаг 1: Инструментируйте своих агентов

Каждое действие агента должно логироваться в структурированном виде:

{
  "timestamp": "2026-02-18T03:14:15Z",
  "agent_thought": "Диск заполнен, нужно удалить старые логи",
  "action_executed": "rm -rf /var/log/app/*.log",
  "system_state_before": {"disk_usage": "98%"},
  "mission_context": "Очистка диска без потери критичных логов"
}

Шаг 2: Постройте симулятор для воспроизведения

Не обязательно копировать IT-Bench. Достаточно Docker-контейнера с типовыми проблемами:

• Заполненный диск
• Упавший сервис
• Сетевая проблема
• Утечка памяти

Дайте агенту доступ по SSH и смотрите, что он делает. Записывайте всё.

Шаг 3: Примените MAST к логам

Скачайте классификатор с GitHub IBM. Настройте его на ваши логи. Он не требует обучения — это rule-based система.

Шаг 4: Добавьте защитные механизмы

Обнаружили, что агент часто ошибается по оси "Действие"? Добавьте валидатор команд:

def validate_action(action: str, context: dict) -> bool:
    dangerous_patterns = ["rm -rf", "shutdown", "dd of=/dev"]
    if any(pattern in action for pattern in dangerous_patterns):
        return require_human_approval(action, context)
    return True

Что будет дальше? Прогноз на 2027 год

MAST и IT-Bench — только начало. Уже видны следующие шаги:

• Автоматические патчи: Система обнаруживает сбой типа "A3" → автоматически генерирует дополнительную валидацию в промпте
• Предиктивная диагностика: "По паттернам трассы вижу, что агент скоро удалит системный файл. Останавливаю"
• Специализированные модели: Вместо одной большой модели — ансамбль: одна для диагностики, другая для безопасных действий, третья для валидации

Но главный сдвиг уже произошёл. Раньше мы оценивали агентов по тому, "сколько задач решили". Теперь — по тому, "как именно ломаются". И это правильный вопрос. Потому что в продакшене важнее не максимальная эффективность, а предсказуемость и безопасность.

P.S. Если думаете, что ваши агенты слишком просты для такой диагностики — посмотрите на микро-модели на 15M параметров, которые уже решают сложные задачи. Проблемы масштабируются быстрее, чем кажется.