AutoGen i CrewAI w porównaniu: tworzenie zespołów agentów, obliczanie ich kosztów

Przez długi czas w pracach z wykorzystaniem LLM obraz interakcji z sztuczną inteligencją przedstawiał się jako pojedynczy cykl: ktoś wpisuje prompt, model odpowiada, a rozmowa trwa dalej. To dobrze funkcjonuje przy odpowiadaniu na pytania. Zaczyna sprawiać problemy, gdy celem jest rzeczywiście wykonanie jakiejś pracy, takiej jak pisanie i debugowanie programu, planowanie raportu badawczego lub uruchamianie wieloetapowego procesu, który obejmuje kilka narzędzi i źródeł danych.

Istnieją systemy wieloagentowe, które adresują tę lukę. Zamiast prosić jeden monolityczny prompt o załatwienie wszystkiego, zadanie jest podzielone na role: inżynier, krytyk, badacz, pisarz. Każda z tych ról staje się agentem, który jest „opakowaniem” wokół modelu językowego z własną osobowością, pamięcią i obowiązkami. Agenci rozmawiają ze sobą, przekazują sobie częściowe wyniki, krytykują się nawzajem i iterują, aż praca zostanie ukończona. To bardziej przypomina zarządzanie małym, bardzo szybkim zespołem niż konsultowanie się z orakulem.

W tym obszarze dominują dwa frameworki, które są tu porównywane: AutoGen, który pochodzi z Microsoft Research i jest dostępny jako oprogramowanie otwarte, oraz CrewAI – młodsza platforma stworzona z myślą o procesach biznesowych w przedsiębiorstwach. Trzecim narzędziem jest AgentOps, które dodaje warstwę obserwowalności, dzięki której można zobaczyć, co robią agenci oraz ile to kosztuje.

Role zamiast jednego dużego promptu

Zmiana koncepcyjna następuje przed użyciem jakichkolwiek narzędzi. W konfiguracji z jednym agentem jeden prompt systemowy pełni jednocześnie dwie funkcje: definiuje postać agenta oraz przewiduje to, o co może zostać poproszony model. Frameworki wieloagentowe rozkładają ten obciążenie – każdy agent otrzymuje bardziej precyzyjny opis zadań, składający się z postaci, celu, a czasami także historii, która kształtuje jego podejście.

To naśladuje sposób pracy zespołów ludzkich – seniorowy inżynier nie jest jednocześnie recenzentem jakości, menedżerem projektu i autorem materiałów technicznych. Rozdzielenie tych funkcji pomiędzy agenty przynosi trzy praktyczne korzyści:

• Specjalizacja poprawia jakość. Agent, którego jedynym zadaniem jest sprawdzanie kodu pod kątem problemów bezpieczeństwa, będzie go badał bardziej konsekwentnie niż osoba zajmująca się wieloma zadaniami naraz.
• Pętle zwrotne stają się jawne. Kierowanie wynikami jednego agenta do innego, którego zadaniem jest ich ocena, tworzy celowy cykl przeglądu, zamiast polegać na tym, że ten sam model sam wykryje swoje błędy.
• Możliwe staje się pracowanie równoległe. W bardziej złożonych systemach agenci mogą jednocześnie zajmować się różnymi elementami większego celu, przy czym agent badawczy i agent pisarski realizują oddzielne podzadania.

Trudnym aspektem, który każda platforma rozwiązuje na swój sposób, jest komunikacja. Jak agenci wymieniają się informacjami? Czy prowadzą jedną rozmowę, czy też mają izolowane wymiany informacji, które tylko sporadycznie się przenikają? Odpowiedzi na te pytania różnią się między AutoGen a CrewAI, a ta różnica wpływa na wszystko inne.

AutoGen: wszystko to rozmowa

