👣 Архитекторы, тестировщики и кодеры. Создаем мультиагентную команду

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

Недавно в блоге Flutter вышла статья, в которой автор экспериментирует с мультиагентным подходом. Вместо одного универсального агента он создал команду из четырех специализированных ролей: архитектор, тестировщик, кодер и координатор. Задача была не простая: портировать популярную Python-библиотеку python-statemachine в статически типизированный Dart-пакет без использования рефлексии (dart:mirrors во Flutter запрещены).


Как устроена мультиагентная команда:

Основа эффективной агентной команды - четко определенные роли с ограничениями на то, что агент может делать.

Автор создал общий воркфлоу-скилл (tdd-dart-workflow) с правилами TDD и разрешениями, а также четыре ролевых скилла:

🔹Архитектор: анализирует исходный код, создает architecture_blueprint.md и спецификации модулей в specs/. Не может писать в lib/, test/ и example/.

🔹Тестировщик: пишет падающие тесты в test/ на основе спецификаций архитектора. Не может просматривать или изменять lib/ и specs/.

🔹Кодер: создает скелеты и реализует код в lib/src/, чтобы тесты проходили. Не может редактировать test/ и specs/.

🔹Координатор: управляет родительским агентом. Отвечает за коммиты, запуск dart analyze и dart test, делегирует задачи суб-агентам.

Строгое разделение ролей не дает ни одному агенту изменять и тесты и код одновременно. Координатор получает только краткий отчет о завершении задачи. Это создает когнитивный файрвол: история проб и ошибок суб-агента отбрасывается после завершения его задачи. Контекст координатора остается чистым, без переполнения токенами.

Для предотвращения гонок и непроверенных коммитов доступ к файловой системе ограничен:

🔹Координатор: чтение и запись везде, но без прямых изменений кода.

🔹Архитектор: чтение везде, запись только в specs/ и skills/.

🔹Тестировщик: чтение везде, запись только в test/ и example/.

🔹Кодер: чтение везде, запись только в lib/ и example/.


Статическая типизация и TDD:

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

Решение: сначала тестировщик пишет тесты по спецификации. Затем кодер создает скелеты в lib/src/ с заглушками, которые возвращают dummy-значения или бросают UnimplementedError. Когда скелет удовлетворяет компилятору, координатор запускает dart analyze && dart test и проверяет, что тесты падают по правильным причинам. Комментарии отделяют временные заглушки от постоянных тестовых утилит.


Результат:

Итоговый Dart-пакет state_machine сохранил полную функциональность оригинальной Python-библиотеки. Кодер реализовал fluent-билдеры для поддержки Dart-синтаксиса.


🔗 Читать подробнее


💡 Вывод:

Мультиагентный подход с разделением ролей работает для Flutter-разработки. Он предотвращает потерю контекста, уменьшает галлюцинации и повышает качество кода. Когнитивный файрвол позволяет сохранять чистоту контекста координатора, отбрасывая историю суб-агентов после завершения задач.

Но подход не без проблем. Необходимы четкие роли, ограничения на запись и навыки, описывающие процессы. Требуется постоянная доработка скиллов по мере возникновения новых ситуаций.

В итоге автор получил не просто Dart-пакет, а набор переиспользуемых навыков для мультиагентной разработки. Вместо одного агента, который пытается делать все, команда из четырех специализированных агентов работает эффективнее. И это, вероятно, будущее Flutter-разработки с ИИ.


Подписаться на канал:
➡️ Flutter & Dart | Мобильный трудоголик