«61,8 % за $155 против 63,2 % за $510»: Cohere измерила, где в команде кодинг-агентов окупаются дополнительные агенты

Что именно проверили

Команды кодинг-агентов уже собирают большие проекты, но, как отмечают авторы, сравнение таких проектов между собой ничего не говорит о том, какие решения в организации команды имели значение и во что они обошлись по сравнению с одиночным агентом. Чтобы ответить на этот вопрос, Cohere Labs построила управляемый стенд и меняла в нём по одному решению.

Стенд намеренно минимальный и вдохновлён mini-swe-agent: каждый агент работает через простой bash-инструмент в одном общем рабочем каталоге, один агент-ведущий (lead) получает задачу и раздаёт работу инструментом delegate_agent, а работник видит только свою подзадачу и отчитывается по её завершении. Ведущий сам решает, сколько работников запустить и что каждому поручить, а вызов delegate_agent либо поднимает нового работника с чистым контекстом, либо возвращает уже использованного — с сохранённым контекстом.

Проверка идёт на ProgramBench: 200 программ, которые нужно собрать заново, начиная с пустого каталога, имея на руках исполняемый файл оригинала, который можно запускать, но нельзя читать, и его документацию. Оценка — доля пройденных скрытых поведенческих тестов; задачи идут от утилит вроде jq и ripgrep до SQLite, FFmpeg и интерпретатора PHP, а лучший публичный результат на FFmpeg — около 10 % тестов. Дополнительно на 16 библиотеках Python проверяется Commit0-Lite, где спецификация уже дана, и ещё один набор — 30 задач ProgramBench (10 простых, 10 средних, 10 сложных) для сравнения разных моделей.

Основные модели — GPT-5.6 в трёх размерах Luna, Terra и Sol по возрастанию способности и цены; если не указано иное, каждая конфигурация прогонялась три раза на всех 200 задачах, а сравнения идут по парам задач с 95 % интервалами. Разброс одной задачи от прогона к прогону — около 6 пунктов, но среднее по бенчмарку устойчивее: около 0,5 пункта у типичной конфигурации.

Команда против одиночного агента

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

Плата за это названа прямо: все четыре команды Sol стоят от 4 до 7 раз дороже соответствующего одиночного агента. Асинхронный ведущий, который продолжает работать, пока работники выполняют задачи, при PIV-сценарии закончил на 19,5 % быстрее блокирующего при примерно том же результате.

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

Работники окупаются в разведке и планировании

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

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

Причина в конструкции бенчмарка: целевая программа — чёрный ящик, её поведение приходится выяснять запуском, а планировщики делают это параллельно, каждый изучая свою часть интерфейса и передавая ведущему находки — после чего код пишет уже сам ведущий, с гораздо более полной картиной. На Commit0, где спецификация задана репозиторием, картина обратная: там самой выгодной стадией для делегирования в восьми из десяти конфигураций оказалась реализация, но авторы называют это лишь намёком, потому что способный одиночный агент уже проходит все тесты на 12 из 16 задач.

Планировщики могут быть дешёвыми, ведущий — нет

Если планировщики в основном собирают информацию для ведущего, нужны ли им сильные модели? Заменив планировщиков Sol на значительно более дешёвую Luna, авторы потеряли немного: 60,5 % против 63,6 % у полностью Sol-команды. Но относительно одиночного агента такая команда сохранила 47,5 % прироста полностью Sol-команды всего за 13,9 % её дополнительных затрат — то есть каждый доллар принёс более чем втрое больше результата.

Сравнение с конфигурацией «по умолчанию»: команда, где сильному ведущему предписано использовать сильных работников на всех стадиях, дошла до 63,2 %, но за $510; распознав, что узкое место ProgramBench — выяснение того, что именно нужно построить, и поставив дешёвых работников только на планирование, авторы оказались в 2,7 пункта от неё за пятую часть цены.

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

Больше работников — не линейно лучше

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

Работники-реализаторы и проверяющие вели себя иначе: они улучшали результат при росте с двух до четырёх, а затем он немного снижался. Причина видна в прогонах: каждый планировщик запускал эталонную программу около семи раз независимо от размера команды, поэтому больше планировщиков показывали ведущему больше поведения оригинала — суммарное число запусков эталона выросло с 15 при двух планировщиках до 109 при шестнадцати, а отчёты — с 17 тыс. до 75 тыс. знаков.

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

Переписка агентов между собой не помогла

По умолчанию вся связь идёт через ведущего — он раздаёт подзадачи и получает отчёты. Авторы дали агентам инструмент send_message с возможностью писать любому другому работающему агенту: канал использовался в основном для отчётов наверх — в Sol-командах с PIV-подсказкой 84 % сообщений шли от работников к ведущему, а переписка между работниками не дотягивала до одного сообщения на задачу и поднималась лишь примерно до одного, когда работникам предлагали считать друг друга коллегами.

На результат это не повлияло: у команд Sol и Terra он не изменился, а Luna потеряла от 4 до 7 пунктов. Сильные модели писали в этот канал в 3,4–5 раз больше текста, чем Luna, а около половины вызовов send_message у Luna оказались неверно оформлены и были отклонены стендом.

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

Разные модели по-разному используют команду

На подмножестве из 30 задач авторы прогнали с одинаковыми инструментами и подсказками пять других моделей и сравнили их с GPT-5.6 на тех же задачах. 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 пункта с асинхронным. Авторы подчёркивают, что на этих 30 задачах у каждой модели был один прогон, поэтому разницы меньше примерно 5 пунктов могут быть шумом.

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

Главный вывод по моделям авторы сводят к двум условиям: ведущий должен решить делегировать, и он должен хорошо распорядиться тем, что вернулось. Opus 4.7 не справился с первым, а Haiku 4.5 и Gemini 3.7 Flash — со вторым, и насколько общим является улучшение ведущих в новых поколениях, по одному прогону на модель установить нельзя.

Что авторы считают следующим шагом

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

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

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