AutoGen, rozmowa agentów i co dalej

AutoGen, czyli agenci rozmawiający ze sobą

AutoGen zaczął od pomysłu, który wtedy brzmiał ekscentrycznie, a dziś jest oczywisty: zamiast jednego modelu wykonującego zadanie od początku do końca, kilku agentów o różnych rolach rozmawia ze sobą, aż dojdą do rozwiązania.

Jeden pisze kod, drugi go sprawdza, trzeci uruchamia testy i zgłasza błędy. Rozmowa toczy się bez udziału człowieka, a wynikiem jest gotowa praca, nie pojedyncza odpowiedź. Ta koncepcja rozeszła się po całym ekosystemie i dziś odnajdziesz ją w większości bibliotek agentowych.

Zanim przejdziemy dalej, konieczne jest zastrzeżenie, bo bez niego cały tekst wprowadzałby w błąd.

Trzy projekty zamiast jednego

Microsoft przeniósł AutoGen w tryb utrzymania w październiku 2025 roku. Repozytorium nosi oficjalną informację, że projekt nie dostaje nowych funkcji i jest prowadzony przez społeczność, a poprawki ograniczają się do błędów i krytycznych łatek bezpieczeństwa.

W miejsce jednego projektu są dziś trzy drogi.

Pierwsza to AutoGen w wersji dotychczasowej. Działa, instaluje się, a istniejące wdrożenia będą działać dalej, natomiast nie rozwija się.

Druga to Microsoft Agent Framework, który producent nazywa wprost bezpośrednim następcą. Powstał z połączenia dwóch linii: orkiestracji wieloagentowej z AutoGena i zaplecza korporacyjnego z Semantic Kernel. Wersja stabilna ukazała się w kwietniu 2026 roku, w wariantach dla Pythona i dla platformy .NET.

Trzecia to AG2, odgałęzienie prowadzone przez społeczność na licencji swobodnej, założone przez część pierwotnych autorów po odejściu z Microsoftu. Rozwija się niezależnie i utrzymuje pierwotną filozofię projektu.

Wniosek praktyczny: nowego projektu nie zaczynaj na AutoGenie. Wybierasz między następcą od producenta a odgałęzieniem społecznościowym, i to jest realna decyzja, nie formalność.

Na czym polegał pomysł

Warto zrozumieć oryginalną koncepcję, bo przeszła do obu następców i do konkurencji.

from autogen import AssistantAgent, UserProxyAgent

programista = AssistantAgent(
    name="programista",
    system_message="Piszesz kod w Pythonie. Poprawiasz go po uwagach recenzenta.",
    llm_config={"model": "gpt-4o"},
)

recenzent = UserProxyAgent(
    name="recenzent",
    human_input_mode="NEVER",
    code_execution_config={"work_dir": "robocze"},
)

recenzent.initiate_chat(
    programista,
    message="Napisz funkcje liczaca mediane z listy i przetestuj ja.",
)

Wykonuje się tu więcej, niż widać. Pierwszy agent pisze kod, drugi go wyodrębnia z odpowiedzi i uruchamia, a wynik uruchomienia wraca jako kolejna wiadomość w rozmowie. Jeśli test padnie, komunikat błędu trafia do autora, który poprawia kod. Pętla kręci się do skutku albo do limitu tur.

Dwie rzeczy były tu nowatorskie. Pierwsza to potraktowanie wykonania kodu jako uczestnika rozmowy, a nie jako narzędzia wywoływanego przez model. Druga to brak sztywnego przepływu: kolejność wypowiedzi wynikała z rozmowy, a nie z zaprogramowanego grafu.

Ta druga własność była zarazem największą siłą i największym problemem, o czym za chwilę.

Rozmowa grupowa

Przy większej liczbie agentów potrzebny był mechanizm decydujący, kto mówi następny.

from autogen import GroupChat, GroupChatManager

grupa = GroupChat(
    agents=[analityk, programista, tester],
    messages=[],
    max_round=20,
)

