Как заставить нескольких агентов работать над одним проектом и не мешать друг другу

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

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

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

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

• Средний уровень — агенты, управляющие архитектурой модуля: где какие классы, как связаны зависимости.

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

Это немного напоминает команду с джуниорами, сеньорами и техлидом, но роли исполняют не люди, а агенты.

8 шагов мультиагентной системы

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

Первый шаг — сетап. Это онбординг нового проекта в процесс spec-driven development. Агент создаёт все необходимые файлы: rules.md, описание архитектуры, style guide. Он ещё не пишет код, а готовит инфраструктуру для дальнейшей работы.

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

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

Четвёртый шаг — spec. Агент создаёт спецификацию: документирует компоненты, элементы дизайна, API, рисует диаграммы. Спецификация становится единым источником правды — главным артефактом, из которого будет генерироваться всё остальное.

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

Шестой шаг — implement. Группа агентов разбирает бэклог и выполняет задачи. Здесь как раз и работает трёхуровневая иерархия: одни агенты пишут код, другие следят за архитектурой модулей, третьи — за архитектурой всей системы.

Седьмой шаг — audit drift. Самый важный агент в системе. Он проверяет, насколько текущий код соответствует спецификации, и находит расхождения. Если код отстаёт от спецификации или, наоборот, обгоняет её, audit drift добавляет новые задачи в бэклог. Цикл повторяется до тех пор, пока расхождение не станет равным нулю. Именно этот агент отвечает за то, чтобы проект не расползается, а код всегда соответствовал задуманному.

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

Параллелизация и выбор модели

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

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

Коротко о главном

• Одиночный агент переполняет контекст и теряет фокус на больших проектах. Разделение на этапы и роли снимает эту проблему.

• Главное — спецификация, из которой генерируется всё остальное. Если результат не устраивает, то менять нужно не код, а спецификацию. После этого код генерируется заново.
  • Чем лучше описана задача, тем более простую и дешёвую модель можно использовать для её выполнения.

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