Microsoft AutoGen: jak ocenić system wielu agentów

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 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 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 opisuje następcę dla nowych systemów. Oficjalna mapa migracji z 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 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, a następnie sprawdź, czy problem rzeczywiście potrzebuje systemu wielu autonomicznych agentów. Liczba agentów nie jest miarą dojrzałości rozwiązania. Jest kosztem, który musi mieć uzasadnienie.