Мультиагентные системы для кода: архитектор, кодер, тестер

За 2024–2025 годы генерация кода в ИИ ушла от «допиши функцию в редакторе» к автономным системам, которые берут задачу целиком: читают репозиторий, планируют изменения, пишут код, запускают тесты и открывают pull request. Ключевой сдвиг — разбиение работы между несколькими агентами¹ с разными ролями: архитектор, разработчик, тестировщик. Так устроены Devin от Cognition, режим агентов в Cursor, GitHub Copilot Workspace и открытые фреймворки вроде OpenHands (бывший OpenDevin), MetaGPT и AutoGen. Идея простая: один агент с одной ролью ошибается предсказуемее, чем один агент, пытающийся держать в голове всё сразу.

Что вообще значит «мультиагентная генерация кода»

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

Классическое разделение выглядит так:

• Архитектор (планировщик) — разбивает задачу на шаги, решает, какие файлы трогать, описывает интерфейсы и структуру. На выходе — план, а не код.
• Разработчик — по плану пишет и редактирует файлы, работает с инструментами: чтение репозитория, правка, запуск команд в терминале.
• Тестировщик (критик) — пишет и запускает тесты, читает вывод об ошибках, возвращает задачу разработчику с конкретным замечанием. Часто именно этот агент решает, готова задача или нет.

Дополнительно бывает ревьюер, который читает диф целиком и ловит то, что тесты не покрывают: утечки секретов, стиль, дублирование логики.

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

Чем это отличается от обычного автодополнения

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

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

Как сравнить основные подходы

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

Открытые фреймворки не готовы «из коробки» так, как Devin или Cursor: вы сами описываете роли, инструменты и правила остановки. Зато вы платите только за токены выбранной модели и контролируете, что уходит наружу.

Где мультиагентность реально помогает, а где мешает

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

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

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

Кому не подойдёт

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

Что сломается на практике

Главная проблема — накопление ошибки. Если архитектор неверно понял задачу, разработчик добросовестно реализует не то, а тестировщик проверит по тем же неверным критериям. Цикл сходится к уверенно неправильному результату.

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

Третье — доступ. Агенту, который сам запускает команды в терминале и открывает PR, нужны права. Изолируйте среду (контейнер, отдельная ветка, отдельный токен с минимальными правами) и не давайте автономному агенту доступ к продакшену.

По измеримым результатам: для оценки таких систем используют SWE-bench — набор реальных задач из GitHub-репозиториев, где агент должен внести исправление, проходящее тесты. Смотрите свежий лидерборд теста перед выбором инструмента, а не рекламные цифры вендора: методики и версии набора различаются, и число из пресс-релиза может быть несопоставимо с другим.

¹ Агент — программа на основе языковой модели, которая не просто отвечает текстом, а вызывает инструменты (правка файлов, запуск команд, поиск), получает результат и решает следующий шаг сама, в цикле.

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