AutoGen firmy Microsoft traktuje każdą interakcję agentów jako rozmowę. Podstawową zasadą jest to, że agenci komunikują się ze sobą w języku naturalnym, tak jak ludzie w temacie czatu. Dzięki temu jest to intuicyjne: każdy, kto obserwował, jak dwóch kolegów w kanale Slack wymienia się uwagami w celu udoskonalenia pomysłu, już posiada model mentalny leżący u podstaw agentów umiejących rozmawiać w AutoGen.

Próba w AutoGen Studio

Zanim zostanie napisany jakikolwiek kod w Pythonie, AutoGen Studio oferuje graficzny sposób eksperymentowania. Instaluje się go za pomocą pip, odczytuje klucz API z zmiennej środowiskowej i uruchamia się poprzez jedno polecenie w linii poleceń. Następnie otwiera się interfejs przeglądarki. Wpisz tam zadanie, a agent proxy użytkownika będzie współpracować z jednym lub kilkoma agentami asystentami, aż zadanie zostanie wykonane.

Wzorzec, który się pojawia, warto poznać, ponieważ występuje wszędzie. Załóżmy, że celem jest przedstawienie popularności określonego słowa kluczowego w czasie. Agent asystent rozpoczyna tworzenie fragmentów kodu do poszczególnych zadań pomocniczych. Następnie agent proxy użytkownika uruchamia te fragmenty w zabezpieczonym środowisku i ocenia, czy wynik jest prawidłowy. Jeśli kod nie działa lub wynik jest błędny, proxy wysyła informacje zwrotne, asystent dokonuje korekty, a cykl tworzenia kodu, jego wykonywania, oceny i korekty trwa dalej, aż proxy będzie zadowolony.

Ta pętla automatyzuje ludzką część przeglądu kodu. Podczas zwykłej sesji programista pisze kod, uruchamia go, obserwuje jego niepowodzenie i osobiście naprawia błąd. Tutaj proxy przejmuje zadanie uruchomienia i sprawdzenia, dzięki czemu osoba może odejść, podczas gdy dwa agenty rozwiązują problem. Nie jest to rozwiązanie bezwadne, ponieważ zmienione biblioteki lub przestarzałe funkcje czasami sprawiają trudności agentom, ale w przypadku dobrze zdefiniowanych problemów jest niezwykle skuteczne. Generowanie obrazów, wizualizacja danych oraz krótkie aplikacje często są kończone w ciągu kilku iteracji.

Często pojawia się jedna rekomendacja: uruchamiaj AutoGen i AutoGen Studio w środowisku Docker, gdy tylko generowany kod może mieć wpływ na system operacyjny. Agenci są zaprojektowani do pisania i wykonywania dowolnego kodu, więc kontener chroni hosta przed skutkami ubocznymi. Ta rada nabiera znaczenia, gdy agenci otrzymują większą autonomię.

Umiejętności jako dodatkowe zdolności

Studio dostarczany jest z zaledwie kilkoma wbudowanymi narzędziami, takimi jak pobieranie treści internetowych lub generowanie obrazów. Jego prawdziwa siła leży w dostosowanych umiejętnościach. Umiejętność to zwykła funkcja w Pythonie o jasnej nazwie i dobrze napisanej dokumentacji, a framework czyta tę dokumentację, aby zdecydować, kiedy i w jaki sposób ją wywołać.

Przykład pokazuje implementację umiejętności describe_image, która wysyła obraz do modelu posiadającego zdolności widzenia i otrzymuje jego opis. Po zarejestrowaniu jej w głównym asyście umożliwia ona bardzo konkretne żądanie: stworzenie okładki książki do danego tytułu, a następnie użycie umiejętności opisu obrazu w celu sprawdzenia, czy tekst tytułu jest poprawnie zapisany. Generatory obrazów są powszechnie uznawane za słabe w tworzeniu czytelnego tekstu, więc stanowi to naturalny cykl weryfikacyjny. Asystent tworzy obraz, umiejętność widzenia sprawdza napisy, a jeśli są błędne, asystent próbuje ponownie. Tworzenie małych, dobrze udokumentowanych narzędzi zapewnia zachowanie zaskakująco odporne na błędy.

