Крупная задача почти всегда распадается на части, которые между собой не связаны: разобраться с auth, найти, где лежат тесты, сверить контракт внешнего API. Естественно поручить всё это одному агенту и вести по очереди в одном разговоре - он уже в контексте, зачем плодить сущности. Проблема в том, что независимые куски работы, слитые в одну ленту, мешают друг другу сильнее, чем кажется.
Наивный ход - держать всё в единственном контексте parent-агента и проходить пункты последовательно. Пока частей две-три и они короткие, это терпимо. Но каждый шаг исследования оседает в окне: прочитанные файлы, тупиковые ветки, длинные выводы поиска. Контекст пухнет, и на основную задачу у агента остаётся всё меньше внимания.
Ломается это на том, что окно контекста - ресурс, а не бесконечная лента. Шумное исследование одной подзадачи вытесняет из него то, что нужно для другой; агент начинает перечитывать уже прочитанное, путать нити и тратить токены на восстановление того, что сам же вытеснил. Последовательный проход по независимым частям платит за мнимую простоту ростом контекста и потерей фокуса.
Профессиональный механизм - subagent: отдельная роль со своим контекстом и своим расходом, которой parent делегирует часть работы. Запускается она в одном из двух режимов. Foreground приостанавливает parent и исполняется внутри сессии - у вас есть возможность подтверждать и отклонять вызовы инструментов в реальном времени. Background работает параллельно, пока parent продолжает, но инструменты, не преаппрувнутые заранее, автоматически отклоняются. На дату среза это скрыто за переключателем Subagents (Preview), и его состояние стоит сверять с актуальной версией.
Почему режима именно два, а не один универсальный. Foreground нужен там, где важен человеческий контроль над правами: агент может дойти до записи или exec, и вы хотите увидеть запрос, прежде чем он выполнится. Background нужен там, где важна параллельность и вы готовы заранее решить, какими инструментами субагент вправе пользоваться сам; всё, что не разрешено, он не будет ждать - оно просто отклонится. Разделение прямо отражает обмен: контроль в реальном времени против параллельного хода без остановок.
Роль субагента выбирают под характер работы. Встроенный subagent_explore оптимален для read-only исследования: он работает на более дешёвой модели по умолчанию и не может править файлы, поэтому безопасен для разведки. subagent_general наследует модель parent и обладает полными возможностями, вплоть до изменений, - он подходит, когда субагенту поручают завершить цельную часть задачи, а не просто осмотреться. Выбор роли здесь - то же решение о правах, что и permission-модель, только принятое заранее и на весь субагент.
Цена у этого механизма прямая. Каждый субагент - это отдельное окно контекста и отдельный расход: на тарифах по промптам он тратит кредиты так же, как пользовательское сообщение. Параллельность умножает не только скорость, но и счёт, поэтому запускать субагентов веером имеет смысл лишь тогда, когда части действительно независимы, а не ради ощущения бурной работы. Параллелить стоит там, где ожидание одной ветки реально экономит время, а не просто занимает лишние окна.
Делегировать нужно по независимости, и это главный критерий. Хорошие ветки - те, что не пересекаются: исследовать auth, найти тесты, проверить API contract, каждая возвращает свой результат сама по себе. Плохие - те, что делят состояние или ждут друг друга: три агента одновременно редактируют один central file и затирают правки, или один субагент не может двинуться, пока другой не примет решение. Зависимую работу параллелить - значит платить за координацию больше, чем экономишь на скорости.
Проверять результат субагента нужно как чужой вывод, а не как истину. Он возвращается сжатой сводкой; её читают и сверяют с кодом, а не принимают на веру - у отдельного окна нет доступа к вашей полной картине, и оно могло упустить контекст. Для background-ветки отдельно убедитесь, что нужный инструмент был преаппрувнут: иначе агент честно отклонил вызов и остановился, а вы приняли пустой результат за завершённую работу.
Типичные провалы предсказуемы. Первый - запустить background-субагента и не заметить, что он упёрся в авто-отклонение непреаппрувнутого инструмента, и вернул половину. Второй - распараллелить зависимые части, получить гонку за общий файл и потом сводить конфликтующие правки руками. Третий - принять сводку субагента за проверенный факт и построить на ней следующий шаг. Признак всех трёх один: делегировали работу, но не назвали заранее, что считать её завершением и какими правами субагент действует сам.