kierownik = GroupChatManager(groupchat=grupa, llm_config={"model": "gpt-4o"})
analityk.initiate_chat(kierownik, message="Zbuduj raport sprzedazy za czerwiec.")

Wybór następnego mówcy należał do modelu, który czytał historię rozmowy i wskazywał, kto powinien się teraz odezwać. Elastyczne i imponujące na pokazie, kłopotliwe w produkcji.

Problem polegał na tym, że ten sam wsad dawał różne przebiegi. Raz analityk oddawał głos programiście, raz testerowi, a czasem dwaj agenci wpadali w wymianę uprzejmości, wypalając limit tur bez efektu. Debugowanie takiej pętli jest trudne, bo nie ma jednego miejsca, w którym zapadła zła decyzja.

Stąd wziął się kierunek, w którym poszła cała branża: przepływy jawnie opisane w kodzie, jak w LangGraph, albo role o sztywno przypisanych zadaniach, jak w CrewAI. Swoboda rozmowy ustąpiła przewidywalności, bo produkcja wymaga powtarzalności.

Wzorce współpracy, które warto znać

Niezależnie od wybranej biblioteki, układy współpracy agentów powtarzają się w kółko i warto rozpoznawać je po nazwie, bo to skraca projektowanie z godzin do minut.

Układ z krytykiem to dwa agenty: jeden tworzy, drugi ocenia i odsyła z uwagami. Sprawdza się wszędzie tam, gdzie da się sprawdzić wynik łatwiej, niż go wytworzyć, czyli przy kodzie, tekstach z wymogami formalnymi i wyliczeniach. Zysk jakościowy bywa duży, koszt to podwojenie liczby wywołań.

Układ z kierownikiem rozdziela zadanie na części i przekazuje je wykonawcom. Działa dobrze, gdy części są niezależne, bo wtedy wykonują się równolegle. Przy częściach zależnych od siebie kierownik staje się wąskim gardłem i lepiej wypada zwykły przepływ zapisany w kodzie.

Układ z ekspertami kieruje zapytanie do agenta wyspecjalizowanego w danej dziedzinie. Popularny w obsłudze zgłoszeń, gdzie inny zestaw instrukcji obsługuje reklamacje, a inny pytania techniczne. Warto natomiast pamiętać, że rozdzielanie zapytań to zwykła klasyfikacja, więc tańszy model wystarczy do tego kroku.

Układ z debatą uruchamia kilku agentów na tym samym zadaniu i wybiera odpowiedź większością. Kosztowny, bo mnoży wywołania, i wart rozważenia tylko tam, gdzie błąd kosztuje więcej niż trzykrotne wykonanie.

Trzy z tych czterech układów da się zbudować bez frameworka, w kilkudziesięciu liniach zwykłego kodu. Biblioteka zarabia na siebie dopiero przy ich łączeniu i przy potrzebie śledzenia, co się dzieje w środku.

Koszt i obserwowalność

Dwie rzeczy, które przy rozmowie agentów wyglądają inaczej niż przy pojedynczym wywołaniu, a decydują o tym, czy rozwiązanie nadaje się na produkcję.

Koszt rośnie szybciej, niż podpowiada intuicja, bo każda tura niesie ze sobą całą dotychczasową historię rozmowy. Dziesiąta wypowiedź w wątku kosztuje wielokrotnie więcej niż pierwsza, mimo że wygląda tak samo. Przy dwudziestu turach rachunek za jedno zadanie potrafi przekroczyć dolara, co przy tysiącu zadań dziennie zmienia rozmowę z zespołem finansowym.

Trzy sposoby ograniczenia tego wydatku są proste i skuteczne. Pierwszy to twardy limit tur, ustawiony niżej, niż podpowiada ostrożność, bo rozmowy dłuższe niż kilkanaście wypowiedzi rzadko poprawiają wynik. Drugi to skracanie historii, czyli przekazywanie dalej podsumowania zamiast pełnego zapisu. Trzeci to dobór modelu do roli: krytyk sprawdzający formalne wymagania nie potrzebuje najmocniejszego modelu, a wykonawca zwykle tak.

