Команды агентов за $155 вместо $510: Cohere нашла, где делегировать работу выгодно

Агенты переехали в production

За последний год команды программирующих агентов вышли из статуса интересных демонстраций в реальные промышленные проекты. Шестнадцать Claude-агентов написали C-компилятор объёмом 100 тыс. строк кода, способный собирать ядро Linux, потратив около 2 тыс. сессий и $20 тыс. API. Команда Cursor запустила сотни агентов, совместно написавших веб-браузер больше чем на миллион строк кода за неделю. Проект Bun в 11 дней перенёс кодовую базу с языка Zig на Rust, используя 64 Claude-агентов, работавших параллельно.

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

Сравнивать эти проекты значило бы ничего не сказать о том, какие решения имели вес и во сколько они обошлись. Factory опубликовала исследование собственной трёхролевой системы (оркестратор → реализатор → валидатор в цикле): на одной задаче (восстановление библиотеки GDAL) её команда удвоила результат одного агента, но обошлась в 14 раз дороже и заняла в 13 раз больше времени.

Где делегировать — важнее, чем сколько агентов

Cohere построила контролируемый стенд на основе mini-SWE-agent: каждый агент работает через bash-интерфейс в едином рабочем пространстве, лидер раздаёт задачи через инструмент delegate_agent, рабочие видят только свою подзадачу. Исследовали пять переменных:

1. Где лидер использует рабочих: минимальный prompt просто приказывает командовать командой; структурированный (P-I-V) добавляет явные стадии — планирование, имплементацию, верификацию.
2. Как лидер ждёт: синхронный (ждёт, пока все доложат) или асинхронный (продолжает сам работать, проверяя обновления по требованию).
3. Какие модели на каких ролях: гомогенные команды (все на Sol) против гетерогенных (лидер на Sol, рабочие на Luna).
4. Размер команды: лидер сам решает, сколько нужно рабочих, или размер зафиксирован на 2, 4, 8, 16.
5. Коммуникация: через лидера (по умолчанию) или напрямую между агентами.

Тесты проводили на бенчмарке ProgramBench — 200 программ от утилит (jq, ripgrep) до сложных систем (SQLite, FFmpeg, PHP-интерпретатор). Агент видит только рабочий бинарник и документацию оригинальной программы, должен обратным инжинирингом выяснить поведение и написать новую реализацию. Оценка — процент пройденных тестов поведения.

Планирование платит в 2× раза больше

Солидная команда Sol-агентов обошла одного агента на 9,7 точки (61,8% против 52,1%), но обошлась в 4–7 раз дороже. Асинхронный лидер экономит время: с PIV-prompt заканчивается на 19,5% быстрее при том же результате.

Основное открытие: когда лидер делегировал только планирование (Luna-агенты исследуют программу, выясняют поведение, набрасывают план), он добился 63,6% корректности за $249. Это ровно половина от $510, которую тратит тим, делегирующий все три этапа, но теряет всего 0,4 точки (63,2% против 63,6%). Имплементация и верификация дали заметно меньше — 58–71% на тех же 16 агентах.

Причина в дизайне ProgramBench: целевая программа — чёрный ящик, поведение надо открывать тестированием. Рабочие-планировщики параллельно зондируют разные части интерфейса, лидер собирает отчёты и пишет код сам. Это параллелизм, дающий максимум окупаемости.

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

Вторичный бенчмарк Commit0-Lite (16 Python-библиотек с удалённой реализацией, но полной документацией и тестами) подтвердил: когда spec дан явно, стадия планирования остаётся критичной.