Глава 07 · Делегирование

Subagents — когда главному агенту нужен помощник

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

Когда главному агенту нужен помощник

Есть три ситуации, в которых имеет смысл форкнуть отдельный agent loop. Первая — задача требует много контекста: разобрать большой README, прочитать десять файлов, провести веб-поиск с сотней страниц выдачи. Если все эти страницы прочтёт главный, он увезёт их в каждый следующий API-вызов и быстро упрётся в лимит. В основном диалоге нужен только финальный вывод.

Вторая — задачи независимы и параллелизуемы. Когда нужно проверить пять файлов на одну и ту же ошибку или собрать данные про десять компаний — нет смысла делать это последовательно. Anthropic пишет об этом прямо: «the lead agent spins up 3–5 subagents in parallel rather than serially; the subagents use 3+ tools in parallel. These changes cut research time by up to 90% for complex queries».

Третья — нужна особая роль или инструменты, которым нечего делать в основном диалоге. Code-reviewer, security-auditor, doc-writer — у каждого свой системный промпт, свой набор инструментов, свои правила. Засовывать всё в основной системный промпт — значит превращать его в винегрет. Лучше вынести в отдельную сущность и звать её через Agent-tool.

Пять режимов dispatch

Сам факт того, что главный агент позвал «помощника», ничего не говорит о том, как этот помощник запустится. claude-cli различает пять ортогональных режимов; все они проходят через одну точку входа (AgentTool.call), расходятся только по флагам:

1. Sync. Главный ждёт ответа так же, как ждал бы обычного tool call. Делает запрос, блокируется, получает строку, продолжает. Просто и предсказуемо.

2. Async. Fire-and-forget: главный диспатчит sub-агента и сразу продолжает. Когда дочка закончит, её результат прилетит в следующий ход как user-сообщение в специальном XML-конверте — в claude-cli это <task-notification>.

3. Coordinator. Главный превращается в дирижёра: его инструменты урезаются до Agent / TaskStop / SendMessage / SyntheticOutput, и он буквально не может делать работу сам — только спавнить воркеров и синтезировать результат. Формализация anthropic-паттерна про research.

4. In-process. Sub-агент запускается в том же процессе. Дёшево, быстро, но падение одного может убить всю сессию. Подходит для дочек с краткой узкой задачей.

5. Remote. Sub-агент уезжает на другую машину или в облачную CCR-сессию. Дороже по латентности, но даёт настоящую изоляцию: ESC в основном процессе не убивает воркера, сбой воркера не утягивает главного.

Эти режимы не взаимоисключающие. Один sub-агент может быть, скажем, async + remote (фоновая задача на VM) или sync + in-process (быстрый помощник). Архитектурно важно одно: точка входа одна.

Anthropic: orchestrator–worker и multi-agent research

Для Research-фичи Claude — той самой, где модель бегает по интернету и собирает многоуровневые отчёты, — Anthropic выбрали паттерн orchestrator–worker. Lead-агент на Opus принимает запрос, планирует стратегию, раскладывает задачу на параллельные ветки и спавнит N sub-агентов на Sonnet. Каждый воркер уходит в свою тему со своим набором инструментов, делает поиск, отсеивает мусор и возвращает компактное резюме. Lead собирает резюме воедино, при необходимости спавнит ещё одну волну — и финальный текст идёт пользователю.

Внутренние замеры: такая система обогнала single-agent Claude Opus 4 на 90.2% на их research eval. Не потому, что воркеры умнее, а потому, что появилась возможность тратить токены параллельно. «Multi-agent systems work mainly because they help spend enough tokens to solve the problem» — 80% дисперсии успеха в их данных объясняется одним только объёмом токенов. Параллельная архитектура — способ обойти лимит на одну сессию.

Важная деталь: sub-агенты ничего не знают друг о друге. Они не координируются, не передают результаты по цепочке, не висят на чужих апдейтах. Координирует только lead. Это намеренно: попытка добавить peer-to-peer общение быстро вырождается в «agents distracting each other with excessive updates».

OpenAI: manager vs decentralized handoffs

В «A Practical Guide to Building Agents» OpenAI описывает два канонических паттерна оркестрации, и они задают полезную дихотомию.

