Оркестрация агентов Claude Code: как заставить их работать командой

Коротко (TL;DR)

Оркестрация — это когда одна главная сессия Claude Code (оркестратор) раздаёт работу нескольким агентам и собирает их результаты. И здесь важно понимать: в Claude Code для этого есть не один, а четыре разных встроенных механизма — обычные субагенты, Agent Teams, Dynamic Workflows и Agent View. Путаница между ними — главная причина, почему практики либо не используют оркестрацию вообще, либо включают её там, где она не окупается.

Ключевой критерий, который сразу расставляет всё по местам, — кто держит план выполнения. У субагентов и Agent Teams план держит сама модель ход за ходом. У Dynamic Workflows план живёт в коде скрипта — поэтому масштаб на порядки больше. У Agent View агенты вообще не связаны друг с другом, это просто диспетчер независимых фоновых сессий.

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

Фичи оркестрации активно развиваются, часть из них экспериментальные — сверяйтесь с документацией; у версий и цифр в тексте указана своя дата.

SpaceX · xStockSpaceX — частная компания. Торгуй её токеном на Bybit за крипту.Торговать SpaceX →

Оркестратор и воркеры: что происходит на самом деле

За всеми четырьмя механизмами стоит один паттерн — «оркестратор-воркеры». Центральный агент дробит задачу на части, раздаёт их воркерам (субагентам), а потом синтезирует их ответы в общий результат. Это не теория про архитектуры вообще (проектирование собственных многоагентных систем — отдельная большая тема), а конкретная механика: когда Claude Code запускает несколько вызовов инструмента Agent в одном шаге, каждый вызов уходит в свой субагент со своим контекстным окном.

AMD покупает себе место у Anthropic: 2 гигаватта MI450 в обмен на инвестицию до $5 млрд

Один агент или несколько: как выбрать мультиагентную архитектуру

Пять паттернов агентных систем: механика, примеры и цена каждого

Воркфлоу против ИИ-агента: как выбрать и не переплатить за автономность

Как не терять контекст в Claude Code: компакт, resume и handoff

Почему это вообще работает лучше, чем один агент? По той же причине, что и субагенты по отдельности: каждый воркер думает в своей «комнате» и возвращает наверх только сжатый итог, не засоряя контекст оркестратора. В собственных замерах Anthropic многоагентная конфигурация (ведущий агент на Opus плюс субагенты на Sonnet) показала прирост качества около 90,2% против одиночного агента на том же research-бенчмарке (13 июня 2025). Важная оговорка: это внутренний eval Anthropic по одной методике, независимого повторения нет — принимаем как заявление первоисточника, а не как многократно подтверждённый закон.

Есть и обратная сторона, которую сама Anthropic прямо признаёт: исполнение воркеров синхронное. Оркестратор ждёт, пока закончат ВСЕ воркеры, и общее время равно времени самого медленного. Один зависший воркер блокирует всю систему, каким бы быстрым ни был остальной флот. Держите это в голове — к экономике и ограничениям мы ещё вернёмся, потому что именно из этой синхронности растут и латентность, и часть перерасхода.

Четыре механизма: кто держит план

Вот та самая карта, которой обычно не хватает. Все четыре — встроенные в Claude Code, но решают разные задачи:

Разберём три «старших» механизма подробнее (субагенты как таковые — отдельная тема, здесь они кирпичик fan-out).

Dynamic Workflows: план держит скрипт

Dynamic Workflows (версия v2.1.154) — это принципиально другой подход к оркестрации. План выполнения здесь живёт не в голове модели, которая решает следующий шаг по ходу, а в коде JavaScript-скрипта. Вы описываете логику детерминированно: что запустить, в каком порядке, что сделать с результатами, где ветвление. Модель исполняет роли внутри этого плана, но не выбирает структуру.

Практическое следствие — масштаб. Когда планом управляет код, а не пошаговое решение модели, система спокойно разворачивает десятки и сотни агентов за один прогон. Это территория крупных повторяемых операций: миграции по множеству файлов, массовые аудиты, обработка больших списков однотипных задач. Там, где Agent Team упёрлась бы в несколько teammates, workflow пробегает по сотне элементов, потому что координацию держит предсказуемый скрипт, а не диалог.

