Порівняння AutoGen та CrewAI: створення команд агентів, підрахунок їхніх витрат

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

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

У цій галузі домінують дві платформи, які тут порівнюються: AutoGen, створений Microsoft Research у вигляді відкритого коду, та CrewAI — молодша платформа, розроблена з урахуванням корпоративних робочих процесів. Третій інструмент, AgentOps, додає рівень спостережуваності, щоб можна було бачити, що роблять агенти та скільки це коштує.

Ролі замість одного великого запиту

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

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

• Спеціалізація підвищує якість. Агент, чиєю єдиною метою є перевірка коду на наявність проблем з безпекою, буде перевіряти його більш послідовно, ніж універсаліст, який виконує кілька завдань одночасно.
• Цикли зворотного зв’язку стають чіткими. Надсилання результатів роботи одного агента іншому, чиїм завданням є їх оцінка, створює свідомий цикл перевірки замість сподівань на те, що сама модель виявить власні помилки.
• Можливим стає паралельна робота. У більш складних системах агенти можуть одночасно працювати над різними частинами більшої мети, причому один агент займається дослідженнями, а інший — написанням тексту, виконуючи окремі підзавдання.

Складною частиною, яку кожна платформа вирішує по-своєму, є комунікація. Як агенти обмінюються інформацією? Чи ведуть вони одну розмову, чи мають ізольовані діалоги, які лише іноді перетинаються? Відповіді на ці запитання відрізняються у AutoGen та CrewAI, і саме ця різниця впливає на все інше.

AutoGen: все є розмовою

AutoGen від Microsoft розглядає кожну взаємодію агентів як розмову. Основне рішення, яке лежить в основі цього інструменту, полягає у тому, що агенти спілкуються між собою природною мовою, так само, як це роблять люди у чаті. Це робить його інтуїтивно зрозумілим: кожен, хто бачив, як двоє колег у каналі Slack обмінюються думками та удосконалюють ідею, вже має уявлення про принципи функціонування розмовних агентів AutoGen.

Спробувати у AutoGen Studio

Перш ніж писати будь-який код на Python, AutoGen Studio пропонує графічний інструмент для експериментування. Його можна встановити за допомогою pip, він читає ключ API з змінної середовища та запускається за допомогою одного командного запиту. Потім відкривається інтерфейс браузера. Там потрібно ввести завдання, і проксі-агент користувача працює з одним або кількома асистентськими агентами, поки завдання не буде виконане.

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

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

Є одна рекомендація, яка постійно згадується: запускайте AutoGen та AutoGen Studio у Docker щоразу, коли генерований код може впливати на операційну систему. Агенти розроблені для написання та виконання довільного коду, тому контейнер захищає хост від побічних ефектів. Ця порада стає ще більш актуальною, оскільки агентам надають більше автономії.

Навички як додаткові здібності

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

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

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

Чистий код з pyautogen

Після Studio наступним кроком є написання коду на Python з використанням пакету pyautogen. Важливими є два елементи:

• ConversableAgent — це універсальний агент, який безпосередньо спілкується з LLM.
• UserProxyAgent виступає в ролі людського користувача та може виконувати код у робочій директорії.

Мінімальна налаштування з’єднують їх та розпочинають розмову, наприклад, запитуючи рішення задачі FizzBuzz у одному рядку. Під час виконання проксі запитує про відгук після того, як асистент запропонує щось. Натискання Enter без відгуку означає, що потрібно продовжити та виконати код самостійно. Якщо бракує необхідного пакету, наприклад Pygame, проксі встановлює його перед виконанням програми. Це самостійне забезпечення є невеликим, але значущим ознакою свободи, яку можуть мати ці системи, зі своїми перевагами та недоліками.

Корисні завдання з програмування для оцінки моделей включають перевірку того, чи є число простим, створення гри Snake та клону Asteroids у Pygame. Вони є самодостатніми, піддаються тестуванню та достатньо різноманітні за рівнем складності, щоб виявити відмінності між моделями чи конфігураціями.

Додавання критика через вкладені чати

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

Замість того, щоб одразу включати рецензента до основної розмови, AutoGen пропонує вкладені чати. Проксі користувача реєструє вкладений чат, який активується щоразу, коли агент-інженер створює новий результат. Код автоматично надсилається рецензенту у власному бічному чаті; рецензент відповідає зі своїми зауваженнями, які потім передаються назад у основну розмову. Таким чином етап перевірки вставляється без того, щоб рецензент заважав у кожному кроці, і він висловлюється лише тоді, коли є щось нове для аналізу.

При виконанні завдання, такого як створення гри Snake за допомогою Pygame, різниця порівняно зі звичайною роботою інженера з використанням проксі є помітною. Після виконання коду з’являється експерт із списком пропозицій щодо покращень, що фактично імітує процес перегляду pull-request, який щодня проводять людські команди.

Кешування для контролю витрат

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

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

Груповий чат та проблема передачі інформації

Вкладені чати мають структурну слабкість, яка нагадує дитячу гру „телефон“. Інформація передається від одного агента до іншого по ланцюзу, і з кожним кроком деталі можуть загубитися, спотворитися або бути переосмислені. Якщо оцінювач ніколи не бачить повного початкового завдання, а лише те, що інженер вирішив передати, його відгук може не відображати суті проблеми.

Рішенням AutoGen є груповий чат. Об’єкт GroupChat зберігає спільний набір агентів та повідомлень, схожий на канал команди, замість низки точкових ретрансляторів. GroupChatManager координує чергування, щоб агенти не відповідали одночасно. Ключовою властивістю є те, що кожен учасник може бачити всю історію розмови, а не лише те, що йому безпосередньо передано.

