1024 агента без начальника: где Agensh нашла предел масштабирования

Заголовок обещает 1024 агента. Но если посмотреть на цифры, на задаче pandoc рост с одного агента до 1024 даёт прирост final test-pass rate с 33,89% до 55,06% — примерно 1,62-кратный относительный выигрыш, а не 1024-кратный. На пяти сложнейших задачах ProgramBench масштабирование с 1 до 128 агентов поднимает средний результат с 19,31% до 28,78% — около 49% относительного прироста. Это не отменяет инженерного достижения, но сразу задаёт вопрос: где именно дополнительные воркеры перестают добавлять ценность и почему об этом нет публичных данных?

Что такое Agensh и чем она отличается от оркестраторных схем

Agensh — это самоорганизующаяся мультиагентная система без центрального оркестратора. Каждый воркер выполняет пятишаговый цикл: собирает контекст, захватывает подзадачу, действует и делится находками, проверяет результат и асинхронно сливает прогресс в общий Git-репозиторий. Инфраструктура держится на трёх компонентах: общем рабочем пространстве (Git), интерфейсе обмена сообщениями и общем контексте. В оркестраторных схемах единая точка планирования распределяет задачи и контролирует качество; здесь воркеры сами выбирают, за что взяться.

Такая архитектура снимает узкое место оркестратора, но переносит сложность в механизмы обмена и проверки. Если один воркер захватил подзадачу, другие должны видеть, что она занята, а результаты должны сливаться без конфликтов. Именно поэтому Agensh использует Git как общий воркспейс: слияние кода становится частью цикла координации, а не отдельной операцией.

Какие результаты подтверждены, а какие остаются заявлениями

Подтверждённые цифры выглядят так. На пяти сложнейших задачах ProgramBench масштабирование с 1 до 128 агентов повышает средний final test-pass rate с 19,31% до 28,78%. На pandoc рост с 1 до 1024 агентов поднимает этот показатель с 33,89% до 55,06%. Условия эксперимента: модель GPT-5.6-sol (high), шестичасовой бюджет, отсутствие доступа в интернет, 16 узлов по 64 агента. Код открыт 24 октября 2026 года под лицензией MIT (версия 1.0, коммит 0468a3e); в репозитории есть Docker Compose, baseline для одного агента и скрипты запуска экспериментов.

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

Отдельно стоит наблюдение из практики. Автор Qiita запускал Codex CLI в конфигурациях 1, 2, 4 и 8 агентов и отметил, что на некоторых задачах 8 агентов работают хуже одного. Это неофициальный мини-эксперимент, а не результат Microsoft, но он показывает: кривая отдачи не монотонна и зависит от задачи.

Где масштабирование перестаёт окупаться — что известно и чего не хватает.

Из доступных данных можно уверенно сказать, что отдача не линейна. 1024-кратное увеличение числа агентов даёт примерно 1,62-кратный относительный прирост на pandoc, а почти 45% тестов всё ещё проваливаются. Это значит, что где-то между малыми масштабами и тысячей воркеров кривая начинает замедляться. Но где именно — неизвестно: в прочитанных источниках нет систематических данных по промежуточным конфигурациям (32, 64, 256 агентов).

Отсутствие названного порога — не ошибка авторов, а пробел для читателя. Без него нельзя выбрать масштаб осознанно: непонятно, даёт ли 128 агентов большую часть выигрыша или основная часть прироста приходится на первые 16–32 воркера. Наблюдение Qiita о том, что 8 агентов могут быть хуже 1, только усиливает неопределённость: возможно, на некоторых задачах оптимум лежит в районе нескольких единиц, а не сотен.

Но даже если бы порог насыщения был известен, остаётся вопрос цены: сколько стоит прогнать 1024 агента?

Скрытая цена: почему отсутствие данных о затратах меняет выводы

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

Вместо расчёта стоимости имеет смысл сформулировать вопросы, на которые стоит получить ответ перед внедрением. Сколько токенов тратит один воркер на типичной задаче? Как масштабируется потребление при росте числа агентов? Есть ли данные о соотношении затрат и прироста pass rate? Если авторы не раскрывают эти цифры, их придётся измерять самостоятельно на своих задачах.

Практические критерии: когда децентрализация оправдана, а когда центральный оркестратор дешевле

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

Ключевой критерий — не «сколько агентов я могу запустить», а «какой минимальный масштаб даёт достаточный прирост на моих задачах». Промежуточные конфигурации (16–64 агента) могут дать большую часть выигрыша при меньшей сложности, но это гипотеза, а не подтверждённый официальными данными факт: в прочитанных источниках нет систематических замеров на этих масштабах. Наблюдение Qiita о регрессиях на малых масштабах напоминает: больше — не всегда лучше, и оптимум может оказаться неожиданно низким.

Что проверить перед тем, как пробовать Agensh в своей инфраструктуре

Код открыт под MIT, есть Docker Compose и baseline для одного агента. Но полноценное воспроизведение на 1024 агентах требует 16 узлов по 64 агента и шестичасового бюджета на задачу. Автор Qiita отмечает, что официальные скрипты рассчитаны на Linux; на Mac он запускал только малые конфигурации. Перед запуском стоит проверить доступность узлов, совместимость с вашими моделями (Copilot, Pi, Codex, Claude Code) и бюджет токенов.

Отдельного внимания требует правовой статус. Microsoft* 2 октября 2026 года включена Роскомнадзором в реестр организаторов распространения информации (ОРИ). Это не запрет продукции компании, но накладывает обязательства по хранению данных пользователей; неисполнение может привести к штрафам и потенциальной блокировке сервисов. Для пользователей риски оцениваются как минимальные, поскольку компания свернула коммерческие сервисы в России ещё в 2022 году, но при планировании инфраструктуры это стоит учитывать.

Вывод: 1024 — это не ответ, а вопрос

Agensh подтверждает, что децентрализованная самоорганизация кодирующих агентов технически возможна и масштабируется до 1024 воркеров. Но относительный прирост скромнее, чем подразумевает заголовок, точка убывающей отдачи не названа, а стоимость масштабирования не раскрыта. Разумная стратегия — не гнаться за максимальным масштабом, а тестировать промежуточные конфигурации на своих задачах и сравнивать не только pass rate, но и совокупную стоимость токенов. Децентрализация — инструмент для задач, допускающих параллельное дробление, а не универсальная замена оркестратору.

* Microsoft 2 октября 2026 года включена Роскомнадзором в реестр организаторов распространения информации (ОРИ). Это не запрет продукции компании, но накладывает обязательства по хранению данных пользователей; неисполнение может привести к штрафам и потенциальной блокировке сервисов.