Скільки AI-агентів потрібно: коли флот виграє в одного

Andrew Maryasov, AI-консультант, засновник Auspex і Grow2.ai. Правило «згорни ланцюг із дванадцяти агентів в одного з сильним eval» тримається рівно доти, доки завдання eval — перевірити відповідь. Там, де він здатний ранжувати багато кандидатів, а правильна відповідь наперед невідома, флот агентів доходить до кращого рішення швидше за одного. Умова тут не «скільки агентів ви можете запустити», а «чи існує автоматичний вердикт». Нижче — що саме виміряли в NVIDIA, чому друга половина того ж результату говорить протилежне, і за яких трьох умов це взагалі переноситься на бізнес-процеси.

Вісім

Число, заради якого цю роботу цитують, — вісім. У проєкті ENPIRE (NVIDIA, CMU, UC Berkeley, червень 2026) більша кількість агентів, у переказі Import AI це порядок восьми, доходить до вищих за оцінкою рішень раніше, і подеколи мультиагентна конфігурація дає вищий абсолютний бал за одиночну. Причину автори переказу називають імовірною, а не встановленою: ширше дослідження простору рішень.

Число тут — найменш цікаве. Флот у ENPIRE можливий тільки тому, що в системі вже є автоматичний вердикт «вийшло / не вийшло»; без нього вісім агентів видають вісім текстів, які хтось має прочитати. Ба більше, та сама робота містить протилежний за настроєм результат: зі зростанням кількості роботів середня утилізація робота падає, бо агент читає логи, пише код і чекає на модель, поки дороге залізо стоїть. На бізнес звідси переносяться три умови: результат перевіряється автоматично, середовище скидається без наслідків, простір рішень справді широкий. Перші дві провалює більшість процесів у компаніях.

Правило, яке зараз повторюють усі

Формулювання ходить у різних варіантах, але суть одна: якщо ви можете написати наскрізний eval для завдання (набір прикладів із правильними відповідями плюс скрипт, який ставить оцінку без людини) — згорніть ланцюг із п’яти чи дванадцяти агентів в одного з відпрацьованим промптом.

Найчіткіше воно сформульоване в AI-Native Playbook (розділ 3.4, автор — Gerstep): «Мультиагентний ланцюг — це людський спосіб упоратися зі складністю, а не відповідь на неї». Тобто команди розбивають задачу на агентів не тому, що задача цього вимагає, а тому, що не тримають складність одного промпта в голові. Eval тримає її замість них.

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

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

З аргументами все гаразд. Погано те, що правило майже завжди наводять без передумови, за якої воно істинне.

Що саме показав ENPIRE

18 червня 2026 року дослідники NVIDIA, Університету Карнегі — Меллона і Берклі виклали препринт ENPIRE — обгортку, яка дає кодовим агентам замкнутий цикл для навчання політик реальних роботів.

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

Зараз мене цікавить інша половина тієї ж роботи — та, що про кількість агентів.

Автори формулюють в анотації: «ENPIRE можна суттєво прискорити на флоті роботів», і пропонують дві метрики — Mean Robot Utilization (MRU) і Mean Token Utilization (MTU) — щоб міряти ефективність мультиагентного фізичного автодослідження. Не кількість агентів. Утилізацію.

Jack Clark в Import AI 463 (29 червня 2026) підсумовує результат так: є переконлива віддача від масштабування агентів, більша їх кількість — наприклад, вісім — доходить до вищих за оцінкою рішень раніше за інших, і подеколи мультиагентна конфігурація дає вищий абсолютний бал, ніж одиночна, ймовірно через ширше дослідження простору можливих рішень.

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

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

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

Чому це не спростування правила, а його межа

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

ENPIRE вирішує задачу протилежного типу. Який алгоритм навчить робота зав’язувати зіп-тай, наперед не знає ніхто — ні дослідник, ні агент. Робота полягає не в тому, щоб виконати відому відповідь, а в тому, щоб її знайти. Тут eval перестає бути контролером і стає суддею на турнірі: він порівнює багато кандидатів і впорядковує їх.

У цього підвищення є ціна, про яку варто сказати одразу. Щойно eval стає суддею, за яким ранжуються кандидати, він перетворюється на мішень: оптимізувати оцінку завжди дешевше, ніж оптимізувати результат. В ENPIRE це закрили грубо — у промпті прямим текстом написано, що правити код середовища не можна, це шахрайство. Механіку я розбирав окремо в тексті про reward hacking і чотири захисти; при переході від одного агента до восьми ризик не лишається тим самим, а множиться на кількість гілок.

Звідси розділення, яке я тепер вважаю точнішим за початкове правило:

Наявність автоматичного eval визначає, чи можливий флот. Ширина простору рішень визначає, чи він потрібен.

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

При вузькому просторі рішень флот не потрібен — навіть з ідеальним eval. Якщо відповідь одна, вісім агентів знайдуть ту саму відповідь вісім разів.

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

Та сама робота містить результат, який рідко цитують разом із «вісьмома агентами». Автори пишуть прямо:

Кодові агенти не використовують ресурси робота повністю, поки читають логи, пишуть код, налагоджують або чекають на мовну модель. Зі зростанням кількості роботів MRU падає, а активна утилізація GPU зростає.