U podstaw leży określona filozofia projektowa. Zamiast polegać na agentach, które muszą pisać zupełnie nowy kod na każdą potrzebę, często bardziej skuteczne jest dostarczenie im ustalonej bazy gotowych, przetestowanych umiejętności. Kod generowany przez LLM w czasie rzeczywistym może ulec awarii, gdy biblioteki się zmieniają lub zależności ulegają zmianie, natomiast sprawdzona, spakowana umiejętność zachowuje się przewidywalnie. Kwestia, czy agenci powinni pisać kod dynamicznie, czy korzystać z gotowych narzędzi, zostanie omówiona później w kontekście planowania i działań, a jest to jedna z najważniejszych decyzji przy projektowaniu systemu agentów.

Kod surowy z pyautogen

Po Studio następnym krokiem jest pisanie kodu w Pythonie przy użyciu pakietu pyautogen. Istotne są dwa elementy budulcowe:

• ConversableAgent to agent o zastosowaniu uniwersalnym, który komunikuje się bezpośrednio z LLM.
• UserProxyAgent reprezentuje użytkownika i może wykonywać kod w katalogu roboczym.

Minimalna konfiguracja łączy te dwa elementy i rozpoczyna rozmowę, na przykład prosząc o jednowierszową rozwiązanie zadania FizzBuzz. Po uruchomieniu proxy prosi o informacje zwrotne po tym, jak asystent coś zaproponuje. Naciśnięcie klawisza Enter bez żadnych informacji zwrotnych oznacza, że należy kontynuować i uruchomić sam kod. Jeśli brakuje niezbędnego pakietu, takiego jak Pygame, proxy instaluje go przed uruchomieniem programu. To samodzielne dostarczanie zasobów jest małym, ale wymownym znakiem swobody, jaką mogą mieć te systemy, z zarówno zaletami, jak i wadami.

Praktyczne zadania programistyczne służące do oceny modeli obejmują sprawdzanie, czy liczba jest pierwsza, tworzenie gry Snake oraz klonu Asteroids w Pygame. Są one samodzielne, poddawalne testom i wystarczająco zróżnicowane pod względem trudności, aby ujawnić różnice pomiędzy modelami lub konfiguracjami.

Dodawanie krytyka poprzez zagnieżdżone rozmowy

Pomocnik w połączeniu z proxyem jest przydatny, ale systemy wieloagentowe odnoszą sukces dzięki specjalistycznym osobowościom. Drugi pomocnik może pełnić rolę recenzenta kodu, przy czym wiadomość systemowa zapewnia dokładność, ścisłe przestrzeganie standardów oraz skupienie na problemach związanych z bezpieczeństwem i jakością.

Zamiast od razu włączać recenzenta do głównej rozmowy, AutoGen oferuje zagnieżdżone rozmowy. Proxy użytkownika rejestruje taką zagnieżdżoną rozmowę, która uruchamia się za każdym razem, gdy agent inżynierski tworzy nowy wynik. Kod trafia automatycznie do recenzenta, w ramach osobnej, bocznej rozmowy; recenzent odpowiada recenzją, a ta jest następnie przekazywana z powrotem do głównej rozmowy. Krok recenzji jest wstawiany bez konieczności, by recenzent zakłócał każdą kolejną rozmowę, i występuje on tylko wtedy, gdy jest coś nowego do sprawdzenia.

W przypadku zadania takiego jak stworzenie gry Snake za pomocą Pygame różnica w porównaniu z zwykłym uruchomieniem przez inżyniera i proxy jest wyraźna. Po wykonyaniu kodu pojawia się osoba oceniająca z listą zalecanych ulepszeń, co faktycznie odtwarza proces przeglądania pull requestów, który zespoły ludzkie przeprowadzają codziennie.

Kasowanie danych w celu kontrolowania kosztów

Rozmowy między wieloma agentami szybko stają się kosztowne. Każda wymiana zużywa tokeny, a skomplikowane zadania mogą wymagać dziesiątek rund. AutoGen zawiera system kasowania danych: domyślnie stan rozmowy jest zapisywany na dysku w folderze .cache, dzięki czemu długie lub przerwane zadanie można wznowić bez konieczności ponownego płacenia za te same tokeny.

