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.