Масштабирование команд агентов: достижение передовых результатов за 30% стоимости

Команды агентов создают программное обеспечение

За последний год команды агентов-программистов прошли путь от интересных демонстраций до создания крупномасштабных программных проектов. Шестнадцать агентов Claude написали компилятор C на 100 000 строк кода, способный собирать ядро Linux, в рамках проекта, который потребовал около 2000 сессий агентов и 20 000 долларов США на оплату API [1]. Cursor запустил сотни агентов, которые вместе написали веб-браузер с нуля — более миллиона строк кода — примерно за неделю [2]. Bun был перенесен с Zig на Rust за 11 дней, при этом на пике параллельно работали 64 агента Claude [3].

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

Однако их сравнение мало что говорит о том, какие проектные решения были важны и какова их стоимость по сравнению с одним агентом. Исследование компании Factory, посвященное их собственной мультиагентной системе, которая циклически использует оркестратор, исполнителя и валидатор в фиксированном цикле, показывает, насколько велики могут быть эти затраты [4]. В одной из задач, пересборке геопространственной библиотеки GDAL, их команда из трех ролей более чем удвоила результат, достигнутый одним агентом, почти достигнув поведенческого паритета с эталонной программой, но при этом стоила в 14 раз дороже и заняла в 13 раз больше времени.

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

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

Контролируемый тестовый стенд

Минималистичная обвязка

Мы создали намеренно минималистичную обвязку, вдохновленную mini-SWE-agent [5], чтобы иметь возможность изменять по одному проектному решению за раз. Каждый агент работает через простой инструмент bash в одном рабочем пространстве, общем для всей команды. Один агент, ведущий, получает задачу и распределяет работу с помощью инструмента delegate_agent. Исполнитель видит только порученную ему подзадачу и отчитывается о ее выполнении. Получив задачу, ведущий динамически решает, сколько исполнителей задействовать, что именно делает каждый из них и как консолидировать полученные результаты.

Каждый вызов delegate_agent либо запускает нового исполнителя с «чистым» контекстным окном, либо возобновляет работу исполнителя, которого ведущий уже использовал ранее. Возобновленный исполнитель сохраняет свой предыдущий контекст, поэтому ведущий может продолжить работу с агентом, который уже знаком с частью программы. Например, ведущий может попросить исполнителя исправить ошибки в написанном им коде, вместо того чтобы вводить в курс дела нового исполнителя с нуля.

Исходя из этого, мы варьируем пять параметров:

• Где ведущий использует исполнителей. Мы даем ведущему агенту инструкции с помощью двух основных промптов, которые различаются степенью предоставляемого руководства. Минимальный промпт сообщает ведущему, что он руководит командой, и просит его давать исполнителям четкие, независимые задачи, но оставляет все остальное — от количества исполнителей до способа декомпозиции задачи — на усмотрение ведущего. Промпт PIV добавляет структурированный рабочий процесс исследования и планирования (P), реализации (I) и проверки (V), и требует от ведущего использовать исполнителей на всех трех этапах.
• Как ведущий ожидает результатов. Блокирующий ведущий ждет отчетов от своих исполнителей и в это время ничего не делает. Асинхронный ведущий продолжает работать, пока они выполняются, и имеет два дополнительных инструмента: wait_for_updates для ожидания следующего отчета и list_agents для проверки состояния своих исполнителей.
• Какие модели играют какую роль. Должен ли каждый агент в команде использовать самую мощную и дорогую модель? Мы проверяем это с помощью двух типов команд. В однородной команде ведущий и все его исполнители работают на одной и той же модели. В неоднородной команде ведущий сохраняет мощную модель, а исполнители работают на более дешевой. Представьте старшего инженера, который направляет работу и принимает критические решения, в то время как младшие инженеры выполняют основную часть рутинной работы.
• Сколько исполнителей в команде. Всегда ли большая команда лучше? Чтобы выяснить это, мы сравниваем две конфигурации. В первой ведущий сам решает, сколько исполнителей ему нужно. Во второй мы фиксируем размер команды на уровне двух, четырех, восьми или шестнадцати исполнителей и смотрим, как меняются результат и стоимость по мере роста команды.
• Как агенты общаются. По умолчанию все общение идет через ведущего, который распределяет каждую подзадачу и получает отчет каждого исполнителя. В одной серии запусков мы предоставляем агентам инструмент send_message и позволяем им общаться друг с другом напрямую.