Obserwowalność jest tu ważniejsza niż przy zwykłym wywołaniu, bo błąd nie objawia się wyjątkiem, tylko złą odpowiedzią po piętnastu turach. Zapisuj każdą wypowiedź razem z użyciem tokenów, identyfikatorem przebiegu i czasem. Bez tego jedyną dostępną metodą diagnozy jest powtarzanie przebiegu i patrzenie w konsolę, a przy niedeterministycznym przepływie to metoda zawodna.

Który następca wybrać

Pierwsze pytanie dotyczy platformy. Jeśli firma stoi na .NET i usługach chmurowych Microsoftu, wybór następcy od producenta jest naturalny, bo to jedyny wariant z pełnym wsparciem obu języków i integracją z resztą oferty. W tym samym ekosystemie stoi też Foundry Agent Service, które nie jest biblioteką, tylko usługą uruchamiającą agenta po stronie dostawcy: dostajesz osobną tożsamość dla każdego agenta, izolację sesji i wersjonowanie definicji, a płacisz za to związaniem z jedną chmurą i koniecznością sprawdzania, które narzędzia wyszły już z zapowiedzi publicznej.

Drugie dotyczy skali migracji. Odgałęzienie społecznościowe jest bliższe kodowi, który już masz, więc przejście bywa kwestią zmiany nazwy pakietu i drobnych poprawek. Następca od producenta to inna architektura i realne przepisywanie.

Trzecie, najczęściej pomijane, dotyczy tego, czy w ogóle potrzebujesz frameworka wieloagentowego. Sporo zadań opisanych jako współpraca agentów to w rzeczywistości trzy wywołania modelu po kolei, a taki kod jest krótszy, tańszy i łatwiejszy w utrzymaniu niż jakakolwiek biblioteka.

Migracja bez przepisywania wszystkiego

Niezależnie od kierunku, kolejność prac jest podobna i warto ją zaplanować przed pierwszą zmianą.

Zacznij od spisania, co Twoi agenci naprawdę robią. Zwykle okazuje się, że rozmowa ma stałą kolejność, a swoboda wyboru mówcy nigdy nie została wykorzystana. Wtedy migracja polega na zapisaniu tej kolejności wprost, co przy okazji usuwa źródło niepowtarzalności.

Drugim krokiem jest wydzielenie narzędzi. Funkcje wywoływane przez agentów, czyli zapytania do bazy, wywołania API i operacje na plikach, powinny być zwykłym kodem niezależnym od frameworka. To ta część ma największą wartość i przenosi się bez zmian między bibliotekami.

Trzecim jest odtworzenie przepływu w nowym narzędziu i porównanie wyników na tym samym zestawie przypadków. Bez zestawu testowego migracja jest zgadywanką, bo agenci nie zwracają wartości, które da się porównać znakiem równości.

Czwartym, opcjonalnym, jest uruchomienie obu wersji równolegle na części ruchu. Przy procesach ważnych biznesowo to jedyny sposób, żeby zobaczyć różnicę przed przełączeniem.

Wykonywanie kodu i bezpieczeństwo

Jedna rzecz z pierwotnego projektu zasługuje na osobne omówienie, bo powraca w każdym następcy i bywa lekceważona.

Agent uruchamiający kod napisany przez model to potężny mechanizm i jednocześnie otwarta furtka. Kod powstaje z tekstu, na który wpływ ma treść zapytania, a przy odczycie danych z zewnątrz również ta treść. Uruchamianie go w tym samym procesie co aplikacja jest ryzykiem, którego nie warto podejmować.

Właściwym rozwiązaniem jest kontener bez dostępu do sieci, z zamontowanym wyłącznie katalogiem roboczym i limitem czasu wykonania. Konfiguracja zajmuje kwadrans i zamienia poważny problem w drobny.

