AOS-Bench проверил ИИ-агентов: при параллельных задачах качество падает на 13-23 пункта

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

Как устроен эксперимент

Тестировали пять связок "модель + агентская оболочка": Claude Opus 5, GPT-5.6-sol, DeepSeek-V4-Pro, GLM-5.3 и Kimi-K3. Каждой системе давали ограничение в 4 процессорных ядра и 8 гигабайт памяти — в одном случае задачи поступали строго по одной (это эталон "индивидуальной" производительности), а в другом — несколько задач приходили друг за другом с интервалами, как в реальной работе ("поток"). Было два уровня сложности: средний (10 задач на один прогон) и тяжёлый (20 задач).

Что показали цифры

При тяжёлой нагрузке каждая из пяти систем потеряла от 13 до 23 процентных пунктов успешных решений по сравнению с тем, что та же система показывает на тех же задачах по одной. Лучше всех справился Claude Opus 5: успешность упала с 75,5% на отдельных задачах до 62,5% в потоке — то есть система сохранила примерно 83% своей базовой способности решать задачи. Остальные четыре системы сохранили лишь 61–75% от своего базового уровня.

При средней нагрузке результаты оказались даже более показательными: насколько хорошо система решает отдельные задачи, почти не предсказывает, насколько хорошо она справится с потоком. У GPT-5.6-sol самый высокий результат на отдельных задачах — 85,3%, но в потоке он теряет 14,5 пункта. А у Kimi-K3 базовый результат на 11 пунктов ниже, но в потоке он теряет всего 6,3 пункта. Самый яркий пример: две системы, чья успешность на отдельных задачах отличается всего на 0,6 пункта (74,9% против 74,3%), в потоке выдают 68,1% и 53,9% — разрыв почти в 15 пунктов там, где его не должно быть.

Почему так происходит

Главная причина — не в том, что агенты хуже решают сами задачи. Авторы разбили каждую потерю очков на причины и обнаружили: большую часть разрыва на тяжёлой нагрузке (16–26 пунктов из 16–23 у четырёх систем) составляют задачи, которые агент вообще не взял в работу, не успел закончить до истечения времени или закончил уже после того, как память переполнилась. Собственно ошибки при выполнении взятых задач дают потерю не больше 1,3 пункта. Проще говоря: системы спотыкаются не на решении задач, а на том, чтобы вообще взяться за них вовремя.

Особенно показательны GLM-5.3 и DeepSeek-V4-Pro — в части прогонов они просто переставали брать новые задачи и начинали работать по одной, из-за чего 25% и 48% поступивших задач остались нетронутыми (у Claude Opus 5 — 0%). При этом если задачи подавать все сразу принудительно (без серийной очереди), системы забирают в работу три четверти задач — то есть проблема не в сложности задач, а именно в логике приёма новой работы.

Неожиданный вывод про "умное" управление

Казалось бы, решение — научить агента умнее планировать параллелизм. Но эксперимент показал обратное: простейшее правило "выполнять ровно две задачи одновременно без всякого анализа" почти не уступает (разница до 4 пунктов) лучшим стратегиям, где агент сам решает, что и когда запускать. При этом независимо от стратегии управления процессор, пока задачи ждут своей очереди, используется меньше чем на 30% от выделенных четырёх ядер — ресурсы простаивают, даже когда работы полно.

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