Что такое мультиагентная разработка
Один агент в цикле может решить задачу от начала до конца. Мультиагентная схема делит эту работу между несколькими агентами. У каждого своя роль, свои инструкции, свой набор инструментов и свой контекст.
Типовые роли в разработке:
- Планировщик. Читает задачу, уточняет требования, пишет спеку и план, разбивает работу на шаги.
- Исполнитель. Пишет код и тесты по плану.
- Ревьюер. Проверяет изменение по спеке, правилам и тестам, возвращает замечания.
- Исследователь. Ищет по коду и документации, возвращает выжимку.
Оркестрация — логика, которая решает, какой агент работает следующим, что ему передать и где остановиться для решения человека.
Спор о мультиагентах: два подхода
В 2025 году две компании опубликовали разборы с противоположными выводами.
В Anthropic описали мультиагентную систему для исследований: ведущий агент раздаёт подзадачи субагентам, которые работают параллельно. На внутреннем тесте схема с Claude Opus 4 в роли ведущего агента и субагентами на Claude Sonnet 4 обошла одиночный Claude Opus 4 на 90,2%. Цена — расход токенов: мультиагентные системы тратили примерно в 15 раз больше токенов, чем обычный чат. В том же тексте сказано, что схема подходит для задач, которые распадаются на независимые направления. Задачи, где все агенты должны видеть общий контекст и сильно зависят друг от друга, подходят плохо. Пример такой области в статье — большинство задач по коду: в них меньше частей, которые можно делать параллельно.
В Cognition, авторы агента Devin, выпустили статью «Don't Build Multi-Agents». Их аргумент: каждое действие агента содержит неявные решения. Если два агента параллельно пишут части одного изменения и не видят решений друг друга, части не стыкуются. Вывод статьи — давать агентам полный общий контекст и по умолчанию не строить схемы, где несколько агентов пишут код параллельно.
Позиции сходятся в главном: параллельно хорошо работают агенты, которые читают и исследуют. Писать одно изменение должен один исполнитель с полным контекстом.
Рабочие схемы в разработке
Последовательная цепочка с контрольными точками
Агенты работают по очереди и передают результат через файлы в репозитории. Схема из практики Праксора в крупной корпорации:
Planner ─▶ [Gate 1: человек] ─▶ Coder ─▶ Reviewer ─▶ [Gate 2: человек]
│ │
│ └─ замечания ─▶ Coder
└─ ветка, merge request, обновлённые спеки- Planner создаёт ветку и merge request, обновляет спеки.
- На Gate 1 человек утверждает спеку и план.
- Coder пишет код, Reviewer проверяет код и результат CI.
- На Gate 2 человек принимает изменение.
- Состояние задачи хранится в метке MR в GitLab. Возврат к агенту идёт через комментарии в том же MR.
Состояние живёт в Git-хостинге, поэтому процесс прозрачен для людей: всё видно в обычном интерфейсе MR, без отдельной панели оркестратора.
Исполнитель и ревьюер на разных моделях
Одна модель пишет, другая проверяет. Правило «разработчик не ревьюит свой код» действует и для агентов. Модели ошибаются по-разному, поэтому разные модели ловят ошибки друг друга чаще, чем одна модель, проверяющая саму себя. Подробнее — в статье про AI code review.
Субагенты-исследователи
Основной агент отправляет субагентов искать по коду, читать документацию или разбирать логи. Каждый работает в своём контексте и возвращает выжимку. Основной агент сохраняет контекст для решения. Субагенты читают и ничего не меняют, поэтому риск рассогласования минимален.
Параллельные независимые задачи
Несколько агентов работают одновременно над разными задачами в разных ветках или рабочих копиях: один чинит баг в биллинге, другой добавляет эндпоинт в отчётах. Задачи не пересекаются по файлам, и каждая проходит обычный цикл ревью.
Правила, без которых цепочка ломается
- Передача через спеку и MR. Агенты обмениваются спекой, планом, диффом и комментариями в MR. Пересказ в свободной форме теряет решения.
- Лимит пересдач. Если ревьюер трижды вернул работу, задача уходит человеку. Без лимита агенты могут спорить бесконечно и сжигать бюджет.
- Контрольные точки по масштабу изменения. Изменения внутри модуля проходят без человека. Изменения в публичных API, данных и чужих модулях останавливаются на gate.
- Бюджет токенов. Мультиагентные схемы дорогие. Лимиты на задачу и учёт расходов по командам настраивают в LLM-шлюзе.
- Наблюдаемость. Логи всех вызовов моделей и инструментов, чтобы разбирать, на каком шаге цепочка ошиблась.
Когда достаточно одного агента
Большинство задач в разработке решает один агент с хорошим harness. Цепочка оправдана, если:
- задачи крупные и проходят несколько этапов с разными навыками;
- нужна независимая проверка до человека;
- команда уже стабильно работает с одиночными агентами и упирается в пропускную способность ревью.
Команде, которая только начинает работать с агентами, цепочка добавит сложности без выигрыша. В кейсе Праксора на мультиагентный пайплайн перешла команда, которая уже уверенно работала с агентами на отдельных задачах.
Агентные пайплайны с Праксором
Строим цепочки агентов под ваш Git-хостинг и требования ИБ: роли, контрольные точки, лимиты пересдач, закрытый контур через единый LLM-шлюз. Смена модели не требует переделки кода агентов. Кейсы
Вопросы
Что такое оркестрация AI-агентов?
Логика, которая решает, какой агент работает следующим, какой результат ему передать и где остановиться для решения человека. В разработке её часто строят на ветках, merge request и метках в Git-хостинге.
Несколько агентов всегда лучше одного?
Нет. Мультиагентные схемы тратят в разы больше токенов и ломаются, когда агенты пишут части одного изменения без общего контекста. Для большинства задач хватает одного агента с хорошими правилами и проверками.
Какие фреймворки нужны для мультиагентной разработки?
Для разработки часто хватает CI, Git-хостинга и агентов с CLI: состояние задачи хранится в MR, а передача работы идёт через комментарии и метки. Отдельный фреймворк нужен, если цепочка выходит за пределы репозитория.
Как контролировать стоимость мультиагентной схемы?
Лимит пересдач на задачу, бюджет токенов на команду и маршрутизация простых шагов на дешёвые модели через LLM-шлюз.