Дороге і дефіцитне тут — робот. Він фізичний, його не інстанціюєш ще вісім штук командою в терміналі. Агент, навпаки, дешевий і паралельний. Коли ви додаєте роботів, вузьке місце переїжджає з фізичного шару на шар мислення: станція з парою маніпуляторів, камерами і власною RTX 5090 стоїть і чекає, поки агент дочитає логи й дочекається відповіді моделі.

Саме тому автори і запропонували MRU з MTU. Метрика флоту звучить так: яка частка дефіцитного ресурсу реально працює. Кількість запущених агентів на це питання не відповідає.

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

Три умови, за яких це переноситься на бізнес

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

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

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

Третя: простір рішень справді широкий. Є багато незалежних способів зробити роботу, і ви наперед не знаєте, який кращий. Якщо спосіб один і він описаний у регламенті — вам потрібен надійний виконавець, а не пошук.

Три з трьох — можна думати про флот. Дві з трьох — не можна, і найчастіше провалюється друга.

Де флот законний у звичайній компанії

Ділянки, де всі три умови сходяться, існують, просто їх менше, ніж здається з анонсів.

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

Найближчий аналог до того, що робить ENPIRE, — пошук самої інструкції для агента. Ви фіксуєте eval-набір, генеруєте вісім варіантів промпта чи скіла, проганяєте кожен по набору й берете той, що дав кращий бал. Це рівно та сама конструкція: паралельні гілки, спільне число, ранжування замість усереднення. І вона доступна будь-якій компанії, яка спромоглася зібрати п’ятдесят прикладів із правильними відповідями.

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

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

Коефіцієнти нагляду нікуди не поділися

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

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

Тепер видно, чому коефіцієнти нагляду саме такі. Вони описують середовища, де автоматичного eval немає і людина є eval. Коли вердикт виносить людина, кількість агентів упирається в її увагу, а бюджет і інфраструктура тут ні до чого. Чим вища ставка, тим уважніше треба дивитися і тим менше агентів вміщується в одну голову.

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

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

Як звучить правило з передумовою

Початкове формулювання варто добудувати до такого:

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

Практичний порядок дій перед тим, як додавати агентів:

1. Спитайте, чи існує машинний вердикт для цієї задачі. Немає — далі не йдіть, вся інша дискусія передчасна.
2. Спитайте, чи відома правильна відповідь наперед. Відома — вам потрібен один надійний виконавець.
3. Спитайте, що у вашому процесі є дефіцитним ресурсом на кшталт робота, і чи не почне він простоювати, поки агенти думають.
4. Міряйте утилізацію цього ресурсу, а не кількість запущених агентів.

Четвертий пункт — прямий висновок із MRU. Кількість агентів на дашборді нічого не каже про те, чи працює те, за що ви платите. І як з будь-якою метрикою агента, спершу назвіть знаменник: «утилізація 60%» без відповіді на питання «від чого рахували» — це просто число, а не показник.

Чого ця робота не доводить

ENPIRE не доводить, що вісім агентів кращі за одного взагалі. Результат отриманий на одному класі задач — пошук алгоритму навчання політики для маніпуляції — у середовищі з автоматичним ресетом і автоматичною верифікацією.

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

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

FAQ

Скільки AI-агентів потрібно бізнесу?

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

Коли флот агентів реально виграє в одного агента?

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

Чи означає це, що правило «один агент із сильним eval» помилкове?

Ні. Воно правильне для задач, де відповідь по суті визначена, а eval перевіряє результат — це більшість корпоративних процесів. Помилкове не правило, а його застосування без цієї передумови до задач пошуку, де відповідь наперед невідома.

Що таке MRU і MTU в ENPIRE?

Mean Robot Utilization і Mean Token Utilization — дві метрики, які автори запропонували для вимірювання ефективності мультиагентного фізичного автодослідження. Вони міряють, яка частка дефіцитного ресурсу реально працює, а не скільки агентів запущено.

Чому зростання флоту роботів погіршує утилізацію?

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

Чи можна масштабувати агентів, якщо в нас немає автоматичної перевірки?

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

З чого почати, якщо хочеться спробувати паралельний пошук?

З найдешевшої ділянки, де вердикт уже автоматичний. Зберіть п’ятдесят-сто прикладів із правильними відповідями, згенеруйте кілька варіантів інструкції для агента, проженіть кожен по набору й візьміть кращий за балом. Це та сама конструкція, що у ENPIRE, тільки без роботів.

Що далі

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

Компанії зазвичай йдуть у зворотному порядку і впираються в те, що дискусія про кількість агентів була передчасною на два кроки.

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

Джерела:

• ENPIRE: Agentic Robot Policy Self-Improvement in the Real World — препринт, arXiv:2606.19980, 18.06.2026 (NVIDIA, CMU, UC Berkeley)
• Проєктна сторінка ENPIRE — анотація, метрики MRU/MTU, дерево гіпотез
• Import AI 463 — Jack Clark, 29.06.2026, переказ результату про масштабування агентів
• AI-Native Playbook, 3.4 Making Agents Reliable — Gerstep, формулювання правила про згортання ланцюга

Опублікував Andrew Maryasov, AI-консультант, засновник Auspex і Grow2.ai; впровадження ведуть Auspex (CRM) і Grow2.ai (AI-агенти).