Оркестрація агентів у Claude Code: як змусити їх працювати командою

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

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

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

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

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

Оркестратор і воркери: що відбувається насправді

За всіма чотирма механізмами стоїть один патерн — «оркестратор-воркери». Центральний агент дробить завдання на частини, роздає їх воркерам (субагентам), а потім синтезує їхні відповіді в загальний результат. Це не теорія про архітектури взагалі (проєктування власних мультиагентних систем — окрема велика тема), а конкретна механіка: коли 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 пробігає по сотні елементів, бо координацію тримає передбачуваний скрипт, а не діалог.

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 доречний.