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

Когда подагенты полезны

Подагенты работают лучше всего, когда исследование отделено от выполнения. Если каждый шаг в задаче зависит от того, что было обнаружено на предыдущем шаге, эту работу лучше оставить в основном потоке. Но если вам нужен только результат, а не процесс его получения, делегируйте задачу подагенту.

Подагенты превосходно справляются с задачами, где:

• Вам нужен результат, а не пошаговый отчёт о том, как он был найден
• Исследовательская работа загромоздит контекст основного потока
• Задача выиграет от свежего взгляда или специального системного запроса

Исследовательские задачи

Исследование — классический случай применения подагентов. Представьте, что вы изучаете, как работает аутентификация в незнакомой кодовой базе. Основному потоку нужно знать, где происходит проверка JWT, но не обязательно видеть все файлы, которые были просмотрены по пути.

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

> Проверка JWT происходит в middleware/auth.js на строке 42,

> вызывается из Express-маршрутизатора в route/api.js

Подагент выполнил всю тяжёлую работу. Основной поток получает именно то, что нужно для продолжения.

Код-ревью

Claude Code эффективнее рецензирует код, если он представлен так, будто написан кем-то другим. Если вы разрабатывали фичу в несколько этапов с основным потоком, просьба провести ревью у того же потока часто даёт слабую обратную связь. Claude участвовал в создании кода, поэтому ему сложно взглянуть на него свежим взглядом.

Рецензирующий подагент видит изменения в отдельном контексте. Он выполняет `git diff`, читает изменённые файлы и применяет свои специализированные критерии ревью без истории создания кода. Это разделение также позволяет закодировать в системном запросе подагента специфические для проекта стандарты ревью, обеспечивая согласованные критерии оценки в команде.

Пользовательские системные запросы

Системный запрос по умолчанию в Claude Code делает акцент на кратких, ориентированных на код ответах. Это отлично подходит для программирования, но не для всего.

Вот два случая, когда пользовательский системный запрос делает подагента действительно лучше основного потока:

• Подагент для копирайтинга — укажите инструкции по тону, аудитории и стилю. Системный запрос по умолчанию в Claude Code склоняется к кратким техническим текстам, что совсем не подходит для посадочной страницы или email-рассылки. Подагент для копирайтинга может иметь совершенно другие инструкции по голосу и структуре.

• Подагент для стилей — укажите ему файлы вашей дизайн-системы. Когда подагент запускается, эти файлы автоматически загружаются в его контекст, поэтому он знает ваши цветовые переменные, соглашения по отступам и шаблоны компонентов ещё до того, как начнёт писать CSS.

Когда подагенты мешают

Накладные расходы на запуск подагента — потеря видимости его работы и сжатие выводов в резюме — оправданы только тогда, когда подагент делает то, что основной поток сделать не может. Есть три распространённых анти-паттерна, на которые стоит обратить внимание.

«Экспертные» подагенты

Подагенты, претендующие на экспертность, редко помогают. Запросы вроде «ты — эксперт по Python» или «ты — специалист по Kubernetes» не добавляют ценности, потому что Claude уже обладает этими знаниями. Нет ничего такого, что мог бы сделать «экспертный» подагент, чего не смог бы сделать основной поток напрямую.

Последовательные конвейеры

Последовательные цепочки подагентов создают проблемы. Рассмотрим трёхэтапный процесс: один подагент воспроизводит баг, другой — отлажирует его, а третий — исправляет. Конвейеры работают, когда задачи действительно независимы. Они дают сбой, когда каждый этап зависит от открытий предыдущего — а исправление багов почти всегда именно таково. Информация теряется при передаче между агентами.

Подагенты для запуска тестов

Подагенты для запуска тестов склонны скрывать информацию, которая вам нужна. Когда тесты не проходят, вы хотите увидеть полный вывод, чтобы диагностировать проблемы. Подагент, который возвращает «тесты не прошли», заставляет вас писать дополнительные скрипты для получения деталей, которые были бы видны в прямом выводе. Тестирование показало, что схема с подагентом для запуска тестов работает хуже всех остальных конфигураций.

Правило принятия решения

При решении использовать подагента задайте себе один вопрос: важна ли промежуточная работа?

Если ответ «нет» — вам нужен только конечный результат — делегируйте задачу подагенту. Если ответ «да» — вам нужно видеть и реагировать на происходящее по ходу дела — оставьте её в основном потоке.

Используйте подагенты для:

• Исследований и разведки
• Код-ревью
• Задач, требующих пользовательского системного запроса

Избегайте подагентов для:

• «Экспертных» ролей, не добавляющих реальной функциональности
• Многоэтапных конвейеров, где каждый шаг зависит от предыдущего
• Запуска тестов, где для отладки нужен полный вывод