TL;DR
Динамическая параллельность — режим, в котором главный агент сам решает по ходу работы, запускать ли помощников-субагентов, что им поручить и как собрать результат. Это не заранее прописанный конвейер. В Claude Code это Dynamic Workflow, в Codex — multi-agent v2, в Kimi Code — AgentSwarm. Исследователи прогнали одни и те же задачи с включённым и выключенным режимом, при тех же модели, промпте и бюджете времени.
Главная находка: больше агентов не значит лучше. Токенов уходит в 1,4–3,3 раза больше. Качество не растёт стабильно: на задачах вроде «исправь один баг» режим часто вредит. У Claude Code и Kimi Code доля решённых задач на SWE-bench упала примерно с 77–83% до 59%. Польза проявляется на длинных многоэтапных проектах, где есть независимые куски работы. Даже там результат смешанный: у одного агента выигрыш, у другого падение на той же задаче. Типичная беда: главный агент раздал работу, «заснул» в ожидании всех помощников и не оставил времени собрать результат.
Практический вывод в три правила. Включай параллельность только для крупных задач с независимыми частями. Для маленьких задач отключай. Если включил, прописывай агенту правила: таймауты короче общего бюджета, интеграция по мере готовности, время на финальную сборку и проверку.
Схема: как решать, включать ли субагентов
ШАГ 1: Оцени размер задачи
→ точечная правка / баг / одна функция → ОТКЛЮЧИТЬ субагентов
→ большой проект, много независимых модулей → переходи к шагу 2
ШАГ 2: Проверь независимость кусков
→ части зависят друг от друга, общие файлы без чётких интерфейсов → риск конфликтов, осторожно
→ части независимы, интерфейс зафиксирован → ВКЛЮЧИТЬ
ШАГ 3: Задай правила (в инструкции агенту)
→ таймаут субагента < общего бюджета
→ не ждать весь батч целиком, собирать по мере готовности
→ зарезервировать время на сборку и тесты
ШАГ 4: Используй параллельность там, где она реально помогает
→ дополняющая работа (разные модули)
→ альтернативные решения одной задачи
→ независимая проверка кода другим агентом
Пример применения
Задача: Вы руководите небольшой студией, которая делает сервис уведомлений для интернет-магазина на российском стеке. Нужны модули: Telegram-бот, email-рассылка, SMS через SMS.ru, приём вебхуков от ЮKassa, админка, тесты. Модулей много, они друг от друга почти независимы. Это сильная зона параллельности: проект с нуля, широкий объём, чёткие границы.
Промпт (в Claude Code с включённым режимом субагентов):
Задача: собрать с нуля сервис уведомлений для интернет-магазина (Python, FastAPI).
Модули: telegram_bot, email_sender, sms_ru_client, yookassa_webhooks, admin_panel.
Общий бюджет времени: 60 минут.
Правила работы с субагентами:
1. Сначала сам напиши общее ядро: структуру проекта, интерфейс отправителя
Notifier.send(user_id, text), конфиг, скрипт запуска. Только после этого
раздавай модули.
2. Каждому субагенту дай один модуль, конкретные файлы и интерфейс ядра.
Файлы других модулей трогать запрещено.
3. Максимальное время субагента — 25 минут. Не жди, пока вернутся все:
принимай и интегрируй готовые модули по мере поступления.
4. Не позднее 40-й минуты прекращай делегирование. Оставшееся время —
сборка, запуск тестов, исправление недостающих модулей самим.
5. Если субагент не уложился, допиши его модуль сам по заготовке.
6. В конце отдельным субагентом проверь собранный код: запусти тесты
и составь список расхождений с интерфейсом.
Результат: Агент сначала напишет общее ядро, затем запустит несколько субагентов по модулям. Готовые модули он будет принимать по очереди, а не ждать всех. К 40-й минуте остановит раздачу работы и перейдёт к сборке. Отстающий модуль допишет сам. В финале отдельный субагент проверит результат и вернёт список расхождений. Расход токенов будет заметно выше, чем у одиночного агента. Это цена за скорость и независимую проверку.
Обратный пример, где параллельность не нужна: «Почини баг: после оплаты через ЮKassa статус заказа не обновляется». Это ограниченная задача. Здесь исследование показало потери качества и рост затрат. Отключайте субагентов.
Почему это работает
Слабость. Главный агент должен одновременно разбить задачу, передать контекст, ждать помощников и склеить результат. Всё это он делает в одном потоке. Любая ошибка в разбиении, в интерфейсах или в ожидании ломает общий результат. В короткой задаче накладные расходы на координацию больше, чем выигрыш от разделения труда.
Сильная сторона. У длинных проектов есть настоящие независимые куски: разные модули, команды, тесты. Модель умеет хорошо работать над одной узкой частью с чётким интерфейсом. Отдельный субагент без контекста «авторства» лучше замечает чужие ошибки.
Как метод обходит слабость. Правила делегирования переносят критичные решения в явный вид, чтобы агент не «изобретал» их на ходу: границы модулей, таймауты, момент остановки раздачи и резерв времени на сборку. Без этого агент склонен делать самое естественное: раздать всё и ждать всех.
Рычаги управления: - Таймаут субагента → короче общего бюджета, чтобы один зависший помощник не съел всё время. - Момент остановки делегирования → раньше при жёстком дедлайне, позже при щедром бюджете. - Число субагентов → меньше для экономии токенов. В исследовании число создаваемых агентов росло вместе со сложностью задачи. - Роль проверяющего → добавь отдельного субагента для независимой проверки. Это одно из условий, при которых параллельность помогла. - Альтернативные решения → попроси двух субагентов решить одну задачу разными путями, а главного — выбрать лучшее.
Шаблон промпта
⚠️ В статье нет готового промпта. Исследователи включали и выключали режимы переключателями. Шаблон ниже — моя сборка правил на основе выводов и разбора провала на задаче seqtk. Это стартовая заготовка, а не проверенная авторами формулировка.
Задача: {описание_проекта}
Общий бюджет времени: {минут} минут.
Правила работы с субагентами:
1. Сначала сам создай общее ядро: {что_входит_в_ядро}
(структура, интерфейсы, конфиг). Только затем раздавай части.
2. Раздели работу на независимые части: {список_частей}.
Каждому субагенту — одна часть, конкретные файлы и интерфейс ядра.
Чужие файлы трогать запрещено.
3. Таймаут субагента — {минут_на_субагента} минут (строго меньше общего бюджета).
4. Не жди все ответы сразу: принимай и интегрируй готовое по мере поступления.
5. К отметке {минута_остановки} прекращай делегирование. Остаток времени —
сборка, запуск тестов, исправление недостающих частей самостоятельно.
6. Если субагент не вернулся вовремя — допиши его часть сам.
7. В конце запусти отдельного субагента для независимой проверки:
прогнать тесты, сверить интерфейсы, составить список расхождений.
Если задача маленькая (одна правка, один баг) — не запускай субагентов,
работай сам.
Что подставлять: {описание_проекта} — что строим. {минут} — реальный бюджет. {список_частей} — независимые модули. {минут_на_субагента} — примерно 40% бюджета. {минута_остановки} — примерно 65–70% бюджета.
🚀 Быстрый старт — вставь в чат:
Вот шаблон правил делегирования субагентам. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про размер проекта, бюджет времени и список независимых частей. Это нужно, чтобы понять, стоит ли вообще включать субагентов, и расставить таймауты. Она возьмёт паттерн из шаблона и подстроит под вашу задачу.
Ограничения
⚠️ Короткие задачи: на ограниченных задачах (исправление одного бага) параллельность часто вредит: качество падает, время и токены растут. Для них режим лучше отключать.
⚠️ Цена: расход токенов вырастает в 1,4–3,3 раза. На самых больших задачах это десятки миллионов токенов на один запуск.
⚠️ Нет гарантии даже на длинных задачах: на крупных проектах результат смешанный. У одного агента прирост, у другого падение на том же наборе. У Claude Code на двух из длинных наборов доля решённых задач упала. Универсального «да» нет.
⚠️ Только кодинг: исследование про написание кода. Для текстов, аналитики и исследований вывод не проверяли.
⚠️ Нет рецепта в самой статье: в доступном фрагменте есть выводы и разбор провалов, но нет проверенных формулировок промптов. Правила делегирования из шаблона — мои, их нужно проверить на своей задаче. Таксономия из 28 паттернов ошибок и разбор условий пользы в этом фрагменте не раскрыты: приведены только названия категорий.
⚠️ Нужные настройки зависят от инструмента: режим включается переключателями (
ultracodeв Claude Code,swarm_modeв Kimi Code,multi_agentв Codex). Названия и поведение у разных продуктов различаются и могут меняться.
Как исследовали
Исследователи взяли три флагманских кодовых агента: Codex, Claude Code и Kimi Code. Каждый — в родной оболочке, на самом сильном уровне рассуждений. Агентов прогнали на 354 задачах из пяти наборов: четыре с длинными проектами (пересборка библиотек на другом языке, программы из описания, развитие репозитория на много шагов) и один с короткими задачами (SWE-bench Verified). Каждую задачу выполнили дважды: с параллельностью и без. Модель, промпт, окружение и время одинаковые. Получилось 2124 запуска примерно на $20 тыс.
Сравнивали долю полностью решённых задач и долю пройденных тестов, а также время, токены и число вызовов оболочки. Ключевой инсайт: параллельность помогает, когда проект большой и долгий. Самый заметный выигрыш был на самом длинном наборе LoopsBench: у Claude Code доля решённых задач выросла с 7,1% до 21,4%. На коротких задачах эффект нулевой или отрицательный.
Для разбора провалов вручную аннотировали полные траектории работы агентов (согласованность разметчиков — 0,77). Получилась таксономия из четырёх категорий: оркестрация задач, управление исполнением, общий контекст, общее состояние и слияние. Всего 13 подкатегорий и 28 паттернов.
Показательный случай — пересборка утилиты seqtk. Главный агент раздал 22 подкоманды 20 субагентам за раз и стал ждать всех. Таймаут ожидания он выставил на 2 часа при бюджете 40 минут. Два субагента уложились, а главный так и не вернулся к интеграции. В итоге программа собралась, но часть команд отсутствовала: пройдено 92 из 440 тестов. Удивило то, что провал вызвала не плохая идея параллелить, а отсутствие простого правила «не ждать всех».
Адаптации и экстраполяции
🔧 Техника: независимая проверка → поймать ошибки главного агента
Одно из условий, при которых параллельность помогла: отдельный субагент проверяет чужую работу. Добавь в инструкцию отдельный блок:
После сборки запусти субагента-ревьюера. Он не видел процесс написания кода.
Его задача: прогнать тесты, найти расхождения с описанием задачи,
вернуть список проблем. Исправляй только то, что он нашёл.
Для небольших задач это дешевле полного режима параллельности: один дополнительный субагент вместо двадцати.
🔧 Техника: альтернативные решения → выбор лучшего
Второе условие пользы из статьи — исследование альтернативных решений. Для сложного места попроси:
Для модуля {модуль} запусти двух субагентов с разными подходами:
первый — {подход_А}, второй — {подход_Б}.
Сравни результаты по тестам и выбери лучший.
Экстраполяция: проверка перед включением. Перед запуском большого проекта спроси агента:
Оцени задачу: сколько в ней независимых частей и где они пересекаются
по файлам? Стоит ли использовать субагентов? Ответь «да» или «нет»
и объясни одним абзацем, исходя из стоимости (токены) и риска конфликтов.
Это моя идея, а не результат статьи. Её нужно проверить самому.
Ресурсы
- Работа: When Sub-Agents Work in Parallel: The Promises and Pitfalls of Dynamic Concurrency in Long-Horizon Coding Tasks (2026)
- Авторы: Han Li, HanHaoNing Li, Ziqian Jiang (Nanjing University / Central University of Finance and Economics), Yiling Lou (University of Illinois at Urbana-Champaign)
- Изученные механизмы: Codex multi-agent v2, Claude Code Dynamic Workflow, Kimi Code AgentSwarm
- Наборы задач: RepoZero, ProgramBench, NL2Repo, LoopsBench, SWE-bench Verified
- Данные: авторы публикуют 2124 траектории запусков, разметку паттернов ошибок и скрипты анализа