один агент чи п'ятнадцять? реальний гайд з архітектури мульти-агентних систем

Дроби на кілька агентів лише тоді, коли один агент доказово не витягує задачу — коли робота розпадається на незалежні підзадачі, кожній з яких потрібен свій контекст, свої інструменти, і вони можуть іти паралельно, не заважаючи одна одній. Канонічний патерн — orchestrator-worker (агент-«супервайзер», що планує й делегує, плюс субагенти, кожен з яких розкопує одну гілку). Усе інше — агенти, що перекидають задачу одне одному по одному повідомленню, «команди» в спільному чаті — це зазвичай театр. У червні 2026 Anthropic відзвітувала, що її мульти-агентна research-система обігнала одиночного агента на 90,2% на внутрішньому тесті — але ціною приблизно 15× за токенами. Cognition (команда Devin) дала протилежну пораду — «Don't Build Multi-Agents» — бо паралельні агенти ухвалюють суперечливі рішення, коли не ділять контекст. Праві обидві. Реальна навичка — не зібрати п'ятнадцять агентів, а зрозуміти, які задачі заслуговують більш ніж одного, і спроєктувати контекст, який вони ділять. Цей гайд — про архітектуру, патерни спілкування, шар пам'яті та чесний розділ «коли перемагає один агент».

чому «мульти-агент» став маркетинговим словом

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

У спільноти є точна назва цьому розриву: «deployed, not demoed» — задеплоєно, а не показано в записі екрана. Мульти-агентна система, що виграє скрінкаст, і система, що переживає тиждень у продакшені, — це різні артефакти. Демка оптимізується під «виглядає автономно». Продакшен оптимізується під коректно, дешево й відлагоджувано — і ці три речі з кожним новим агентом даються складніше, а не легше.

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

єдине рішення, що справді важить: дробити чи лишити одного

Тест на перехід до мульти-агентів рівно один, і це не «складна задача». Це: чи розбивається робота на підзадачі, достатньо незалежні, щоб іти паралельно, кожна зі своїм контекстом?

Ресерч — «знайди все про X по 30 джерелах» — підручниковий кейс для мульти-агентів: можна розгорнутися віялом, паралельно копати незалежні зачіпки й злити результат. Кодинг — підручниковий анти-кейс: кожна правка залежить від попередньої, тому паралельні кодинг-агенти заважають одне одному. Саме тому Anthropic обрала мульти-агентів для ресерчу, а Cognition аргументує проти них для кодинг-агентів на кшталт Devin. Один рік, протилежні поради — і обидві праві, просто описують різні форми задач.

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

патерн supervisor — той, що доживає до продакшену

Патерн, що реально їде в прод, — orchestrator-worker, він же supervisor. Один провідний агент тримає план; він породжує субагентів, у кожного своє вікно контексту та свої інструменти, щоб паралельно копати незалежні гілки; субагенти повертають стиснуті висновки; провідний зводить їх в одну відповідь.

                  ┌────────────────────────┐
   запит юзера →  │  LEAD / ОРКЕСТРАТОР    │  планує, дробить, делегує
                  └───────────┬────────────┘
            ┌─────────────────┼─────────────────┐
            ▼                 ▼                  ▼
      ┌──────────┐     ┌──────────┐       ┌──────────┐
      │ субагент │     │ субагент │       │ субагент │   своє вікно контексту,
      │  (веб)   │     │  (доки)  │       │  (код)   │   свої інструменти, паралельно
      └────┬─────┘     └────┬─────┘       └────┬─────┘
           └────── стиснуті висновки ──────────┘
                            ▼
                  ┌────────────────────────┐
                  │  LEAD зводить воєдино → │  фінальна відповідь + посилання
                  └────────────────────────┘

Чому так, а не спільний чат-безлад? Три причини:

• Кожен субагент отримує чистий, сфокусований контекст. Він не тоне в балаканині інших — бачить свою гілку та свої інструменти. Це найпотужніший важіль якості.
• Паралельність справжня. Незалежні гілки йдуть одночасно, тому час за годинником падає, навіть якщо сумарна ціна в токенах зростає.
• Один письменник — одне джерело істини. Фінальну відповідь збирає лише провідний. Жодні два агенти не б'ються за вивід.

У мінімальній формі провідний — це просто агент, чиї «інструменти» — інші агенти:

# Псевдокод — цикл supervisor, без прив'язки до фреймворку
def lead_agent(query):
    plan = llm_plan(query)                  # розбити на незалежні підзадачі
    results = run_parallel([                 # розгорнути віялом — у кожного свій контекст
        subagent(task=t, tools=tools_for(t))
        for t in plan.subtasks
    ])
    return llm_synthesize(query, results)    # один письменник зводить усе воєдино