Рисунок 2. Два ведущих распределяют одни и те же подзадачи, и выполнение каждого исполнителя занимает одинаковое время. Блокирующий ведущий простаивает, пока исполнители не пришлют отчеты. Асинхронный ведущий продолжает работать и начинает второй раунд, как только приходят отчеты по первому. Столбцы — это интервалы работы, направленные вниз стрелки — вызовы delegate_agent, а направленные вверх стрелки — отчеты, возвращаемые ведущему. Тайминги приведены для иллюстрации.

ProgramBench

Мы тестируем эти варианты на ProgramBench [6], бенчмарке из 200 программ для пересборки с нуля. В каждой задаче агент начинает с пустого рабочего пространства, имея исполняемый файл исходной программы, который он может запускать, но не читать, а также документацию к этой программе. Он должен исследовать программу, чтобы обнаружить ее интерфейс, граничные случаи и поведение, а затем написать новую реализацию, которая ведет себя так же. Мы оцениваем каждую задачу по доле пройденных поведенческих тестов из скрытого набора и усредняем этот показатель по всем задачам, чтобы получить результат, который мы приводим далее.

Задачи варьируются от небольших утилит командной строки, таких как jq и ripgrep, до крупных систем, таких как SQLite, FFmpeg и интерпретатор PHP. Самые сложные из них остаются далеко за пределами досягаемости. В задаче FFmpeg лучший результат в публичной таблице лидеров проходит около 10% тестов.

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

Рисунок 3. Одна из задач ProgramBench — dsq, инструмент командной строки, который выполняет SQL-запросы к JSON, CSV и другим файлам данных. На верхней панели показан одиночный агент Sol с минимальным промптом, а на нижней — асинхронная команда Sol с промптом PIV. Одиночный агент пишет программу как один файл Python, в то время как команда разбивает ее на модули, некоторые из которых пишутся исполнителями. Панель команды отображает файлы одного запуска, команды упрощены по сравнению с собственными командами агентов, а тайминги приведены для иллюстрации.

Мы сосредоточились в основном на трех моделях GPT-5.6: Luna, Terra и Sol, расположенных в порядке возрастания возможностей и стоимости. Если не указано иное, мы запускали каждую конфигурацию трижды на всех 200 задачах ProgramBench и приводим средние значения по трем прогонам для вознаграждения, общей стоимости и общего времени выполнения. Оценка отдельной задачи варьировалась от прогона к прогону со стандартным отклонением около 6 баллов, но средний показатель по всему бенчмарку был гораздо стабильнее: стандартное отклонение составило 0,5 балла для типичной конфигурации и 1,4 для самой «шумной». Каждая конфигурация запускалась на одних и тех же задачах, поэтому мы сравниваем каждую команду с ее одиночным базовым вариантом для каждой задачи и приводим 95% доверительные интервалы для этих различий.

Мы также запустили Commit0-Lite [7], набор из 16 библиотек Python, реализации которых были удалены. Агенту предоставляется скелет репозитория каждой библиотеки, документация и модульные тесты, и он должен написать код так, чтобы тесты проходили. В ProgramBench агент должен выяснить, что именно нужно создать, запустив исходную программу. В Commit0 эти предоставленные материалы дают четкие указания, поэтому бенчмарк показывает, приносят ли те же этапы пользу, когда спецификация уже задана. Поскольку задач всего 16, мы используем его в качестве дополнительной проверки.

Команды превосходят одиночных агентов, но требуют затрат

Мы начнем с самого простого сравнения: одиночный агент Sol против команды агентов Sol. При использовании того же минимального промпта блокирующая команда в среднем проходила 61,8% тестов, по сравнению с 52,1% у одиночного агента. Предоставление одиночному агенту промпта PIV частично сократило этот разрыв (57,7%), но блокирующая команда с промптом PIV все равно оказалась примерно на 5 пунктов впереди (63,1%).

Мы также запустили оба промпта с асинхронным ведущим, который может продолжать работу, пока работают его исполнители. Все четыре команды Sol стоили в 4–7 раз дороже, чем соответствующий одиночный агент. С промптом PIV асинхронная команда завершила работу на 19,5% быстрее, чем блокирующая, и достигла примерно такого же вознаграждения.

