Усі уроки · 44
Мультиагентні системи
Коли одного агента замало: ізоляція контексту, спеціалізація, паралельна робота, шаблон «оркестратор — виконавці» та підводне каміння, про яке ніхто не попереджає.
Навіщо ділити одного агента на кількох?
Уявіть одну здібну людину, яка виконує весь проєкт сама: досліджує ринок, пише тексти, перевіряє цифри, малює слайди. Можливо — але повільно, а до шостої години вона тримає в голові стільки, що деталі починають вислизати. Команда з чотирьох спеціалістів працює швидше, і кожен лишається зібраним на своїй ділянці. Ціна — координація: комусь потрібно роздавати роботу й зшивати результати.
В агентів та сама проблема. В одного агента одне контекстне вікно — текст, який він бачить одночасно, його робоча пам’ять, — і один характер. Це стає обмеженням у трьох випадках:
- Ізоляція контексту. Один агент, який вивчає двадцять джерел, заповнить своє контекстне вікно шумом. До моменту, коли він пише звіт, корисні факти виявляються розбавленими десятьма тисячами токенів нерелевантних результатів пошуку. А кожен виконавець (worker) читає лише свої джерела й повертає тільки те, що важливо.
- Спеціалізація. Промпт, який робить агента прискіпливим рецензентом коду, водночас робить його гіршим дослідником в інтернеті. Розділення ролей дає змогу кожному агентові отримати сфокусовані інструкції та лише потрібні йому інструменти — з тієї самої причини, з якої в команді є і дизайнер, і бухгалтер.
- Паралельна робота. Якщо один агент обробляє десять документів послідовно, на їх стислий переказ іде вдесятеро більше часу, ніж на один. Незалежні підзавдання можна виконувати одночасно, в окремих контекстах — так само, як четверо людей можуть прочитати по одному розділу.
Підступ у тому, що мультиагентні системи примножують усе, зокрема витрати, затримку й кількість місць, де щось може піти не так. Більше агентів — це більше рук, але й більше координації. Починайте з одного агента; розділяйте, коли зіткнетеся з однією з перелічених вище проблем.
Шаблон «оркестратор — виконавці»
Найпоширеніша структура — керівник і команда. Продовжуючи аналогію: керівник проєкту сам не пише ні рядка тексту, але вирішує, хто що робить, і збирає результат:
- Оркестратор отримує мету, розбиває її на підзавдання й вирішує, хто що робить.
- Виконавці отримують кожен по одному сфокусованому підзавданню, виконують його у власному чистому контексті зі своїми інструментами й повертають результат.
- Оркестратор збирає результати, помічає прогалини, за потреби доручає доопрацювання й складає підсумкову відповідь.
Користувач просить звіт про ринок електросамокатів у Європі.
Зверніть увагу, завдяки чому це спрацювало: кожен виконавець повернув стисле резюме, а не сиру стенограму. Контекст оркестратора лишається невеликим — у цьому весь сенс шаблону.
Як агенти спілкуються між собою
Під капотом ніякої таємниці немає: передача між агентами — це просто виклик
інструмента, що запускає цикл іншого агента. В оркестратора є інструмент на
кшталт assign_task(worker="pricing", task="..."); ваш код піднімає виконавця,
проганяє його цикл і повертає його фінальне повідомлення як результат інструмента.
Під час проєктування потрібно вирішити три питання:
- Що передається між ними. Зазвичай вистачає опису завдання на вході та підсумкового звіту на виході. Якщо передавати між агентами цілі стенограми, повертається проблема шуму, від якої ви намагалися піти.
- Хто що бачить. Виконавець отримує завдання та лише ті файли чи дані, які йому потрібні. Мінімум вхідних даних — менше чинників, що відволікають, і нижчі витрати на токени.
- Хто головний. В ієрархічних схемах вирішує оркестратор, а виконавці виконують. У схемах-«пайплайнах» агенти передають результат фіксованим ланцюжком: автор, потім рецензент, потім редактор. Фіксовані пайплайни менш гнучкі, зате простіші в налагодженні.
Витрати й підводне каміння
- Поширення помилок. Якщо виконавець повертає хибний факт, оркестратор зазвичай не може цього помітити — він упевнено зводить усе докупи. Помилка на другому кроці тихо отруює п’ятий. Заходи: агенти-перевіряльники, які звіряють твердження; структуровані схеми виводу; вимога до виконавців посилатися на джерела.
- Налагоджувати важче. Стенограма одного агента була історією, яку можна прочитати. Десять агентів породжують павутину переплетених циклів. Трасування з уроку SDK і фреймворки для агентів перестає бути необов’язковим — це єдиний спосіб побачити, що сталося.
- Витрати множаться. Кожен виконавець стартує зі своїм контекстом і своїми викликами моделі; оркестратор перечитує все. Завдання, що коштує один долар для одного агента, може коштувати п’ять доларів для команди з п’яти.
- Накладні витрати на координацію. Агенти можуть дублювати роботу одне одного, чекати одне на одного або сперечатися. Кожне повідомлення між ними витрачається на координацію замість завдання.
Коли додавати агента
Додавайте агента лише тоді, коли можете назвати проблему, яку він розв’язує: контекстне вікно, що переповнюється, конфлікт ролей у промпті або підзавдання, які можна виконувати паралельно. Якщо назвати проблему не виходить, один агент із добрим промптом і добрими інструментами майже завжди дешевший, швидший і простіший у налагодженні.
Перевірте себе
Що з цього — вагома причина розділити одного агента на кількох?
Що має повертати оркестраторові агент-виконавець?
Яка головна прихована ціна мультиагентної системи?
Куди йти далі
Тепер ви можете проєктувати системи, де кілька агентів ділять роботу під проводом оркестратора, — і знаєте, коли цього робити не варто. Якщо щось із цього здалося абстрактним, перегляньте два попередні уроки: що таке AI-агент і SDK і фреймворки для агентів, звідки зазвичай і береться обв’язка для цього шаблону.