Вложенные под-агенты в Claude Code: пятиуровневая делегация перестраивает маршрутизацию моделей и архитектуру затрат

10 июня Anthropic выпустила архитектурно значимое обновление Claude Code: под-агенты теперь могут порождать собственных под-агентов с глубиной до пяти уровней. Это не косметическое улучшение. Оно превращает agent runtime Claude Code в иерархический движок делегации — а эта иерархия создаёт естественную поверхность маршрутизации по уровням моделей, которую каждая AI-инженерная команда должна учитывать в своих архитектурных решениях.

Что произошло

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

В том же релизе:

• Приоритет региона Amazon Bedrock: Claude Code теперь читает регион AWS из ~/.aws/config, если AWS_REGION не задан — поведение соответствует стандартному порядку разрешения AWS SDK.
• Поиск в маркетплейсе плагинов: команда /plugin теперь включает строку поиска при просмотре маркетплейса.
• Атрибут модели в OTEL: метрика claude_code.lines_of_code.count теперь несёт атрибут model, позволяя observability-конвейерам отслеживать использование в разрезе моделей.
• Авто-компактификация контекста 1M: сессии с 1M-контекстом без usage credits теперь автоматически компактируются до стандартного лимита вместо зависания.
• Исправления безопасности фоновых агентов: устранена ошибка, при которой фоновый агент на разогретом воркере читал настройки .mcp.json другой директории.

Изменение вложенности — главное в этом релизе. Всё остальное полезно, но только пятиуровневая делегация кардинально меняет архитектуру agent-воркфлоу.

Почему это важно для AI-команд

До этого релиза модель агентов в Claude Code была плоской: главный агент порождает под-агентов, каждый работает на одном уровне, родитель ждёт. Это вынуждало команды закладывать сложную декомпозицию задач в единый prompt — длинный, хрупкий и дорогой.

Пятиуровневая вложенность меняет модель декомпозиции. Coding-воркфлоу теперь может выглядеть так:

• Уровень 0 (агент планирования): читает весь репозиторий, понимает задачу, выбирает стратегию декомпозиции. Использует сильнейшую модель (Opus).
• Уровень 1 (агент оркестрации): получает подзадачу, разбивает на параллельные рабочие единицы. Использует модель среднего уровня (Sonnet).
• Уровень 2 (агент исполнения): реализует одну рабочую единицу, пишет код, запускает тесты. Использует ту же или более дешёвую модель.
• Уровень 3 (агент верификации): проверяет diff, запускает linter, ищет регрессии. Использует более дешёвую модель (Haiku).
• Уровень 4 (вспомогательный агент-лист): читает файл, считает строки, запускает утилиту. Использует самую дешёвую доступную модель.

Каждый уровень делегации — это точка принятия решения о маршрутизации. Родительский агент неявно выбирает, какому уровню модели передать задачу. Claude Code уже поддерживает переопределение модели через CLAUDE_CODE_SUBAGENT_MODEL, а в этом релизе /model-селектор корректно распространяет ограничения availableModels на под-агентов.

Взгляд router/operator

Пятиуровневая вложенность создаёт иерархию маршрутизации, идентичную каскадным паттернам делегации, которые операторы годами применяют в API gateway. Вот что меняется для команд, запускающих agentic coding в масштабе:

Детализация затрат. Каждый уровень делегации можно направить на другой уровень модели. Пятиуровневый воркфлоу, где уровни 3–4 используют Haiku вместо Opus, снижает стоимость типичных задач рефакторинга на 40–60%. Авто-компактификация 1M-контекста также предотвращает неконтролируемый расход токенов при случайном достижении потолка сессии.

Надёжность в слоях. Если агент-лист (уровень 3–4) даёт сбой — сгенерировал несуществующий путь к тесту, упёрся в rate limit, выдал неверный код — родительский агент уровня 2 может зафиксировать сбой, передать задачу другой модели или выполнить работу самостоятельно. Это fallback на уровне агента, а не на уровне provider. Внешней routing-инфраструктуры не требуется, но паттерн идентичен тому, что API gateway делает при переключении provider.

Контроль governance. Лимит в пять уровней — это параметр управления. Команды, которым нужен более жёсткий контроль затрат, могут ограничить вложенность тремя уровнями через availableModels. Изменения в OTEL-метриках также позволяют отслеживать затраты и latency в разрезе уровней вложенности при наличии соответствующей инструментации.

Зависимость от provider. При указании ANTHROPIC_BASE_URL на совместимый endpoint вся пятиуровневая иерархия может работать через другого provider. Архитектура вложенности не привязана к конкретной модели на уровне маршрутизации; характеристики затрат и latency изменятся, но паттерн делегации сохранится.

На что обратить внимание

• Накопление rate limit: каждый уровень вложенности генерирует собственные API-вызовы. Агент уровня 0, передающий задачи трём агентам уровня 1, каждый из которых обращается к трём агентам уровня 2, создаёт девять параллельных API-потоков. Планирование rate limit должно учитывать мультипликативный fan-out.
• Ограничение глубины в CI: команды, запускающие Claude Code в CI-конвейерах, должны проверить, достигают ли их воркфлоу пятиуровневого потолка и как runtime ведёт себя на границе.
• Изменение региона Bedrock: исправление приоритета ~/.aws/config означает, что Claude Code на Bedrock может разрешить другой регион. Если маршрутизация зависит от явного AWS_REGION, проверьте конфигурацию после обновления.
• Observability затрат: новый атрибут model в OTEL-метриках в сочетании с gateway-уровневым журналом запросов даёт разбивку затрат по уровням делегации — ключевой сигнал для построения дашбордов расходов на coding-агенты.
• Стратегия маршрутизации по уровням моделей: пятиуровневая вложенность делает модельную маршрутизацию в coding-агентах обоснованной. Задачи планирования требуют сильнейшей модели; задачи-листья — нет. Если ваша стратегия fallback между provider по-прежнему плоская — одна модель на всё — этот релиз повод начать stratификацию.