При использовании минимального промпта асинхронная команда завершила работу на 60% быстрее, но ее ведущий выполнял больше работы самостоятельно, делегируя задачи лишь 4,4 раза за задачу, по сравнению с 6,1 раза у блокирующего ведущего. Его команда получила лишь на 3,8 балла больше, чем одиночный агент с минимальным промптом, против 9,7 балла у блокирующей команды, а с показателем 55,9% она даже уступила одиночному агенту с промптом PIV (57,7%).

Рисунок 4. Среднее вознаграждение в зависимости от стоимости вывода (слева) и времени выполнения (справа), каждое из которых является общим для всех 200 задач, усредненным по трем прогонам. Погрешности представляют собой 95% интервалы парной разницы каждой команды по каждой задаче относительно соответствующего одиночного агента.

Исполнители наиболее полезны при планировании

Чтобы выяснить, где исполнители приносят наибольшую пользу, мы поручили ведущему делегировать подзадачи исполнителям только на одном этапе, выполняя остальные два этапа самостоятельно. На этапе исследования и планирования (P) исполнители запускают программу, чтобы изучить ее поведение и составить план, а ведущий реализует и проверяет его. На этапе реализации (I) исполнители пишут код. На этапе проверки (V) исполнители тестируют реализацию ведущего.

Планирование стало явным победителем. Среди асинхронных команд ведущий, делегирующий только планирование, сравнялся по вознаграждению с тем, который делегирует каждый этап (63,6% против 63,2%), при вдвое меньших затратах ($249 против $510). Если измерять вознаграждение, полученное на каждые $100 дополнительных затрат, планирование оказалось примерно в два раза эффективнее следующего по результативности этапа.

Рисунок 5. Асинхронные команды Sol, делегирующие один этап или все три. Средние значения по трем прогонам. Линии идут от одиночного агента PIV к каждой команде. Пунктирная стрелка идет от команды PIV к команде планирования, которая стоит вдвое дешевле. Погрешности представляют собой парные 95% интервалы относительно одиночного агента PIV.

Например, в задаче dsq одиночный агент с промптом PIV в среднем проходил 60% тестов. Команды, делегирующие только планирование, проходили 79% с асинхронным ведущим и 76% с блокирующим, причем каждый из их шести прогонов превзошел любой одиночный прогон. Команды, делегирующие реализацию или проверку, проходили только от 58% до 71%.

Причина кроется в дизайне бенчмарка. Целевая программа — это «черный ящик», поэтому ее поведение нужно обнаруживать путем запуска. Исполнители планирования делают это параллельно, каждый исследует разную часть интерфейса программы и передает ведущему то, что удалось найти. Затем ведущий сам пишет код, имея гораздо более полное представление о том, что нужно создать.

Другие работы сообщают о схожих выводах. Валидатор Factory начинает с исследования эталонной программы, чтобы создать исполняемый стандарт того, что означает «готово», прежде чем будет написан какой-либо код [4]. Команда C-компилятора Карлини вышла из тупика при работе с ядром Linux, используя GCC в качестве оракула для сравнения [1]. В каждом случае узким местом было точное понимание того, что нужно создать, и вложение вычислительных мощностей именно туда принесло результат.

Commit0 показывает другую сторону этого процесса. Там репозиторий уже определяет, что нужно создать, и реализация, а не планирование, была наиболее эффективным этапом для делегирования в восьми из десяти наших командных конфигураций. Однако передовые модели, такие как GPT-5.6 Sol, близки к насыщению Commit0: способный одиночный агент уже проходит все тесты в 12 из 16 задач, что оставляет только четыре задачи, где команда могла бы показать лучший результат, поэтому мы рассматриваем это как предположение, а не как окончательный вывод.

Исполнители планирования могут быть недорогими

Если исполнители планирования в основном собирают информацию для ведущего, должны ли они быть мощными моделями? Мы оставили Sol в качестве ведущего и заменили его исполнителей планирования на Luna, гораздо более дешевую модель. Команда уступила несколько баллов команде, полностью состоящей из Sol (60,5% против 63,6%). Однако по сравнению с одиночным агентом она сохранила 47,5% прироста команды Sol при затратах всего 13,9% от ее дополнительных расходов, поэтому каждый доллар принес более чем в три раза больше вознаграждения.