Manager pattern (agents as tools). Центральный manager-агент держит контроль над всем диалогом и зовёт специализированных агентов как обычные инструменты — буквально spanish_agent.as_tool(...) в Agents SDK. Manager решает, кого позвать, и синтезирует ответ пользователю. Подходит, когда нужно держать единый голос и единый контекст.

Decentralized handoffs. Агенты-пиры передают друг другу управление через handoff — одностороннее переключение, при котором сессия с пользователем переходит к новому агенту вместе с историей диалога. Triage-агент видит, что вопрос про доставку, и делает handoff к order-management-агенту; тот дальше говорит с пользователем напрямую.

Trade-off очевиден: manager даёт централизованный контроль (всегда видно, кто чем заведует, единая точка для guardrail'ов), decentralized — гибкость. claude-cli идеологически ближе к manager-у: sub-агент возвращает только финальный ответ, в диалоге с пользователем не участвует. Coordinator-mode — это строгая версия того же паттерна.

Manus wide-research: subagents как побег от context window

У Manus в посте «Wide Research: Beyond the Context Window» аргумент за sub-агентов идёт с другой стороны. Их наблюдение: когда модель последовательно перерабатывает много однотипных элементов, начиная примерно с восьмого она начинает галлюцинировать. Не из-за плохого промпта и не из-за слабой модели — а потому, что окно контекста забивается шаблонами, кросс-ссылками, форматированием. Пункты 1–5 получают честный ресёрч, пункты 6–8 — деградируют, пункты 9+ это «plausible-sounding content based on statistical patterns».

Решение Manus — не растягивать контекст ещё на лимон токенов, а форкнуть N свежих агентов в отдельных VM. Каждый получает «a complete virtual machine environment, full tool library access, independent internet connection, fresh, empty context window». Один пункт — один воркер. Дополнительный бонус — линейная масштабируемость: 50 пунктов занимают примерно столько же, сколько 5.

Это другой взгляд на ту же конструкцию. Anthropic — про увеличение бюджета токенов через параллелизм; Manus — про побег от деградации в длинном контексте через изоляцию. Технически тот же fork, идеологически два разных способа объяснить, зачем он нужен.

Context isolation как первичная мотивация

Если читать claude-cli/12-subagent-dispatch внимательно, главное преимущество субагентов формулируется не как «параллелизм», а как изоляция контекстов. Дочка не видит, что лежит в messages у родителя; родитель не видит транскрипта дочки. Главный получает только финальный отчёт — последний text-block последнего assistant-сообщения sub-агента, обёрнутый в обычный tool-result.

Это влечёт несколько практических следствий. У sub-агента свой системный промпт: можно посадить туда специалиста с другой ролью. У sub-агента свой набор tools: claude-cli применяет ALL_AGENT_DISALLOWED_TOOLS на каждый спавн, async-агенты урезаны до ASYNC_AGENT_ALLOWED_TOOLS, координатор сидит на собственном узком списке. У async-агента свой AbortController: ESC в родителе не убивает её. На каждый sub-агент пишется свой sidechain-транскрипт в subagents/<agentId>.jsonl — посмотреть можно постфактум.

В сумме это «manager pattern с настоящей инкапсуляцией»: главный отдал задачу, получил ответ, и неважно, что воркер делал внутри. Инженерно похоже на функцию с её собственным стеком — родитель видит только return value.

Цена

Бесплатно sub-агенты не работают. Первая статья — токены. Каждый воркер это новый agent loop с собственным system prompt, собственным первоначальным сообщением и собственной серией tool-call'ов. Где у моноагента был бы один длинный диалог, у мульти-агентной системы — N+1 параллельных, каждый со своим overhead. Anthropic честно: «agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats». В пятнадцать раз. Многоагентная архитектура оправдана только там, где ценность результата это перекрывает.

Вторая — сложность отладки и координации. Несколько асинхронных воркеров с разными abort-контроллерами легко влетают в состояние «половина закончила, четверть продолжает, ещё четверть упала», и главный не знает, ждать ли. Главу «Cost» мы посвящаем тому, чтобы трезво считать всё это сразу.

Простое правило: не плодите sub-агентов, пока работа влезает в один цикл. Sub-агент оправдан, когда есть существенный выигрыш — изоляция большого контекста, реальный параллелизм или специализированная роль. Иначе лучше оставить один loop.