Повторне створення прикладу інженера та критика з використанням групового чату забезпечує більш послідовну співпрацю. Коментарі критика ґрунтуються на тому самому повному контексті, який був у інженера, і інженер може безпосередньо відповідати на конкретні зауваження, замість того щоб працювати з перефразуванням. Ціною, як і очікувалося, є зайва об’ємність тексту. Групові розмови споживають більше токенів, оскільки кожен агент фактично прослуховує кожну зміну, що має значення при оплаті за токен у великих масштабах.

Що вчать ранні приклади

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

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

CrewAI: структура замість імпровізації

Якщо AutoGen спрямований на відкриті діалоги, то CrewAI має більш структурований підхід та чітко орієнтований на бізнесові та виробничі умови. Замість вільного діалогу він вимагає трьох чітких визначень: агентів із їхніми ролями, цілями та історіями; завдань, які їм призначені; та команди, яка об’єднує їх за певною стратегією обробки.

З чого складається агент

Агент CrewAI налаштовується за допомогою кількох параметрів:

• role: короткий позначник функції агента, наприклад Senior Joke Researcher.
• goal: твердження мовою природи про те, що намагається досягти агент, яке часто створюється за шаблоном для подальшого використання з різними вхідними даними.
• backstory: наратив, який формує персонажа, надаючи контекст та риси характеру, схожий на персонажа у системних запитах.
• memory та verbose: прапорці, які контролюють, чи буде агент зберігати контекст між взаємодіями та чи буде він виводити свої міркування у консолі.
• allow_delegation: чи може агент делегувати завдання іншим учасникам команди.

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

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

Ігровий приклад: команда жартів

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

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

AgentOps: стеження за витратами

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

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

• загальну тривалість виконання та середовище, в якому воно відбулося,
• кількість токенів запиту та відповіді для кожного виклику LLM,
• час виконання кожного окремого виклику,
• оцінку вартості всього процесу у доларах.

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

Команда розробки ігор

Для прямого порівняння з прикладами кодування AutoGen, CrewAI використовується для створення невеликої команди з трьох агентів для розробки ігор:

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

Завдання виконуються за такою самою структурою: один створює початкову реалізацію, другий перевіряє її на дефекти, а третій об’єднує обидві версії в остаточну, виправлену версію. Цей трьохетапний процес перевірки — написання, критика та завершення — є більш деталізованою версією підходу AutoGen, який ґрунтується на ролі інженера та критика, та реалізований у CrewAI через декларативне розділення завдань та агентів.

Коли скрипт запускається інтерактивно та запитує, яка гра потрібна та як вона має поводитися, код зазвичай виходить значно кращого якості, ніж у випадку роботи одного автономного кодувальника без керування. Частково це пов’язано з тим, що контроль головного інженера з якості дозволяє виявити проблеми, які інакше могли б залишитися непоміченими.

Послідовна та ієрархічна обробка

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

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

Ієрархічна обробка передбачає наявність керівника над командою, зазвичай це власне підключення LLM, яке використовується лише для координації та контролює агентів та завдання, замість того щоб змушувати їх діяти синхронно. Переключення є простим: вкажіть Process.hierarchical замість Process.sequential та надайте параметр manager_llm, яким зазвичай є інстанція ChatOpenAI з температурою нуль для більш стабільних рішень щодо керування.

На папері ієрархічний режим мав би бути кращим, адже роль менеджера відображає принципи функціонування великих людських організацій. Однак експерименти показують інше. За даними AgentOps, виконання тієї самої завдання в ієрархічному режимі коштувало більш ніж удвічі більше, причому код не став значно кращим у цьому випадку. Це приголомшливий факт. Додавання координації, нагляду та кількох рівнів агентів не завжди покращує результати, а багатоагентні системи так само легко можуть потрапити у дорогі, неефективні цикли, коли ніхто уважно не стежить за ними.

Зупинка неконтрольованих агентів

Цей результат пов’язаний із прихованим способом збою – повторюваними шаблонами мислення. Агент, який не впевнений у власних рішеннях, може постійно повертатися до одних і тих самих варіантів ідеї замість того, щоб прийняти рішення та рухатися далі, витрачаючи ресурси та гроші без реального прогресу.

У AgentOps є візуалізація Repeat Thoughts саме для цього — вона показує, як часто міркування агента повертаються до схожого контенту під час виконання завдання. Часте повторення є ознакою того, що щось у структурі потрібно змінити. Можливо, описи завдань занадто неоднозначні, можливо, для складності проблеми залучено занадто багато агентів, або ж режим обробки потребує перегляду. Такі діагностичні засоби допомагають відрізнити випадкові експерименти від систематичної роботи виробничого рівня. Краще бачити, коли щось йде не так, ніж чекати на надто великий рахунок.

Стилі комунікації поруч один з одним

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

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

Вибір між двома

Жодна з цих платформ не є абсолютно кращою. Кожна відображає різні погляди на те, скільки підтримки має мати багатоагентна система. AutoGen дозволяє формувати структуру безпосередньо під час розмови, тоді як CrewAI вимагає від розробника заздалегідь визначити всі етапи.

AutoGen підходить, коли:

• необхідна максимальна гнучкість, і агенти можуть імпровізувати свої дії через відкритий діалог;
• завдання виграє від дослідницького взаємодії, такого як брейнштормінг чи ітеративне виправлення помилок, де правильна послідовність кроків невідома заздалегідь;
• корисним є зручний візуальний інструмент, як-от AutoGen Studio, для нетехнічних експериментів перед тим, як приступити до написання коду.

CrewAI підходить, коли:

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

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