Хаос-тестирование для ИИ-агентов: устранение пробелов

Вот сценарий, который должен встревожить каждого корпоративного архитектора, внедряющего автономные ИИ-системы прямо сейчас: агент наблюдаемости работает в продакшене. Его задача — обнаруживать инфраструктурные аномалии и инициировать соответствующую реакцию. Поздно ночью он фиксирует повышенную оценку аномалии в производственном кластере — 0,87, что выше заданного порога в 0,75. Агент находится в пределах своих разрешенных полномочий. У него есть доступ к службе отката. И он им пользуется.

Откат приводит к четырехчасовому сбою. Аномалия, на которую он отреагировал, была запланированным пакетным заданием, с которым агент никогда раньше не сталкивался. Никакой реальной неисправности не было. Агент не стал эскалировать проблему. Он не спросил. Он действовал уверенно, автономно и катастрофически.

Что делает этот сценарий особенно неприятным, так это то, что сбой был не в самой модели. Модель вела себя ровно так, как ее обучали. Сбой заключался в том, как система тестировалась перед попаданием в продакшен. Инженеры проверили поведение в штатных условиях (happy path), провели нагрузочное тестирование и проверку безопасности. Чего они не сделали, так это не задались вопросом: как этот агент ведет себя при столкновении с условиями, для которых он никогда не проектировался?

Именно об этом пробеле я и хочу поговорить.

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

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

В отчете Gravitee State of AI Agent Security 2026 отмечается, что лишь 14,4% агентов запускаются в работу с полным одобрением со стороны ИТ-отдела и службы безопасности. Документ, опубликованный в феврале 2026 года более чем 30 исследователями из Гарварда, Массачусетского технологического института (MIT), Стэнфорда и Университета Карнеги-Меллона (CMU), задокументировал нечто еще более тревожное: хорошо выровненные ИИ-агенты в многоагентных средах склонны к манипуляциям и ложному завершению задач исключительно из-за структуры стимулов, причем без какого-либо состязательного промптинга (adversarial prompting). Агенты не были сломаны. Проблемой было поведение на системном уровне.

Это различие имеет важнейшее значение для разработчиков агентной инфраструктуры: модель может быть выровнена, но система все равно может дать сбой. Локальная оптимизация на уровне модели не гарантирует безопасного поведения на системном уровне. Инженеры по хаос-тестированию знают это о распределенных системах уже пятнадцать лет. Мы заново усваиваем этот урок на горьком опыте с агентным ИИ. Причина, по которой наши текущие подходы к тестированию не справляются, заключается вовсе не в том, что инженеры срезают углы. Дело в том, что три фундаментальных предположения, заложенных в традиционную методологию тестирования, полностью рушатся в агентных системах:

• Детерминизм: Традиционное тестирование исходит из того, что при одинаковых входных данных система выдает одинаковый результат. Агент на базе большой языковой языковой модели (LLM) выдает вероятностно схожие результаты. Этого достаточно для большинства задач, но опасно для пограничных случаев (edge cases) в продакшене, когда неожиданный входной сигнал запускает цепочку рассуждений, которую никто не предвидел.

• Изолированный сбой: Традиционное тестирование предполагает, что при сбое компонента А он происходит в ограниченном, отслеживаемом диапазоне. В многоагентном конвейере ухудшенный результат работы одного агента становится «отравленным» входом для следующего. Ошибка усугубляется и видоизменяется. К тому моменту, когда она всплывает наружу, вы занимаетесь отладкой на пяти уровнях от истинного источника.

• Наблюдаемое завершение: Традиционное тестирование исходит из того, что при выполнении задачи система точно сообщает об этом. Агентные системы могут — и регулярно делают это — сигнализировать о завершении задачи, находясь при этом в деградированном или непредусмотренном состоянии. У проекта MIT NANDA есть термин для этого: «уверенная ошибочность» (confident incorrectness). У меня есть менее вежливый термин: то самое происшествие в 4 часа утра, на расследование которого ушло три часа.

Хаос-тестирование на основе намерений (intent-based chaos testing) существует как раз для того, чтобы устранять подобные режимы отказов до того, как ваши агенты попадут в продакшен.

Основная концепция: Измерение отклонения от намерения, а не только от успеха

Хаос-инженерия как дисциплина не нова. Компания Netflix создала Chaos Monkey еще в 2011 году. Принцип прост: намеренно внедряйте сбои в свою систему, чтобы обнаружить ее слабые места до того, как их найдут пользователи. Что является новым — и что индустрия еще не применила с должной строгостью к агентному ИИ, — так это калибровка хаос-экспериментов не только под сценарии инфраструктурных сбоев, но и под поведенческие намерения.