SpaceX · xStockSpaceX — частная компания. Торгуй её токеном на Bybit за крипту.Торговать SpaceX →

Agent View: диспетчер независимых сессий

Agent View (версия v2.1.139) — это вообще не про совместную работу. Это список независимых фоновых сессий Claude Code (claude agents), которые не общаются друг с другом. Каждая делает свою задачу в изоляции.

Ключевая деталь — изоляция правок через git worktree: каждая фоновая сессия пишет в свой отдельный worktree, сама коммитит, пушит в свою ветку и открывает черновой (draft) pull request. При этом она никогда не пушит в main/master и ничего не мержит — финальное решение остаётся за человеком. Это удобно, когда нужно параллельно двигать несколько несвязанных задач и не хочется, чтобы они топтались в одних файлах, — но это диспетчеризация, а не оркестрация в строгом смысле: синтеза результатов здесь нет, каждый агент сам по себе.

Agent Team: команда сессий, которые общаются

Agent Teams — официальный термин Anthropic, не наше маркетинговое название. Это та самая команда агентов Claude Code, о которой чаще всего спрашивают: экспериментальная фича, по умолчанию выключена, включается переменной окружения CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Статус остаётся экспериментальным даже на версии v2.1.205 (на 11 июля 2026) — то есть в продакшн её тащить рано.

Чем команда отличается от обычного fan-out субагентов? Архитектурой: — Есть lead-сессия и несколько teammates — каждый в своём полном контекстном окне. — Teammates общаются напрямую через общий почтовый ящик (mailbox) и общий список задач (task list) — а не только отчитываются лидеру, как обычные субагенты. — Контроль качества можно вешать хуками жизненного цикла команды: TeammateIdle, TaskCreated, TaskCompleted.

Как менялась фича: в v2.1.32 она вышла как research preview с явными командами TeamCreate/TeamDelete; к v2.1.178 модель упростили — команда стала «неявной» (implicit team), а ручные команды создания/удаления убрали.

Архитектурные ограничения, которые важно знать заранее: — Нет вложенных команд. Teammate не может завести свою собственную команду teammates. — Ровно одна команда на сессию. — Безопасность делегирования: teammate не может одобрить запрос на разрешение за пользователя. Релей чужого одобрения блокируется — то есть команда агентов не сможет «прокликать» за вас доступ к чему-то опасному.

Начинать Anthropic советует с 3–5 teammates. И вот любопытный факт: ровно такой же диапазон «3–5 параллельных воркеров» независимо всплыл в их же Research-системе годом раньше (2025) — две разные команды, разные продукты, разное время, одна цифра. Это уже похоже не на произвольную рекомендацию, а на практический предел управляемости.

Fan-out: запускаем N воркеров одним сообщением

Самый доступный вид оркестрации не требует экспериментальных флагов. Fan-out — это несколько вызовов субагентов в одном обращении, которые отрабатывают параллельно. Субагенты стартуют вместе, но оркестратор дожидается завершения всех и только потом обрабатывает их результаты вместе — то есть общее время равно времени самого медленного воркера (та самая синхронность из начала статьи).

Готовый рецепт «3 ревьюера, 3 угла» (параллельное ревью): 1. Сформулируйте задачу так, чтобы её можно было разбить на независимые проверки — например, «корректность», «безопасность», «производительность». 2. Попросите оркестратора поднять на каждый угол по субагенту разом и вернуть находки списком. 3. Оркестратор синтезирует три отчёта, снимает дубли и отдаёт вам сводку.

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

Это не абстракция: у самого Claude Code есть живой продакшн-пример такого паттерна — фича Code Review (релиз 9 марта 2026). Под капотом — флот специализированных агентов, которые ревьюят pull request параллельно, затем верификация и дедупликация находок. Результат (по данным Anthropic): менее 1% ложных срабатываний, $15–25 за ревью, около 20 минут, а доля PR с содержательными комментариями выросла до 54% с прежних 16%. Обратите внимание: официальная документация говорит про «флот специализированных агентов» без точного числа — расхожая цифра «пять ревьюеров» из вторичных блогов первоисточником не подтверждена, поэтому за факт её не берём.