Цифри й підступ. Anthropic відзвітувала, що її orchestrator-worker research-система (провідний Claude Opus 4 керує субагентами Claude Sonnet 4) обігнала одиночного Opus 4 на 90,2% на внутрішньому research-тесті. Там само вони з'ясували: сам обсяг використаних токенів пояснює близько 80% розкиду результатів — більша частина виграшу в тому, що більше агентів дозволяють витратити більше токенів, паралельно, по більшому контексту. Підступ: це коштувало приблизно 15× токенів від звичайного чату. Така економіка виправдана лише для дорогих задач, де ретельність варта реальних грошей. Не вішай множник 15× на «підсумуй цей лист».

як агенти насправді спілкуються одне з одним

Тут більшість мульти-агентних систем тихо ламається. Наївний дизайн — агенти перекидаються по одному повідомленню: агент A шле агенту B фразу, B відповідає фразою. Здається природним — і це пастка. До моменту, коли інформацію тричі стиснули до однорядкового хендофу, початковий сенс втрачено, і два агенти впевнено діють на різних версіях правди.

Жорсткі правила Cognition, вистраждані на Devin, б'ють рівно в цю точку:

• Ділись контекстом і ділись повними трейсами агентів — не лише фінальним повідомленням. Субагент має бачити міркування, що привело до його задачі, а не голу однорядкову витяжку. Втрачений контекст — причина №1 суперечливих рішень.
• Тримай запис (writes) однопотоковим. Коли кілька агентів читають — нормально; коли кілька пишуть в один стан паралельно — отримуєш незв'язний вивід. Хай додаткові агенти додають інтелект (аналіз, варіанти), але самі дії проводь через одного письменника. Це принцип «single writer», і саме тому supervisor — а не рівноправний груповий чат — це стійкий патерн.

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

спільна пам'ять як файлова система, а не як лог чату

Щойно агентів кілька, «де живе спільне знання?» стає архітектурним питанням. Запхати все в один гігантський промпт не масштабується — виносиш вікно контексту й ховаєш сигнал. Патерн, що набирає силу у 2026-му, — ставитися до пам'яті агента як до файлової системи.

OpenViking (виклала у open source команда Volcano Engine від ByteDance, ~15K★) — найнаочніший приклад. Він виставляє контекст — пам'ять, ресурси, навички — під схемою URI viking://{scope}/{path}, якою агенти ходять звичними командами на кшталт ls і find. Ключова ідея — багаторівневе завантаження: кожен шматок контексту зберігається на трьох рівнях деталізації.

Агент переглядає анотації L0, щоб знайти релевантне, читає L1 там, де важливо, і тягне повний L2 лише коли деталь реально потрібна — адресуючись по URI, як відкриваючи файл. Так ти даєш команді агентів спільну велику базу знань, не змушуючи кожного тягати її цілком у контексті. Це чисто лягає на supervisor: субагенти пишуть стиснуті висновки в сховище, провідний читає анотації й заглиблюється лише там, де зобов'язаний.

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

недооцінений ключ: куратор, що керує співвідношенням сигнал/шум

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

Ліки — субагент-куратор: маленька дешева модель, чия єдина робота — відсікати шум і лишати опорні факти до того, як контекст побачить дорога модель. Стаття 2026 року «Escaping the Context Bottleneck: Active Context Curation for LLM Agents via Reinforcement Learning» (підхід ContextCurator) ставить у пару заморожений потужний TaskExecutor і легку policy-модель, навчену через RL агресивно вичищати шум оточення, зберігаючи рідкісні факти, що знадобляться далі. Результати:

Куратор на 7B (на базі Qwen-2.5-7B) не поступився варіанту з gpt-4o у ролі куратора — фронтирна модель для вичистки не потрібна. Це і є архітектурний хід, який досі недооцінений: у мульти-агентній системі один із найцінніших «агентів» — зовсім не експерт із предметки, а дешевий вахтер, що вирішує, що взагалі дозволено побачити дорогим агентам. Краще співвідношення сигнал/шум майже завжди б'є «більше агентів».

коли один агент із хорошими інструментами просто перемагає

У більшості випадків тобі не потрібно нічого з переліченого вище. Один агент із грамотно зібраним поясом інструментів б'є рій по ціні, затримці й відлагоджуваності. Бери одного агента, коли:

• Задача послідовна. Кожен крок залежить від попереднього (кодинг, багатокрокові транзакції, будь-що зі станом). Паралельні агенти лише заважали б одне одному.
• Усе влазить в один контекст. Якщо вся робота спокійно вміщується в одне вікно, дроблення додає накладні витрати на координацію без виграшу.
• Затримка чи ціна на межі. Один агент — один рахунок за токени й нуль міжагентних round-trip'ів.
• Це треба відлагоджувати. Один цикл, один трейс. Відмова рою — це «десь у маршрутизації повідомлень», а це паскудне місце, щоб сидіти там о 3 ночі.

