Почему ломаются AI-агенты в продакшене: разбор ошибок по таксономии MAST на примере ITBench

Ваш AI-агент в продакшене сломался. Опять

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

Знакомо? Добро пожаловать в клуб.

IBM и UC Berkeley недавно выпустили исследование, которое систематизировало все эти сбои. Они взяли бенчмарк ITBench (реальные IT-задачи) и проанализировали тысячи провалов агентов. Результат - таксономия MAST. Это не просто классификация ошибок. Это карта мин, на которые наступают 95% разработчиков AI-агентов.

Mission: когда агент не понимает, что от него хотят

Самая обидная категория ошибок. Агент получает задачу, но интерпретирует ее неправильно. В ITBench это выглядело так:

• Задача: "Настроить алерты на высокую загрузку CPU"
• Агент делает: устанавливает мониторинг, но не настраивает пороги
• Результат: система мониторинга есть, алертов нет

Почему это происходит? LLM-модели (даже GPT-4.5 Turbo 2026 года) страдают от "иллюзии понимания". Они генерируют связный текст, который выглядит правильным, но не соответствует реальным требованиям.

В исследовании IBM обнаружили интересный паттерн: агенты на основе Claude Sonnet 4.5 лучше справлялись с пониманием миссии, чем GPT-4.5. Разница - 23%. Почему? У Claude оказалась лучше развита способность задавать уточняющие вопросы при неоднозначности.

Action: каскадные ошибки выполнения

Здесь начинается настоящий ад. Агент понял задачу правильно, но совершает неправильные действия. В ITBench это проявлялось в трех формах:

Самое опасное в Action-ошибках - каскадный эффект. Одна маленькая ошибка на 5-м шаге приводит к катастрофе на 20-м. В реальном продакшене это выглядит так:

# Что делает агент (ошибочно):
sudo apt-get install nginx -y  # Шаг 1 - ок
sudo systemctl start nginx     # Шаг 2 - ок
sudo ufw allow 'Nginx HTTP'    # Шаг 3 - ок
sudo apt-get install certbot -y # Шаг 4 - ок
sudo certbot --nginx -d example.com # Шаг 5 - ОШИБКА: домен не настроен

Агент пропустил критический шаг - настройку DNS и виртуального хоста. Certbot падает, весь процесс установки SSL ломается.

В похожем исследовании ABC-Bench обнаружили ту же проблему: агенты проваливаются в настройке окружения именно из-за неправильной последовательности действий.

State: агент теряет контекст, как золотая рыбка

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

В ITBench зафиксировали два типа State-ошибок:

1. Потеря контекста между шагами: агент устанавливает пакет, но в следующем шаге проверяет его наличие как будто ничего не устанавливал
2. Игнорирование изменений состояния: команда возвращает ошибку, но агент продолжает как будто все ок

Почему современные LLM (даже 2026 года) страдают от потери контекста? Потому что их архитектура не предназначена для долгосрочного отслеживания состояния. Они обрабатывают каждый запрос относительно изолированно.

Решение? Нужно явно управлять состоянием. Как в LangSmith Insights Agent - там используется внешняя база состояний, куда агент записывает каждый шаг и результат.

Tool: когда инструменты подводят

Последняя категория MAST - ошибки инструментов. Здесь виноват не столько агент, сколько его "руки". В ITBench обнаружили:

• Инструменты возвращают неожиданные форматы данных
• API меняются без обратной совместимости
• Сетевые таймауты и частичные failures

Реальный пример из исследования: агент использует инструмент для проверки статуса сервиса. Инструмент возвращает JSON с полем "status": "running". Через месяц выходит обновление инструмента, и поле меняется на "state": "active". Агент ломается, потому что ищет несуществующее поле.

Что делать? Нужно строить агентов с учетом хрупкости инструментов. Добавлять:

# Псевдокод обработки Tool-ошибок
def safe_tool_execution(tool, params, max_retries=3):
    for attempt in range(max_retries):
        try:
            result = tool.execute(params)
            # Валидация результата
            if validate_result_structure(result):
                return result
            else:
                # Структура изменилась, пробуем адаптироваться
                result = adapt_to_new_structure(result)
                return result
        except ToolError as e:
            if attempt == max_retries - 1:
                raise
            # Экспоненциальная backoff задержка
            time.sleep(2 ** attempt)

Почему бенчмарки врут (и ITBench не исключение)

Прежде чем вы начнете оптимизировать своего агента под ITBench, важное предупреждение. Как показало исследование "Бенчмарки врут", до 58% ошибок в датасетах могут искажать реальную картину.

С ITBench есть две проблемы:

1. Задачи слишком идеализированы. В реальном продакшене окружение грязнее, сети ненадежнее, а требования меняются на лету
2. Метрики успеха бинарные. В жизни есть градации: "сделал идеально", "сделал с костылями", "сломал, но починил"

Это не значит, что ITBench бесполезен. Наоборот. Но нужно понимать его ограничения. Ваш агент может показывать 95% в ITBench и проваливаться в реальном проекте.

Практический план: как не сломать продакшен

1 Добавьте MAST-валидацию в пайплайн

Перед каждым действием агента запускайте мини-чеклист:

• Mission check: точно ли мы делаем то, что нужно?
• Action validation: правильная ли последовательность шагов?
• State tracking: сохраняем ли контекст?
• Tool verification: работают ли инструменты как ожидается?

2 Внедрите каскадный мониторинг

Не ждите, пока агент полностью провалится. Отслеживайте ранние признаки проблем:

3 Стройте агентов с graceful degradation

Идеальный агент не существует. Все ломаются. Вопрос - как они ломаются. Хороший агент:

• При ошибке Mission - просит уточнений у пользователя
• При ошибке Action - откатывается к последнему стабильному состоянию
• При ошибке State - перезапускает контекст с контрольной точки
• При ошибке Tool - использует альтернативные инструменты

Что будет дальше? (Спойлер: не все так плохо)

Глядя на статистику ITBench, можно впасть в уныние. 67% агентов проваливают хотя бы одну задачу из-за MAST-ошибок. Но есть и хорошие новости.

Во-первых, таксономия MAST - это уже половина решения. Раньше мы гадали, почему агент сломался. Теперь у нас есть четкая система диагностики.

Во-вторых, появляются специализированные фреймворки. Как AssetOpsBench от IBM для промышленных агентов. Они учитывают реальные условия, а не лабораторные идеалы.

В-третьих, модели становятся лучше. Claude Sonnet 4.5 в тестах 2026 года показывает на 18% меньше State-ошибок, чем GPT-4.5. Разработчики LLM наконец-то начали оптимизировать модели для долгих цепочек рассуждений.

Мой прогноз? К 2027 году мы увидим агентов, которые при MAST-ошибках будут не просто падать, а запускать авто-диагностику. Агент сломался -> проанализировал трассу выполнения -> определил тип ошибки по MAST -> применил специфичный фикс -> продолжил работу.

А пока - проверяйте своих агентов на ITBench, внедряйте MAST-валидацию и помните: каждый сбой в продакшене - это не провал, а data point для улучшения системы.