Behawior ten można wyraźnie ustalić, otaczając wywołanie czatu menedżerem kontekstu, który dostarcza cache_seed. Znaczenie tego aspektu łatwo jest niedocenić. W rozwoju agentów często chce się odtworzyć lub przeanalizować wcześniejsze uruchomienie zamiast je ponownie generować, czy to w celach debugowania, czy po to, by pokazać zaangażowanym stronom dokładnie, w jaki sposób agent doszedł do określonego wyniku.

Czat grupowy a problem telefonu

Czaty wewnętrzne mają strukturalną słabość przypominającą dziecięcą grę w telefon. Informacje są przekazywane z jednego agenta na następny w łańcuchu, a przy każdym przekazie szczegóły mogą zostać utracone, zniekształcone lub błędnie zinterpretowane. Jeśli osoba oceniająca nigdy nie widzi pełnego oryginalnego zadania, a jedynie to, co inżynier postanowił przekazać, jej opinia może nie trafiać w sedno sprawy.

Rozwiązaniem oferowanym przez AutoGen jest czat grupowy. Obiekt GroupChat utrzymuje wspólny zasób agentów i wiadomości, podobny do kanału zespołowego, zamiast serii połączeń punkt-do-punktu. GroupChatManager koordynuje kolejność odpowiedzi, aby agenci nie odpowiadali wszyscy jednocześnie. Kluczową cechą jest to, że każdy członek może zobaczyć całą historię rozmowy, a nie tylko to, co zostało mu wyraźnie przekazane.

Odbudowa przykładu inżyniera i krytyka przy użyciu czatu grupowego zapewnia bardziej spójną współpracę. Opinie krytyka opierają się na tym samym pełnym kontekście, jaki miał inżynier, a inżynier może bezpośrednio odpowiedzieć na konkretne uwagi, zamiast pracować na podstawie parafrazy. Ceną, co nie dziwi, jest rozwlekłość. Rozmowy grupowe zużywają więcej tokenów, ponieważ każdy agent faktycznie słucha każdej wymiany informacji, co ma znaczenie przy płatnościach za token w dużych skali.

Czego uczą wczesne przykłady

Łącznie sesje w studiu oraz eksperymenty z surowym kodem wskazują na kilka kwestii, które mają zastosowanie we wszystkich projektach opartych na agentach. Zadanie powinno być na tyle małe, aby można było sprawdzić jego pomyślność, ponieważ pętla proxy działa tylko wtedy, gdy istnieje sposób na stwierdzenie, czy wynik jest prawidłowy. Wykonanie powinno być izolowane, gdyż ta sama autonomia, która sprawia, że pętla jest przydatna, pozwala jej również instalować pakiety i uruchamiać dowolne programy. Recenzje są tanie w dodawaniu, gdy już istnieją role, więc krytyk prawie zawsze warto wypróbować. Koszty powinny być uwzględniane od samego początku projektowania: cacheowanie, ponowne uruchamianie oraz określenie liczby kroków potrzebnych do wykonania zadania to elementy budowy systemu, a nie dodatkowe rozważania.

Istnieje również lekcja na temat tego, gdzie należy wkładać wysiłek. Napisanie dobrego komunikatu systemowego dla krytyka lub jasnego dokumentu opisowego dla danej umiejętności zmienia zachowanie znacznie bardziej niż dodanie kolejnych agentów. Obie platformy nagradzają precyzyjne, szczegółowe opisy tego, do czego służy każdy agent.

CrewAI: struktura zamiast improwizacji

Podczas gdy AutoGen opiera się na rozmowach otwartych, CrewAI ma bardziej zorganizowaną strukturę i jest bardziej zorientowany na konkretne cele, przeznaczony wyraźnie do środowisk biznesowych i produkcyjnych. Zamiast swobodnego dialogu, wymaga trzech wyraźnych definicji: agentów z określonymi rolami, celami i historiami; zadań, które im są przydzielone; oraz zespołu, który łączy ich pod określoną strategią przetwarzania.