Теперь сравним это с тем, что мы могли бы создать, не анализируя задачу. Естественным сравнением была бы настройка PIV, где мы говорим сильному ведущему использовать сильных исполнителей на каждом этапе. Эта команда достигла 63,2%, но при стоимости $510. Поняв, что узким местом ProgramBench является обнаружение того, что делает программа, и назначив дешевых исполнителей только на планирование, мы приблизились к этому результату на 2,7 балла при стоимости в пять раз меньше.

Рисунок 6. Команды с рисунка 5 вместе с двумя командами, которые объединяют ведущего Sol с исполнителями Luna (меньшие точки исполнителей), одна из которых делегирует планирование, а другая — все три этапа. Все команды асинхронные. Пунктирная стрелка идет от команды планирования, полностью состоящей из Sol, к команде планирования Luna, с указанием доли прироста команды Luna от команды Sol и дополнительных затрат, измеренных относительно одиночного агента PIV. Погрешности представляют собой парные 95% интервалы относительно одиночного агента PIV.

Чтобы отделить вклад ведущего от вклада исполнителей, мы зафиксировали исполнителей на уровне Luna и повысили уровень ведущего с Luna до Terra и до Sol. Вознаграждение росло с каждым обновлением: с 42,5% до 51,6% и до 60,5% (Рисунок 7), и каждая команда превзошла одиночного агента, работающего на модели своего ведущего (37,4%, 47,2% и 57,7%). Однако дешевые исполнители не смогли компенсировать слабого ведущего. Ведущий Terra с исполнителями Luna все равно уступил одиночному агенту Sol (51,6% против 57,7%).

Рисунок 7. Среднее вознаграждение в зависимости от общих затрат на логический вывод (логарифмическая шкала) для одиночных агентов PIV и асинхронных команд планирования. Гомогенные команды, в которых каждый агент использует одну и ту же модель, обозначены точками одинакового размера, а гетерогенные команды, объединяющие более сильного руководителя с исполнителями Luna, — меньшими точками исполнителей. Заштрихованная полоса объединяет три команды с исполнителями Luna.

Это согласуется с недавней работой Meta по мета-рассуждениям [8]. Их система разделяет агента на контроллер, который решает, над чем работать дальше и на каких предыдущих результатах основываться, и исполнителей, которые выполняют эту работу. При тех же исполнителях и том же бюджете более совершенный контроллер получил более высокий балл на ProgramBench (71,5% против 63,7% с GPT-5.5), и его преимущество росло по мере увеличения бюджета, в то время как показатели более простых контроллеров выравнивались. Как в их, так и в нашей настройке, более сильный агент, принимающий решения, повышал результативность тех же исполнителей.

Масштабирование количества исполнителей

До сих пор руководитель сам выбирал, сколько исполнителей использовать. Чтобы увидеть, что дают дополнительные исполнители, мы зафиксировали размер команды, предоставив руководителю Sol двух, четырех, восьми или шестнадцать исполнителей Luna. Команды планирования улучшали общую производительность по мере своего роста: с 59,6% при двух исполнителях до 61,8% при шестнадцати. Даже при шестнадцати исполнителях планировщики Luna стоили 155 долларов, что на 38% меньше, чем команда планирования, состоящая только из Sol (249 долларов), и на 70% меньше, чем команда, состоящая только из Sol, которая делегирует все три этапа (510 долларов), при этом оставаясь в пределах двух пунктов от обеих.

Исполнители по реализации и проверке вели себя по-разному. Их показатели улучшались при переходе от двух к четырем исполнителям, а затем немного снижались по мере добавления новых. Анализ выполнения показывает причину. Каждый планировщик запускал эталонную программу около семи раз, независимо от размера команды, поэтому большее количество планировщиков показывало руководителю больше вариантов поведения программы. В целом по команде количество запусков эталонной программы выросло с 15 при двух планировщиках до 109 при шестнадцати, а объем отчетов планировщиков увеличился с 17 000 до 75 000 символов.

