Субагенты (Subagents и делегирование)

1. Обзор концепции и системная проблема

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

Если все эти операции выполняет один главный агент в рамках единого диалога:

1. Катастрофическое загрязнение контекста (Context Pollution): Тысячи строк сырого кода и логов вытесняют первоначальные системные инструкции пользователя.
2. Потеря внимания (Lost-in-the-Middle): Агент начинает путаться в собственных промежуточных черновиках, теряя первичную цель.
3. Последовательное узкое горло (Sequential Bottleneck): Агент вынужден просматривать каждое источник по очереди, тратя минуты там, где можно распараллелить работу за секунды.

Паттерн субагентов (Subagents) внедряет принцип изоляции контекста выполнения: родительский агент создает отдельных дочерних исполнителей с чистым окном внимания, делегирует им рутину и принимает назад лишь рафинированный, структурированный вывод.

2. Архитектурная таксономия и ментальная модель

По способу организации работы субагентов выделяют три основные топологии:

• 1. Fork-Join (Map-Reduce паттерн): Родительский агент разбивает большое задание на $N$ независимых частей (например, анализ 4 отдельных микросервисов), одновременно запускает 4 параллельных субагента (Fork), ждет их завершения и объединяет результаты в единый отчет (Join).
• 2. Transient Deep-Dive Worker (Одноразовый разведчик): Субагент создается под одну специфическую операцию: например, зайти на сайт документации, пройти авторизацию, найти пример использования эндпоинта и вернуть лишь 5 строк кода. После этого контейнер субагента удаляется.
• 3. Иерархическое дерево с ограничением глубины (Bounded Delegation Tree): Родительский процесс управляет субагентами первого уровня, а те при необходимости могут создавать работников второго уровня. Для предотвращения неконтролируемого потребления ресурсов глубина рекурсии строго ограничивается (max_depth = 2).

3. Технический пайплайн и внутренняя механика

Жизненный цикл работы субагента:

1. Delegation Call (Инициация делегирования): Главный агент вызывает специальный инструмент запуска: invoke_subagent(task_name="grep_auth_logs", prompt="...", tools=["grep", "cat"]).
2. Context Sandbox Isolation (Создание изолированного потока): Рантайм поднимает новую сессию LLM с чистым контекстом. В него инжектируется лишь инструкция для подзадачи и ограниченный список разрешенных инструментов.
3. Autonomous Execution (Автономный внутренний цикл): Субагент выполняет собственный ReAct-цикл, делает ошибки, тестирует гипотезы и формирует финальный результат, не беспокоя родительский агент промежуточными сообщениями.
4. Synthesis & Garbage Collection (Сжатие и возврат): Сырой лог диалога субагента архивируется или уничтожается. Главный агент получает сообщение от инструмента с коротким резюме (например: «Найдено 2 утечки памяти в файле worker.ts: строки 14 и 89»).

4. Практические инженерные сценарии в продакшене

01. Параллельный аудит безопасности большого монорепозитория

Главный архитектор создает трех субагентов одновременно:

• Работник 1: сканирует бэкенд на SQL-инъекции и небезопасные сырые запросы.
• Работник 2: проверяет фронтенд на XSS и опасные вызовы dangerouslySetInnerHTML.
• Работник 3: анализирует конфигурационные файлы Docker и CI/CD на наличие открытых портов и незагартованных образов. Каждый субагент читает сотни файлов, но главный архитектор получает компактную сводную таблицу с тремя критическими пунктами.

02. Фоновый анализ массивных серверных логов

Вместо передачи 50 мегабайт логов Nginx в главный контекст, запускается субагент-аналитик. Он локально фильтрует логи через grep/awk, находит аномальный всплеск статус-кодов 500 и возвращает главному агенту лишь выделенный стектрейс.

03. Исследование внешних библиотек без потери фокуса

Пока кодовый агент проектирует архитектуру сервиса, он отправляет субагента прочитать официальную документацию Stripe API. Субагент разбирается в синтаксисе чек-аутов и возвращает готовый минимальный пример кода.

5. Подводные камни, типовые ошибки и безопасность

• Токенный шторм и Rate Limits (TPM Spikes): Запуск 10 субагентов одновременно создает огромный всплеск запросов к провайдеру, что приводит к каскадным ошибкам 429 Too Many Requests. Всегда используйте очереди задач с ограничением пула (например, максимум 3 одновременно работающих).
• Конфликты параллельной записи (Race Conditions): Если два субагента одновременно попытаются отредактировать один и тот же файл в репозитории, возникнет перезапись или повреждение кода. Предоставляйте исследовательским субагентам исключительно права Read-Only.
• Бесконечная рекурсия делегирования (Fork Bomb): Субагент решает, что задача слишком сложная, и создает еще 5 субагентов, каждый из которых делает то же самое. Всегда запрещайте дочерним агентам вызывать инструмент invoke_subagent.