Z czego składa się agent

Agent w CrewAI jest konfigurowany za pomocą kilku parametrów:

• role: krótka etykieta opisująca funkcję agenta, na przykład Senior Joke Researcher.
• goal: stwierdzenie w języku naturalnym określające, czego agent próbuje osiągnąć, często w formacie umożliwiającym ponowne użycie z różnymi danymi wejściowymi.
• backstory: narracja budująca postać agenta, dostarczająca kontekstu i cech osobowości, podobnie jak persona w promptach systemowych.
• memory i verbose: flagi kontrolujące, czy agent przechowuje kontekst między interakcjami oraz czy wyświetla swój tok rozumowania w konsoli.
• allow_delegation: czy agent może przekazać zadania innym członkom zespołu.

Zadania są definiowane oddzielnie. Każde z nich zawiera opis pracy, pole expected_output opisujące, jak powinien wyglądać sukces z punktu widzenia agenta i czytelnika, odniesienie do odpowiedzialnego agenta oraz opcje takie jak wykonywanie zadań asynchronicznie lub zapisywanie wyników do pliku.

Obiekt Crew łączy w końcu agenty i zadania wraz z ustawieniami dotyczącymi sposobu współpracy – sekwencyjnej lub hierarchicznej – oraz opcjami dotyczącymi dzielenia się pamięcią, buforowania oraz ograniczenia liczby żądań na minutę, które kontroluje użycie API.

Zabawny przykład: zespół żartownisiów

Aby to uogólnić, tworzy się zespół składający się z dwóch agentów zajmujących się żartami. Starszy badacz żartów analizuje, co sprawia, że dany temat jest zabawny, oraz odnotowuje istotne trendy społeczne, natomiast autor żartów przekształca te informacje w rzeczywisty żart. Badacz może delegować zadania, podczas gdy autor nie może tego robić. Jest to rozsądny podział, ponieważ autor ma pełnić rolę ostatniego etapu w procesie, a nie centrum, które rozdziela zadania dalej.

W przypadku tematu takiego jak żarty o inżynierach sztucznej inteligencji zespół tworzy naprawdę zabawne treści poprzez proces badania, a następnie pisania, zamiast polegać na jednym, monolitycznym poleceniu. Choć to zabawne, pokazuje to, dlaczego oddzielenie zrozumienia danej dziedziny od tworzenia kreatywnego rezultatu może przynieść bardziej przemyślane wyniki. Prace przygotowawcze badacza stanowią kontekst pomocny dla autora, niczym miniaturowy krok wyszukiwania wbudowany w proces pracy.

AgentOps: obserwowanie wydatków

Rozwijający agenty ciągle wracają do jednego istotnego problemu: ile kosztuje ten proces i dokąd znika czas? Systemy wieloagentowe, jeśli nie są monitorowane, mogą generować zaskakująco wysokie rachunki, ponieważ każda wymiana informacji między agentami, delegacja zadań oraz wywołanie narzędzi wpływają na ogólny koszt. AgentOps to platforma do obserwacji zachowań agentów opartych na modelach językowych, inna od tradycyjnych narzędzi MLOps, które nie zostały zaprojektowane dla autonomicznych, konwersacyjnych agentów.

Dodanie jej do projektu CrewAI nie wymaga dużego wysiłku: wystarczy zainstalować pakiet, uzyskać klucz API, umieścić go w konfiguracji środowiska i zainicjować bibliotekę na początku skryptu. Każdy proces realizowany przez zespół jest następnie rejestrowany na panelu kontrolnym, który pokazuje:

• całkowity czas trwania procesu oraz środowisko, w którym odbył się,
• liczbę tokenów promptu i odpowiedzi dla każdego wywołania modelu językowego,
• czas trwania każdego pojedynczego wywołania,
• oszacowany koszt w dolarach za cały proces.