Дополнительные исполнители по реализации не добавили такой информации. Каждый из них получал более тонкий фрагмент плана, и объем заданий сократился с примерно 1400 символов на исполнителя при двух реализаторах до 440 при шестнадцати. Доля кода, приходящаяся на исполнителей, выросла с 54% при двух до 85% при шестнадцати, но руководитель проверял объединенную программу по эталону не чаще — от 5 до 6 запусков, независимо от того, объединял ли он две части или шестнадцать.

Рисунок 8. Вознаграждение асинхронного руководителя Sol с 2–16 исполнителями Luna в зависимости от размера команды (слева) и общей стоимости (справа). Каждый маркер исполнителя Luna имеет одну маленькую точку на исполнителя. Маркеры с точками одинакового размера — это команды, состоящие только из Sol, размер которых определяется руководителем. Каждая конфигурация фиксированного размера выполняется один раз. Погрешности представляют собой парные 95% интервалы относительно одиночного агента PIV.

Изучение коммуникации

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

В наших запусках мы заметили, что канал использовался в основном для отчетов «вверх». В командах Sol с промптом PIV 84% сообщений отправлялись от исполнителей к руководителю, содержа промежуточные выводы, предлагаемые интерфейсы, результаты сбоев тестов и вопросы. Сообщения между исполнителями составляли в среднем менее одного на задачу и возрастали примерно до одного на задачу только тогда, когда исполнителям давали указание относиться друг к другу как к сотрудникам.

Более сильные модели использовали канал чаще. Агенты Sol писали в 3,4–5 раз больше текста сообщений, чем агенты Luna, а руководители Sol отправляли своим исполнителям больше указаний. Однако вознаграждение осталось прежним для команд Sol и Terra, а команды Luna потеряли от 4 до 7 пунктов. Одно из возможных объяснений заключается в том, что поток промежуточных обновлений перегружает более слабого руководителя, в то время как более сильный может его усвоить. Другое заключается в том, что исполнители Luna плохо использовали инструмент: около половины их вызовов send_message были сформированы неправильно и отклонены системой.

Рисунок 9. Асинхронные команды, состоящие только из Luna, только из Terra и только из Sol, с инструментом send_message. Заштрихованные сегменты — это отклоненные вызовы. Слева: количество сообщений на задачу. В центре: объем текста сообщений на задачу. Справа: изменение вознаграждения по сравнению с той же командой без инструмента, с парными 95% интервалами.

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

В противовес этому, Park et al. обнаружили, что когда агенты разделяют одну цель и общее рабочее пространство без фиксированных ролей, команда из пяти общающихся агентов сравнялась с лучшим из 33 независимых агентов на ARC-AGI-3 [9]. Ключевым ингредиентом, который они называют «проверенным обменом прогрессом», является то, что агенты могут проверять, является ли открытие товарища по команде действительно улучшением. Agensh, самоорганизующаяся система от Microsoft, также сообщает о сотрудничестве, возникающем само по себе в больших плоских командах 10.

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

Как другие модели используют команду

Мы также протестировали пять других моделей с идентичными инструментами и промптами на подмножестве из 30 задач ProgramBench (10 простых, 10 средних и 10 сложных задач) и сравнили их с запусками GPT-5.6 на тех же задачах. Для каждой модели мы провели по одному испытанию для одиночных, блокирующих и асинхронных команд, используя как минимальные, так и PIV-промпты. При одном запуске на модель различия в несколько пунктов могут быть шумом.

Модели использовали команду очень по-разному. Команды GPT-5.6 часто делегировали задачи и получали до 6,9 пунктов преимущества по сравнению со своим лучшим одиночным агентом, и большинство их командных конфигураций оказались в выигрыше. Claude Opus 4.8 вел себя примерно так же, получив 5,9 пунктов с промптом PIV и асинхронным руководителем. Claude Opus 4.7 редко делегировал задачи, максимум 1,3 раза на задачу, и его команды мало что выиграли по сравнению с лучшим одиночным агентом. Claude Haiku 4.5 и Gemini 3.7 Flash делегировали задачи так же охотно, как GPT-5.6, но ничего от этого не выиграли. Gemini 3.8 Flash получил 3,1 пункта с промптом PIV и блокирующим руководителем, но потерял 4,6 с асинхронным.

