Один агент чи кілька: як обрати мультиагентну архітектуру

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

Головне питання під час проєктування — не «мультиагент краще чи гірше», а «яка архітектура правильна саме для цього завдання». Найкраща ілюстрація того, що відповідь неочевидна: 12 червня 2025 року команда Devin (Cognition) публічно написала «не будуйте мультиагентів», а буквально наступного дня, 13 червня, Anthropic показала протилежне — їхня мультиагентна система обійшла одиночного агента більш ніж на 90%. Обидві позиції виявилися правильними — просто кожна для свого типу завдань, і зрозуміти, для якого саме, і є навичкою архітектора.

Коротка відповідь на «один агент чи кілька»: – Один агент — коли завдання вкладається в його контекст, експертиза одна, і важливі передбачуваність та контроль. – Кілька — коли контекст переповнюється, потрібні різні спеціалізації, важлива швидкість через паралельність або ізоляція збоїв.

Мультиагентна система коштує в 10–15 разів дорожче в токенах, ніж одиночний агент, тож ускладнювати варто лише під доведену необхідність, а не «про запас» або тому що так роблять великі компанії. Нижче — де саме проходить межа, два типи координації, дерево рішень із чотирьох питань Anthropic, реальні датовані кейси та чесний розбір провалів.

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

Один агент чи кілька: де проходить межа

Починати завжди варто з одного агента — це дешевше, передбачуваніше і простіше в налагодженні. Переходити до мультиагента має сенс за одного з чотирьох сигналів:

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

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

Воркфлоу проти ШІ-агента: як обрати і не переплатити за автономність

Як не втрачати контекст у Claude Code: компакт, resume і handoff

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

• Насичення контексту (context saturation). Завдання не вміщується у вікно одного агента — забагато файлів, джерел, кроків. Тоді роботу ділять між агентами, у кожного своє вікно.
• Спеціалізація завдань (task specialization). Потрібні різні експертизи, які погано вживаються в одному промпті (наприклад, юридичний аналіз і фінансове моделювання).
• Паралелізм заради швидкості (latency). Незалежні підзавдання можна виконувати одночасно, а не послідовно.
• Ізоляція збоїв (fault isolation). Помилка одного агента не повинна валити всю систему — окремі контексти локалізують проблему. Це особливо цінно там, де частина підзавдань працює з ненадійними зовнішніми даними: нехай «падає» один агент, а не весь конвеєр.

Зверніть увагу: три з чотирьох сигналів (насичення, спеціалізація, паралелізм) — про те, що завдання переросло один контекст, і лише четвертий — про надійність. Якщо ваш біль не описується жодним із них, а це просто «хочеться як у великих» — це не сигнал, а спокуса.

Якщо жоден сигнал не спрацював — не переходьте до мультиагента. Спеціалізований одиночний агент під конкретне завдання найчастіше ефективніший за ціною і надійніший, ніж передчасна мультиагентна конструкція.

Важливе уточнення щодо теми статті. Тут ідеться про проєктування власної мультиагентної системи (загальна архітектура за каноном Anthropic), а не про конкретну фічу субагентів у якомусь інструменті. Якщо ви, наприклад, користуєтеся готовим механізмом оркестрації агентів усередині середовища розробки — це частковий випадок тих самих принципів, але з уже ухваленими за вас рішеннями. Ми ж говоримо про рівень вище: як узагалі вирішити, скільки агентів потрібно і як їх пов’язати, ще до вибору інструмента.

Два типи мультиагентних систем

Якщо рішення дробити ухвалене, є два принципові способи організувати агентів:

Ієрархія простіша в контролі: супервайзер тримає план і роздає завдання. Її вузьке місце — переповнення контексту самого супервайзера; типові рішення — редагування контексту, інструменти пам’яті та стеля порядку 25 тисяч токенів на підзавдання.

Колаборація гнучкіша, але небезпечніша: рівні агенти можуть прийти до емерджентної (незапланованої) поведінки, а налагодити переписку багатьох агентів складно. Важливий нюанс із незалежного дослідження: топологія впливає на швидкість поширення помилок окремо від їхньої частоти. Незалежні агенти підсилюють помилку приблизно в 17,2 раза, а централізована координація — лише в 4,4 раза. Тобто навіть неповна ієрархія стійкіша за повний рій — вагомий аргумент на користь супервайзера за замовчуванням.