Pierwsze zapoznanie z ostatnim elementem jest szokujące. Jedna sesja pracy zespołu żartownisiów, która wydaje się błahej dla człowieka, kosztuje niemałą część dolara, gdy dodamy wszystkie pośrednie procesy rozumowania, delegowanie zadań oraz wywołania narzędzi. Dla każdego, kto buduje systemy agentów o charakterze komercyjnym, jest to ważna lekcja rzeczywistości: koordynacja agentów jest potężna, ale nie jest bezkosztowa, a możliwość obserwacji przekształca abstrakcyjny koszt w konkretną kwotę, którą można uwzględnić w budżecie i optymalizować.

Zespół deweloperów gier

Aby dokonać bezpośredniego porównania z przykładami kodowania AutoGen, do stworzenia małego zespołu deweloperów gier składającego się z trzech agentów użyto CrewAI:

1. Główny inżynier oprogramowania pisze implementację w Pythonie dla żądanej gry.
2. Inżynier kontroli jakości oprogramowania sprawdza kod pod kątem wad – od brakujących importów i niespójnych nawiasów po luki bezpieczeństwa oraz błędną logikę.
3. Główny inżynier QA może delegować zadania i ponosi ostateczną odpowiedzialność za upewnienie się, że gotowy kod spełnia pierwotne wymagania.

Zadania są zorganizowane według tej samej struktury: jeden tworzy wstępną implementację, drugi sprawdza ją pod kątem błędów, a trzeci łączy obie wersje w ostateczną, poprawioną wersję. Ten trójetapowy proces przeglądania – tworzenie, krytyka i finalizacja – stanowi bardziej rozwiniętą wersję modelu inżyniera i krytyka z AutoGen, zrealizowanego poprzez deklaratywne rozdzielenie zadań od agentów w CrewAI.

Gdy skrypt jest uruchamiany interaktywnie, pytając o rodzaj gry i jej zachowanie, kod zazwyczaj wygląda znacznie lepiej niż w przypadku pojedynczego, nie nadzorowanego agenta programistycznego. Częściowym powodem jest to, że nadzór głównego inżyniera ds. jakości pozwala wykryć problemy, które w przeciwnym razie mogłyby umknąć uwadze.

Przetwarzanie sekwencyjne versus hierarchiczne

CrewAI oferuje dwa sposoby organizacji pracy zespołu nad zadaniami, a właściwy wybór ma znaczenie.

Przetwarzanie sekwencyjne jest standardowe i najprostsze. Zadania są wykonywane jedno po drugim w określonej kolejności, a każdy agent kończy pracę, zanim przekaże ją dalej. Nadaje się do procesów, w których poszczególne kroki rzeczywiście zależą od siebie w ustalonej kolejności: najpierw badania, potem pisanie, albo najpierw implementacja, potem przegląd, a na końcu finalizacja.

Przetwarzanie hierarchiczne umieszcza menedżera nad zespołem, zazwyczaj wykorzystując własne połączenie z LLM wyłącznie do koordynacji, który nadzoruje agenty i zadania zamiast zmuszać je do działania w sposób synchroniczny. Przełączenie jest proste: należy określić Process.hierarchical zamiast Process.sequential oraz podać manager_llm, zwykle instancję ChatOpenAI z temperaturą zero, aby zapewnić bardziej stabilne decyzje nadzorcze.

Na papierze tryb hierarchiczny powinien przeważyć, ponieważ rola menedżera odzwierciedla sposób funkcjonowania większych organizacji ludzkich. Eksperymenty pokazują coś innego. Według AgentOps ta sama zadanie w grze, realizowana pod kierownictwem menedżera hierarchicznego, kosztowała ponad dwa razy więcej, a kod nie był w związku z tym znacząco lepszy. To demotywujący fakt. Dodawanie koordynacji, nadzoru oraz warstw agentów nie poprawia automatycznie wyników, a systemy wieloagentowe równie łatwo mogą popaść w kosztowne, nieproduktywne błędy, gdy nikt nie obserwuje ich uważnie.

