Когда ИИ-агенты спорят: кто выигрывает в конфликте

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

Что вообще считать конфликтом агентов

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

• Противоречие в выводах. Агент-аналитик говорит «инвестировать», агент-риск-менеджер говорит «нет». Финальное решение принимает кто-то третий или заранее заданное правило.
• Гонка за общий ресурс. Общая память, файл, запись в базе, лимит вызовов внешнего API. Кто записал последним — тот и переписал.
• Зацикливание. Ревьюер отклоняет, исполнитель переделывает, ревьюер снова отклоняет. Без ограничителя это бесконечный и дорогой цикл.

Важно не путать конфликт с полезным разногласием. Спор двух агентов, из которого рождается более взвешенный ответ, — это фича (её называют debate). Проблема начинается, когда у системы нет механизма закрыть спор.

Почему «кто убедительнее» — плохой критерий

Соблазн отдать победу тому агенту, чей ответ звучит увереннее, велик. Но языковые модели одинаково уверенно излагают и верное, и ошибочное. Уверенность тона не коррелирует с правотой, поэтому арбитраж «по красноречию» систематически проигрывает арбитражу «по правилам и проверкам».

Пять механизмов, которые решают, кто победит

В реальных системах исход конфликта определяет не сам агент, а архитектура вокруг него. Вот основные подходы, от самого жёсткого к самому «демократичному».

Иерархия: самый частый выбор в проде

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

Голосование и его цена

Подход self-consistency^* — запустить одну и ту же задачу несколько раз и взять самый частый ответ — заметно поднимает точность на задачах с одним верным решением (арифметика, классификация). Но каждая «переголосовка» — это отдельный вызов модели. Пять агентов вместо одного — примерно пятикратный счёт за токены и пятикратная задержка. Для чата с пользователем это часто неприемлемо, для ночного батча — нормально.

Побеждает не самый умный агент, а тот, чью правоту система умеет проверить. Если проверить нечем — побеждает тот, кому вы заранее отдали право последнего слова.

Внешняя проверка бьёт любой спор

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

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

Как выстроить разрешение конфликтов: чек-лист

1. Задайте лимит итераций. Максимум N кругов «переделай — проверь», после чего задача уходит человеку или закрывается лучшим из имеющихся вариантов. Это ваша защита от бесконечного счёта.
2. Определите арбитра заранее. Для каждого типа спора должно быть понятно, кто выносит финал: оркестратор, правило приоритета или внешний тест.
3. Разведите доступ к общим ресурсам. Если агенты пишут в одну память или файл, введите блокировки или отдельные пространства, чтобы они не перезаписывали друг друга.
4. Логируйте разногласия. Сохраняйте, где агенты разошлись и чей ответ выбран. Без этого вы не поймёте, почему система выдала именно это.
5. Ставьте бюджет в токенах и деньгах. Жёсткий потолок на прогон — единственная защита от «спора на 40 000 токенов».

^* Self-consistency — приём, при котором модель генерирует несколько независимых ответов на один запрос, а финальным считается самый частый из них. Повышает точность на задачах с единственным верным ответом за счёт дополнительных вызовов.