Warto też ograniczyć to, co agent w ogóle może zrobić. Lista dozwolonych bibliotek działa lepiej niż lista zakazanych operacji, bo tej pierwszej nie da się obejść pomysłowością, której nie przewidziałeś.

Osobno warto przemyśleć, co agent widzi. Jeśli w kontekście rozmowy znajdą się klucze API albo dane osobowe, trafią do wygenerowanego kodu i do zapisu przebiegu, a przy dłuższej historii również do każdego kolejnego wywołania modelu. Przekazywanie identyfikatorów zamiast wartości, z podstawieniem właściwych danych dopiero w narzędziu wykonywanym po Twojej stronie, rozwiązuje to raz na zawsze i nic nie kosztuje.

Typowe błędy

Pierwszy to rozpoczynanie nowego projektu na AutoGenie. Tryb utrzymania oznacza brak nowych funkcji, więc wybieraj spośród następców.

Drugi to mylenie odgałęzienia społecznościowego z projektem producenta. Nazwy są podobne, licencje i kierunki rozwoju różne, a mieszanie dokumentacji obu prowadzi do kodu, który się nie uruchamia.

Trzeci to poleganie na modelu przy wyborze kolejności mówców w procesie produkcyjnym. Jeśli kolejność jest znana, zapisz ją wprost, bo zyskujesz powtarzalność za darmo.

Czwarty to brak limitu tur i limitu kosztu. Rozmowa agentów potrafi kręcić się w kółko, a każda tura to wywołanie modelu, więc górny próg wydatku powinien być ustawiony od pierwszego uruchomienia.

Piąty to uruchamianie kodu agenta bez izolacji. Kontener bez sieci z limitem czasu to minimum, nie środek ostrożności dla wyjątkowo ostrożnych.

Szósty to sięganie po framework wieloagentowy do zadania, które jest sekwencją trzech wywołań modelu. Prostsze rozwiązanie jest tu zwykle lepsze i tańsze w utrzymaniu.

FAQ

Czy AutoGen jest wycofany?

Nie w sensie usunięcia, ale w trybie utrzymania od października 2025 roku. Kod działa i dostaje poprawki błędów oraz krytyczne łatki bezpieczeństwa, natomiast nowe funkcje nie powstają, a projektem zarządza społeczność.

Czym różni się AG2 od Microsoft Agent Framework?

AG2 to odgałęzienie prowadzone przez społeczność, założone przez część pierwotnych autorów, bliskie oryginalnemu kodowi i wydawane na licencji swobodnej. Microsoft Agent Framework to następca od producenta, powstały z połączenia AutoGena z Semantic Kernel, z wersjami dla Pythona i .NET oraz wsparciem komercyjnym.

Czy muszę migrować już teraz?

Nie natychmiast. Działające wdrożenie na przypiętych wersjach będzie działać dalej. Warto natomiast zaplanować przejście, bo brak nowych funkcji z czasem oznacza rozjazd z resztą ekosystemu, zwłaszcza przy nowych modelach i protokołach.

Czy warto w ogóle używać frameworka wieloagentowego?

Zależy od zadania. Przy procesie o stałej kolejności kroków zwykły kod wywołujący model kilka razy jest prostszy i tańszy. Framework zarabia na siebie dopiero wtedy, gdy potrzebujesz zarządzania stanem, ponawiania, obserwowalności i równoległych gałęzi.

Jak porównać dwie biblioteki przed wyborem?

Zbuduj w obu ten sam, realny przypadek ze swojego projektu i zmierz trzy rzeczy: liczbę linii kodu, koszt jednego przebiegu i to, jak łatwo ustalić przyczynę po nieudanym uruchomieniu. Trzecia miara jest najważniejsza, a najrzadziej sprawdzana przed decyzją.

Stan projektu opisuje repozytorium AutoGena, a drogę migracji dokumentacja Microsoftu.