Порівняння чотирьох шаблонів багатоагентних систем: підагенти, навички, передача обов’язків, маршрутизатори.
Практичне порівняння чотирьох основних шаблонів багатоагентних систем для штучних інтелектуальних агентів: скільки коштує кожен, де він застосовується та як вибрати один, щоб не створювати зайвого.
Джерела: I’ve Been Building AI Agents Wrong. Here’s What I Learned About Multi-Agent Architectures.
Знайома історія: команда створює складну систему агентів із кількома моделями, заплутаними шляхами передачі даних та агентами, які генерують інших агентів, а потім виявляє, що версія з одним агентом, створена за вихідні, перевершує її за часом відгуку, здатністю до дебагування та всіма іншими важливими показниками. Щоб вийти з цієї пастки, спочатку потрібно усвідомити, що майже кожна серйозна багатоагентна система будується за допомогою чотирьох шаблонів, та знати, що кожен з них коштує вам та що приносить.
Чи справді вам потрібні кілька агентів?
Зазвичай ні. Часто вже на першому тижні вдається до використання багатоагентної платформи під впливом реклами та привабливості діаграми, наповненої стрілками, але результат часто є крихким та дорогим, тоді як один агент із правильними інструкціями міг би працювати краще.
Дві ситуації виправдовують використання додаткових механізмів. Перша — це обмеження обсягу контексту. Неможливо включити до одного запиту юридичний аналіз, медичну кодування, фінансове моделювання та обробку емоційних сигналів та очікувати послідовного результату, адже перевантажений контекст погіршує якість та уповільнює відповіді. Друга ситуація — це розподіл обов’язків між командами. Коли одна команда відповідає за запаси, а інша — за виконання замовлень, їх змушення використовувати один спільний запит призводить до конфліктів, проблем з реалізацією та плутанини щодо того, хто відповідає за що. У разі наявності будь-якої з цих проблем наведені нижче підходи стають практичним рішенням, а не просто архітектурою заради неї самої.
Підагенти: керівник штабу
Уявіть собі начальника штабу, який ніколи не виконує роботу особисто, але точно знає, кого запитати. Головний агент-керівник контролює всю ситуацію. Коли потрібно отримати дані CRM, скласти електронний лист чи провести обчислення, він викликає спеціалізованого підагента, ніби це інструмент, отримує результат та об’єднує все разом.
Ключовою перевагою є чистота. Кожен підагент працює ізольовано у власному вузькому контексті, тому ніщо не «протікає» між доменами: юридичний підагент нічого не знає про запаси. Така ізоляція є корисною, коли домени великі та різні, адже кожен фахівець може виконувати детальні інструкції, не конкуруючи за простір із несумісним матеріалом. Це також полегшує тестування, оскільки кожен підагент можна оцінити окремо. Ціною є додатковий виклик моделі за кожен запит, адже результати надсилаються назад через керівника, тож три підагенти означають три додаткові поїздки. Додатки, чутливі до затримок, швидко це відчувають.
Це підходить для дослідницьких платформ, які делегують роботу фахівцям у певних галузях, особистих асистентів, які одночасно координують календар, електронну пошту та завдання, а також для систем медичної триажу, де головний агент одночасно направляє завдання до клінічних підагентів. Одна з опублікованих дослідницьких конфігурацій, у якій велика модель виконувала основну роль, а менші моделі — функції підагентів, за даними досліджень, перевершила окрему велику модель більш ніж на 90% у внутрішніх тестах. Паралельне міркування у окремих вікнах контексту є дуже ефективним, коли це необхідно для виконання завдання.
Навички: один агент, багато ролей
З технічної точки зору це все ще єдиний агент, хоча він і не поводиться як такий. Він починає кожну розмову, знаючи лише назви та короткі описи наявних навичок, а повний контекст навички завантажується, коли з’являється щось релевантне. Лікар-універсал працює аналогічним чином, запускаючи спеціалізований протокол при появі певного стану, не запам’ятовуючи їх усіх для кожної консультації.
Практичною перевагою є незалежність. Команда, яка працює з Python, підтримує навичку Python, а команда, яка працює з базами даних, — навички SQL, причому кожна з них є окремим пакетом, і ніхто не координує роботу за спільним запитом. Для організацій з розподіленою інженерною структурою це справжнє полегшення. Однак є проблема накопичення токенів: чим довша розмова та чим більше навичок вона завантажує, тим важчим стає контекст, що зрештою погіршує як витрати, так і якість у кінці сеансу. Це можна контролювати, але це реальна проблема.
Навички підходять для асистентів з кодування, які переходять між режимами фронтенду, бекенду та інфраструктури, творчих інструментів, що змінюють стиль написання, а також для агентів підтримки, які застосовують спеціалізовані знання залежно від конкретної проблеми клієнта.
Передача обов’язків: естафета
Якщо підагенти — це паралельне делегування, а навички — динамічна спеціалізація, то передача обов’язків — це послідовний процес, що найбільше нагадує спосіб, яким люди просуваються крізь складну процедуру. Користувач починає співпрацю з Агентом А. Як тільки щось говориться або досягається певна умова, контроль переходить до Агента Б, у якого є власні системні вказівки, інструменти та, можливо, особливості характеру, а потім — до Агента В. Протягом усього цього часу стан справ, тобто все, що було обговорено та вирішено, передається разом із кожною передачею.
Переходи керуються станом. Агенти не просто взаємодіють між собою; вони оновлюють спільний стан, і саме цей стан визначає, хто буде активним далі. Фактично це машина станів, у якій агенти є станами.
Це природна структура для багатоетапних процесів підтримки (сортування, потім діагностика, потім вирішення проблеми), для юридичного оброблення справ, де перевірка конфліктів має передувати прийманню справи, а також для процесів оформлення замовлень, де оплата не може розпочатися до підтвердження кошика. Люди забувають про те, що послідовність означає відсутність паралелізму: якщо вам потрібно одночасно звертатися до трьох баз знань, шукайте інший підхід. Цей підхід підходить для робочих процесів, де крок B справді не може розпочатися до завершення кроку A. Керування станами також є складним, і коли ланцюжок передачі даних руйнується, виправлення помилок не є простим, тому перед тим, як обрати цей шлях, виділіть додатковий час на відстеження та використання інструментів для спостереження.
Маршрутизатор: диспетчер повітряного руху
Концептуально це просто. Щось у вхідному класі класифікує кожен надійшлий запит та направляє його до відповідного фахівця чи фахівців. Вони працюють паралельно, а їхні результати об’єднуються в одну відповідь. Рутер не зберігає жодного стану, тому кожен запит обробляється незалежно.
Його сильною стороною є пропускна здатність. Запит, який стосується трьох областей знань, одночасно надсилається до всіх трьох агентів, і загальний час обробки приблизно дорівнює часу обробки найповільнішого запиту, а не сумі часів. У корпоративній базі знань запит співробітника може стосуватися правил кадрів, рекомендацій з IT-безпеки та вимог фінансового контролю; рутер одночасно активує всі трьох агентів та синтезує одну відповідь, тоді як інакше знадобилося б три окремі запити або один перевантажений агент, який мусив би обробляти всі три області.
Чесна межа полягає у тому, що безстановий підхід означає відсутність пам’яті. Наступне запитання надходить без жодних слідів попереднього, що є справжньою проблемою для продуктів для спілкування. Зазвичай цю проблему вирішують шляхом оточення роутера становим зовнішнім агентом, який зберігає історію, хоча це поєднує різні патерни та додає складності. Роутери підходять для систем з великим обсягом даних із чітко розділеними компонентами, для всього, що потребує одночасного використання кількох джерел інформації, а також у випадках, коли послідовність кожного запиту важливіша за безперервність спілкування.
Вибір
Це не обов’язково має бути складно.
- Кілька окремих доменів, чиста паралельна обробка та централізований пункт керування підагентами.
- Один агент з багатьма спеціалізаціями, який належить різним командам, та посилання на відповідні навички.
- Робочий процес, який є за своєю природою послідовним, із передумовами та станом, що передається далі, та посилання на передачу обов’язків.
Ще одним фактором є продуктивність. Схеми, навички та процедури передачі даних, які зберігають стан, дозволяють заощадити приблизно 40–50 відсотків викликів моделі під час повторних запитів, оскільки вони пам’ятають попередній контекст. Підагенти та маршрутизатори не мають стану та сплачують однакову вартість щоразу, але в обмін отримують сильну ізоляцію контексту, що є важливим для паралельних завдань у великих доменах.
Обмеження — на першому місці
Не створюйте багатоагентні системи лише для того, щоб виглядати сучасно; створюйте їх для вирішення реальної проблеми, з якою ви стикаєтесь. Розумний підхід — це спочатку один агент із дійсно якісними інструкціями, потім інструменти, а вже пізніше багатоагентні схеми, коли ви зіткнетеся з конкретними перешкодами, такими як перевантаження контексту, труднощі у координації роботи команди чи потреба у паралелізмі, яку не може забезпечити один агент. Команди з найкращими системами — це зазвичай ті, які найдовше опиралися складності та могли пояснити, навіщо існує кожен елемент.
Що буде далі
Вважайте ці чотири патерни основною граматикою проектування багатоагентних систем на сьогодні, оскільки нові терміни з’являються дуже швидко. Постійні локальні агенти, які зберігають пам’ять між сеансами та підключаються до особистих файлів та додатків, переходять від досліджень до реальних продуктів. Протокол Model Context Protocol, за даними на початок 2026 року, мав 97 мільйонів встановлень, і він стає основою для взаємодії агентів від різних постачальників без необхідності спеціальної інтеграції. Починають з’являтися мережі агентів, які динамічно створюють нових агентів, скориговуючи кількість своїх працівників відповідно до складності завдання. Субагенти, навички, процедури передачі та маршрутизатори є основою всього цього, тому їх вивчення зараз дає перевагу. Основне правило для прийняття рішення: спочатку описайте конкретну проблему, вкажіть патерн, який її вирішує, а лише потім складіть діаграму. Почніть з простого, будьте чесні щодо своїх потреб, і коли ви перейдете до багатоагентних систем, ви знатимете, які варіанти обрати.