Як субагенти та багатоагентні системи розподіляють роботу та токени витрат.
Підагенти проти багатоагентних систем: концепція оркестратора та працівника, чотири топології, скільки коштує кожна у токенах, та випадки, коли один агент працює краще.
Джерела: Subagents vs. Multi-Agent Systems: The Complete Guide to How AI Agents Actually Work Together
Чому окремий агент досягає своїх меж
Кожен, хто бачив, як працюють Claude Code, LangGraph чи функція досліджень Claude, помічав момент, коли асистент перестає відповідати самостійно та звертається по допомогу. З’являється помічник для пошуку файлів, він шукає та повертається з результатами. Для вирішення дослідницького запитання модель тихо аналізує десяток джерел за час, необхідний людині для відкриття двох вкладок. Модель не стала раптово розумнішою — цю роботу виконує невелика команда.
Нижче наведено простий огляд того, як формується така командна робота, з урахуванням підагентів, багатоагентних систем, їхньої базової архітектури та витрат, пов’язаних із ними.
Один агент, тобто одна модель, яка працює в циклі з використанням інструментів, є здатним до виконання завдань. Він читає файли, переглядає інформацію, пише код та обробляє дані через кілька кроків. Однак у проекту передбачені три обмеження:
- Одне вікно контексту. Усе, що агент читає, обмірковує та робить, накопичується в одному просторі. Під час тривалої дослідницької задачі результати роботи інструментів зрештою витісняють початкове запитання з поля уваги.
- Одна лінія виконання. Робота відбувається послідовно. П’ятдесят пошуків по дві секунди кожен займають понад дев’яносто секунд, перш ніж почнеться будь-яке записування.
- Одна перспектива. Один запит формує кожне рішення, тому агенту важко одночасно використовувати два суперечливі підходи чи виявляти власні сліпі плями.
Підагенти та багатоагентні системи — це два рішення цієї проблеми, які часто поєднуються. Решта тексту пояснює, що таке кожен з них, як вони створюються та коли вони окупають себе.
Що таке підагент
Підагент — це допоміжний інструмент з вузьким функціоналом, який запускається в межах однієї сесії. Він виконує одне конкретне завдання у власному вікні контексту, а потім надсилає звіт.
Хорошим прикладом є Claude Code. Якщо основна сесія програмування мусить зрозуміти якусь незнайому частину кодової бази, вона може передати це завдання підагенту, тим самим звільнивши основну розмову. Підагент:
- починає роботу з чистим, новим вікном контексту
- зазвичай має менший, обмежений набір інструментів
- виконує власний цикл читання, пошуку та міркувань
- надсилає резюме до батьківської сесії та зберігає запис розмови для себе
Тут ключовою характеристикою є ізоляція, а не додаткова інтелектуальна здатність. Основна розмова ніколи не бачить п’ятдесят файлів, які відкрив помічник, лише три речення, що мають значення, тож основний потік залишається чітким протягом тривалої сесії та не заповнюється шумом.
Кілька особливостей визначають цю модель у тих інструментах, які її реалізують, наприклад Claude Code:
- Підагенти існують в межах однієї сесії. Це спосіб делегування завдань, а не окремі процеси, що працюють незалежно.
- Вони зазвичай не можуть створювати власних підагентів, що забезпечує просту та зрозумілу ієрархію.
- Визначення підагента пишеться один раз та використовується знову. Якщо надати підагенту-рецензенту фіксоване системне запитання та короткий список інструментів, він буде діяти однаково при кожному виклику.
Що таке багатоагентна система
Багатоагентна система має іншу структуру. Кілька незалежних агентів, кожен зі своїм контекстом, власними інструментами та іноді власною моделлю, прагнуть до спільної мети, зазвичай у процесі, який є довшим або складнішим, ніж делегування завдань у межах однієї сесії.
Найвідомішим публічним прикладом є функція Research від Anthropic. Широке запитання не відповідається безпосередньо. Натомість головний агент розробляє підхід та створює кілька підагентів, кожен з яких досліджує різний аспект одночасно. Їхні результати об’єднуються, перевіряється точність посилань, і вони повертаються як єдина відповідь.
У сукупності лідируючий агент, паралельні спеціалісти та крок фінальної синтезації утворюють модель, яку сьогодні використовують більшість виробничих багатоагентних систем, і саме цю модель розглядається далі в цій статті.
У чому різниця між двома підходами
У Інтернеті ці терміни використовуються як синоніми, що спричиняє плутанину. Фактична різниця показана тут.
Найпростіший спосіб її запам’ятати: підагент — це техніка, яка використовується всередині агента, тоді як багатоагентна система — це архітектура, створена навколо кількох агентів. На практиці багато багатоагентних систем будуються на основі моделі підагента. Лідируючий агент, який використовує підагентів, є одночасно і тим, і іншим.
Архітектура оркестратора та працівників
Майже кожна продакшн-система з кількома агентами, включаючи функцію досліджень від Anthropic, патерн керівника від LangGraph та модель підагентів у Claude Code, є якоюсь версією однієї схеми: оркестратор та працівник.
Кожен компонент має конкретну функцію:
- Головний агент (оркестратор). Він читає запит, розробляє стратегію та визначає, скільки зусиль вимагає завдання. Це рішення має більше значення, ніж здається. У ранніх версіях цих систем іноді запускалося п’ятдесят підагентів для запитання, яке потребувало лише одного.
- Пам’ять або тимчасовий буфер. План записується поза межами розмови. Довгі процеси роботи агентів можуть перевищити обсяг контексту моделі, і якщо це трапляється посеред процесу, план має залишитися актуальним після обрізання даних та не зникнути разом з ними.
У діаграмі використано два типи стрілок. Суцільні стрілки вказують на виконання завдань вниз, а пунктирні — на надсилання стислих результатів вгору. Ця асиметрія є навмисною: підагенти повертають стислий результат, а не всю історію своєї роботи, що запобігає надмірному накопиченню інформації у контексті головного агента.
Робочий процес від запитання до відповіді
Якщо відійти від окремих компонентів, ось послідовність подій від введеного користувачем запитання до готової відповіді.
Кілька кроків заслуговують на увагу:
- Крок 2 (мислення перед плануванням) має більше значення, ніж здається. Саме тут система визначає, скільки зусиль потрібно вкласти у обробку запиту: швидка перевірка фактів може вимагати одного агента та кількох викликів інструментів, тоді як запит широкого характеру може потребувати десяти чи більше підагентів із чітко розподіленими обов’язками.
- Крок 7 (повторне оброблення) відокремлює агентську систему від фіксованої схеми обробки. Нічого не прописано заздалегідь, оскільки головний агент переглядає результати та вирішує, чи відповісти, чи продовжити пошук. Саме тут найчастіше виникають проблеми. Агент, який занадто неохоче повторює обробку, дає поверхневі відповіді, а той, хто занадто активно це робить, марнує час та ресурси на пошук джерел, яких насправді немає.
- Кроки 8 та 9, де цитування є окремим етапом, існують тому, що агент, якому потрібно написати відповідь та водночас оцінити джерела, схильний робити впевнені твердження, які не мають під собою підстав. Незалежна друга перевірка допомагає це виявити.
Чотири способи організації кількох агентів
Звичайною структурою є оркестратор та працівники, але це не єдиний варіант. Залежно від того, як насправді розділяється завдання, одна з чотирьох загальних топологій підійде краще за інші.
Коли незрозуміло, що обрати, команди з розробки зазвичай дотримуються простого правила: для всього, що потрапляє у продакшн, використовувати ієрархію з керівником, а для дослідницької роботи, де потік не можна заздалегідь визначити, — мережеву або сітчасту структуру. Сітчасті схеми виглядають елегантно на діаграмах, але їх найскладніше відлагоджувати.
Чому це ефективно: економіка токенів
Важливо точно пояснити, чому багатоагентні системи краще справляються з завданнями, ніж одноагентні, адже відповідь не полягає у тому, що «більше агентів означає більше інтелекту».
У внутрішніх оцінках Anthropic схема, де Claude Opus 4 виконує провідну роль, а Claude Sonnet 4 — функції підагентів, перевершила одного агента Claude Opus 4 на 90,2% у внутрішньому дослідницькому тесті. При аналізі причин більшу частину пояснювала ємність системи. У тесті на складні пошукові завдання саме використання токенів становило близько 80% різниці в продуктивності, а кількість викликів інструментів та вибір моделі пояснювали решту факторів.
Коротко кажучи, перевага у завданнях, що вимагають широкого аналізу великих обсягів інформації, походить переважно від ємності системи. Розподіл роботи між окремими вікнами контексту надає системі значно більше можливостей для міркувань, ніж одне вікно, а кожен підагент стискає прочитане у короткий звіт.
Ця ємність не є безкоштовною. Дані процесу виробництва свідчать про те, що робочі процеси з агентами споживають приблизно в чотири рази більше токенів, ніж звичайний діалог, а багатоагентні процеси — приблизно в п’ятнадцять разів. Саме цей коефіцієнт має визначити, чи варто взагалі використовувати таку архітектуру, що веде до наступного пункту.
Коли багатоагентна система є неправильним інструментом
Більшість матеріалів про архітектуру агентів пропускають цю частину, а саме вона допомагає заощадити як час, так і бюджет токенів.
Завдання має розділятися на справді незалежні частини. Коли підзавдання сильно залежать одне від одного, їх розподіл між агентами призводить до додаткових витрат на координацію та не створює справжнього паралелізму. Окремі дослідницькі запитання добре піддаються розділенню, тоді як написання однієї цілісної функції зазвичай цього не робить.
Кодування є найяскравішим контрприкладом. У власному описі компанії Anthropic чітко зазначається: більшість завдань з кодування мають менше підзавдань, які можна виконувати паралельно, ніж у дослідженнях, а сучасні агенти ще не є надійними у координації та передачі роботи один одному в реальному часі. Інші тестові методи підтверджують це. Одна академічна оцінка показала, що багатоагентні системи для кодування використовують від 4 разів до понад 200 разів більше токенів, ніж аналогічний одноагентний система, а інший аналіз галузі виявив, що багатоагентні системи виконують завдання, які вимагають суворо послідовної роботи, на 39–70 відсотків гірше, ніж одноагентна система.
Помилки поширюються. Неправильна припущення в одному агенті залишається окремою помилкою. У координованій системі вона може поширюватися через передачу завдань та посилюватися. Один аналіз оцінив приблизне посилення на 4 рази при централізованій оркестрації, а ситуація стає ще гіршою, коли агенти працюють незалежно без координації.
Отриманий прибуток має покривати витрати. З коефіцієнтом множення близько 15 разів, конструкції з кількома агентами підходять для завдань високої цінності та складності, таких як глибокі дослідження, багатодоменний аналіз та масштабні переробки. Для всього, що добре налаштований один агент із хорошими інструментами може виконати за один прохід, вони є зайвими.
Існує простий тест: якщо ви не можете визначити, що саме буде виконувати кожен агент, на відміну від інших, ймовірно, рішенням буде сильніший один агент, а не додаткові.
Уроки з їх створення
Огляд Anthropic їхньої системи досліджень є одним із найщиріших публічних описів того, що йде не так, коли працездатна демо-версія перетворюється на продакшн-систему з кількома агентами. Найбільш корисні уроки у стислому вигляді:
- Запит є основним інструментом керування. Оскільки запит керує кожним агентом, навіть незначні зміни у формулюванні впливають суттєво на те, чи будуть підагенти виконувати завдання одночасно чи залишати прогалини.
- Розслаблена делегування призводить до дублювання зусиль. Інструкція на кшталт „дослідіть проблему нестачі напівпровідників“ здається зрозумілою, але насправді не є такою. У ранніх системах кілька підагентів досліджували одні й ті самі аспекти, оскільки ніхто не визначив, де закінчується одне завдання. Хороша інструкція вказує на мету, очікуваний формат результату та межі компетенції кожного агента.
Мінімальний опис структури
Нижче наведено спрощений, нейтральний щодо фреймворків опис оркестратора та працівника. Повторні спроби, стрімінг та постійна пам’ять відсутні, щоб було легко побачити структуру логіки; цей опис може використовуватися як псевдокод для портування до LangGraph, Claude Agent SDK чи простого циклу API.
def run_research(query: str) -> str:
# 1. Lead agent plans
plan = lead_agent.think_and_plan(query)
memory.save("plan", plan) # survives context truncation
findings = []
subtasks = plan.subtasks # explicit objective + boundaries per subtask
# 2. Spawn subagents in parallel, not sequentially
results = run_in_parallel([
subagent.execute(task=subtask, tools=subtask.allowed_tools)
for subtask in subtasks
])
findings.extend(results)
# 3. Lead agent decides: enough evidence, or loop again?
while not lead_agent.has_sufficient_evidence(findings):
new_subtasks = lead_agent.refine_plan(findings)
more_results = run_in_parallel([
subagent.execute(task=t, tools=t.allowed_tools)
for t in new_subtasks
])
findings.extend(more_results)
# 4. Synthesize, then verify citations in a separate pass
draft = lead_agent.synthesize(findings)
cited_answer = citation_agent.attach_citations(draft, findings)
return cited_answer
Два аспекти заслуговують на найбільшу увагу, і жоден з них зазвичай не зустрічається у прикладах іграшкових систем. По-перше, це run_in_parallel: виклик підагентів по одному призводить до значного втрати швидкості. По-друге, це явний цикл while, який знову планує дії, адже один фіксований цикл роботи підагентів не може адаптуватися, коли після першого проходження залишається більше запитань, ніж відповідей.
Перевірки перед випуском
Перед тим, як випустити підагента чи багатоагентну систему, перевірте наступні моменти:
- Кожен підагент має чітку мету, формат вихідних даних та межі завдання, а не просто однорядкову інструкцію.
- Підагенти працюють паралельно там, де вони справді незалежні.
- План зберігається у сховищі, а не лише у рамках розмови, на випадок скорочення контексту.
Пов’язана література
- Коли два агенти перемагають одного: Copilot для перевірки коду в LangGraph, створений у обох форматах — Створіть одного перевіряючого код агента як окремий елемент та ще одного у форматі Аналізатора з перевіркою ризиків у LangGraph, а потім дізнайтеся про три ситуації, коли використання багатьох агентів є доцільним.
- Практичні поради: Як стати одним із 1% найкращих користувачів Hermes Agent: Повний посібник — Детальний пошаговий огляд Практичних порад: Як стати одним із 1% найкращих користувачів Hermes Agent: Повний посібник, включаючи контракти, перевірки та шаблони коду для команд, які використовують цю модель.