Это различие имеет критическое значение. Когда в ходе хаос-эксперимента дает сбой традиционный микросервис, вы измеряете время восстановления, частоту ошибок и доступность. Когда сбой терпит агентная ИИ-система, эти метрики могут выглядеть абсолютно нормально, в то время как агент действует совершенно за пределами своих предназначенных поведенческих границ: ноль ошибок, нормальная задержка, катастрофически неверные решения. Именно эта концепция лежит в основе системы шкалы хаоса, откалиброванной не только по степени тяжести сбоя, но и по тому, насколько поведение системы отклоняется от ее целевого назначения. Результат этого измерения я называю показателем отклонения намерения (intent deviation score).

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

Весовые коэффициенты не случайны. Они отражают профиль рисков конкретного агента. Для аналитического агента, работающего только на чтение, вы можете снизить вес области доступа к данным. Для агента с правом записи в производственные системы точность сигнала завершения и достоверность эскалации — это те аспекты, где сбои превращаются в аварии. Смысл в том, что вы определяете эти измерения до того, как внедряете какой-либо сбой, основываясь на том, что агент вообще должен делать.

Оценка отклонения рассчитывается как средневзвешенное значение того, насколько каждое наблюдаемое измерение отклонилось от своего базового уровня:

def compute_intent_deviation_score(

    baseline: dict[str, float],

    observed: dict[str, float],

    weights: dict[str, float]

) -> float:

    «»»

Система вычисляет, насколько поведение агента отклонилось от задуманной базы, и возвращает оценку от 0.0 (нет отклонений) до 1.0 (полное нарушение намерений).   

Это НЕ метрика производительности. Задержка и частота ошибок могут выглядеть нормально, пока эта оценка повышена. В этом и заключается вся суть.

    «»»

    score = 0.0

    for dimension, weight in weights.items():

        baseline_val = baseline.get(dimension, 0.0)

        observed_val = observed.get(dimension, 0.0)

        # Нормализация отклонения относительно величины базы

        raw_deviation = abs(observed_val — baseline_val) / max(abs(baseline_val), 1e-9)

        score += min(raw_deviation, 1.0) * weight

    return round(min(score, 1.0), 4)

Получив оценку отклонения, вы классифицируете ее по уровням, требующим определенных действий:

Агент отката из вступительного сценария? В рамках этой структуры он набрал бы примерно 0,78 по шкале отклонения намерения во время тестирования Фазы 3 (катастрофический). Только одно измерение точности сигнала завершения просигнализировало бы о том, что агент сообщает о состояниях успеха, которые не соответствуют действительным результатам системы. Этот показатель заблокировал бы агенту путь в продакшен. Четырехчасовой сбой стал бы обнаруженной на этапе предварительного тестирования проблемой.

Структура эксперимента: Четыре фазы с расширяющимся радиусом поражения

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

Фаза 1: Деградация одного инструмента. Ухудшите работу одной нисходящей зависимости и понаблюдайте, как адаптируется агент. Повторяет ли он попытки разумно? Эскалирует ли проблему, когда повторные попытки терпят неудачу? Изменяет ли он последовательность вызовов инструментов разумным образом или начинает делать вызовы, для которых никогда не предназначался? На этой фазе радиус поражения намеренно узок: один инструмент, один агент, никакого производственного трафика.

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

Схема логирования, необходимая вашему стеку наблюдаемости для того, чтобы Фаза 2 имела смысл, не ограничивается счетчиками ошибок и задержкой. Вам необходимы сигналы намерений:

{

  «timestamp»: «2026-03-30T02:47:13.441Z»,

  «agent_id»: «observability-agent-prod-07»,

  «action»: «triggered_rollback»,

  «decision_chain»: [

    {«step»: 1, «observation»: «anomaly_score=0.87», «source»: «telemetry_feed»},

    {«step»: 2, «reasoning»: «score exceeds threshold,  initiating response»},

    {«step»: 3, «tool_called»: «rollback_service», «params»: {«scope»: «prod-cluster-3»}}

  ],

  «context_completeness»: 0.62,

  «escalation_triggered»: false,

  «intent_deviation_score»: 0.78,

  «chaos_level»: «CATASTROPHIC»

}

Полем, которое изменило бы все в начальном сценарии, является context_completeness (полнота контекста): 0,62. Агент принял высокоуверенное, необратимое решение при доступности лишь 62% ожидаемого контекста. Он не обнаружил отсутствующие поля. Он не произвел эскалацию. Схема логирования, фиксирующая это, превращает загадочный сбой в диагностируемую инженерную проблему — но только в том случае, если вы настроите инструментирование до начала тестирования.

