--- title: "Microsoft AutoGen: jak ocenić system wielu agentów" url: "https://majchrzycki.com/blog/co-to-jest-microsoft-autogen-multi-agent-system-mas" description: "Kiedy wielu agentów ma sens, jak testować ich role i koszty oraz co oznacza tryb utrzymania AutoGen dla nowych i istniejących projektów." --- # Microsoft AutoGen: jak ocenić system wielu agentów 4 maja 2024· Aktualizacja: 29 września 2026·6 min czytania·Krzysztof Majchrzycki Temat: [Architektura systemów AI](https://majchrzycki.com/blog/filar/architektura-systemow-ai) Microsoft AutoGen był ważnym frameworkiem do eksperymentów z agentami i rozmowami wielu agentów, ale nie jest dziś domyślnym wyborem dla nowego systemu produkcyjnego. Oficjalne repozytorium informuje, że projekt działa w trybie utrzymania, a nowym użytkownikom Microsoft zaleca Microsoft Agent Framework. AutoGen nadal ma wartość w istniejących rozwiązaniach, badaniach i prototypach. Decyzję trzeba jednak zacząć od pytania, czy zadanie rzeczywiście wymaga wielu agentów. Jeżeli proces da się opisać jako zwykłą funkcję albo jawny przepływ, dodatkowi agenci zwiększą koszt, opóźnienie i liczbę miejsc awarii bez proporcjonalnej korzyści. ## Najważniejsza zmiana: AutoGen jest w trybie utrzymania [Oficjalne repozytorium AutoGen](https://github.com/microsoft/autogen) określa obecny status jednoznacznie: framework nie otrzymuje nowych funkcji, jest utrzymywany przez społeczność, a nowe projekty powinny zaczynać od Microsoft Agent Framework. Istniejący użytkownicy mogą nadal korzystać z AutoGen i przejść według oficjalnego przewodnika migracji. To istotna korekta względem wcześniejszych opisów produktu jako rozwijanej platformy Microsoft do wdrożeń wieloagentowych. AutoGen nie stał się przez to bezużyteczny. Jego warstwowa architektura nadal obejmuje AgentChat do szybkiego budowania agentów i zespołów, Core do komunikacji zdarzeniowej oraz Extensions do integracji z modelami i narzędziami. AutoGen Studio pomaga prototypować przepływy przez interfejs graficzny, lecz dokumentacja ostrzega, że nie jest gotową aplikacją produkcyjną. Uwierzytelnianie, zabezpieczenia i pozostałe elementy potrzebne we wdrożeniu trzeba zbudować osobno. Sytuacja Rozsądny wybór Dlaczego utrzymujesz działający system AutoGen pozostanie i plan migracji ograniczasz ryzyko nagłego przepisywania tworzysz eksperyment badawczy AutoGen może wystarczyć pozwala szybko sprawdzić wzorzec rozmowy agentów zaczynasz nowy system produkcyjny Microsoft Agent Framework to wskazany następca z aktywnym rozwojem proces ma stałe, znane kroki zwykły workflow lub kod łatwiej testować koszt i poprawność jedno zadanie wymaga jednego modelu i narzędzi pojedynczy agent mniej przekazań kontekstu i punktów awarii Nie wybieraj frameworka na podstawie liczby demonstracji. Oceń cykl wsparcia, stabilność API, sposób przechowywania stanu, obserwowalność, testy oraz możliwość zatrzymania przepływu. Status projektu jest elementem architektury, ponieważ wpływa na poprawki bezpieczeństwa, kompatybilność i koszt utrzymania przez kilka lat. ## Kiedy wielu agentów ma sens Wielu agentów uzasadnia zadanie, w którym role mają różne narzędzia, zasady albo kryteria oceny, a ich rozdzielenie poprawia kontrolę. Przykładem może być przygotowanie raportu: jeden agent wyszukuje informacje w zatwierdzonych źródłach, drugi oblicza wskaźniki, a trzeci sprawdza zgodność wyniku z wymaganym formatem. Każdy ma wąski kontrakt i można osobno zmierzyć jego pracę. Sama różnorodność promptów nie wystarcza. Dwa agenty korzystające z tego samego modelu, tych samych danych i tych samych narzędzi mogą powielać te same błędy. Krytyk nie staje się niezależnym kontrolerem tylko dlatego, że ma nazwę „recenzent”. Wartość pojawia się wtedy, gdy role różnią się dostępem, dowodem albo regułą akceptacji. Zanim dodasz drugiego agenta, sprawdź trzy prostsze możliwości. Po pierwsze, czy jeden agent z dobrze opisanym narzędziem wykona zadanie. Po drugie, czy etap można zapisać jako deterministyczną funkcję. Po trzecie, czy człowiek powinien podjąć decyzję zamiast kolejnego modelu. System wieloagentowy jest uzasadniony dopiero, gdy żadna z tych opcji nie daje potrzebnej separacji albo elastyczności. ## Wybierz jawny wzorzec współpracy AutoGen AgentChat obsługuje agentów i zespoły, a Core udostępnia niższy poziom komunikacji i środowisko wykonawcze. Nie oznacza to, że swobodna rozmowa grupowa jest dobrym projektem. Każda topologia powinna odpowiadać strukturze pracy. Wzorzec Kiedy pomaga Główne ryzyko Warunek zatrzymania sekwencja etapy mają stałą kolejność błąd przechodzi dalej walidacja po każdym etapie przekazanie specjalista przejmuje wybrany przypadek błędny wybór odbiorcy lista dozwolonych przekazań praca równoległa niezależne analizy można połączyć sprzeczne wyniki jawna reguła agregacji krytyk i wykonawca wynik ma mierzalne kryteria nieskończona poprawa limit iteracji i próg jakości rozmowa grupowa zadanie naprawdę wymaga negocjacji ról pętle i wysoki koszt limit rund oraz moderator Im bardziej otwarty wzorzec, tym trudniej przewidzieć koszt i zachowanie. W procesie biznesowym często lepszy jest graf z jawnymi przejściami niż rozmowa, w której agenci sami ustalają kolejność. [Microsoft Agent Framework](https://github.com/microsoft/agent-framework) rozwija właśnie kontrolowane przepływy: sekwencyjne, równoległe, przekazania i współpracę grupową, a także checkpointy i udział człowieka. To jeden z powodów, dla których Microsoft kieruje nowe wdrożenia do następcy AutoGen. ## Zaprojektuj kontrakt każdej roli Dla każdego agenta zapisz wejście, wyjście, dostępne narzędzia, dozwolone dane i warunek ukończenia. Wyjście powinno mieć strukturę możliwą do walidacji, na przykład status, listę źródeł, wynik i kod błędu. Przekazywanie długiej rozmowy jako jedynego interfejsu utrudnia testy i zwiększa zużycie tokenów. Agent wyszukujący może zwracać zestaw rekordów ze źródłem i datą. Agent analityczny powinien przyjmować tylko te rekordy, a nie całą historię dialogu. Walidator sprawdza wymagane pola i reguły biznesowe. Dzięki temu można wymienić model jednego agenta bez zmieniania całego przepływu, a błąd ma określone miejsce. Narzędzia muszą mieć wąskie interfejsy. Zamiast ogólnej funkcji wykonującej dowolne zapytanie SQL przygotuj operację pobierającą konkretny zestaw danych. Zamiast pełnego dostępu do skrzynki pocztowej udostępnij wysłanie wersji roboczej do wskazanej kolejki. Prompt nie zastępuje kontroli uprawnień. ## Stan, pamięć i przekazanie kontekstu System wielu agentów szybko gromadzi kontekst. Jeśli każdy agent otrzymuje pełną historię, koszt rośnie z każdą rundą, a ważne dane giną w rozmowie. Jeśli historia jest agresywnie skracana, system może utracić warunek albo źródło. Rozdziel więc trzy rodzaje stanu. Stan zadania zawiera fakty niezbędne do ukończenia bieżącej pracy. Pamięć operacyjna przechowuje informacje przydatne w kolejnych krokach. Rejestr audytowy dokumentuje, co się wydarzyło. Nie używaj jednego wektora pamięci do wszystkich trzech celów. Każdy typ wymaga innego czasu przechowywania, dostępu i sposobu usuwania. Przekazanie między agentami powinno być małym, wersjonowanym obiektem. Umieść w nim identyfikator zadania, zatwierdzone fakty, niepewności, wykonane operacje i następny oczekiwany krok. Nie przekazuj sekretów ani pełnych odpowiedzi narzędzi, jeśli odbiorca ich nie potrzebuje. Ta dyscyplina zmniejsza ryzyko wycieku oraz ułatwia wznowienie procesu po awarii. ## Koszt wielu agentów trzeba liczyć na ukończone zadanie Cena jednego wywołania modelu niewiele mówi o ekonomice systemu. Licz wszystkie rundy, ponowienia, narzędzia, przechowywanie, monitoring i czas człowieka. Układ wykonawca–krytyk może poprawić jakość, ale również potroić liczbę wywołań. Agent, który deleguje pracę kolejnemu agentowi, tworzy dodatkowy kontekst i opóźnienie. Przyjmij syntetyczny test 60 zadań: 40 typowych, 10 z brakującymi danymi i 10 konfliktowych. Porównaj pojedynczego agenta, jawny workflow i zespół wieloagentowy. Dla każdego policz odsetek poprawnego ukończenia, medianę czasu, koszt zadania, liczbę niepotrzebnych przekazań i minuty kontroli człowieka. To przykład metody, a nie dane z rzeczywistego wdrożenia. System wieloagentowy wygrywa tylko wtedy, gdy poprawa wyniku pokrywa dodatkowy koszt i złożoność. Jeśli zespół agentów osiąga ten sam rezultat co sekwencja funkcji, wybierz sekwencję. Kod jest łatwiejszy do odtworzenia, zabezpieczenia i objęcia testami regresji. ## Testuj role osobno i cały przepływ razem ### Oddziel środowisko wykonawcze od rozmowy Agent generujący kod albo polecenie nie powinien wykonywać go w tym samym procesie, który przechowuje dane uwierzytelniające. Uruchamiaj takie zadania w izolowanym środowisku z limitem czasu, pamięci, sieci i systemu plików. Obraz środowiska powinien być odtwarzalny, a wynik ograniczony do jasno określonych artefaktów. Dotyczy to również demonstracji AutoGen Studio: wygodny interfejs nie dodaje automatycznie kontroli wymaganych w produkcji. Traktuj wiadomości od innych agentów jak dane zewnętrzne. Agent nie powinien uzyskiwać szerszych praw dlatego, że polecenie przyszło od roli nazwanej „manager”. Autoryzację sprawdza warstwa narzędzi na podstawie tożsamości i kontraktu, a nie treści rozmowy. Ogranicz też liczbę delegacji i głębokość wywołań. W przeciwnym razie błąd routingu może utworzyć trudną do zatrzymania kaskadę operacji i kosztów. Najpierw przygotuj test kontraktowy dla każdego agenta: poprawne wejście, brakujące pole, dane sprzeczne, niedozwolona operacja i błąd narzędzia. Następnie sprawdź integrację: czy wiadomości trafiają do właściwej roli, czy stan nie jest gubiony i czy pętla kończy się zgodnie z limitem. Ostatni poziom to test procesu na reprezentatywnych zadaniach. Rejestruj wersję modeli i instrukcji, kolejność wiadomości, wywołania narzędzi, czas, tokeny i decyzje człowieka. Bez takiego śladu nie odróżnisz błędu modelu od błędu routingu, narzędzia albo niepełnego wejścia. AutoGen Core opisuje runtime jako warstwę zarządzającą komunikacją, cyklem życia agentów, granicami bezpieczeństwa i obserwowalnością. To potrzebne elementy, ale framework nie definiuje za firmę kryterium poprawnej decyzji. Zespół nadal musi stworzyć dane testowe i reguły akceptacji odpowiadające własnemu procesowi. ## Mapa decyzji przed migracją do Agent Framework Osobny [przewodnik po Microsoft Agent Framework](https://majchrzycki.com/blog/microsoft-agent-framework-ai-os) opisuje następcę dla nowych systemów. [Oficjalna mapa migracji z AutoGen](https://learn.microsoft.com/en-us/agent-framework/migration-guide/from-autogen/) pokazuje między innymi zmianę modelu orkiestracji z zespołu i zdarzeń na jawny przepływ danych. Przed przenoszeniem kodu rozlicz każdy element obecnego systemu: Element AutoGen Pytanie kontrolne w nowym projekcie Zespół agentów Czy każda rola potrzebuje osobnych narzędzi lub uprawnień? Przekazywanie rozmowy Jaki minimalny, sprawdzalny obiekt ma przechodzić między etapami? Stan i wznowienie Kiedy zapis jest trwały i co stanie się po powtórzeniu operacji? Narzędzia Które funkcje mogą tylko czytać, a które powodują skutek? Telemetria Czy potrafisz porównać poprawność, koszt i czas na tym samym zbiorze zadań? Jeżeli działające rozwiązanie spełnia te warunki, migracja może poczekać do zaplanowanej modernizacji. Jeśli nowy projekt potrzebuje długotrwałego stanu i punktów zatwierdzenia, warto sprawdzić następny framework na próbie przed wyborem architektury. ## Migracja nie powinna być mechanicznym przepisaniem klas Jeżeli używasz AutoGen, zacznij od inwentaryzacji: wersja pakietów, topologia agentów, modele, narzędzia, magazyn stanu, punkty zatwierdzeń i telemetria. Oficjalny [przewodnik migracji Microsoft Agent Framework](https://learn.microsoft.com/en-us/agent-framework/migration-guide/) prowadzi do materiałów dla AutoGen. Potraktuj migrację jako okazję do usunięcia zbędnych ról, a nie odwzorowanie każdej rozmowy jeden do jednego. Zamroź zestaw testowy przed zmianą. Uruchom stary i nowy przepływ na tych samych danych, porównując wynik, koszt i ślad narzędzi. Szczególną uwagę poświęć zachowaniu przy wznowieniu, błędzie częściowym i zatwierdzeniu człowieka. Dopiero zgodność operacyjna pozwala ocenić, czy można przełączyć ruch. Nie migruj tylko dlatego, że pojawił się następca. Działający, odizolowany system AutoGen może pozostać przez zaplanowany okres, jeśli ryzyko zostało zaakceptowane i zespół ma plan poprawek. Jednocześnie brak nowych funkcji i długoterminowego wsparcia jest realnym kosztem, który powinien znaleźć się w rejestrze architektonicznym. ## Decyzja architekta na pierwszy tydzień Weź jedno zadanie, które wydaje się wieloagentowe. Narysuj kroki, dane i decyzje. Zaznacz te etapy, które można wykonać funkcją, oraz te, które wymagają oceny modelu. Zbuduj najpierw wersję z jednym agentem i jawnym workflow. Drugiego agenta dodaj tylko wtedy, gdy wprowadza odrębne narzędzia, odpowiedzialność albo kryterium kontroli. Jeśli rozpoczynasz nowy projekt, oceń Microsoft Agent Framework zamiast przyjmować AutoGen z dawnych materiałów. Jeśli utrzymujesz AutoGen, zabezpiecz wersje, testy i plan migracji. W obu przypadkach najpierw uporządkuj role w ramach [systemu operacyjnego firmy](https://majchrzycki.com/system), a następnie sprawdź, czy problem rzeczywiście potrzebuje [systemu wielu autonomicznych agentów](https://majchrzycki.com/blog/multi-autonomous-ai-agent-system-app). Liczba agentów nie jest miarą dojrzałości rozwiązania. Jest kosztem, który musi mieć uzasadnienie. - Agenci AI - Modele i LLM ## Przełóż temat na projekt w Twojej firmie Zobacz zakres współpracy: od rozpoznania procesu i danych po projekt rozwiązania AI. [Zobacz współpracę](https://majchrzycki.com/wspolpraca) ## Czytaj dalej - [Microsoft Agent Framework po AutoGen i Semantic Kernel](https://majchrzycki.com/blog/microsoft-agent-framework-ai-os) - [Semantic Kernel: kiedy orkiestracja AI ma sens](https://majchrzycki.com/blog/co-to-jest-microsoft-semantic-kernel) - [LangChain: kiedy framework pomaga aplikacji AI](https://majchrzycki.com/blog/langchain-ai-llm-apps) - [System wieloagentowy AI: kiedy ma sens w firmie](https://majchrzycki.com/blog/multi-autonomous-ai-agent-system-app)