Парадокс сабагентов, роёв и прочих мультиагентных системПост родился как логическое продолжение предыдущего поста про правила, где я намеренно придушиваю возможность запускать сабагентов.
Откуда это вообще пошло. Всё чаще наблюдаю картинку как люди торопятся подключить как можно больше агентов в свой харнесс, при этом даже в один поток еще работу не наладили. Что они ожидают увидеть в таком случае на выходе? Мне не понятно. Думаю, им тоже. Ощущается, что они заражены какими-то постами блогеров или какими-то хайповыми роликами/статьями, воспринимают это как решение большинства проблем, но предметно объяснить какую проблему они этим подходом решают, не могут.
Давайте откатимся чуть назад, чтобы вспомнить, для чего их вообще придумали.Впервые щупать сабагентов я начал на Claude моделях, когда было жесткое ограничение в 200 000 токенов контекста, а модели могли выбирать не самый оптимальный путь мышления перед реализацией задачи. Тогда сабагенты выглядели как инженерный приём, который позволяет:
1️⃣ Экономить контекст. Сабагент получил задачу, выполнил ее, передал результат основному агенту.
2️⃣ Сузить фокус агента на конкретной задаче. Сабагент и агент работают внутри своих окон, каждый может иметь свой системный промпт (я про промпт, описывающий работу сабагента/агента, а не про тот случай, когда сейчас GPT или Claude могут сами спавнить в любой момент себе помощников, которых вы заранее не прописывали).
Работало действительно неплохо. Можно было делать ресерч одним сабагентом, код писать основным агентом, а тестирование, ревью и обновление документации поручать другим сабагентам, узко настроенным на свой спектр задач. Тогда можно было спокойно закончить достаточно большую задачу до того, как мы переполним контекст и схватим компакт. А компакты в то время своим качеством не славились и многие придерживались принципа "если компакт произошел, то дальше процесс уже стал неуправляемым и надо срочно финалить задачу и перепроверять, не начудил ли агент".
И напомню, что 200к контекста - не совсем те 200к, которые мы можем взять и использовать в полной мере. На старте, пока не появились скиллы и были только MCP, в легкую могло уходить по 30-40к токенов на содержание MCP в контексте, и буфер для сжатия контекста при компакте в районе 40к контекста. Даже на самых оптимизированных конфигах по факту мы имели на старте не 200к, а примерно 140к свободного для работы контекста. Это теперь кажется диким, ведь сейчас на среднем проекте только сбор информации по проекту перед реализацией какой-либо фичи уже может достичь 100к+ контекста.
Далее вендоры стали добавлять собственных системных сабагентов в наши харнессы, там и модель можно использовать попроще и побыстрее, и промпты заранее нужные заготовлены, и обслуживать это не надо. Все работает из коробки. Например, какой-нибудь explore агент для сбора контекста по проекту и последующей передачи его основному агенту, яркий тому пример. И качество компактов сильно подтянули, можно было спокойно переживать 2-4 компакта и все нужные детали всё еще агент учитывал, можно было сильно не переживать, а нужный контекст после компакта добирался. К тому же, у Claude появился 1 миллион контекста, у GPT тоже (но в какой-то момент они свернули не туда, и жестко его порезали). Но этот миллион контекста не работал так надежно, как хотелось бы, часто после 30-40% заполнения уже начинались явные проблемы в работе и потеря фокуса на задаче (сейчас с этим всё гораздо лучше).
Из этого как бы следует логичный вывод. что да, сабагенты нужны, разгружаем основного агента, а он на своем минимальном узкосфокусированном контексте контролирует процесс. С точки зрения задумки всё красиво. Но на практике картина вырисовывается иная:
1️⃣ Основной агент на старте запроса собирает контекст, даже если он это сделал в минимальном размере и поручил основной сбор сабагенту, сабагент заново читает ВЕСЬ контекст, отдает саммари основному агенту. Основной агент, перед тем как начать выполнять задачу, всё равно пойдет читать связанные файлы чтобы посадить новый код в известное ему место, а не по наводке агента по ресерчу. Итого имеем почти двухкратное чтение контекста, а мы еще даже код писать не начали. Время, кстати, тоже теряем. У GPT 5.6 буквально в системном промпте указано, что он должен спавнить сабагента для сбора контекста при любом запросе. Даже когда вы обсудили с ним большую часть реализации, и в целом он сам уже коснулся всех нужных файлов в достаточной степени, чтобы сделать какой-то вывод и распланировать задачу, он все равно будет спавнить агента который опять всё заново будет читать. Это бред. Так быть не должно. Он сам уже все карты на руках имел. Ах да, еще и не забываем что уходит приличное количество токенов на мышление и генерацию промпта от основного агента -> сабагенту, и после отработки сабагента происходит тоже самое в обратную сторону. Экономия, говорите? Ну, нет. Звучит это всё как какой-то заговор на то, чтобы мы больше токенов сжигали. Оптимизация ради оптимизаций порождает отрицательную эффективность.
❓
Что с этим делать? Брать запуск сабагентов под контроль исходя из вашего воркфлоу, а не из-за пожеланий вендоров в системном промпте. Допускаю, что каких-то кейсах запуск агента по ресерчу будет ценным шагом, особенно на новых фреймворках когда надо перелопатить и код в проекте, и документацию, и внешние источники с документацией библиотек. Это скорее крайние случаи в проектах с непопулярным набором фреймворков и библиотек. Иначе у основного агента мозги от кол-ва информации закипят и контекст действительно забьется мусором. Мои советы релевантны скорее для общей массы веб проектов. Конечно же, крайние случаи надо рассматривать индивидуально.
2️⃣ Потеря важных деталей при передаче задачи сабагенту и возврат отчета обратно агенту. У себя я это выявил в результате достаточного долгосрочных тестов и наблюдений и этот факт уже ничем не перебить. Когда у основного агента есть достаточно жирный промпт с кучей детальных инструкций, он далеко не всегда все эти детали ответственно передает. Из-за чего сабагент начинает работать с самого старта над некорректно поставленной задачей. И вернет отчет тоже с некоторой долей вероятности, тоже с потерей деталей уже с его стороны. Писал об этом
тут , в бизнес агентах это даже мешало, что пришлось отключать на уровне конфига возможность спавнить помощников.
❓
Что с этим делать? Отключать на 100%, как мы ранее уже решили, конечно их не будем, а вот контролировать - обязательно. Для передачи задач и отчетов между агентом и сабагентом нужно заключать в рамки строго контракта: что, в каком виде и с какой степенью глубины и детальности должно передаваться. Это можно буквально зашить в правилах агента, он будет составлять задачу для сабагента в нужном вам формате и указывать ему формат отчета, по которому он должен будет вернуть результат работы, что значительно повысит качество их взаимодействия и сбережет ваши нервы.
Итого, действительно полезное применение этого я вижу только в некоторых проектах где нужен глубокий ресерч по проекту и документации, и в процессах ревью кода, где чистая изолированная сессия это базовый минимум для честного ревью. Кто и как это реализует это уже другой вопрос, можно и другой модели это отдать, и даже отдать какому-то удаленному ревьюиверу, без проблем. Главное уловить суть, что если мы хотим адекватный расход токенов и быстрое выполнение задач, мы должны взвесить что для нас важно. Как по мне, лучше пережить пару компактов на гпт (на клоде с его миллионом контекста, скорее всего и не придется), но работать в один поток и сабагентов пускать строго под присмотром по установленному контракту, где ожидаете это вы, а не где вздумается модельке.
А что с роями? а я даже это обсуждать не хочу, пока это игрушки для энтузиастов с безлимитным доступом к токенам. Возможно, за пределами вайбкодинга это и применимо, но точно не здесь. Чтобы рой ожил и выполнял свои задачи, при этом не мешая друг другу и не трогая одни и те же файлы, придется плодить пачку worktree, которые еще потом придется как-то сливать в одну ветку и решать кучу конфликтов.
Что думаете? Может я их "готовить" не могу, и у вас сложилось всё куда удачнее и стабильнее с мультиагентами?
