Почему мультиагентные системы зацикливаются и как это чинят

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

Откуда берутся циклы

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

• Нет критерия завершения. Агенты обмениваются репликами, но ни один не отвечает за вопрос «мы уже закончили?». Каждый ждёт, что решит другой.
• Субъективные требования. Ревьюер оценивает не по объективному тесту, а по вкусу. У вкуса нет фиксированной точки: то, что было хорошо на шаге 3, стало плохо на шаге 8.
• Потеря контекста. Из-за ограниченного контекстного окна* агент забывает, что этот вариант уже отвергали, и предлагает его снова.
• Взаимная вежливость. Два агента с промптами «будь полезным» уходят в бесконечное «а как вам такой вариант?» — «отлично, но давайте улучшим ещё».

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

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

Приёмы, которые обрывают цикл

Ни один способ по отдельности не спасает. Рабочая система обычно сочетает жёсткий лимит, детектор повторов и объективный критерий выхода.

1. Жёсткий потолок итераций

Самая дешёвая страховка. Задаёте максимум шагов графа или раундов диалога — например, 8 или 12 — и по достижении лимита система не молча зависает, а завершает работу с явным статусом «не сошлось». Это не решение проблемы, а предохранитель, который переводит бесконечную трату денег в конечную и заметную ошибку.

2. Детектор повторяющихся состояний

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

3. Объективный критерий выхода вместо мнения

Замените «ревьюеру нравится» на измеримое условие: тесты прошли, схема провалидировалась, JSON распарсился, число уложилось в диапазон. Если у задачи в принципе нет объективной проверки, введите её искусственно — например, ревьюер обязан вернуть решение после N замечаний, а не бесконечно копить их.

4. Роль арбитра

Третий агент или детерминированный код, который единолично решает, продолжать или останавливаться. Два спорщика не должны сами определять момент завершения — это конфликт интересов, встроенный в архитектуру.

5. Бюджет вместо счётчика шагов

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

Как это выглядит в популярных фреймворках

Механизмы называются по-разному, но идея общая — не дать графу крутиться вечно.

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

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

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

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

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

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

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