Zatrzymywanie niekontrolowanych agentów

To odkrycie wiąże się z subtelnym modelem awarii: powtarzalnymi wzorcami myślenia. Agent, który nie ma pewności co do swojego wyniku, może w kółko rozważać różne warianty tej samej idei zamiast podjąć decyzję i iść dalej, marnując zasoby bez rzeczywistego postępu.

AgentOps posiada wizualizację Repeat Thoughts właśnie do tego celu – pokazuje ona, jak często rozumowanie agenta wraca do podobnych treści podczas wykonywania zadania. Częste powtarzanie jest sygnałem, że coś strukturalnego wymaga zmiany. Być może opisy zadań są zbyt niejasne, być może do rozwiązania tego problemu zaangażowano zbyt wielu agentów, albo może tryb przetwarzania wymaga ponownej oceny. Takie narzędzia diagnostyczne odróżniają przypadkowe eksperymenty od zorganizowanej, profesjonalnej pracy. Lepiej zauważyć, gdy coś idzie nie tak, niż czekać na podejrzanie wysoką fakturę.

Stylы komunikacji obok siebie

Pytanie postawione na początku, jak agenci przekazują sobie informacje, ma teraz konkretne odpowiedzi. AutoGen oferuje dwa modele. Wbudowane rozmowy przekazują materiał poprzez dodatkowe konwersacje, co utrzymuje porządek w głównej ścieżce rozmowy, ale niesie ryzyko utraty szczegółów przy każdym przekazie. Rozmowa grupowa umożliwia wszystkim dostęp do pełnej historii, co poprawia spójność, ale kosztem liczb tokenów. CrewAI omija tę dylematę, czyniąc proces przekazywania informacji jawny: każde zadanie określa swojego agenta oraz oczekiwany wynik, a ustawienia procesu decydują o tym, czy wyniki trafiają dalej w łańcuchu, czy przez menedżera. Jeden podejście faworyzuje spontaniczną współpracę, a drugie – proces, który można przewidzieć z góry.

Żaden z tych rozwiązań nie eliminuje konieczności śledzenia rachunku. Obie opcje generują więcej wywołań modelu niż jeden prompt, a obie mogą wpadać w błędy pętli. Dlatego narzędzia do obserwowalności są równie ważne jak wybór frameworku.

Wybór między nimi

Żaden z tych frameworków nie jest bezkonkurencyjny. Każdy odzwierciedla inne podejście do tego, jak dużo wsparcia powinien mieć system wielu agentów. AutoGen pozwala, by struktura powstawała w trakcie samej rozmowy, natomiast CrewAI wymaga od twórcy, aby wszystko zaplanował z góry.

AutoGen nadaje się, gdy:

• potrzebna jest maksymalna elastyczność, a agenci mogą improwizować swoje podejście poprzez otwartą konsultację;
• zadanie korzysta z eksploracyjnej wymiany opinii, takiej jak burza mózgów lub iteracyjne naprawianie błędów, gdzie właściwa kolejność kroków nie jest znana z góry;
• przyjazny wizualny interfejs, jak AutoGen Studio, jest przydatny do eksperymentów niezwiązanych z programowaniem przed przystąpieniem do pisania kodu.

CrewAI nadaje się, gdy:

• potrzebne są przewidywalne, sprawdzalne procesy z jasno określonymi rolami i obowiązkami, jak w procesach biznesowych, gdzie spójność ma większe znaczenie niż improwizacja;
• Wolą się wbudowana pamięć, cache oraz ograniczenia szybkości działania zamiast własnoręcznie opracowanych wersji;
• Bardzo ważna jest możliwość obserwacji procesów, biorąc pod uwagę niemal bezproblemową integrację z AgentOps.

W praktyce wiele rzeczywistych projektów łączy obie te metody: klarowność deklaratywna CrewAI w przypadku dobrze zrozumianych części procesu oraz elastyczność konwersacyjna AutoGen w sytuacjach bardziej złożonych i eksploracyjnych.