Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Группу ИИ-агентов научили совместно собирать сложное программное обеспечение без единого диспетчера, который раздаёт задачи и принимает результаты. Работа Zhihao Zhan и коллег не прошла рецензирование, а все числа получили сами авторы: на пяти сложных проектах крупная группа прошла примерно на половину больше тестов, чем одиночный агент. Для команд это вариант архитектуры, в которой координация не становится узким местом при росте числа исполнителей.
Общий протокол заменяет центрального диспетчера
В обычной многоагентной системе главный агент составляет план, дробит его на части, назначает исполнителей и сводит ответы. Чем больше работников, тем больше решений и результатов проходит через один контекст. Ошибка главного агента при декомпозиции или сборке затрагивает всю систему.
В Agensh все работники равноправны и выполняют один цикл. Агент изучает общую цель и текущее состояние проекта, выбирает свободную подзадачу, объявляет о ней коллегам, вносит изменения, проверяет их и объединяет с общей работой. После этого он ищет следующую подзадачу, не ожидая завершения общего раунда.
Координацию поддерживают три общих механизма. Рабочее пространство хранит текущие и уже объединённые изменения; в реализации для этого использовали Gitea с отдельными ветками и обнаружением конфликтов. Mattermost передаёт общие объявления и срочные личные сообщения. Отдельное хранилище накапливает подтверждённые факты, неудачные подходы, занятые подзадачи и описания готовых исправлений.
Агенты получают свежие записи при следующем обращении к инфраструктуре, а старую историю могут искать отдельно. Поэтому каждому не требуется помещать весь ход проекта в своё контекстное окно. При конфликте исполнитель забирает последние изменения, исправляет несовместимость и повторяет объединение.
Agensh работает поверх обычной одноагентной управляющей оболочки, а не заменяет её. Нижний уровень вызывает модель и инструменты, хранит локальный диалог и выполняет действия. Верхний уровень присваивает работникам идентификаторы, доставляет события и поддерживает общие сервисы. Цикл сотрудничества задан в подсказке, одинаковой для всех агентов, поэтому его можно подключать к разным оболочкам через адаптер.
Число агентов повышает результат и сокращает ожидание
Основная метрика — доля пройденных тестов: она показывает, сколько проверок успешно прошло программное обеспечение, воссозданное агентами. При переходе от 1 исполнителя к 128 средний результат вырос на 49%. На задаче pandoc группа из 1 024 агентов довела долю пройденных тестов до 55,06%.
Крупные группы также раньше достигали того же качества, которое небольшие команды показывали позднее. Здесь параллелизм улучшал не только итог, но и время до пригодного результата — это полезно для задач с жёстким сроком выполнения.
Записи работы показывают, как менялось сотрудничество. Сначала агенты согласовывали интерфейсы и устраняли пересечения между подзадачами. Затем они начали передавать исправления на независимую проверку, выбирать интеграторов по опыту и повторно использовать удачные процедуры. В самой крупной группе одну специализированную роль могли выполнять несколько работников, поэтому неудача одного не блокировала направление целиком.
Менять архитектуру стоит для делимых и проверяемых задач
Agensh меняет планы команд, у которых центральный агент уже тратит заметную часть времени на распределение работы и сбор ответов. Вместо усложнения его подсказки или обучения отдельного планировщика можно вынести состояние проекта в общую инфраструктуру и дать исполнителям самим занимать подзадачи.
Такая схема требует чётких границ работы. Агент должен понять, что ещё не сделано, объявить область изменений и проверить результат по заранее известному критерию. Для разработки это дают репозиторий, ветки, тесты и история изменений. Если результат нельзя независимо проверить или безопасно объединить, самоорганизация не устраняет проблему координации.
Работу проверяли на пяти самых трудных задачах ProgramBench: агенты с GPT-5.6-sol high через Copilot воссоздавали FFmpeg, gromacs, pandoc, PHP-src и ctags. На выполнение давали шесть часов, доступ к интернету отключали. Такой стенд проверяет длительную совместную разработку, но не подтверждает тот же эффект для поддержки клиентов, аналитики или процессов с участием людей.
В статье не приведён расчёт расходов на модели, вычисления и инфраструктуру, поэтому результаты нельзя напрямую превратить в экономическое обоснование группы из сотен агентов. Практический следующий шаг — проверить сам протокол на меньшем числе исполнителей: общее состояние, самостоятельный захват задач, обязательная проверка и объединение через систему версий. Масштабирование имеет смысл после того, как эта схема перестанет создавать дублирующую работу и конфликты быстрее, чем агенты их разрешают.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
