Субагенты и расширения

Предыдущие страницы описали агента-одиночку: модель, инструменты, память. Эта страница рассказывает про верхний этаж: как агент делегирует работу другим агентам и как харнес (agent harness) расширяется под процессы команды.

Что такое субагент

Субагент (subagent) — вспомогательный агент, которого основной агент запускает для отдельной подзадачи. У субагента своё контекстное окно (context window), свой набор инструментов и своя инструкция. Он получает задание, работает самостоятельно и возвращает основному агенту только итоговый отчёт.

Механически это просто ещё один инструмент: основной агент вызывает «запусти агента с таким-то заданием» так же, как вызывает чтение файла. Но последствия у этого инструмента особые.

Зачем: изоляция контекста и параллелизм

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

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

Рабочие паттерны

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

Многие харнесы позволяют определять именованных кастомных агентов: вы описываете роль («ревьюер безопасности»), инструкцию и доступные инструменты, и такой агент вызывается по имени, вручную или автоматически, когда основной агент сочтёт нужным.

Расширения харнесов

Субагенты — часть более широкого набора механизмов расширения. Основные:

Слэш-команды. Сохранённые промпты, вызываемые по короткому имени: /review, /release-notes, /standup. По сути макросы: часто используемая инструкция оформляется один раз и становится доступной всей команде. Хорошо подходят для повторяемых действий, у которых есть понятное имя.
Хуки (hooks). Автоматические действия на события жизненного цикла агента: не «попросили модель», а «гарантированно выполняется». Примеры: после каждой правки файла автоматически запускается форматер; перед выполнением команды скрипт проверяет её по чёрному списку и блокирует опасную; по завершении задачи приходит уведомление. Важное отличие от инструкций в памяти: инструкцию модель может забыть, хук сработает всегда. Критичные правила надёжнее оформлять хуками.
Плагины. Упакованные наборы расширений: команды, агенты, скилы, хуки, MCP-серверы одним пакетом. Удобный способ распространять командную настройку: новый сотрудник ставит плагин и получает всё окружение сразу.

Вместе с памятью (Память), скилами (Скилы) и MCP (MCP-серверы) это превращает харнес из «умного чата с терминалом» в настраиваемую платформу под процессы конкретной команды.

Оркестрация нескольких агентов: когда оправдана

Дальше по этой дороге лежат мультиагентные схемы: агент-оркестратор раздаёт работу команде агентов, те трудятся параллельно, результаты сводятся вместе. Звучит эффектно, и здесь нужна трезвость.

Когда оправдано:

Работа действительно распараллеливается на независимые части: миграция по множеству модулей, проверка большого списка однотипных объектов.
Нужен взгляд со свежим контекстом: связка «исполнитель + независимый ревьюер».
Черновой работы много, и она забила бы контекст одиночного агента: глубокие исследования с последующей выжимкой.

Когда это лишняя сложность:

Задача по силам одному агенту. Один агент с хорошим контекстом почти всегда предсказуемее трёх с плохой координацией.
Подзадачи зависят друг от друга. Агенты, параллельно редактирующие связанный код, порождают конфликты и несогласованность; координация съедает весь выигрыш.
Вы ещё не отладили работу с одним агентом. Оркестрация умножает и сильные стороны, и проблемы: если одиночный агент у вас регулярно уходит не туда, пять агентов будут уходить не туда в пять раз быстрее.

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

Что дальше

Рабочий цикл с агентом: постановка, рамки, итерации.
Обзор харнесов: какие харнесы что умеют, сравнение расширяемости.

Автор учебника — Шахматов Алексей