Окремо про керування контекстом супервайзера — це не абстрактний «виклик», а конкретна інженерна робота. Координатор, який тримає в голові весь план і результати всіх спеціалістів, швидко впирається в межу вікна. Вирішують це трьома способами: редагуванням контексту (викидати відпрацьоване), інструментами пам’яті (виносити стан назовні) і жорсткою стелею на обсяг, який кожен субагент повертає нагору (порядку 25 тисяч токенів). Без цих заходів супервайзер деградує так само, як одиночний агент у переповненому вікні, — і вся ієрархія втрачає сенс. Модель координатора при цьому зазвичай беруть потужнішу: наприклад, флагман рівня Claude Sonnet 5 як lead, а на воркерів ставлять дешевшу модель — так влаштована і сама дослідницька система Anthropic.

Агентні воркфлоу: патерни і що за ними

Усередині будь-якої з архітектур робота організується одним із п’яти базових патернів Anthropic: ланцюжок промптів, маршрутизація, паралелізація, оркестратор-воркери та оцінювач-оптимізатор. Детальний розбір кожного з механікою і прикладами — окрема велика тема; тут важливо, що це готовий «алфавіт», з якого збирається система.

Окремо варто згадати emerging-напрям: динамічну генерацію агентів на льоту і мережеві (peer-to-peer) топології. Динамічна генерація — це коли система сама вирішує, яких агентів створити під конкретне завдання, а не працює із заздалегідь прописаним набором ролей. Мережеві топології — коли агенти пов’язані не через центр, а між собою безпосередньо, як вузли графа. Обидві ідеї звучать потужно, але це поки експериментальна зона — стійких продакшн-систем на них майже немає, а складність налагодження і непередбачуваність поведінки зростають швидше, ніж виграш.

В архітектурному PDF Anthropic є теза, що «роєва» (вільно пов’язана) архітектура трохи перевершує супервайзера за всім спектром завдань, але вона наведена без посилання на дослідження, і незалежного підтвердження їй знайти не вдалося. З огляду на дані про поширення помилок (рій підсилює їх сильніше за централізовану координацію) ставимося до цієї тези обережно — як до попереднього твердження вендора, а не як до встановленого факту. На практиці для продакшну розумніше починати з ієрархії.

Дерево рішень: чотири питання

Найцінніше в підході Anthropic — не абстрактні поради, а конкретне дерево із чотирьох питань, яке веде до архітектури:

1. Скільки потрібно контролю? Якщо на кону регуляторика, гроші або безпека — беріть одного агента або суворо послідовний воркфлоу з явними точками контролю. Автономність тут — ризик.
2. Наскільки складний домен? Вузький домен закриває один агент; багато різнорідних піддоменів — сигнал до мультиагента зі спеціалізацією.
3. Який бюджет токенів? Мультиагент коштує в 10–15 разів дорожче одиночного агента. Мало ресурсів — один агент або акуратний паралельний, а не повноцінна мультиагентна система.
4. Чи потрібна глибока експертиза? Якщо завдання вимагає кількох різних спеціалізацій, які не вживаються в одному промпті, — це аргумент на користь окремих агентів (або навичок-спеціалізацій).

Логіка проста: кожне «так» у бік складності підвищує і ціну, і ризик. Не рухайтеся деревом далі, ніж вимагає завдання.

Розберемо на прикладі. Завдання — автоматизувати розбір вхідних звернень до банку. Питання 1 (контроль): на кону гроші і регуляторика — отже, автономію обмежуємо, потрібні явні точки контролю. Питання 2 (домен): звернення різнорідні (картки, кредити, шахрайство) — є спеціалізація. Питання 3 (бюджет): важливо не роздути вартість на потоці — повноцінний рій відпадає. Питання 4 (експертиза): так, гілки вимагають різних знань. Відповіді складаються в конкретну архітектуру: послідовний воркфлоу з маршрутизатором на вході і спеціалізованими обробниками — тобто гібрид «послідовний + динамічна маршрутизація», а не вільний мультиагент. Дерево не видає «мультиагент так/ні», воно видає форму системи.

Гід із вибору архітектури

Зведемо відповіді в практичний навігатор — від простого до складного:

Практичний сигнал, який часто упускають: рахуйте інструменти, а не лише домени. За дослідженнями, завдання з 16+ інструментами — найсильніший предиктор провалу координації, сильніший за саму складність домену. Якщо у вас розростається набір інструментів на агента — це привід спростити, а не додати ще агентів. І контрінтуїтивний факт із тієї самої області (знахідка DyLAN): три оптимізовані агенти нерідко випереджають сім, а обрізання команди із семи до чотирьох одночасно поліпшує результат і знижує витрату токенів на 52,9–67,8%. Більше агентів ≠ потужніше.

Гібридні стратегії

На практиці архітектури комбінують. Три робочі гібриди з фреймворку Anthropic:

• Ієрархія + паралель. Супервайзер роздає завдання кільком спеціалістам, які працюють паралельно. Приклад — оцінка фінансових ризиків: супервайзер запускає паралельно кредитний, ринковий і операційний аналіз, потім зводить.
• Послідовний + динамічна маршрутизація. Фіксований конвеєр, де один із кроків — роутер, який спрямовує запит за ситуацією. Приклад — підтримка: спочатку класифікація, потім маршрутизація в потрібну гілку.
• Один агент + ескалація в мультиагент. За замовчуванням працює одиночний агент, а на складних випадках система розгортається в мультиагентну. Економно: платите за складність лише тоді, коли вона справді потрібна.

Гібрид майже завжди практичніший за крайнощі — він дозволяє тримати просте простим, а складне винести туди, де воно виправдане.

Розберемо детальніше гібрид «ієрархія + паралель» на фінризиках, бо він показовий. Супервайзер отримує заявку і паралельно запускає три спеціалізовані агенти: кредитний (оцінює платоспроможність), ринковий (дивиться на ризики портфеля) і операційний (перевіряє комплаєнс і внутрішні правила). Кожен працює у своєму контексті і зі своїми даними, не заважаючи іншим. Супервайзер збирає три вердикти і виносить загальне рішення. Виграш подвійний: паралельність дає швидкість, а поділ експертиз — якість, якої один агент із гігантським промптом «на все одразу» не досягне. При цьому ієрархія згори зберігає контроль — критично для фінансової сфери, де потрібна простежуваність рішень.

Реальні кейси

Варто показати і успіхи, і те, що за ними стоїть.

Як влаштований кейс Anthropic Research архітектурно: провідний агент (lead) отримує запит, декомпозує його і роздає підзавдання субагентам, кожен із яких досліджує свою частину в окремому контексті, а потім lead синтезує відповідь. Це класичний оркестратор-воркери на read-heavy завданні — там, де паралельне читання безлічі джерел складається в кращий результат. Саме форма завдання (багато незалежного читання) пояснює, чому тут мультиагент виграв, а в інших сценаріях програє.

Важливі застереження. Приріст +90,2% — внутрішній замір Anthropic за однією методикою на дослідницьких завданнях, не універсальний закон. Кейси Coinbase і Gradient Labs походять з архітектурного PDF Anthropic; там-таки згадується прискорення «в 100 разів» у Tines, але його другий підтверджувальний матеріал належить тому самому вендору — тому цей показник ми не виносимо як незалежно підтверджений. Загальний принцип під час читання будь-яких таких кейсів: успіх конкретної компанії — не доказ, що архітектура підійде вам; дивіться на схожість форми завдання, а не на гучність цифри.

Окремий тип кейса — спеціалізація ролей без класичного супервайзера: зв’язка агента-ініціалізатора (готує середовище) і агента-кодера (автономний цикл) із розбору Anthropic для багатоденних завдань. Це мультиагентність через поділ ролей, а не через ієрархію координації. Для контрасту, одиночний персональний ШІ-агент — це інший полюс: одна роль, один контекст, своя економіка.

Де ламається: ризики і провали

Тут мультиагентність показує зворотний бік — і його важливо зважити до, а не після впровадження.

Індустрія розколота, і це важливо. Cognition у пості «Don’t Build Multi-Agents» (12 червня 2025) прямо попереджає: паралельні субагенти з ізольованим контекстом ухвалюють конфліктні рішення, і зібрати з них узгоджений результат важко — особливо в завданнях із записом (код). Приблизно через десять місяців вони пом’якшили позицію: читати дані мультиагентно можна, а от записувати краще однопотоково. Anthropic на своєму дослідницькому продукті (read-heavy завдання) отримала протилежний результат. Висновок не «хто правий», а «різні форми завдань вимагають різних архітектур»: write-heavy код тяжіє до одного агента, read-heavy дослідження виграє від багатьох.

Гроші і статистика провалів. Gartner прогнозує (25 червня 2025, опитування 3400+ організацій), що понад 40% проєктів agentic AI буде закрито до 2027 року — через зростання витрат, неясну цінність і слабкий контроль ризиків. Академічний розбір MAST (1600+ трас, 14 типів провалів) фіксує частоту збоїв мультиагентних систем у діапазоні 41–86,7% (за вторинним переказом первинного дослідження).

Коли мультиагент прямо ГІРШИЙ. Найцінніше — кількісні пороги з незалежного дослідження Google DeepMind (грудень 2025). Якщо одиночний агент уже вирішує завдання з успіхом вище ~45%, додавання агентів погіршує результат (ефект насичення здатності). На паралельних завданнях мультиагент дає приріст до +80,9%, а на послідовних міркуваннях — деградацію від −39% до −70%. Це операціоналізує інтуїцію «ускладнюй лише коли доведено» в конкретні числа: подивіться на тип завдання (паралельне чи послідовне) і на поточний успіх одиночного агента, перш ніж дробити.

