TL;DR
Когда агенту (Claude Code, Codex и подобным) подкидывают задачи потоком, он теряет заметную долю результата по сравнению с теми же задачами, выданными по одной. При этом сама способность решать задачу почти не объясняет потери. Два агента с одинаковым результатом на одиночных задачах (74,9% и 74,3%) в потоке доводят до конца 54% и 68% задач. Разница в том, как агент берёт работу и распределяет её. Исследование называет это «агент как менеджер нагрузки» (AOS-Bench).
Главная проблема, которую показал эксперимент, — агент берёт задачи по одной и не берёт новые, пока не закончит текущую. Остальное просто лежит. У GLM-5.3 и DeepSeek-V4-Pro часть задач так и не была взята в работу: 25% и 48% соответственно, у Claude Opus 5 — 0%. Если принудительно заставить агента работать строго по очереди, на тяжёлой нагрузке 73% задач остаются нетронутыми. При этом процессор в среднем простаивает: медианная загрузка не превышает 30% выделенных ядер, пока задачи ждут.
Неожиданно, что «умное» управление почти не лучше простого правила. Фиксированный лимит «не больше двух задач одновременно» даёт результат в пределах четырёх пунктов от лучшей политики, которой управляет сам агент. Подсказки агенту про планирование на тяжёлой нагрузке сделали хуже: он брал больше задач, но доводил до конца меньше.
Схема метода
Это не техника, а бенчмарк с экспериментом на вмешательствах. Устроен так:
ШАГ 1: Берут реальные задачи из CLI-бенчмарков (сборка, обработка данных, компиляция)
ШАГ 2: Прогон «по одной» (individual) → эталон: что агент умеет на изолированной задаче
ШАГ 3: Прогон «потоком» (stream) → те же задачи приходят в течение 20–60 минут
в общую песочницу (4 CPU, 8 ГБ памяти)
ШАГ 4: Независимые проверки (verifiers) оценивают итоговые файлы → доля доставленного
ШАГ 5: Вмешательства (на одной модели): строго по очереди / как сам решит /
с подсказкой / фиксированно 2 параллельно
Пример применения
Метод — это бенчмарк, и промпта в нём нет. Ниже моя адаптация выводов на практическую ситуацию. Статья этот текст не проверяла: она проверяла лимиты параллельности в диспетчере.
Задача: Основатель небольшого интернет-магазина на Wildberries держит Claude Code на рабочем сервере. Утром ему в одну сессию прилетает три задачи: пересобрать парсер карточек, обработать выгрузку заказов на 2 ГБ, сконвертировать 40 видеообзоров для карточек. Агент берёт первое и тянет его два часа, остальное лежит.
Промпт (в CLAUDE.md):
## Правила работы с потоком задач
- Если пользователь прислал несколько задач или они приходят пока ты работаешь,
не жди завершения текущей. В начале сессии выведи список всех известных задач
и их статусов: «не взята / в работе / готово / заблокирована».
- Бери в работу не больше 2 задач одновременно. Остальные оставляй в очереди,
но не теряй: когда одна из двух закончена, сразу бери следующую.
- Тяжёлые по CPU и памяти задачи (сборка, конвертация видео, обработка больших
файлов) одновременно не запускай.
- Пока тяжёлая задача ждёт ответа внешнего сервиса или идёт долгая команда,
займись лёгкой задачей из очереди.
- Каждые 15 минут выводи список задач. Если есть «не взята» и свободен слот —
бери в работу.
- Перед завершением проверь: нет ли задач в статусе «не взята».
Результат: Агент сначала выведет список задач со статусами и будет вести его дальше. В любой момент в работе будет не больше двух задач, а лёгкие задачи будут заполнять паузы тяжёлых. В конце появится итоговый список, где видно, что готово, а что нет. Реальный выигрыш зависит от агента и харнесса, и статья его для такой инструкции не мерила.
Почему это работает
Слабость. Агент по умолчанию склонен «довести текущую задачу до конца» и не смотрит в очередь. Это видно по тому, что часть моделей перестаёт брать новые задачи и работает по одной. Он не видит общей картины: ни очереди, ни того, что ядра простаивают, пока он ждёт ответ модели или инструмента.
Сильная сторона. Агент хорошо выполняет конкретную задачу, когда её взял. Основная потеря возникает не из-за провала в решении, а из-за невзятых и недоделанных задач и памяти. Это устраняется простым правилом приёма работы, а не умным планированием.
Рычаги. - Лимит параллельности (в статье k=2) → увеличь для лёгких задач, уменьши для тяжёлых. При k=1 результат был самым плохим. - Подсказки про планирование → не усложняй. Подробное «руководство» привело к тому, что на тяжёлой нагрузке агент брал больше, но доставлял меньше. - Явный список статусов → заставляет агента видеть невзятые задачи. Это моя адаптация, статья её не проверяла. - Память → при тяжёлых задачах опасно превысить лимит: все задачи, завершённые после превышения, засчитываются как нулевые.
Шаблон промпта
Это адаптация, а не промпт из статьи.
## Управление потоком задач
- В начале сессии и каждые {интервал_минут} минут выводи список задач:
«не взята / в работе / готово / заблокирована».
- Одновременно в работе не больше {число_параллельных} задач.
- Тяжёлые задачи ({примеры_тяжёлых}) вместе не запускай.
- Пока идёт долгая команда или ожидание, займись лёгкой задачей из очереди.
- Не завершай сессию, пока есть задачи «не взята».
Подставь {число_параллельных} (начни с 2), {интервал_минут} (10–15) и {примеры_тяжёлых} (то, что у тебя ест ядра и память: сборка, конвертация, обработка больших файлов).
Ограничения
⚠️ Вывод про вмешательства — на одной модели: сравнение «по очереди / сам / с подсказкой / фиксированно 2» сделано только на GLM-5.3. Для других агентов оно может выглядеть иначе.
⚠️ Малая выборка: на тяжёлой нагрузке всего пять наборов задач. Авторы называют доверительные интервалы там грубой проверкой.
⚠️ Нужна прямая настройка: в исследовании лимит параллельности реализован через диспетчер задач. Его надо превратить в инструкцию для агента, и результат придётся проверять.
⚠️ Только про потоки: если ты даёшь агенту по одной задаче, статья тебе мало что даёт.
⚠️ Нет универсального лимита: «2 параллельно» хорошо сработало в песочнице на 4 ядра и 8 ГБ. На твоей машине число может быть другим.
⚠️ Смещение в сторону потока: задачи в потоке иногда оказываются экземплярами одной задачи в одном файловом пространстве, и результат одной помогает проверке другой. Это завышает итог потока, так что потери реально чуть больше.
Как исследовали
Исследователи взяли задачи из восьми существующих бенчмарков по работе в командной строке, собрали их в общий Docker-образ и запускали на пяти парах «модель + агентная оболочка». У каждой пары был эталон: те же задачи по одной, каждая в своей песочнице. Потом сравнивали этот эталон с потоком, где задачи приходят в течение 20–60 минут в общую среду на 4 ядра и 8 ГБ памяти.
Идея в том, чтобы отделить умение решать от умения управлять нагрузкой. Результат: рейтинги по этим двум критериям не совпали. Лучшая по одиночным задачам GPT-5.6-sol потеряла 14,5 пункта, а Kimi-K3 с более слабым эталоном — только 6,3. Разбор потерь показал, что на тяжёлой нагрузке основная часть связана с задачами, которые не взяли, не закончили или закончили после превышения памяти. Ошибки решения вносят в сумму не больше 1,3 пункта.
Затем на одной модели (GLM-5.3) сравнили четыре политики. «Строго по очереди» дала 39,5% и 28,6%, «как сам решит» — 53,9% и 44,4%, фиксированное «2» — 56,6% и 42,8%. «Подсказка» на средней нагрузке дала 60,2%, а на тяжёлой — 39,2% при том, что брали больше задач. Удивительно, что «глупое» правило почти не уступает «умному» агенту.
Адаптации и экстраполяции
🔧 Техника: добавить сигнал «ресурсы заняты» → меньше риска превысить память.
Если для задачи нужно много памяти (большие файлы, сборка) — запускай её одна.
Лёгкие задачи в это время не запускай, пока не получишь подтверждение, что память свободна.
Основание: на тяжёлой нагрузке у ряда систем были превышения памяти (до 40%), а после первого такого превышения все завершённые задачи не засчитывались.
Ресурсы
AOS-Bench: Can LLM Agents Manage Dynamic Workloads? — Erle Zhu, Genrui Zhang, Keyang Hu, Mingyu Su, Hongning Wang (Tsinghua University, Columbia University). Код: https://github.com/AOS-Bench/AOS-Bench. Источники задач: Terminal-Bench, SkillsBench, TerminalWorld, WildClawBench, CompileBench, CompileAgent, ParEval, One Billion Row Challenge. Формат задач: Harbor.