Чему учит этот кейс с точки зрения архитектуры: сильная сторона паттерна «N воркеров → синтез» не в том, что агентов много, а в этапе верификации после сбора. Параллельные ревьюеры генерируют находки широко (высокая полнота), а отдельный шаг проверки и дедупликации отсекает ложные срабатывания (высокая точность). Именно связка «разошлись вширь → сошлись и отфильтровали» даёт тот самый показатель менее 1% ложных срабатываний. Если вы строите свой fan-out, копируйте не число агентов, а эту двухтактную схему: сначала разные углы независимо, потом единый проход, который сверяет и снимает дубли.

Сколько это стоит: почему токены растут нелинейно

Здесь начинается самое недопонятое. В сети гуляет миф «N агентов = N× дороже». Реальность сложнее, и точной единой цифры для Claude Code CLI просто нет.

Что известно достоверно. Единственное первичное измерение — от Anthropic: агентные системы расходуют примерно вчетверо больше токенов, чем обычный чат, а их многоагентная research-система — примерно в пятнадцать раз больше. Официальная документация Claude Code про сами команды даёт лишь качественное «расход растёт линейно» без числа.

Вторичные источники расходятся: marc0.dev называет около 5× за каждого teammate, а один вендорский разбор выносит в заголовок провокационное «почему три агента стоят как десять». Одно «среднее» тут выдумывать некорректно — числа получены на разных системах и без общей методики.

Почему цифра «плавает»? Потому что рост нелинейный и складывается из нескольких факторов (по разбору Augment Code, 16 мая 2026): — Дублирование контекста — каждый воркер тащит свою копию вводных. — «Налог на координацию» — токены на постановку задач и сборку ответов. — Каскад ретраев — в звёздной топологии (все воркеры висят на одном оркестраторе) одна ошибка на уровне оркестратора типично раздувает стоимость всей трассы в 2–3×, потому что зависимые воркеры приходится перезапускать.

Отдельно про источники экономики: и разбор Augment Code, и работа про «эффект harness» (arXiv, июль 2026, где смена только слоя оркестрации при тех же шести моделях дала −41% цены, −44% времени и −38% токенов) — это вендорские материалы с явным конфликтом интересов (их авторы продают свои оркестраторы). Мы берём из них общий принцип — оркестрация это архитектурное решение, а не просто счётчик агентов — а не конкретные маркетинговые числа под Claude Code.

Что из этого следует для практики — три способа держать счёт под контролем: — Модель под роль. Ведущему агенту (синтез, планирование) — флагман, воркерам (разведка, механическая проверка) — модель попроще. Ровно так устроена связка «Opus-lead плюс Sonnet-воркеры» в замерах Anthropic. — Узкий скоуп воркера. Чем конкретнее задача и меньше набор инструментов у субагента, тем меньше он бродит и дублирует контекст — а именно дублирование контекста и есть главный источник нелинейного роста. — Сжатый формат возврата. Просите воркеров возвращать структурированную выжимку, а не сырые логи: короткий итог экономит токены и оркестратору на синтез, и вам на чтение.

Общий вывод: считать оркестрацию нужно не по числу агентов, а по объёму продублированного контекста и числу «кругов» координации — именно они, а не количество воркеров сами по себе, определяют итоговый счёт.

Если вам нужен не разовый fan-out внутри сессии, а постоянный автономный ассистент со своей экономикой, это другой класс инструментов — мы считали её на примере персонального ИИ-агента OpenClaw.

Где ломается

• Синхронный bottleneck. Латентность равна времени самого медленного воркера. Пять быстрых субагентов и один зависший — ждёте зависшего.
• Нет вложенных команд. Teammate не заведёт свою команду — глубокую иерархию так не построить.
• Задачи «зависают». В экспериментальных Agent Teams задача может застрять в промежуточном статусе, и это официально задокументированное ограничение.
• /resume не восстанавливает teammates. Прервали сессию с активной командой — восстановить in-process teammates не получится, придётся начинать координацию заново.

Что выбрать: субагенты, команда, workflow или view

Практический тест из инженерной практики: «отдали бы вы эту задачу коллеге и ушли, не общаясь с ним до результата?» — Если да, задача независимая и её результат сжимается — хватит обычного fan-out субагентов. Дешевле и проще. — Нужна живая координация между исполнителями (переписка, общий список задач) — это Agent Team, но помните про экспериментальный статус. — Задача требует десятков и сотен агентов по детерминированному плану — это Dynamic Workflow, где план держит скрипт, а не модель. — Нужно просто запустить несколько независимых фоновых задач без всякой координации — это Agent View: каждая сессия пишет в свой git worktree, сама коммитит и открывает черновой PR, но никогда не пушит в main и не мержит.