Чесний хід, що у 2026-му в тренді, а не навпаки: є реальний відкат від переускладнених агентних систем — команди тихо видирають рій назад і котять одного міцного агента. Мульти-агенти — це можливість, а не статусний символ. Якщо один агент із трьома хорошими інструментами справляється, це і є сеньйорське рішення. (Якщо ти ще обираєш сам шар агента — дивись мій розбір фреймворків; якщо жодного разу не збирав базовий цикл — почни з першого агента на чистому Python.)

п'ять способів зламати мульти-агентну систему (і як лагодити)

• Граблі: рівноправний груповий чат замість supervisor. Агенти базікають на рівних і ухвалюють суперечливі рішення. Фікс: orchestrator-worker. Один провідний планує й зводить; субагенти лише звітують нагору.
• Граблі: худі хендофи. Передаєш однорядники — губиш контекст, і наступний агент діє навмання. Фікс: ділись повними трейсами й самодостатніми брифами, а не витяжками (правило Cognition).
• Граблі: паралельні письменники. Два агенти змінюють один стан — отримуєш незв'язний вивід. Фікс: однопотоковий запис — зайві агенти додають інтелект, дії комітить один письменник.
• Граблі: контекст як один гігантський транскрипт. Кожен агент перечитує все, і сигнал тоне. Фікс: адресовна багаторівнева пам'ять (L0/L1/L2 у дусі OpenViking) і субагент-куратор.
• Граблі: мульти-агенти на задачу для одного. Платиш ~15× токенів, щоб зробити зв'язану задачу гіршою. Фікс: чесно прожени тест на дроблення; за замовчуванням — один агент, доки він доказово не перестане витягувати.

як я насправді ганяю агентів у продакшені

За замовчуванням у мене не рій. Більшість задач, які я кочу, — це один агент, щільний набір інструментів і хороша спостережуваність навколо. До мульти-агентів тягнуся лише коли задача реально розгортається віялом — ресерч, широкий збір даних, усе, де незалежні гілки копають паралельно — і навіть тоді це суворий orchestrator-worker: один провідний, що планує й синтезує, і stateless-субагенти, кожен отримує запечатаний бриф і звітує назад. Спільний стан живе в адресовному сховищі, а не в промпті на 200K токенів, який кожен агент перечитує. Дешева модель курує вивід інструментів до того, як його побачить дорога. І кожен агент — одиночний чи суб — крутиться в пісочниці, бо кожен інструмент, який агент може викликати, — це поверхня атаки (чек-лист безпеки тут), із повним трейсингом, щоб у відмови о 3 ночі було де шукатися (моніторинг тут). Архітектура нудна — навмисно. Нудне й доживає до продакшену.

що далі — і коли варто піти

Якщо збираєшся будувати мульти-агентну систему — спершу прожени тест на дроблення. Послідовна, зв'язана, влазить в одне вікно? Збери одного відмінного агента й піди від рою — це сеньйорське рішення. По-справжньому паралельна й жадібна до контексту? Бери orchestrator-worker, ділись повним контекстом униз, тримай запис однопотоковим, роби пам'ять адресовною й став дешевого куратора перед дорогою моделлю. І заклади бюджет на токени до старту, бо ретельність варта 15× лише коли задача того варта.

Джерела

1. Anthropic — «How we built our multi-agent research system» — архітектура orchestrator-worker, приріст 90,2% над одиночним агентом, ціна ~15× за токенами й обсяг токенів як ~80% розкиду результатів. https://www.anthropic.com/engineering/built-multi-agent-research-system Отримано 16 червня 2026.

2. Cognition — «Don't Build Multi-Agents» (Walden Yan) — принципи «ділись повними трейсами» й однопотокового запису («single writer»), а також аргументи проти паралельних агентів на зв'язаних задачах. https://cognition.ai/blog/dont-build-multi-agents Отримано 16 червня 2026.

3. OpenViking (ByteDance / Volcano Engine), GitHub — схема URI viking:// і модель багаторівневого завантаження контексту L0/L1/L2 для спільної пам'яті агентів. https://github.com/volcengine/OpenViking Отримано 16 червня 2026.

4. «Escaping the Context Bottleneck: Active Context Curation for LLM Agents via Reinforcement Learning» (arXiv 2604.11462) — розділення ContextCurator/TaskExecutor, цифри по WebArena і DeepSearch та результат куратора 7B проти gpt-4o. https://arxiv.org/abs/2604.11462 Отримано 16 червня 2026.

Проєктуєш мульти-агентну систему — чи намагаєшся зрозуміти, чи вона взагалі потрібна? Запусти проєкт — я проєктую й збираю AI-агентів, MCP-сервери та агентні системи, що працюють на твоєму сервері, з правильним числом агентів: не демку, а версію, що доживає до продакшену.