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

Что произошло

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

Схема была стандартной: агент-планировщик^* разбивал запрос на подзадачи, агенты-исполнители собирали данные из внутренней базы через RAG^**, агент-критик проверял результат, а финальный агент собирал отчёт. Формально каждое звено отработало без единого исключения в логах. Проблема в том, что «без исключений» и «правильно» — не одно и то же.

Точка входа: одна неверная формулировка

Пользователь запросил сравнение выручки по двум кварталам. Планировщик разложил это на подзадачи, но в одной из них подменил формулировку: вместо «выручка за вычетом возвратов» поставил просто «выручка». Мелочь на уровне одного слова. Дальше эта подзадача ушла исполнителю как готовое, авторитетное указание.

Почему ошибка не остановилась, а разрослась

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

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

Мультиагентная система устойчива ровно настолько, насколько устойчиво её самое слабое звено — и обычно это не исполнитель, а тот, кто ставит задачу.

Три механизма, которые разогнали ошибку

• Отсутствие сквозной сверки с исходным запросом. Каждый агент проверялся против ближайшего соседа, но не против первоначальной формулировки пользователя.
• Ложная уверенность в тоне. Модели формулируют вывод одинаково уверенно и когда правы, и когда ошибаются. Критик не имел сигнала «здесь сомнительно».
• Потеря контекста между шагами. При передаче задачи между агентами обрезался кусок исходной формулировки — уточнение про возвраты просто не долетело до исполнителя из-за ограничений контекстного окна^***.

Как это ловить и чинить

Универсального «выключателя» каскада нет, но есть набор практик, снижающих риск. Их применяют команды, строящие продакшн-пайплайны на оркестраторах вроде LangGraph или CrewAI.

1. Передавайте исходный запрос на каждый шаг. Не только подзадачу от предыдущего агента, но и оригинальную формулировку пользователя — чтобы каждый агент мог сверить, не увело ли его в сторону.
2. Добавьте агента-верификатора против исходника. Отдельный шаг, который сверяет финальный результат не с последней подзадачей, а с первым запросом.
3. Просите модель оценивать уверенность. Структурированный вывод с полем «насколько я уверен и почему» даёт критику сигнал, где копать.
4. Логируйте промежуточные выводы, а не только исключения. Отсутствие ошибки в логах ничего не говорит о корректности вывода.
5. Ставьте контрольные точки с человеком там, где цена ошибки высока. Для финансовых отчётов ручная сверка одного числа дешевле репутационного провала.

Одноагентный или мультиагентный подход

После разбора команда задалась вопросом, нужна ли вообще была цепочка из семи агентов. Часто задачу решает один агент с инструментами, и тогда каскад просто негде образоваться.

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

Пригодится, если вы:

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

Не пригодится, если ваша задача решается одним промптом или одним агентом с парой инструментов. Тогда мультиагентная архитектура добавит стоимость и точки отказа, не дав выигрыша. Каскад ошибок — проблема сложных систем, и лечить её лучше упрощением, а не новым слоем агентов-контролёров.

^* Агент — компонент на базе языковой модели, который получает задачу, сам решает, какие шаги и инструменты применить, и выдаёт результат без пошаговых инструкций от человека.

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

^*** Контекстное окно — максимальный объём текста в токенах, который модель удерживает за один вызов. Всё, что в него не влезло, для модели не существует.