Команда з 6 AI-агентів: як ми будуємо мультиагентні системи і на чому спотикаємось
Один бот не тягне складний процес. Береться за задачу з п’яти кроків, тримає в голові перші два, на третьому втрачає нитку, на четвертому починає вигадувати, а на п’ятому віддає результат, який потім переробляєш вручну. Ми впирались у це раз за разом, поки не розподілили роботу між кількома агентами з чіткими ролями. Далі - як влаштована наша команда з шести агентів і де ми набили гуль.
Навіщо взагалі шість, а не один
Складна задача - це не один великий запит, а ланцюжок різних операцій. Знайти дані, написати чернетку, перевірити факти, записати результат у систему, оцінити, чи він придатний. Кожна операція потребує свого набору навичок, своїх інструментів і свого фокусу.
Коли все це звалюється на одну модель, вона тримає в контексті одразу всі ролі. Інструкції дослідника змішуються з інструкціями редактора, проміжні дані забивають вікно, і до кінця ланцюжка агент працює із замусореною головою. Якість падає не тому, що модель слабка. Просто ми змусили її робити п’ять справ одночасно.
Ми будуємо мультиагентні системи на рушії Hermes - агентному фреймворку з оркестратором і субагентами. У кожного агента свій набір інструментів, свої ключі доступу і своя пам’ять. Ніхто не лізе в чужу зону. Звичайний поділ праці, тільки замість людей - спеціалізовані агенти.
Чи можна обійтися двома-трьома? Іноді так. Але щойно в процесі з’являються перевірка якості, запис у зовнішні системи і фінальний контроль, ролі починають конфліктувати всередині одного агента. Перевіряючий не повинен переписувати, автор не повинен лізти в базу, а той, хто спілкується з користувачем, не повинен тонути в технічних деталях. Шість ролей - це не самоціль, а мінімум, при якому кожен крок отримує чисту голову.
Хто за що відповідає
У робочій конфігурації у нас шість агентів: один оркестратор і п’ять спеціалістів.
Оркестратор веде діалог з користувачем і розуміє задачу цілком. Розбиває її на кроки, роздає їх спеціалістам і збирає результат назад. Сам «чорну роботу» не робить - не шукає, не пише, не смикає API. Його справа - думати про задачу як про ціле і керувати рештою. Це єдиний агент, який бачить усю картину.
Дослідник шукає і збирає інформацію. Ходить по джерелах, витягує факти, перевіряє, що дані не суперечать одне одному. Віддає оркестратору не сирий дамп сторінок, а зібрану фактуру.
Автор перетворює фактуру на текст або матеріал потрібного вигляду. Стаття, пост, лист, опис - його задача оформити зміст так, як вимагає формат. Факти він не перевіряє, він працює з тим, що зібрав дослідник.
Редактор-перевіряючий ловить помилки автора. Фактчек, якість, логіка, тон. Це окремий агент саме тому, що автор погано бачить власні огріхи - та сама історія, що й у людей. Свіжий погляд з чистим контекстом знаходить те, що автор пропустив.
Інтегратор записує результат туди, де він має опинитися. Смикає API, кладе запис у базу, відправляє в потрібний сервіс. Це руки команди - агент, який стикається із зовнішніми системами.
Оцінювач - фінальний контроль. Дивиться на готовий результат і звіряє з критеріями: відповідає чи ні тому, що просив користувач, немає явних провалів. Якщо щось не так, задача іде на доопрацювання, а не до користувача. Останній фільтр перед видачею.
Як вони передають роботу
Оркестратор - єдина точка рішень. Він отримує задачу, розкладає її на кроки і роздає спеціалістам. Далі агенти передають роботу по ланцюжку: дослідник зібрав - автор оформив - редактор перевірив - інтегратор записав - оцінювач підтвердив. Цю передачу ми називаємо handoff.
Є загальний стан задачі, до якого агенти звертаються: що вже зроблено, що на якому кроці, який результат чекаємо на виході. При цьому у кожного агента свій чистий контекст. Дослідник не бачить чернетку автора, автору не потрібні логи інтегратора. Кожен отримує рівно те, що потрібно для його кроку, і нічого зайвого.
У цьому вся суть. Не один агент із роздутою пам’яттю, а кілька з вузьким фокусом і суворою передачею результату між ними.
Оркестратор при цьому не запускає всі шість агентів завжди. Якщо задача проста, він може пройти коротким маршрутом: дослідник і автор, без повного конвеєра. Кого підключати, вирішує він сам - дивиться на задачу і збирає ланцюжок під неї. Тож шість агентів - це не жорсткий потік, через який все проганяється однаково, а набір ролей, з яких оркестратор щоразу будує потрібний маршрут.
Граблі, які ми зібрали
Звучить стрункло, але перші збірки працювали погано. Ось п’ять проблем, на які ми наступили, і що з кожною зробили.
Переповнення контексту. Спільний контекст розбухав. Результати одного агента підмішувались до іншого, вікно забивалось, агенти втрачали фокус і починали плутатись, що від них хочуть. Рішення - жорстко різати пам’ять по ролях. Кожен агент бачить лише своє: дослідник - запит і джерела, автор - зібрану фактуру, і так по ланцюжку. Жодного спільного казана, в який звалюється все підряд.
Криві handoff. На передачі між агентами губилися деталі. Автор віддавав результат вільним текстом, редактор розумів його по-своєму, і на виході виходило не те, що задумувалось. Рішення - суворий формат передачі. Агент віддає не «ось що я написав, розбирайтесь», а структурований результат з полями, які наступний агент точно зрозуміє. Вільний текст між агентами ми прибрали.
Вартість токенів. Шість агентів споживають більше, ніж один. Очевидно, але в перших запусках рахунок дивував. Рішення - не садити дорогу модель на кожну роль. Прості задачі на кшталт форматування або роздачі кроків віддаємо дешевим моделям, а важке міркування - дорогим. Плюс кешуємо те, що повторюється, щоб не платити двічі за одне й те саме.
Дублювання роботи. Агенти робили одне й те саме або починали ходити по колу: дослідник збирав дані, які автор потім збирав знову, оцінювач відправляв на доопрацювання без ясної причини. Рішення - чіткі межі відповідальності. Кожен агент знає, де його зона починається і де закінчується, а оркестратор залишається єдиною точкою, яка вирішує, хто що робить наступним. Жодних самостійних ініціатив у чужій зоні.
Складно налагоджувати. Коли щось ломалось, було незрозуміло, хто з шести винен. Результат поганий, а на якому кроці він зіпсувався - загадка. Рішення - логувати кожен крок і кожне рішення оркестратора. Ми тримаємо трейс по всьому ланцюжку: що отримав агент на вході, що віддав на виході, чому оркестратор відправив задачу саме сюди. Коли є повний слід, розбір збою займає хвилини, а не години.
Що це дає на практиці
Ця архітектура - не теорія, вона працює в наших продуктах.
AI-секретар веде діловодство голосом. Людина надиктовує доручення, а команда агентів розбирає його, оформляє потрібний документ, перевіряє і кладе в систему. Одним ботом таке не зробити - надто багато різних кроків від розпізнавання змісту до запису в базу.
AI Контент-завод - конвеєр з агентів, який перетворює новину на готовий набір матеріалів. Дослідник збирає контекст навколо новини, автор готує статтю, редактор вичитує, далі зі статті народжуються пости під різні майданчики, а інтегратор готує банери. Новина на вході, готовий комплект на виході. Без розподілу на ролі цей конвеєр захлинався б на першій же ланці.
З чого почати
Якщо у вас є процес, який один бот не витягує - це кандидат на мультиагентну систему. Ознака проста: задача складається з різних за характером кроків, і на кожному потрібен свій фокус.
Починати варто не з шести агентів одразу, а з розбору процесу на ролі. Де збір даних, де творча частина, де перевірка, де запис у систему. Коли ролі зрозумілі, архітектура збирається сама.
Ми будуємо такі системи під конкретну задачу - від розбору процесу до робочого конвеєра агентів. Опишіть, що у вас не тягне один бот, і ми подивимось, як це розкласти: puramind.ai#contacts.