Мультиагентні системи у компанії: коли варто та як їх зв'язати

Виробнича компанія створила одного агента, який мав робити все: відповідати на запитання клієнтів, генерувати кошториси, призначати торгові зустрічі та створювати тижневі звіти з продажу. Через три місяці агент працював, але все гірше. Кошториси були менш точними, бо контекст займало вікно для запитань клієнтів. Звіти виходили із запізненням, бо координація з CRM конфліктувала з чергою обслуговування. Вартість одного запиту зросла втричі порівняно з пілотом. Рішенням не була краща модель, а розбиття на чотири спеціалізовані одиниці з агентом-роутером на чолі.

Це типовий сценарій перевантаження окремого агента. Однак не кожен випадок вимагає мультиагентної архітектури.

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

Роутер (класифікатор + dispatch). Агент-координатор аналізує вхідні дані та направляє їх до відповідного агента-спеціаліста. Клієнт запитує про рахунок-фактуру? Потрапляє до фінансового агента. Запитує про статус доставки? Потрапляє до логістичного агента. Роутер не об'єднує результати, а лише перенаправляє. Простий, дешевий, легкий для дебагу.

Конвеєр (послідовність). Завдання проходить через наступних агентів, як на складальній лінії: агент A збирає дані, агент B аналізує, агент C форматує звіт. Кожен агент отримує результат попереднього як вхідні дані. Добре працює при обробці документів, генерації пропозицій, багатоетапних дослідженнях.

Мережа (mesh). Агенти можуть викликати один одного в будь-якому порядку, залежно від потреб завдання. Найбільш гнучкий патерн, але й найскладніший для моніторингу. Ризик петель реальний, якщо немає жорстких лімітів викликів і механізму human-handoff.

Більшість бізнес-впроваджень починають з роутера або конвеєра. Мережу залишаємо на етап, коли два простіші патерни явно не справляються.

Тут немає однієї межі. Є сигнали, які вказують, що час на розбиття:

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

Завдання можуть виконуватися паралельно. Послідовний конвеєр для десяти незалежних клієнтів займає вдесятеро більше часу, ніж одне завдання. Паралельні виклики спеціалізованих агентів скорочують затримку навіть на 60-70%, якщо завдання не мають залежностей між собою.

Різні завдання вимагають різних моделей. Класифікація намірів — завдання для малої, дешевої моделі (відповідь за 200 мс). Синтез багатосторінкової пропозиції вимагає більшої моделі з довшим контекстом. LLM router між агентами підбирає модель під завдання, що знижує витрати на інференс на 30-50% зі збереженням якості.

Межі відповідальності мають юридичне значення. Коли частина процесу стосується персональних даних (RODO, DPIA), а частина — ні, ізоляція агентів з окремими guardrails і окремими логами полегшує документування відповідності вимогам AI Act.

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

Практичні принципи зв'язування:

Контракти між агентами. Кожен агент-спеціаліст має задокументовану схему вхідних і вихідних даних (structured output). Координатор не припускає, що знає формат — читає схему і валідує результат перед передачею далі. Відсутність валідації — джерело тихих помилок у конвеєрі.

Ліміт викликів і таймаут на агента. Кожен виклик має жорсткий таймаут (напр. 30 секунд) і ліміт спроб (напр. 2 retry з exponential backoff). Після перевищення ліміту агент повертає результат помилки з контекстом, а координатор вирішує: ескалація до людини чи fallback на простіший шлях.

Спільний реєстр логів. Кожен агент пише в одну систему логування з ідентифікатором сесії та ідентифікатором виклику. Без цього дебаг події, яка пройшла через трьох агентів, перетворюється на багатогодинне розслідування. Це вимога observability і водночас основа аудиторського сліду, сумісного з AI Act.

Human-gate на незворотних діях. Незалежно від того, який агент виконує дію (надіслати лист, виставити рахунок, змінити статус в ERP), якщо дія незворотна, вона зупиняється і чекає на підтвердження оператора. Це стосується кожного агента в мережі, а не лише координатора.

Більше про архітектуру інструментів і петель читайте в статті про багатокрокових агентів та в описі агентів, які виконують роботу.

Багатоагентна архітектура має реальні витрати. Варто їх знати перед впровадженням:

Петлі та взаємні блокування. Агент A викликає агента B, який викликає агента A з іншим контекстом. Без жорсткого графа залежностей і лічильника глибини викликів система може зациклитися в спосіб, важкий для виявлення. Симптом: різке зростання витрат на інференс без пропорційного зростання цінності.

Вищі витрати на моніторинг. Кожен додатковий агент — це окрема точка метрик, алертів і логів. Моніторинг системи з п'яти агентів коштує пропорційно більше, ніж моніторинг одного. Перед впровадженням оцініть TCO через калькулятор inference та калькулятор ROI.

Складніший дебаг. Помилку в кінці конвеєра потрібно відстежити назад через кожного агента. Без хорошої системи трасування (ID сесії, що передається через весь конвеєр) діагностика займає багаторазово більше часу, ніж у одноагентній системі.

Мережеві затримки сумуються. Кожен виклик між агентами (особливо в хмарній архітектурі) додає затримку. У конвеєрі з п'яти послідовних агентів сумарний час відповіді може перевищити прийнятний для користувача поріг, навіть якщо кожен агент окремо швидкий.

Мультиагент — це інвестиція, а не короткий шлях. Якщо проблему можна вирішити кращим промптом, розширеною базою RAG або розбиттям на два незалежні процеси замість зв'язаної мережі, зробіть це спочатку. Перевірте також витрати на утримання агента AI та статтю про безпеку агентів AI, бо кожен додатковий агент розширює поверхню атаки.

Для більшості компаній 2-4 спеціалізовані агенти плюс один координатор — хороша відправна точка. Цього достатньо для обслуговування кількох відокремлених за доменами процесів, а операційна складність залишається керованою. Системи понад 8-10 агентів мають сенс у дуже великих організаціях з розвиненою DevOps-інфраструктурою під AI.

Ні. Це одна з головних переваг мультиагентної архітектури. Класифікатор намірів може працювати на малій, швидкій моделі (7B, локальній), агент синтезу звітів — на більшій хмарній моделі. Підбір моделі під завдання знижує витрати на інференс на 30-50% без втрати якості на критичних кроках.

Ключ — поширення одного ідентифікатора сесії через весь конвеєр. Кожен агент логує вхід, вихід і час обробки з тим самим ID. При інциденті фільтруєте логи за ID і реконструюєте послідовність викликів. Без цього навіть простий конвеєр стає чорною скринькою.

Залежить від класифікації ризику. Якщо будь-який агент у мережі приймає рішення, віднесені до категорії високого ризику (напр. кредитний скоринг, відбір кандидатів на роботу), вся система підпадає під вимоги AI Act як система високого ризику. Ізоляція агентів не звільняє від обов'язку документування та аудитованості всього процесу.

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