Не один агент, а целая команда: мультиагентный подход к автономной разработке

LLM могут подсказать кусок кода, объяснить ошибку или написать тест. Но как только задача становится похожа на реальную работу разработчиков — прочитать issue, разобраться в проекте, воспроизвести баг, сделать патч и не сломать остальное — один универсальный агент часто не справляется. В статье Agyn: A Multi-Agent System for Team-Based Autonomous Software Engineering авторы предлагают простую идею: может быть, проблема не только в размере модели, а в том, что мы заставляем ИИ работать в неестественной для разработки форме.

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

Вместо монолита — организация процесса

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

Для этого авторы строят систему поверх платформы agyn (open-source), где можно собирать команду агентов как «организацию». Здесь не конвейер с фиксированными шагами и не один супер-агент, а набор ролей со своей ответственностью и контекстом. Принципиально важно, что агенты работают в изолированных sandbox-окружениях: каждый может экспериментировать, запускать тесты, пробовать альтернативы, не ломая работу других. Это похоже на то, как разработчики держат локальные ветки и окружения, а общий результат сходится через PR.

Роли в команде и почему это вообще работает

Состав команды у авторов довольно «человеческий»: менеджер, исследователь, инженер и ревьюер.

Менеджер держит картину целиком: принимает решения, кого звать дальше, когда пора остановить исследование и переходить к правкам. Исследователь разбирается в issue и кодовой базе, формирует спецификацию — что именно нужно поменять и где искать причину. Инженер правит код, гоняет тесты, отлаживает. Ревьюер смотрит diff в PR и оставляет замечания построчно, пока не будет готов сказать «одобряю».

Интересная деталь: роли могут работать на разных моделях. Более «думающие» модели идут на анализ и планирование, а более экономичные и специализированные — на реализацию и дебаг. Это отражает production-логику: не всегда выгодно платить за дорогую модель там, где важнее скорость итераций.

GitHub как «единая доска задач»

Авторы сознательно делают процесс GitHub-native: issue → pull request → inline review → правки. Причём это не имитация в чате, а реальная работа с артефактами GitHub. Для взаимодействия они в итоге предпочли CLI gh вместо API, потому что API раздувает контекст. А для inline-ревью им даже пришлось дописать расширение, потому что стандартный gh не слишком удобен для такой роли.

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

Проверка на SWE-bench и неожиданный акцент

Хотя систему делали не под бенчмарк, авторы оценили её постфактум на SWE-bench 500 — популярном наборе реальных GitHub-задач, где успех считается только если патч проходит тесты проекта. В полностью автономном режиме (без человека) их подход решает 72.4% задач. Это конкурентный результат на фоне сильных baseline-решений в том же диапазоне 70–75%.

Но в обсуждении авторы честно показывают, где процесс ломается. В SWE-bench много репозиториев со старой инфраструктурой: зависимости устарели, CI может падать из‑за deprecated GitHub Actions. В production команда обычно может потратить время на восстановление окружения — а на бенчмарке это превращается в ловушку: агент уходит чинить все вокру», вместо того чтобы чинить конкретный баг. Отсюда важный вывод: даже хороший рабочий процесс может проиграть, если среда под ногами нестабильна.

Что в итоге важно в этой работе

Главная ценность статьи — демонстрация, что прогресс в автономной разработке упирается не только в улучшение LLM, но и в оргдизайн: роли, правила коммуникации, критерии завершения, инфраструктура окружений и работа с артефактами. Здесь «умение работать как команда» становится отдельным инженерным усилителем.

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

💾 Код