AOS-Bench показал: агенты с разницей 0,6 пункта доставляют 54% и 68% задач

Кодинг-агенты постепенно превращаются из исполнителей разовых запросов в постоянных помощников, которым скидывают поток работы: сборку, обработку данных и багфикс одновременно, причём всё на одной машине. Команда авторов из пяти человек во главе с Erle Zhu выпустила AOS-Bench, бенчмарк, который оценивает агентную систему именно как менеджера такой нагрузки. Главный результат: успех в изоляции плохо предсказывает успех в потоке. На тяжёлых нагрузках каждая из пяти протестированных систем теряет от 13 до 23 пунктов.

Почему привычные тесты слепы к очереди

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

AOS-Bench устроен так, что проверенные задачи поступают с течением времени и должны быть доставлены под общими ограничениями CPU и памяти. Те же задачи, выполненные по одной, служат эталоном для конкретной системы. Разница между изолированным и потоковым результатом показывает, сколько способности агента теряется на управлении.

Где теряются очки

Авторы протестировали пять пар «модель–харнес». Картина получилась неровной:

• на тяжёлых нагрузках каждая система теряет 13–23 пункта относительно изолированного успеха;
• на средних нагрузках системы расходятся на 11 пунктов в изолированном успехе, но уже на 26 пунктов в потоковом;
• две системы с разницей 0,6 пункта в изоляции доставляют 54% и 68% одних и тех же задач;
• при последовательной диспетчеризации 73% задач тяжёлой нагрузки остаются невзятыми в работу;
• фиксированная конкурентность, равная двум, отстаёт от лучшей политики с управлением со стороны агента не более чем на 4 пункта и на средних, и на тяжёлых нагрузках;
• при любой политике медианная загрузка CPU остаётся ниже 30% от выделенных ядер, пока задачи ждут своей очереди.

Вмешательства в политику исполнения показали, что значительная часть разрыва объясняется приёмом задач. Агент просто не успевает или не решает взять работу, которая лежит в очереди. Качество самого решения здесь вторично.

Простая очередь против умного менеджера

Самый неудобный вывод касается сложности. Можно было ожидать, что агент, который сам планирует перекрытие задач и распределяет ресурсы, заметно выиграет у примитивной схемы. На деле фиксированный лимит из двух одновременных задач приближается к лучшему агентскому управлению на расстояние в четыре пункта. При этом машина в основном простаивает: ядра заняты менее чем на 30% по медиане, хотя в очереди есть невыполненное.

Значит, узкое место лежит в решении «взять или подождать», а вовсе не в нехватке железа. Агенты слишком осторожны или плохо оценивают, что можно запускать вместе, и оставляют ресурсы неиспользованными.

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

Практический вывод для команд, которые разворачивают постоянных кодинг-агентов: выбирать систему по одиночным бенчмаркам недостаточно. Стоит проверить, как она ведёт себя при нескольких параллельных заданиях на реальной машине. Нужно смотреть долю задач, которые вообще были взяты в работу, и загрузку CPU во время ожидания. Прежде чем строить сложную оркестрацию, полезно сравнить её с жёсткой очередью на два слота: по данным AOS-Bench, такая базовая линия оказывается удивительно сильной. Разработчикам харнесов тест указывает на конкретную точку улучшения: политику приёма задач, где теряется до 73% потенциальной работы.

Препринт опубликован на arXiv 23 октября 2026 года, вторая версия вышла 27 октября.