Рисунок 10. Делегирование на задачу (слева) и командный прирост по сравнению с лучшим одиночным агентом (справа) на подмножестве из 30 задач ProgramBench. Для каждой модели прирост измеряется относительно того одиночного агента, который набрал больше баллов с минимальным или PIV-промптом. Каждый маркер — это одна из четырех командных конфигураций. Результаты GPT-5.6 усреднены по трем запускам на этих 30 задачах. Другие модели — это одиночные запуски, поэтому различия менее чем в 5 пунктов могут быть шумом.

Чтобы команда могла помочь, должны совпасть два условия. Лид должен принять решение о делегировании, и он должен эффективно использовать полученные результаты. Opus 4.7 не справился с первым, а Haiku 4.5 и Gemini 3.7 Flash — со вторым. Две модели Opus показывают, насколько сильно это может меняться внутри одного семейства. Opus 4.7 почти не делегировал задачи, в то время как более новая модель Opus 4.8 распределяла работу между членами команды почти так же, как GPT-5.6, и извлекала из этого выгоду. Являются ли более новые модели в целом лучшими руководителями команд — это вопрос, который мы не можем решить одним запуском для каждой модели.

Модели также по-разному структурировали свои программы. GPT-5.6 переписывала большинство программ на Python (от 70% до 93% представленных решений), независимо от того, на каком языке был написан оригинал. Модели Claude переписывали программу на исходном языке в 72%–90% случаев, а модели Gemini Flash занимали промежуточное положение (от 43% до 70%). Claude Opus 4.8 и обе модели Gemini также распределяли свои программы по большему количеству файлов: медианное значение составило от 5 до 11 исходных файлов на задачу против 1–3 у GPT-5.6.

Что дальше

Наши результаты указывают на несколько направлений, которые нас воодушевляют.

• Иерархия против самоорганизации. В ProgramBench один лид может держать в поле зрения всю программу, поэтому иерархия работает хорошо. Но команда из тысяч агентов, работающая неделями, вероятно, перерастет то, что может отследить один лид. Такая команда должна будет решать, кто распределяет роли, как передается информация и когда проводить реорганизацию. В таком масштабе агентам нужно будет делиться тем, что они узнали, напрямую, возможно, через протоколы, которые они изобретут сами. Предварительное обучение уже дает им базовые навыки, такие как отчетность, запрос информации и делегирование. Возникнет ли из этого реальная координация по мере масштабирования моделей или этому нужно будет обучать — открытый вопрос, который мы считаем центральным для масштабирования логического вывода.
• Альтернативные формы коммуникации. В наших запусках сообщения в основном повторяли то, что лид и так получил бы в отчетах. Общие цели, общие журналы прогресса или сообщения, содержащие проверяемые доказательства, могут дать агентам больше причин для общения.
• Адаптация к задаче. Планирование оправдало себя в ProgramBench, потому что спецификацию нужно было обнаружить, но в других задачах «узкое место» может находиться в другом месте. В Commit0 больше всего помогла реализация. Лид, который может определить, на каком этапе застряла его собственная задача, мог бы перенаправить туда исполнителей, не дожидаясь указаний, какой этап делегировать.
• Обучение моделей лидерству. Модели сильно различались по тому, насколько эффективно они использовали команду, что говорит о том, что лидерство — это навык, которому можно обучить. Лид, который умеет хорошо делегировать, взвешивать противоречивые отчеты и знает, когда нужно подождать, может получить больше от тех же самых исполнителей.

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

Сноски

• Когда размер команды динамический, лид может запустить не более пяти отдельных исполнителей на задачу, а после этого он должен возобновлять работу тех, кто уже есть. Увеличение лимита до двадцати изменило то, как лид делегировал задачи, но не то, насколько успешно работала команда. Лид запускал больше новых исполнителей вместо возобновления старых, общее количество делегирований изменилось максимум на 0,9 на задачу, а вознаграждение изменилось в диапазоне от −1,6 до +1,6 балла.

Когда размер команды динамический, лид может запустить не более пяти отдельных исполнителей на задачу, а после этого он должен возобновлять работу тех, кто уже есть. Увеличение лимита до двадцати изменило то, как лид делегировал задачи, но не то, насколько успешно работала команда. Лид запускал больше новых исполнителей вместо возобновления старых, общее количество делегирований изменилось максимум на 0,9 на задачу, а вознаграждение изменилось в диапазоне от −1,6 до +1,6 балла.