Каскад сбоев: как ошибка одного агента ломает всю систему

Вы поручаете системе из нескольких ИИ-агентов подготовить отчёт: один собирает данные, второй анализирует, третий пишет текст, четвёртый проверяет. Звучит надёжно — четыре пары глаз. Но если первый агент выдумал цифру, остальные три не заметят подвоха: они не перепроверяют вход, а работают с ним как с фактом. Ошибка не гаснет, а разрастается на каждом шаге. Этот эффект называют failure cascade — каскад сбоев, и он стал одной из главных головных болей всех, кто строит агентные пайплайны в 2024–2025 годах.

Что такое каскад сбоев

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

Механика простая и оттого неприятная. Агент A получает задачу, галлюцинирует деталь (например, называет несуществующий параметр API). Агент B принимает эту деталь за данность и строит на ней план. Агент C выполняет план и получает ошибку исполнения — но интерпретирует её не как «данные были ложными», а как «нужно попробовать ещё раз по-другому». Система входит в цикл исправления симптома, а не причины.

Проблема мультиагентных систем не в том, что агент ошибается. Проблема в том, что следующий агент ему верит.

Почему цепочка усиливает ошибку, а не гасит её

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

• Нет источника истины. Агент-проверяющий сверяет текст не с реальностью, а с тем, что ему передали. Если вход выглядит правдоподобно, проверка его пропустит.
• Уверенность не падает с ошибкой. Модель формулирует галлюцинацию тем же ровным тоном, что и факт. Сигнала «здесь я не уверен» вниз по цепочке не передаётся.
• Автономность против прозрачности. Чем больше шагов агент делает сам, тем меньше точек, где человек мог бы вмешаться. Автономность и наблюдаемость тянут в разные стороны.

Где это ломается на практике

Разберём типичные сценарии, где каскад дороже всего обходится.

Кодовые агенты

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

Ресёрч-пайплайны

Система из агента-поисковика, агента-суммаризатора и агента-редактора. Если поисковик подтянул нерелевантный или устаревший документ, суммаризатор честно его пересказывает, а редактор аккуратно оформляет. На выходе — гладкий, уверенный и неверный текст. Здесь особенно помогает RAG², но и он не спасает, если извлечённый источник не проверяется на релевантность отдельно.

Бизнес-автоматизация

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

Одиночный агент против цепочки: где риск

Чем гасят каскад

Универсального выключателя нет, но набор приёмов складывается в общую практику индустрии.

1. Верификация на входе, а не только на выходе. Отдельный шаг проверяет данные до того, как следующий агент начнёт с ними работать. Например, агент, который извлёк параметр API, обязан подтвердить его существование через реальный запрос, а не по памяти модели.
2. Ограничение автономии. Точки, где система останавливается и просит подтверждения человека, — human-in-the-loop. Дорого по времени, зато обрывает каскад до того, как он дойдёт до продакшена.
3. Трейсинг и логирование каждого шага. Инструменты вроде LangSmith, LangFuse и встроенных трейсеров фреймворков показывают, что именно передал каждый агент. Без этого отладка каскада превращается в гадание.
4. Бюджеты и таймауты. Жёсткий лимит на число итераций и токенов не даёт агенту бесконечно «чинить» несуществующую проблему.
5. Изоляция ошибок. Если агент вернул явную ошибку исполнения, система помечает его выход как ненадёжный, а не передаёт дальше как валидный результат.

Кому это пригодится, а кому нет

Мультиагентная архитектура — не универсальное улучшение. Она оправдана в одних сценариях и вредна в других.

• Пригодится: задачи с чёткими, проверяемыми промежуточными результатами. Например, пайплайн, где каждый шаг возвращает структурированные данные, которые можно валидировать программно (JSON по схеме, результат SQL-запроса, статус HTTP).
• Пригодится: процессы, где уже встроен контроль качества — тесты, проверка типов, ручная приёмка на критичных этапах.
• Не стоит: задачи, где промежуточный результат нельзя проверить иначе как «на глаз». Цепочка агентов, пишущих креативный или аналитический текст без источника истины, накапливает ошибки, а не отсеивает их.
• Не стоит: простые задачи, которые решает один вызов модели. Разбивать их на агентов — значит платить больше и получать больше точек отказа без выигрыша в качестве.

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

¹ Мультиагентная система — архитектура, где несколько ИИ-агентов с разными ролями обмениваются результатами, и выход одного служит входом другому.

² RAG (retrieval-augmented generation) — подход, при котором модель перед ответом извлекает релевантные документы из внешней базы и опирается на них, а не только на выученные данные.