Чому так відбувається, легко зрозуміти на пальцях. Паралельне завдання (зібрати дані з десяти джерел) добре ріжеться на незалежні шматки — агенти не заважають один одному, і їхня робота складається. Послідовне міркування (довести теорему, де крок 5 спирається на крок 4) різати не можна: передавання проміжного висновку між агентами губить нюанси, і ланцюжок рветься. Звідси практичне правило: паралельне дробиться, послідовне — ні. Якщо ваше завдання — довгий ланцюжок залежних кроків, один агент із безперервним контекстом майже завжди кращий за команду.

Окремо про частоту збоїв: розбір MAST виділяє 14 типових режимів провалу мультиагентних систем, і більша їхня частина — не про «дурну модель», а про координацію: агенти неправильно розуміють ролі, втрачають інформацію на стиках, зациклюються в переписці. Це ще один аргумент на користь простоти: чим менше стиків між агентами, тим менша поверхня для цих провалів.

Живий ризик на практиці — витік контексту між агентами: у реальному PR (липень 2026) лагодили саме передавання зайвого контексту між агентами, яке призводило до збою. Ізольовані контексти захищають, але стики між агентами — точка, де все ламається.

Витрати, які недооцінюють. Мультиагентність масштабує не лише якість, а й рахунок — причому нелінійно. Спільнота регулярно ділиться історіями штибу «спалили пару мільярдів токенів, будуючи команду з десятка агентів» — не тому що завдання того вартувало, а тому що кожен агент дублює контекст, а координація додає свій оверхед. Перш ніж розгортати систему з багатьох агентів, порахуйте не лише «чи стане краще», а й «у скільки разів дорожче» — і порівняйте з приростом якості, який ви реально виміряли, а не припустили.

Збираючи все разом: мультиагентна архітектура — потужний інструмент для правильної форми завдання (широкі паралельні дослідження, різні експертизи, ізоляція збоїв) і дорога помилка для неправильної (послідовні міркування, вузький домен, обмежений бюджет). Починайте з одного агента, дробіть за сигналами, віддавайте перевагу ієрархії перед роєм, рахуйте інструменти і токени — і перевіряйте виграш заміром, а не вірою в те, що «більше агентів = краще».

FAQ

Коли достатньо одного агента, а коли потрібні кілька? Один агент — коли завдання вкладається в його контекст, експертиза одна, важливі передбачуваність і контроль. Кілька — за насичення контексту, потреби в різних спеціалізаціях, паралелізму заради швидкості або ізоляції збоїв. Якщо жоден із цих сигналів не спрацював, залишайтеся на одному агенті: мультиагент у 10–15 разів дорожчий у токенах.

Чим ієрархічна архітектура відрізняється від колаборативної? В ієрархії центральний супервайзер координує спеціалістів (субагенти як інструменти) — простіше контролювати, але вузьке місце в контексті супервайзера. У колаборативній рівні агенти спілкуються безпосередньо — гнучкіше, але важче в налагодженні і ризикує емерджентною поведінкою. За стійкістю до помилок ієрархія зазвичай виграє: централізована координація підсилює помилки приблизно в 4,4 раза проти 17,2 у незалежних агентів.

Чи правда, що більше агентів — завжди потужніше? Ні. Якщо одиночний агент уже дає вище ~45% успіху, додавання агентів часто погіршує результат. На послідовних міркуваннях мультиагент деградує на 39–70%. Є знахідки, що три оптимізовані агенти випереджають сім, а обрізання команди поліпшує і якість, і вартість. Кількість інструментів (16+) — сильніший предиктор провалу, ніж кількість агентів.

Як обрати архітектуру за деревом рішень Anthropic? Дайте відповідь на чотири питання: скільки потрібно контролю (регуляторика/гроші/безпека → один агент або послідовний воркфлоу), наскільки складний домен, який бюджет токенів (мультиагент 10–15×), чи потрібна глибока різнопланова експертиза. Кожен крок до складності підвищує ціну і ризик — не йдіть далі, ніж вимагає завдання.

Чому одні кажуть «не будуйте мультиагентів», а інші показують +90%? Тому що вони говорять про різні завдання. Cognition попереджає про write-heavy завдання (код), де паралельні агенти конфліктують під час запису. Anthropic показала виграш на read-heavy дослідженнях, де паралельне читання складається добре. Правильний висновок — дивитися на форму свого завдання, а не обирати «табір».