Мультиагентні системи — найбільш розхайпована частина AI-інженерії. Діаграми, де «агент-планувальник», «агент-дослідник», «агент-критик» і «агент-автор» спілкуються між собою, вражають на слайдах. У продакшені картина складніша. Деякі мультиагентні рішення дають результати, недосяжні для одного агента. Багато інших повільніші, дорожчі й менш надійні, ніж один добре побудований агент. У статті — підсумок того, що опублікували команди, які запускають такі системи в масштабі, і рамка для ухвалення рішення.

Що насправді означає «мультиагентна»

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

  • Orchestrator–subagents: головний агент планує, запускає субагентів для підзадач і синтезує їхні результати. Субагенти зазвичай не спілкуються між собою.
  • Конвеєр спеціалістів: агенти передають роботу один одному у фіксованому порядку (дослідження → чернетка → рев'ю).
  • Співпраця рівних / дебати: кілька агентів обговорюють, критикують або голосують.
  • Ієрархії: оркестратори, що керують іншими оркестраторами.

Перша форма домінує серед успішних продакшен-впроваджень. Інші частіше трапляються в дослідженнях і демо.

Аргументи на користь кількох агентів

Anthropic описала, як будувала мультиагентну дослідницьку функцію в Claude: головний агент розбиває дослідницьке запитання на частини й запускає субагентів, які шукають паралельно, кожен у власному контекстному вікні. На внутрішньому дослідницькому оцінюванні мультиагентна система перевершила одного агента на 90,2% (Anthropic, 2025).

Чому це спрацювало:

  1. Паралелізм. Субагенти досліджують різні напрями одночасно, скорочуючи реальний час на широких задачах.
  2. Окремі контексти. Кожен субагент може прочитати десятки тисяч токенів джерел і повернути стислий підсумок, тож контекст головного агента лишається чистим. Це контекстна інженерія на рівні архітектури.
  3. Більше сумарних міркувань. Їхній аналіз показав, що лише кількість токенів пояснювала більшу частину розкиду результатів на оцінюванні з веб-пошуком — мультиагентні системи працюють почасти тому, що дозволяють продуктивно витрачати більше токенів.

Аргументи проти

Той самий звіт відверто говорить про вартість: агенти використовували приблизно в 4 рази більше токенів, ніж чат-взаємодії, а мультиагентні системи — приблизно в 15 разів більше. Це виправдано лише тоді, коли цінність задачі висока.

Cognition, команда кодового агента Devin, у статті Don't build multi-agents стверджує, що для задач на кшталт кодування розподіл роботи між агентами, які не мають спільного повного контексту, призводить до суперечливих рішень: один субагент оформлює компонент в одному стилі, інший будує суміжну частину інакше, і разом це не працює. Їхні принципи: ділитися повним контекстом і повними трасами агентів і пам'ятати, що дії несуть неявні рішення, які конфліктують, якщо ухвалені ізольовано.

Дослідження підтверджують крихкість. Робота, що аналізувала траси кількох популярних мультиагентних фреймворків, побудувала таксономію з 14 режимів збоїв, згрупованих у проблеми специфікації та дизайну системи, розузгодженості між агентами, а також верифікації й завершення задачі (Cemri et al., 2025). Багато збоїв походили не від моделей, а від дизайну системи: нечіткі ролі, втрачена інформація при передачі, ніхто не відповідає за перевірку фінального результату.

Як примирити обидві позиції

Ці дві позиції суперечать одна одній менше, ніж здається:

Властивість задачі На користь кількох агентів На користь одного агента
Чи незалежні підзадачі? Так — дослідження, пошук, збір даних Ні — тісно пов'язані правки, дизайн
Як поєднується результат? Підсумки, списки, знахідки Один цілісний артефакт (код, документ)
Контекст на підзадачу Великий (багато джерел) Малий або спільний
Цінність задачі Висока; токени дешеві відносно цінності Низька або великий обсяг
Толерантність до затримки Паралелізм скорочує реальний час Один цикл простіший

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

Проєктування системи orchestrator–subagents

Якщо ваша задача підходить, ці практики — з опису Anthropic і наших проєктів — підвищують надійність:

Явне делегування

Головний агент має давати кожному субагенту повне завдання: мету, формат виводу, інструменти, межі («лише джерела з 2024 року», «не редагуй файли») і скільки зусиль витрачати. Розмите делегування («досліди ринок») породжує дублювання роботи й прогалини.

Subagent brief:
Objective: Find pricing for the top 5 Ukrainian e-commerce platforms for
SMB merchants (monthly fee, transaction fee, setup cost).
Scope: Official pricing pages and their 2026 updates only.
Output: JSON array [{platform, monthly_fee_uah, transaction_fee_pct,
setup_fee_uah, source_url, retrieved_on}]. Use null if not published.
Budget: max 10 searches. Stop when all 5 are covered.
Do not: speculate about unpublished prices.

Масштабуйте зусилля під задачу

Навчіть оркестратора, скільки субагентів використовувати: одного — для простого факту, кількох — для порівняння, більше — для широкого дослідження. Без підказок агенти схильні запускати забагато субагентів на прості запитання.

Повертайте стислі структуровані результати

Субагенти мають повертати структуровані знахідки з джерелами, а не сирі транскрипти. Великі артефакти зберігаються в спільному сховищі (файли, база даних), а назад передаються посилання, щоб головний агент не тонув у даних.

Перевірка наприкінці

Хтось має перевірити фінальний результат щодо початкового запитання: окремий крок верифікації, перевірка цитат або людина. Відсутність верифікації — одна з головних категорій збоїв у таксономії Cemri.

Інженерія довготривалого стану

Мультиагентні запуски тривають від хвилин до годин. Плануйте збої посеред запуску: зберігайте контрольні точки, робіть виклики інструментів ідемпотентними, відновлюйтеся, а не перезапускайтеся. Діють ті самі патерни надійності, що й для будь-якої розподіленої системи; див. надійність LLM API.

Спостережуваність — не опція

Дебажити мультиагентну систему без трас майже неможливо: збій може бути в плані головного агента, у пошуку субагента чи в синтезі. Трасуйте кожного агента як span із його завданням, викликами інструментів, токенами й результатом, прив'язаний до батьківського. Семантичні конвенції OpenTelemetry для GenAI і спеціалізовані LLM-інструменти роблять це керованим; див. спостережуваність і трасування LLM. Відстежуйте вартість кожного запуску — один погано запромптований оркестратор може запустити десятки субагентів.

Оцінювання мультиагентних систем

Спершу оцінюйте кінцеві результати: чи правильна, повна й підкріплена джерелами фінальна відповідь? Використовуйте LLM-as-a-judge з рубриками, відкалібрований на людських оцінках, як описано у статті evals для LLM. Потім оцінюйте процес: кількість субагентів, дублювання роботи, токени на задачу, час виконання. Починайте з малих наборів — Anthropic зазначає, що на ранньому етапі кілька десятків реалістичних запитів виявляють великі ефекти; сотні не потрібні, щоб побачити, чи допомагає зміна.

Модель вартості до початку розробки

Груба оцінка вбереже від сюрпризів:

Один агент:          ~30 тис. токенів/задача × $X за 1 млн токенів
Мультиагентна:       головний 40 тис. + 5 субагентів × 60 тис. = ~340 тис. токенів/задача (~11x)

Варто, якщо: цінність_кращої_відповіді × задач/місяць > додаткова_вартість × задач/місяць

Для звіту due diligence, що вартий годин роботи аналітика, 11x токенів — дрібниця. Для чат-бота підтримки, що відповідає на тисячі простих запитань щодня, — руйнівно. Маршрутизація моделей — сильна модель для головного агента, дешевші для субагентів — скорочує розрив; див. оптимізація витрат на LLM.

Бізнес-сценарії, що підходять

  • Дослідження й аналіз: огляди ринку, порівняння постачальників, регуляторні дослідження за багатьма документами.
  • Розслідування інцидентів: субагенти паралельно аналізують логи, метрики й останні деплої різних сервісів.
  • Рев'ю великих документів: договори чи тендерна документація розбиваються на розділи, кожен аналізується на конкретні ризики, потім усе консолідується.
  • Збагачення даних: багато незалежних записів збагачуються паралельно, кожен — субагентом з інструментами пошуку.

Сценарії, що зазвичай не підходять: клієнтський чат, обробка форм, зміни коду в одному модулі, усе чутливе до затримки. Для них кращою архітектурою буде workflow або один агент.

FAQ

Чи потрібні субагентам інші моделі? Не обов'язково. Сильна модель для головного агента й дешевші для субагентів — поширена оптимізація вартості, але міряйте якість: слабкі субагенти дають слабкі знахідки.

Чи мають агенти спілкуватися напряму? Рідко. Схему «зірка» через оркестратора легше дебажити й контролювати, ніж вільні розмови агентів.

Чи корисні «дебати агентів»? Дослідження показують, що дебати й самокритика можуть покращувати деякі задачі на міркування, але виграш нестабільний, а вартість висока. Зазвичай достатньо одного кроку оцінювача з чіткими критеріями.

А фреймворки для мультиагентних систем? Вони допомагають з інфраструктурою (стан, передача роботи, трасування). Складні частини — декомпозиція задач, завдання для субагентів, верифікація — лишаються вашою проєктною роботою.

Джерела

  1. Anthropic (2025). How we built our multi-agent research system.
  2. Cognition (2025). Don't build multi-agents.
  3. Cemri et al. (2025). Why Do Multi-Agent LLM Systems Fail?
  4. Anthropic (2024). Building effective agents.
  5. Du et al. (2023). Improving Factuality and Reasoning in Language Models through Multiagent Debate.
  6. OpenTelemetry. Semantic conventions for generative AI.