Фаза 3: Многоагентное вмешательство. Введите второго агента, работающего с пересекающимися данными или общими ресурсами. Именно здесь всплывают эмерджентные сбои из-за несоответствия стимулов. Два агента с индивидуально корректным поведением могут давать коллективно вредные результаты, когда они делят общий доступ на запись к одному и тому же ресурсу. На этой фазе выводы исследователей из Гарварда/MIT/Стэнфорда становятся непосредственно применимыми: запустите своих агентов в реалистичной многоагентной среде и посмотрите, что произойдет с их оценками отклонений.

Фаза 4: Комплексный сбой. Объедините несколько одновременных деградаций: задержку инструментов, пропущенный контекст, конкурирующих агентов, устаревшие базы. Это ваше ближайшее приближение к реальной энтропии производственной среды. Критерии прохождения здесь должны быть строже, чем на предыдущих фазах, — не потому, что вы ожидаете от агента идеальной работы в условиях комплексного сбоя, а потому, что вы хотите понять радиус его поражения в худших условиях, которые вы можете разумно предвидеть.

Критерии прохождения/непрохождения на всех четырех фазах подчиняются единому правилу: если оценка отклонения намерения превышает пороговое значение для данной фазы, агент не переходит к следующей фазе или в продакшен. Точка.

Калибровка глубины тестирования в соответствии с рисками развертывания

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

Агент отката находился на четвертой строчке. Его тестировали по второй. Именно в этой дельте и крылся четырехчасовой сбой.

Цикл переобучения: часть, которую пропускает большинство команд

Проведение хаос-эксперимента один раз перед развертыванием необходимо, но недостаточно. Агентные системы эволюционируют. Они получают новые интеграции инструментов. Их промпты обновляются. Область доступа к данным расширяется. Агент, прошедший все четыре фазы в январе с чистой медицинской картой поведения, может иметь совсем другой профиль риска к апрелю.

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

На практике это означает, что результаты ваших хаос-экспериментов следует рассматривать как артефакт управления, а не как PDF-отчет, которым поделились в Slack и забыли, а как структурированный вводный материал для процесса принятия решений о развертывании. Каждое существенное изменение в конфигурации, наборе инструментов или области действия агента должно вызывать повторный запуск затронутых фаз. Не полную регрессию, а целевое повторное тестирование тех измерений, которые наиболее подвержены влиянию конкретного изменения.

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

Где это встраивается в конвейер

Чтобы внести ясность в то, чем является этот фреймворк и чем он не является: хаос-тестирование на основе намерений не заменяет ни один из видов тестирования, которые вы уже проводите. Модульные тесты (unit tests), интеграционные тесты, нагрузочные тесты, команды безопасности (red teams) по-прежнему необходимы. Это дополнительный шлюз, и он занимает определенную точку в вашем конвейере развертывания:

Разработка  →  Модульные / Интеграционные тесты

Стейджинг      →  Нагрузочное тестирование + Тестирование на проникновение (Red Team)

Пре-продакшен     →  Хаос-тестирование на основе намерений  ← тот самый пробел, который это закрывает

Продакшен   →  Наблюдаемость + Выборочный непрерывный хаос

Шлюз пре-продакшена — это место, где вы отвечаете на вопрос, на который не отвечает ни один другой шлюз: в условиях реалистичных сбоев остается ли этот агент в рамках предназначенных ему поведенческих границ или он отклоняется таким образом, который дорого вам обойдется?

Если вы не можете ответить на этот вопрос до того, как ваш агент выйдет в лайв, вы его не тестируете. Вы развертываете его и надеетесь на удачу.

Неудобная арифметика

Компания Gartner прогнозирует, что более 40% проектов в области агентного ИИ будут отменены к концу 2027 года из-за эскалации затрат, неясной окупаемости инвестиций (ROI) и неадекватных средств контроля рисков. Судя по тому, что я видел при создании и развертывании таких систем, именно элемент контроля рисков выполняет здесь основную работу, и конкретным средством контроля рисков, которое наиболее стабильно отсутствует, является структурированная поведенческая валидация перед развертыванием.

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

Это существенно более высокая планка, чем «развернуть и надеяться на лучшее»; и прямо сейчас эту планку не преодолевает большинство корпоративных команд.

Саяли Патиль (Sayali Patil) — лидер в области ИИ-инфраструктуры и продуктов, имеющая опыт работы в компаниях Cisco Systems и Splunk.

Добро пожаловать в сообщество VentureBeat!

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

Читайте далее материалы нашей программы гостевых постов — и ознакомьтесь с нашими рекомендациями, если вы хотите написать собственную статью!