Как ИИ-агенты делят задачи и спорят о приоритетах

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

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

Откуда берётся конфликт приоритетов

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

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

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

Три модели координации

На практике сложившиеся фреймворки — LangGraph, CrewAI, AutoGen, OpenAI Agents SDK — используют три подхода к тому, как определяется очерёдность. Часто их комбинируют.

Оркестратор-исполнители

Есть один управляющий агент (оркестратор, supervisor). Он держит список задач, раздаёт их исполнителям и решает, что делать первым. Исполнители не спорят между собой — они получают наряд и возвращают результат. Приоритет определяется централизованно, и это проще всего отлаживать: вся логика решений в одном месте.

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

Рыночная модель

Задачи выставляются как «лоты», агенты «торгуются» за них — например, оценивают, насколько подходят под задачу, и заявляют готовность с числовым баллом. Тот, кто заявил выше, забирает задачу. Так работают некоторые исследовательские схемы contract net¹.

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

Приоритет по правилам и весам

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

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

Что сравнивать при выборе

Где системы ломаются

Три сбоя встречаются чаще остальных, и все три связаны именно с приоритетами.

• Взаимная блокировка (deadlock). Агент A ждёт результата B, B ждёт A. Без графа зависимостей и таймаутов система зависает. Лечится тем, что зависимости описаны явно как направленный ациклический граф, где циклы попросту невозможны.
• Голодание (starvation). Низкоприоритетная задача не выполняется никогда, потому что всё время появляются более срочные. Решается «старением» приоритета: чем дольше задача ждёт, тем выше её вес.
• Пинг-понг. Два агента гоняют задачу туда-сюда, каждый считает её чужой зоной ответственности. Каждый круг — это сожжённые токены и время. Помогает жёсткий лимит на число передач и правило «если задача вернулась дважды, эскалируй оркестратору или человеку».

Практический порядок действий

Если вы собираете мультиагентную систему и хотите, чтобы приоритеты не превратились в хаос:

1. Опишите задачи и зависимости между ними явно, до запуска агентов. Граф зависимостей — не украшение, а страховка от deadlock.
2. Начните с самого дешёвого варианта — правил и весов. Переходите к оркестратору или рынку, только когда правила перестают справляться.
3. Поставьте жёсткие лимиты: максимум передач задачи, максимум шагов на всю сессию, таймаут на ожидание зависимости.
4. Логируйте каждое решение о приоритете. Когда система поведёт себя странно, вы должны видеть, кто и почему взял задачу первой.
5. Заложите точку эскалации к человеку на случай, когда агенты не могут договориться за отведённое число шагов.

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

¹ Contract net — протокол распределения задач, где узел-инициатор объявляет задачу, остальные подают «заявки», а инициатор выбирает исполнителя. Идея сформулирована ещё в исследованиях распределённых систем и сегодня применяется к координации ИИ-агентов.