Для контраста: Claude Tag как постоянный ИИ-коллега в Slack — это уже не оркестрация внутри одной сессии, а другой сценарий встраивания Claude в рабочий процесс.

И ещё одна граница, чтобы не путаться в терминах: Managed Agents API (на платформе Claude) — это отдельный продукт, REST-интерфейс для чужих приложений на Claude API (координатор плюс до 20 агентов в ростере, максимум 25 тредов, глубина 1). Он не имеет отношения к оркестрации внутри Claude Code CLI, хотя слова «координатор» и «мульти-агент» звучат одинаково.

Риски

• Экспериментальный статус Agent Teams. Фича официально помечена как экспериментальная со списком известных ограничений (зависающие задачи, неработающий /resume с in-process teammates). Полагаться на неё в критичных процессах пока рано.
• Делегирование прав. Teammate не может одобрить действие за пользователя — это защита, но и напоминание: не рассчитывайте, что команда агентов «сама всё согласует». Опасные операции всё равно потребуют вашего явного одобрения.
• Авто-PR фоновых сессий. Agent View сам коммитит и открывает draft PR. Это удобно, но проверяйте, что именно нагенерили фоновые агенты, прежде чем принимать их работу — они не пушат в main, но код в ветке уже ваш.
• Расход токенов. Оркестрация — осознанная плата. Прежде чем включать её, прикиньте, окупается ли задача: для мелких и последовательных задач это чистый перерасход.

FAQ

Чем Agent Team отличается от обычных субагентов? Обычные субагенты только отчитываются оркестратору и между собой не общаются. Teammates в Agent Team общаются напрямую через общий почтовый ящик и общий список задач, каждый в своём полном контекстном окне. Agent Team — экспериментальная фича за флагом CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1; обычный fan-out субагентов работает без всяких флагов.

Как запустить несколько субагентов одновременно? Достаточно, чтобы оркестратор сделал несколько вызовов субагентов в одном обращении — они стартуют параллельно (fan-out). Это подходит для независимых подзадач: параллельное ревью по разным углам, проверка конкурирующих гипотез при отладке. Anthropic советует держать 3–5 параллельных воркеров: больше — и координация начинает съедать выигрыш от параллельности.

Правда ли, что несколько агентов всегда дороже во столько же раз, во сколько их больше? Нет. Рост стоимости нелинейный: добавляются дублирование контекста, «налог на координацию» и каскад повторных запусков при ошибке оркестратора. Единственное первичное измерение — от Anthropic (агент ≈4× чата, их многоагентная research-система ≈15×); официальная документация про команды числа не даёт, вторичные оценки расходятся, и одно «среднее» тут выдумывать некорректно.

Что такое Dynamic Workflows и чем они отличаются от Agent Team? Dynamic Workflows (версия v2.1.154) — это когда план выполнения держит JS-скрипт, а не модель ход за ходом. За счёт этого масштаб — десятки и сотни агентов за прогон. В Agent Team план держит сама модель, поэтому и число исполнителей небольшое (несколько teammates). Разный «держатель плана» — главный водораздел между механизмами.

Чем Agent View отличается от Dynamic Workflows? Agent View — это диспетчер полностью независимых фоновых сессий: они не общаются и результаты не синтезируются, каждая пишет в свой git worktree и открывает черновой PR. Dynamic Workflows — наоборот, единый прогон по детерминированному плану в скрипте, где результаты агентов собираются по заданной логике и масштаб доходит до сотен исполнителей. Agent View берут для нескольких несвязанных задач, workflow — для одной большой повторяемой операции.

Оркестрация всегда лучше одного агента? Нет. Она окупается на широких задачах, которые дробятся на независимые части (ресёрч, параллельное ревью, разбор большого кода). На узких, последовательных или мелких задачах оркестрация только добавляет латентность и расход токенов. Простой тест: отдали бы вы задачу коллеге и ушли, не общаясь до результата — тогда fan-out уместен.