Współpraca wielu agentów AI – jak projektować rozwiązania wieloagentowe?

Kiedy architektura multi-agent ma sens (a kiedy nie): kryteria i trade-offy

Architektura wieloagentowa ma sens wtedy, gdy podział pracy rozwiązuje konkretny problem, którego pojedynczy agent nie obsługuje wystarczająco dobrze. Nie warto wdrażać jej wyłącznie dlatego, że zadanie obejmuje wiele kroków. Odczytanie dokumentu, wydobycie danych i zapisanie ich w systemie może wymagać kilku operacji, ale niekoniecznie kilku agentów.

O wyborze powinny decydować charakter zadania, możliwość wyodrębnienia niezależnych obszarów pracy oraz korzyść z ich rozdzielenia. Więcej agentów oznacza bowiem nie tylko większe możliwości specjalizacji, lecz także dodatkowe koszty, opóźnienia i zależności.

Jeden agent, workflow czy system wieloagentowy?

Pojedynczy agent korzysta z modelu AI i dostępnych narzędzi, aby realizować cel oraz dobierać kolejne działania. Może przeszukiwać źródła, wykonywać obliczenia i odwoływać się do zewnętrznych systemów. Sama liczba narzędzi nie przesądza więc o potrzebie zastosowania architektury multi-agent.

Workflow prowadzi zadanie przez wcześniej określone kroki i warunki przejścia. Może zawierać wywołania modeli językowych, ale zasadnicza logika procesu pozostaje zaprojektowana z góry. To dobry wybór, gdy wiadomo, jakie operacje trzeba wykonać, a zmienność dotyczy głównie przetwarzanych danych.

System wieloagentowy rozdziela zadanie między agentów, którzy podejmują decyzje w przydzielonym zakresie, a wyniki ich pracy są wykorzystywane do osiągnięcia wspólnego celu. Agenci mogą korzystać z tego samego modelu bazowego — istotny jest podział odpowiedzialności i kontekstu, nie liczba różnych modeli. W praktyce te podejścia można łączyć: przewidywalna część procesu pozostaje workflow, a tylko wybrany fragment wymaga współpracy agentów.

Kiedy podział na wielu agentów daje realną przewagę?

Najmocniejszym argumentem za takim rozwiązaniem jest naturalna podzielność problemu. Poszczególne części powinny mieć jasno określony zakres i dostarczać wyniki, które da się połączyć bez ciągłego odtwarzania całego toku pracy. Podział jest szczególnie uzasadniony, gdy występuje przynajmniej jedna z poniższych sytuacji:

• Zadanie obejmuje różne dziedziny i źródła wiedzy. Analiza złożonego zapytania ofertowego może wymagać osobnego zbadania wymagań technicznych, warunków umownych i możliwości realizacji. Rozdzielenie tych obszarów pomaga ograniczyć nadmiar nieistotnych informacji w kontekście każdego agenta.
• Część pracy można wykonać niezależnie. Równoległe zbadanie kilku wariantów rozwiązania lub zbiorów dokumentów może skrócić czas realizacji, o ile późniejsze łączenie wyników nie pochłonie uzyskanej oszczędności.
• Potrzebne są różne perspektywy oceny. Oddzielne rozpatrzenie propozycji pod kątem wykonalności i zgodności z wymaganiami może ujawnić pominięcia. Nie oznacza jednak automatycznie niezależności ocen ani gwarancji poprawności.
• Obszary pracy mają odmienne granice dostępu. Rozdzielenie analizy informacji od działań w systemach operacyjnych może ułatwić wydzielenie uprawnień. Sama deklaracja osobnych agentów nie tworzy jednak zabezpieczenia — granice muszą być egzekwowane przez aplikację.

Kiedy złożoność przewyższa korzyści?

Architektura multi-agent zwykle nie jest pierwszym wyborem przy krótkich, powtarzalnych zadaniach, takich jak klasyfikacja wiadomości, ekstrakcja pól z formularza czy przygotowanie odpowiedzi na podstawie jednego dokumentu. Jeżeli poprawny przebieg można opisać stabilną sekwencją operacji, prostszy workflow bywa bardziej przewidywalny i tańszy.

Ostrożności wymagają także zadania silnie współzależne. Jeśli każdy agent potrzebuje niemal całej historii i musi nieustannie uzgadniać decyzje z pozostałymi, podział może zwiększyć obciążenie zamiast je zmniejszyć. Przekazywanie wyników rodzi też ryzyko utraty niuansów: skrót wystarczający dla jednego etapu nie zawsze wystarcza do podjęcia kolejnej decyzji.

Podstawowy trade-off to specjalizacja w zamian za koszt koordynacji. Węższy kontekst może ułatwiać wykonanie zadania, ale dodatkowe wywołania modeli, powielane instrukcje i uzgodnienia zwiększają zużycie zasobów. Równoległość może obniżyć opóźnienie, lecz nie musi zmniejszać kosztu. Dodatkowa ocena może poprawić wynik, ale agenci korzystający z podobnych modeli i źródeł mogą powielać te same błędy.

Rozsądny punkt wyjścia to najprostsze rozwiązanie spełniające wymagania. Przed dodaniem kolejnego agenta warto umieć odpowiedzieć na trzy pytania: jaki konkretny problem rozwiązuje jego wydzielenie, czy otrzyma zakres możliwie niezależny od reszty oraz czy oczekiwana korzyść uzasadnia dodatkowy koszt i czas. Jeśli odpowiedzi są niejasne, lepiej najpierw dopracować pojedynczego agenta lub workflow niż rozbudowywać architekturę.

Projektowanie ról i odpowiedzialności agentów: researcher, validator, executor i inne wzorce

Rolę agenta warto definiować przez odpowiedzialność za konkretny rezultat, a nie przez ogólną deklarację kompetencji. Polecenie „jesteś ekspertem od analizy” nie wyznacza użytecznej granicy zadania. Znacznie precyzyjniejsze jest: „ustal fakty potrzebne do rozpatrzenia zgłoszenia, wskaż ich źródła i zaznacz brakujące informacje”. Taki opis pozwala odróżnić pracę agenta od zadań pozostałych uczestników procesu.

W Cognity często słyszymy pytania, jak w praktyce wyznaczać granice odpowiedzialności agentów — odpowiadamy na nie także na blogu. Podział ról nie musi oznaczać użycia różnych modeli językowych. Ten sam model może obsługiwać kilka specjalizacji, jeśli każda z nich ma odrębny zakres zadania, dostęp do odpowiednich narzędzi i jasno określony wynik pracy. Różnice między agentami powinny wynikać z potrzeb procesu, nie tylko z nazw nadanych im w promptach.

Researcher, validator i executor — trzy różne rodzaje odpowiedzialności

Podstawowy podział rozdziela zdobywanie informacji, ich ocenę oraz wykonywanie działań. Każda z tych funkcji odpowiada na inne pytanie:

• Researcher: „Co wiemy i na jakiej podstawie?” Wyszukuje informacje w dostępnych źródłach, zestawia ustalenia i identyfikuje luki. Sprawdza się przy analizie dokumentacji, rozpoznawaniu problemów czy przygotowywaniu materiału do decyzji. Jego wynikiem powinny być ustalenia ze wskazaniem źródeł oraz niepewności, a nie samo płynne streszczenie. Nie powinien przedstawiać własnych przypuszczeń jako potwierdzonych faktów.
• Validator: „Czy ten wynik spełnia wymagania?” Ocenia materiał według określonych kryteriów, takich jak zgodność ze źródłami, kompletność czy spełnienie reguł biznesowych. Powinien wskazywać konkretne uchybienia i uzasadniać ocenę, zamiast jedynie deklarować, że odpowiedź jest poprawna. Samo powierzenie kontroli osobnemu agentowi nie gwarantuje niezależnej weryfikacji — potrzebuje on dostępu do podstaw oceny, a nie wyłącznie do wniosków researchera.
• Executor: „Jak wykonać wskazane działanie?” Realizuje sprecyzowane zadania za pomocą narzędzi, na przykład aktualizuje rekord lub tworzy zgłoszenie. Jego rezultatem jest informacja o faktycznym wykonaniu operacji, jej niepowodzeniu albo niespełnionych warunkach. Nie należy utożsamiać go z decydentem: możliwość wykonania czynności nie oznacza uprawnienia do samodzielnego wyboru celu.

Przykładowo agent zbierający dane może ustalić, że dokumentacja uzasadnia zmianę statusu sprawy. Validator ocenia zgodność tego wniosku z wymaganiami, natomiast executor dokonuje zmiany w systemie. Istotna jest tu granica odpowiedzialności: ustalenie faktów, ocena wniosku i zmiana stanu systemu to odrębne zadania.

Inne wzorce ról: planista, specjalista i redaktor

Planner, czyli planista, przekłada cel na zestaw zadań i określa, jakie rezultaty są potrzebne do jego osiągnięcia. Jest przydatny tam, gdzie zakres pracy zależy od treści problemu. Nie musi jednak sam prowadzić badań ani wykonywać operacji — odpowiada za przygotowanie planu, nie za wszystkie jego elementy.

Specjalista dziedzinowy analizuje problem z jednej, wyraźnie określonej perspektywy, na przykład technicznej lub finansowej. Taki podział ma uzasadnienie, gdy poszczególne analizy wymagają innych źródeł, reguł interpretacji lub narzędzi. Sama zmiana deklarowanej „osobowości eksperta” nie tworzy rzeczywistej specjalizacji.

Redaktor lub syntetyzator łączy ustalenia w spójny materiał dla odbiorcy. Odpowiada za czytelność, strukturę i zachowanie znaczenia informacji. Nie powinien dopisywać brakujących faktów ani ukrywać rozbieżności między analizami tylko po to, by tekst brzmiał jednoznacznie.

Opis roli jako kontrakt odpowiedzialności

Dla każdej roli należy określić cel, wymagane dane wejściowe, oczekiwany rezultat, dozwolone działania oraz warunek zakończenia zadania. Równie ważne jest wskazanie, czego agent nie rozstrzyga. Researcher może ujawnić brak danych, ale nie powinien zastępować ich domysłem; redaktor może uporządkować rekomendację, lecz nie zmieniać jej sensu.

Dobry opis roli uwzględnia również sytuację, w której poprawnym wynikiem jest stwierdzenie „nie można ustalić” lub „brakuje wymaganych informacji”. Dzięki temu odpowiedzialność agenta obejmuje rzetelne rozpoznanie granic własnego zadania, a nie obowiązek dostarczenia pozornie kompletnej odpowiedzi za wszelką cenę.

3. Koordynacja pracy agentów: orkiestracja, protokoły komunikacji, planowanie i przekazywanie kontekstu

Podział zadania między agentów nie wystarcza, by powstał sprawny proces. Trzeba jeszcze ustalić, kto uruchamia kolejne kroki, skąd wiadomo, że praca została zakończona, oraz jakie informacje otrzymuje następny uczestnik. Koordynacja powinna opierać się na jawnych regułach i stanie zadania, a nie wyłącznie na swobodnej rozmowie między modelami. Dzięki temu przekazanie pracy oznacza konkretną zmianę w procesie, nie tylko wysłanie kolejnej wiadomości.

Orkiestracja: kto decyduje o następnym kroku?

W modelu scentralizowanym przebiegiem pracy zarządza orkiestrator. Przydziela zadania, odbiera wyniki i rozstrzyga, które działania można rozpocząć. Nie musi być agentem AI: często wystarczy kod aplikacji lub silnik workflow. Model językowy warto angażować w wybór ścieżki wtedy, gdy decyzja wymaga interpretacji treści, a nie prostego sprawdzenia warunku.

Alternatywą jest koordynacja zdecentralizowana, w której agenci przekazują sobie zadania bez jednego decydenta. Daje większą swobodę w procesach eksploracyjnych, ale wymaga jednoznacznych zasad przejmowania odpowiedzialności i kończenia współpracy. Osobną decyzją jest sposób transportu komunikatów: zarówno układ scentralizowany, jak i zdecentralizowany może korzystać z bezpośrednich wywołań, kolejek lub zdarzeń.

Najczęściej stosowane wzorce przepływu pracy to:

• Sekwencja — wynik jednego kroku stanowi wejście do następnego. Pasuje do zadań z wyraźną kolejnością i silnymi zależnościami.
• Rozgałęzienie i scalenie — niezależne podzadania są wykonywane równolegle, a ich rezultaty trafiają do wspólnego etapu opracowania. Trzeba określić, czy scalenie czeka na wszystkie wyniki, czy na wskazany ich zestaw.
• Routing warunkowy — dalsza ścieżka zależy od treści lub statusu wyniku. Sprawdza się, gdy różne kategorie spraw wymagają różnych działań.
• Delegowanie dynamiczne — agent wybiera wykonawcę lub proponuje kolejne podzadania w trakcie pracy. Jest przydatne tam, gdzie pełnej ścieżki nie da się ustalić przed analizą problemu.

Te wzorce można łączyć. Stały szkielet procesu może zawierać etap dynamicznego planowania, a następnie uruchamiać kilka zadań równolegle. Nie trzeba wybierać między całkowicie sztywnym workflow a pełną autonomią agentów.

Protokół komunikacji: wiadomość musi mieć jednoznaczne znaczenie

Protokół powinien określać nie tylko format danych, lecz także znaczenie komunikatów. Zlecenie wykonania zadania, pytanie o brakujące informacje, wynik częściowy i wynik końcowy to różne zdarzenia. Odbiorca nie powinien odgadywać ich rodzaju z tonu wypowiedzi.

Praktyczna koperta wiadomości zawiera identyfikator zadania i ewentualnego zadania nadrzędnego, nadawcę, adresata, typ komunikatu, wersję schematu oraz treść lub odwołanie do rezultatu. Dla zlecenia należy dodatkowo wskazać oczekiwany format odpowiedzi i kryterium zakończenia. Status zadania powinien być zapisany w dedykowanym polu, a nie ukryty w opisie tekstowym. To pozwala odróżnić potwierdzenie odbioru od faktycznego wykonania pracy.

Gdy komunikacja odbywa się przez kolejkę lub magistralę zdarzeń, nie należy zakładać, że wiadomości zawsze dotrą w kolejności wysłania i tylko raz. Identyfikator komunikatu oraz numer wersji stanu pomagają rozpoznać duplikat lub spóźnioną odpowiedź. Sam poprawny JSON nie rozwiązuje tych problemów — potrzebne są także uzgodnione reguły przetwarzania wiadomości.

Planowanie: zależności zamiast samej listy zadań

Użyteczny plan opisuje cel każdego kroku, wymagane wejścia, oczekiwane wyjście i zależności. Dwa zadania można wykonywać równolegle, jeżeli żadne nie potrzebuje wyniku drugiego. Etap łączący ich rezultaty powinien rozpocząć się dopiero po spełnieniu jawnie określonych warunków. W praktyce taki plan często przyjmuje postać grafu zadań.

Jeżeli plan powstaje dynamicznie, warto oddzielić jego zaproponowanie od uruchomienia. Agent może przedstawić strukturę podzadań, natomiast orkiestrator sprawdza, czy wskazane operacje istnieją i czy ich wejścia są dostępne. Zmiana planu powinna również określać, które dotychczasowe wyniki pozostają aktualne. Inaczej agenci mogą kontynuować pracę według różnych wersji tego samego procesu.

Przekazywanie kontekstu: stan zadania zamiast całej historii

Przesyłanie pełnej rozmowy wszystkim agentom utrudnia rozpoznanie tego, co aktualne i istotne. Lepszym rozwiązaniem jest pakiet przekazania obejmujący cel podzadania, istotne ustalenia, obowiązujące ograniczenia, nierozstrzygnięte pytania oraz odwołania do materiałów źródłowych. Odbiorca powinien też wiedzieć, jaki rezultat ma zwrócić i komu go przekazać.

Warto rozdzielić lokalny kontekst agenta, współdzielony stan procesu i artefakty robocze. Kontekst lokalny służy wykonaniu bieżącego kroku. Stan procesu przechowuje aktualne statusy i ustalenia. Artefakty — na przykład dokumenty czy wyniki analiz — mogą pozostawać w osobnym repozytorium, a wiadomości zawierać ich identyfikatory i wersje.

Streszczenie ułatwia przekazanie pracy, ale nie zastępuje źródeł. Powinno odróżniać potwierdzone informacje od założeń i wskazywać, gdzie sprawdzić szczegóły. Przy pracy równoległej trzeba dodatkowo ustalić, kto może zmieniać poszczególne pola wspólnego stanu oraz jak rozstrzygane są kolizje aktualizacji. W ten sposób każdy agent otrzymuje kontekst potrzebny do działania, a cały proces zachowuje spójny obraz postępu.

Ograniczanie ryzyka: halucynacje, pętle, eskalacje, bezpieczeństwo i kontrola kosztów

W systemie wieloagentowym błąd jednego agenta może stać się założeniem dla wszystkich kolejnych. Niepotwierdzona informacja trafia do rekomendacji, rekomendacja zostaje uznana za decyzję, a decyzja uruchamia działanie w zewnętrznym systemie. Dlatego zabezpieczenia powinny obejmować nie tylko odpowiedzi modeli, lecz przede wszystkim przejście od informacji do działania. Im większe konsekwencje operacji i trudniejsze jej odwrócenie, tym silniejsza powinna być kontrola. W Cognity omawiamy projektowanie takich zabezpieczeń zarówno od strony technicznej, jak i praktycznej – zgodnie z realiami pracy uczestników.

Halucynacje: zgodność agentów nie jest dowodem poprawności

Kilku agentów może zgodnie powtórzyć tę samą nieprawdziwą informację, szczególnie gdy korzystają z podobnych modeli lub wspólnego, błędnego kontekstu. Dodatkowa opinia modelu pomaga wykrywać niespójności, ale nie zastępuje sprawdzenia faktów w wiarygodnym źródle. Weryfikacja powinna dotyczyć zarówno istnienia źródła, jak i tego, czy rzeczywiście potwierdza ono konkretny wniosek.

Informacje wpływające na decyzję powinny zachowywać odniesienie do dokumentu, rekordu lub wyniku narzędzia, z którego pochodzą. Trzeba też oddzielać dane potwierdzone od interpretacji i założeń. Przy obliczeniach, sprawdzaniu uprawnień czy kontroli wymaganych pól lepiej stosować reguły programistyczne niż kolejne zapytanie do modelu. Brak wystarczających danych powinien umożliwiać wstrzymanie decyzji, a nie wymuszać wygenerowanie odpowiedzi za wszelką cenę.

Pętle: ograniczaj próby, nie tylko czas działania

Agenci mogą wielokrotnie odsyłać zadanie do siebie, poprawiać wynik bez wyraźnej zmiany albo ponawiać operację, która nie ma szans powodzenia. Sam limit czasu nie wystarczy: przed jego upływem system może wykonać wiele kosztownych lub szkodliwych działań. Potrzebne są limity liczby kroków, ponowień i przekazań zadania oraz warunek zatrzymania przy braku postępu, na przykład gdy kolejne próby zwracają ten sam błąd i nie dostarczają nowych danych.

Warto odróżnić awarię przejściową, która uzasadnia ograniczone ponowienie, od trwałego problemu, takiego jak brak uprawnień. Szczególnej ostrożności wymagają operacje zmieniające stan systemu. Jeśli po wysłaniu żądania wystąpi timeout, nie oznacza to, że operacja się nie wykonała. Przed ponowieniem należy sprawdzić jej status lub zastosować mechanizm idempotencji, który chroni przed powieleniem skutku, na przykład ponownym utworzeniem tego samego zlecenia.

Eskalacje: określ, kiedy autonomia się kończy

Eskalacja jest potrzebna nie tylko po błędzie technicznym. Powinna następować także przy sprzecznych źródłach, braku wymaganej zgody, niejasnym zakresie zlecenia lub działaniu o wysokich konsekwencjach. Nie należy opierać jej wyłącznie na deklarowanej przez model pewności odpowiedzi. Ważniejsze są sprawdzalne przesłanki: kompletność danych, zgodność z regułami i rodzaj planowanej operacji.

Osoba zatwierdzająca powinna otrzymać konkretny problem, zebrane dowody, proponowane działanie i jego przewidywane skutki. Zgoda musi dotyczyć określonej operacji i jej parametrów; istotna zmiana zakresu wymaga ponownego zatwierdzenia. Jeśli nikt nie odpowie, bezpiecznym zachowaniem jest wstrzymanie działania lub zakończenie zadania ze statusem wymagającym interwencji, a nie automatyczne przyjęcie zgody.

Bezpieczeństwo: treść wejściowa nie może nadawać uprawnień

Dokument, wiadomość czy strona internetowa może zawierać instrukcje próbujące zmienić zachowanie agenta. To ryzyko prompt injection, które w architekturze multi-agent może rozprzestrzeniać się wraz z przekazywanym kontekstem. Treści zewnętrzne należy traktować jako dane, nie jako polecenia sterujące. Samo ostrzeżenie zapisane w prompcie nie zapewnia jednak skutecznej ochrony.

Uprawnienia powinny być egzekwowane poza modelem, na poziomie aplikacji i narzędzi. Każdy agent powinien mieć dostęp wyłącznie do niezbędnych zasobów, a wywołania narzędzi muszą podlegać kontroli dozwolonych operacji, parametrów i odbiorców danych. Dotyczy to również danych przekazywanych innym agentom: wspólny kontekst nie powinien automatycznie obejmować wszystkich informacji dostępnych w systemie. Sekrety, takie jak klucze API, najlepiej obsługiwać poza kontekstem modelu.

Kontrola kosztów: budżet jako granica wykonania

Koszt zadania obejmuje nie tylko tokeny, lecz także płatne narzędzia, wyszukiwanie, ponowienia i równoległe działania agentów. Dlatego budżet powinien dotyczyć całego zadania, a nie jedynie pojedynczego wywołania. Przy pracy równoległej potrzebna jest wspólna kontrola dostępnych środków, aby kilku agentów nie wykorzystało jednocześnie tego samego pozostałego limitu.

Przed kolejnym kosztownym krokiem system powinien sprawdzać dostępny budżet i, tam gdzie to możliwe, rezerwować środki na wykonanie. Po osiągnięciu progu ostrzegawczego można ograniczyć zakres analizy lub poprosić o zgodę na kontynuację. Po wyczerpaniu limitu należy zatrzymać nowe działania i jasno wskazać, czego nie ukończono. Oszczędność nie powinna polegać na pomijaniu obowiązkowej weryfikacji — bezpieczniej dostarczyć wynik częściowy niż wykonać niezweryfikowaną operację.

5. Pomiar jakości i skuteczności: metryki, testy, obserwowalność i ewaluacja offline/online

System wieloagentowy może generować przekonujące odpowiedzi, poprawnie wywoływać narzędzia i nadal nie realizować celu użytkownika. Dlatego jakość trzeba mierzyć na trzech poziomach: wyniku końcowego, działania poszczególnych agentów oraz współpracy między nimi. Sam odsetek poprawnych odpowiedzi nie pokaże, czy sukces wymagał zbędnych powtórzeń, kosztownej wymiany komunikatów albo ręcznej korekty.

Metryki: od efektu biznesowego do jakości współpracy

Punktem wyjścia jest jednoznaczna definicja sukcesu zadania. W obsłudze zgłoszeń może to być prawidłowe rozpoznanie sprawy i wykonanie wymaganej operacji, potwierdzone stanem systemu docelowego. Deklaracja agenta „zadanie zakończone” nie stanowi takiego potwierdzenia. Jeśli część przypadków wymaga decyzji człowieka, poprawne przekazanie sprawy powinno mieć osobne kryterium oceny, zamiast automatycznie liczyć się jako porażka.

Wyniki warto rozdzielać według typu i trudności zadania. Wysoka średnia może maskować słabe działanie na rzadkich, ale istotnych przypadkach. Koszt na sukces należy liczyć jako łączny koszt wszystkich prób podzielony przez liczbę skutecznie zakończonych zadań — dzięki temu nie znika koszt niepowodzeń.

Testy: sprawdzaj elementy i cały przebieg

Testy pojedynczego agenta nie zastępują testów całego systemu. Agent może działać poprawnie w izolacji, lecz otrzymywać niepełne dane od poprzednika albo tworzyć wynik, którego następny etap nie potrafi wykorzystać. Potrzebne są więc testy komponentów, testy integracyjne sprawdzające przekazanie danych oraz testy end-to-end oceniające realizację pełnego zadania.

Zestaw testowy powinien obejmować typowe sprawy, niejednoznaczne polecenia, brakujące informacje, sprzeczne źródła i błędy narzędzi. Dla każdego przypadku trzeba określić oczekiwany rezultat lub reguły akceptacji. Nie zawsze istnieje jedna wzorcowa odpowiedź tekstowa: często ważniejsze są poprawność decyzji, obecność wymaganych informacji i faktyczny efekt wykonanej operacji.

Obserwowalność: ustalaj przyczynę, nie tylko wykrywaj błąd

Metryka wskazuje, że skuteczność spadła; ślad wykonania pozwala sprawdzić, gdzie i dlaczego. Jedno zadanie powinno mieć wspólny identyfikator łączący działania agentów, wywołania narzędzi i wynik końcowy. W śladzie warto zapisywać kolejność zdarzeń, wejścia i wyjścia etapów, czas wykonania, zużycie tokenów, błędy oraz wersje modeli i promptów.

Takie dane pomagają odróżnić błędną interpretację polecenia od utraty kontekstu czy awarii zewnętrznej usługi. Nie wymagają zapisywania ukrytego toku rozumowania modelu — istotne są obserwowalne działania, rezultaty i zwięzłe uzasadnienia decyzji, jeśli system je udostępnia. Zakres rejestrowanych danych powinien uwzględniać prywatność; pełna treść dokumentów nie zawsze jest potrzebna do diagnozy.

Ewaluacja offline i online: dwa różne źródła wiedzy

Ewaluacja offline służy porównywaniu wariantów na stałym zbiorze przypadków przed udostępnieniem zmiany użytkownikom. Ułatwia wykrywanie regresji i ocenę, czy nowe rozwiązanie przewyższa dotychczasową wersję lub prostszy punkt odniesienia, np. pojedynczego agenta. Porównanie powinno odbywać się przy porównywalnych warunkach i jawnych limitach zasobów. Ze względu na zmienność odpowiedzi warto powtarzać próby i analizować rozrzut wyników.

Ewaluacja online pokazuje zachowanie systemu w rzeczywistym ruchu: rzeczywistą skuteczność, czas obsługi, częstość korekt użytkownika i obciążenie pracą ręczną. Test A/B pozwala porównać warianty na odpowiednio przypisanych grupach, natomiast tryb shadow umożliwia ocenę alternatywnego przebiegu bez wykonywania przez niego operacji zmieniających stan systemów. Sam tryb shadow nie potwierdza jednak skuteczności rzeczywistych działań.

Automatyczne reguły najlepiej sprawdzają się tam, gdzie wynik da się zweryfikować jednoznacznie. Ocena ekspercka jest potrzebna przy zadaniach wymagających interpretacji. Model oceniający może przyspieszyć analizę większej liczby odpowiedzi, ale jego zgodność z ocenami ludzi trzeba sprawdzić na oznaczonej próbce. O wyborze wariantu powinien decydować mierzalny wzrost jakości przy akceptowalnym koszcie i czasie, a nie sam wzrost liczby poprawnie wykonanych kroków.

Przykładowa architektura end-to-end: przyjęcie zgłoszenia → analiza → decyzja → wykonanie automatyzacji → raportowanie

Prześledźmy obsługę zgłoszenia pracownika, który potrzebuje dostępu do przestrzeni projektowej. To dobry przykład rozwiązania wieloagentowego: treść prośby wymaga interpretacji, zasadność dostępu trzeba sprawdzić, a zmianę wykonać w zewnętrznym systemie. Nie każdy etap wymaga jednak agenta AI. Odczyt statusu zatrudnienia, sprawdzenie wymaganej zgody czy wywołanie API powinny opierać się na jednoznacznych regułach i standardowych integracjach.

W tym przykładzie przepływ wygląda następująco: system zgłoszeniowy → analiza prośby przez agenta → zebranie i sprawdzenie przesłanek → decyzja zgodna z polityką dostępu → operacja w systemie docelowym → potwierdzenie wyniku i aktualizacja zgłoszenia.

1. Przyjęcie zgłoszenia i ustalenie przedmiotu prośby

Pracownik wysyła wiadomość: „Potrzebuję dostępu do dokumentacji projektu na czas zastępstwa do końca miesiąca”. System zgłoszeniowy nadaje sprawie identyfikator i przekazuje treść do agenta analizującego. Tożsamość wnioskodawcy pochodzi z uwierzytelnionego konta, a nie z podpisu pod wiadomością.

Agent przekształca opis w uporządkowane dane: wskazuje zasób, oczekiwany poziom dostępu, uzasadnienie oraz termin wygaśnięcia. Jeśli nie wiadomo, o jaki projekt chodzi, przygotowuje pytanie uzupełniające. Zgłoszenie pozostaje wtedy w stanie oczekiwania na dane — system nie wybiera samodzielnie najbardziej prawdopodobnej przestrzeni projektowej.

2. Analiza na podstawie danych organizacji

Po uzupełnieniu informacji agent zbierający kontekst korzysta z dostępnych integracji: katalogu pracowników, rejestru projektów i katalogu zasobów. Ustala, czy pracownik ma już część potrzebnych uprawnień, kto odpowiada za wskazaną przestrzeń i jaka procedura dotyczy jej udostępniania. Wynikiem jest zestaw ustaleń ze wskazaniem źródeł, nie samo streszczenie prośby.

Drugi agent sprawdza, czy zebrane informacje rzeczywiście odpowiadają zgłoszeniu. Może wykryć na przykład, że odnaleziona przestrzeń dotyczy archiwalnego projektu albo że uzasadnienie mówi o odczycie dokumentów, podczas gdy wnioskowany zakres obejmuje ich edycję. Taka rozbieżność wraca do wyjaśnienia przed podjęciem decyzji.

3. Decyzja: wykonanie, odmowa lub oczekiwanie na zgodę

Zweryfikowany wniosek trafia do mechanizmu decyzyjnego. Agent może przygotować rekomendację i jej uzasadnienie, ale nie zastępuje wymaganej autoryzacji. O dopuszczalności operacji rozstrzygają reguły organizacji oraz, gdy jest to wymagane, zgoda uprawnionej osoby.

Załóżmy, że w tej przykładowej organizacji czasowy dostęp do dokumentacji wymaga akceptacji właściciela projektu. System kieruje do niego wniosek zawierający konkretny zasób, poziom uprawnień i datę wygaśnięcia. Do momentu otrzymania zgody nie uruchamia automatyzacji. Akceptacja dotyczy dokładnie tego zakresu; późniejsza zmiana z odczytu na edycję wymaga ponownej oceny.

4. Wykonanie automatyzacji i sprawdzenie rezultatu

Po zatwierdzeniu agent wykonawczy otrzymuje ustrukturyzowane zlecenie: identyfikator użytkownika, identyfikator zasobu, dozwoloną operację, zakres dostępu oraz termin jego zakończenia. Korzysta z narzędzia integracyjnego, które wywołuje API systemu docelowego. Nie musi ponownie interpretować całej rozmowy ani samodzielnie ustalać parametrów dostępu.

Jeżeli system obsługuje uprawnienia czasowe, integracja ustawia datę wygaśnięcia. W przeciwnym razie potrzebny jest osobny, zaplanowany mechanizm odebrania dostępu. Bez niego nie można uznać, że warunek czasowości został spełniony.

Samo przyjęcie żądania przez API nie kończy procesu. Integracja odczytuje aktualny stan uprawnień i sprawdza zgodność z zatwierdzonym wnioskiem. Gdy odpowiedź jest niejednoznaczna, zgłoszenie otrzymuje status wymagający weryfikacji, zamiast automatycznie przechodzić do stanu „wykonane”.

5. Raportowanie wyniku i zamknięcie zgłoszenia

Na podstawie potwierdzonego rezultatu agent przygotowuje wiadomość dla pracownika: do jakiego zasobu uzyskał dostęp, w jakim zakresie i do kiedy. Jeżeli operacja się nie powiodła, komunikat opisuje aktualny stan sprawy oraz następny krok, bez sugerowania sukcesu.

Równolegle system zapisuje w zgłoszeniu powiązanie między wnioskiem, akceptacją, wykonaną operacją i wynikiem weryfikacji. Sprawa zostaje zamknięta dopiero po potwierdzeniu realizacji zatwierdzonego zakresu. Dzięki temu końcowy raport odzwierciedla stan systemu docelowego, a nie jedynie deklarację agenta, że zadanie zostało wykonane.

7. Wdrożenie i utrzymanie: iteracyjne usprawnienia, wersjonowanie promptów, governance i dobre praktyki

Wdrożenie systemu wieloagentowego nie kończy się na uruchomieniu agentów w środowisku produkcyjnym. Od tego momentu trzeba zarządzać zmianami w rozwiązaniu, którego zachowanie zależy nie tylko od kodu, lecz także od modeli, instrukcji, narzędzi i źródeł wiedzy. Podstawą utrzymania jest możliwość ustalenia, jaka konfiguracja obsłużyła dane zadanie, kto zatwierdził jej wdrożenie i jak wycofać ją w razie problemów.

Wdrażaj etapami, odpowiednio do skutków działania

Pierwsze uruchomienie warto ograniczyć do wybranego procesu, grupy użytkowników lub kategorii spraw. Tryb obserwacyjny, w którym system przygotowuje propozycje bez wykonywania operacji, pozwala sprawdzić jego przydatność na rzeczywistych przypadkach. Pilotaż z zatwierdzaniem działań przez człowieka służy natomiast weryfikacji całego procesu obsługi. Dopiero później można stopniowo zwiększać zakres samodzielności.

Nie każdy agent musi otrzymać taki sam poziom autonomii. Generowanie wewnętrznych notatek można udostępnić szerzej niż zmianę danych klienta czy uruchamianie płatności. Zakres wdrożenia powinien zależeć od konsekwencji błędu i możliwości jego odwrócenia, a nie wyłącznie od jakości odpowiedzi uzyskanych podczas demonstracji.

Wersjonuj całe wydanie, nie tylko prompty

Prompty należy traktować jak element oprogramowania: przechowywać w repozytorium, przeglądać przed publikacją i przypisywać do konkretnych wydań. Sama historia instrukcji jednak nie wystarczy. Identyfikator wydania powinien wskazywać również używane wersje modeli — o ile dostawca umożliwia ich przypięcie — parametry generowania, definicje narzędzi, schematy danych oraz konfigurację uprawnień. Warto też identyfikować wersję lub stan źródeł wiedzy wykorzystanych przez system.

Jednostką wdrożenia powinien być sprawdzony zestaw współpracujących komponentów. Zmiana formatu odpowiedzi jednego agenta może zaburzyć pracę kolejnego, nawet jeśli lokalnie wygląda na usprawnienie. Dokumentacja wydania powinna więc określać zależności i zgodność interfejsów. Taki zapis ułatwia diagnozę, ale nie gwarantuje identycznego odtworzenia odpowiedzi: modele mogą działać niedeterministycznie, a zewnętrzne usługi i dane zmieniać się w czasie.

Usprawniaj system małymi, uzasadnionymi zmianami

Rozwój po wdrożeniu najlepiej oprzeć na konkretnych problemach z eksploatacji. Zamiast ogólnego zadania „poprawić agenta”, warto zapisać: w jakich sytuacjach proces zawodzi, jaka jest prawdopodobna przyczyna i jaki efekt ma przynieść modyfikacja. Priorytet powinny mieć problemy częste lub dotkliwe dla użytkowników, niekoniecznie te najbardziej widowiskowe.

Nie każda poprawka wymaga nowego promptu ani kolejnego agenta. Przyczyną może być nieaktualna dokumentacja, niejednoznaczny formularz wejściowy lub zmiana w zewnętrznym API. Ograniczanie liczby jednoczesnych modyfikacji ułatwia ustalenie, co rzeczywiście pomogło. Każde wydanie powinno mieć opis celu, zakresu zmian oraz warunków wycofania.

Ustal odpowiedzialność i zasady zatwierdzania zmian

Governance oznacza w praktyce jasne reguły podejmowania decyzji. Właściciel biznesowy odpowiada za dopuszczalny zakres automatyzacji, a właściciel techniczny za wydania i utrzymanie. Zmiany dotyczące dostępu do danych, uprawnień lub działań o istotnych konsekwencjach wymagają udziału odpowiednich osób odpowiedzialnych za bezpieczeństwo i zgodność.

• Zmiany redakcyjne mogą przechodzić uproszczony przegląd, jeśli nie zmieniają zasad działania.
• Zmiany zachowania, takie jak nowe instrukcje decyzyjne lub wymiana modelu, wymagają ponownego sprawdzenia procesu przed publikacją.
• Rozszerzenie uprawnień powinno wymagać jawnej akceptacji i aktualizacji dokumentacji dostępu.

W tych samych zasadach należy określić dostęp do historii interakcji, okresy przechowywania danych i warunki wykorzystywania przypadków produkcyjnych do dalszego rozwoju. Logi mogą zawierać informacje poufne, dlatego nie powinny automatycznie trafiać do ogólnodostępnych zbiorów testowych.

Przygotuj utrzymanie na awarie i zmiany dostawców

Zespół operacyjny potrzebuje krótkiej instrukcji postępowania: jak wstrzymać automatyzację, przekazać sprawy do obsługi ręcznej, przywrócić poprzednią konfigurację i wskazać zadania wymagające korekty. Wycofanie wydania nie cofa operacji już wykonanych w systemach zewnętrznych. Ich naprawa może wymagać odrębnej procedury biznesowej.

Stałe utrzymanie obejmuje również przegląd uprawnień, aktualności wiedzy oraz zapowiadanych zmian modeli i API. Powinno mieć przydzielonego właściciela i budżet, tak samo jak utrzymanie pozostałych usług produkcyjnych. Dzięki temu rozwiązanie wieloagentowe pozostaje zarządzanym procesem, a nie eksperymentem zależnym od wiedzy pojedynczych osób.

Ograniczenia i dobre praktyki: formaty, jakość OCR, pułapki interpretacji oraz obowiązkowa weryfikacja wyników

W rozwiązaniach wieloagentowych przetwarzających dokumenty jakość wyniku zależy nie tylko od modeli, lecz także od tego, co faktycznie otrzymują one do analizy. Jeśli pierwszy etap błędnie odczyta dokument, kolejni agenci mogą zgodnie rozumować na podstawie nieprawdziwych danych. Podział pracy nie zastępuje więc kontroli materiału źródłowego — szczególnie przy analizie umów, faktur, formularzy czy raportów.

Format pliku nie gwarantuje poprawnego odczytu

PDF z warstwą tekstową zwykle pozwala wydobyć treść bez rozpoznawania znaków, natomiast skan lub zdjęcie wymaga OCR albo modelu obsługującego obraz. Samo rozszerzenie pliku nie mówi jednak, czy system odczyta dokument prawidłowo. Jeden PDF może zawierać zarówno tekst, jak i zeskanowane strony, a istniejąca warstwa tekstowa bywa niekompletna lub ma niewłaściwą kolejność odczytu.

W dokumentach wielokolumnowych, zestawieniach i formularzach znaczenie wynika również z położenia elementów. Zamiana strony na ciąg tekstu może oddzielić kwotę od nagłówka kolumny, przypis od właściwego zapisu albo zaznaczone pole od jego etykiety. Dane ustrukturyzowane, na przykład CSV lub JSON, ułatwiają jednoznaczne przypisanie wartości do pól, ale nadal wymagają sprawdzenia schematu, jednostek i sposobu zapisu liczb. Format wejściowy należy dobierać do informacji, którą trzeba zachować, nie wyłącznie do wygody integracji.

Jakość OCR i granice interpretacji

Niska rozdzielczość, przekrzywione strony, odblaski, słaby kontrast i pismo odręczne zwiększają ryzyko błędów odczytu. Szczególnie istotne są pomyłki dotyczące cyfr, separatorów dziesiętnych, znaków minus oraz podobnych znaków, takich jak „0” i „O”. Błąd niemal niewidoczny w zwykłym akapicie może zmienić numer rachunku, termin płatności lub wartość zobowiązania.

Trzeba też oddzielić odczyt od interpretacji. Puste pole nie musi oznaczać zera, data wystawienia nie jest datą obowiązywania, a kwota w sąsiedniej kolumnie niekoniecznie dotyczy analizowanej pozycji. Agent nie powinien uzupełniać nieczytelnych fragmentów na podstawie tego, co wydaje się najbardziej prawdopodobne. W takich przypadkach poprawnym wynikiem jest oznaczenie braku danych lub niepewności, a nie pozornie kompletna odpowiedź.

Weryfikacja musi wracać do źródła

Zgodność odpowiedzi kilku agentów nie stanowi niezależnego potwierdzenia, jeśli wszyscy korzystają z tego samego błędnego odczytu. Weryfikację trzeba oprzeć na oryginalnym dokumencie, a nie wyłącznie na streszczeniu lub danych przekazanych przez poprzedniego agenta. W praktyce warto przyjąć cztery zasady:

• Zachowywać powiązanie wyodrębnionej informacji ze stroną, fragmentem tekstu lub obszarem obrazu, z którego pochodzi.
• Sprawdzać krytyczne wartości przez porównanie ze źródłem oraz, tam gdzie to możliwe, kontrolę formatu i zależności rachunkowych.
• Odróżniać treści odczytane wprost od wniosków, przeliczeń i informacji nieustalonych.
• Wymagać kontroli człowieka przy nieczytelnych danych, sprzecznościach oraz wynikach mogących wywołać istotne skutki prawne lub finansowe.

Weryfikacja powinna być obowiązkowym warunkiem uznania wyniku za gotowy do użycia. Jeżeli kluczowej informacji nie da się potwierdzić, system powinien zwrócić wynik niekompletny z jasno wskazanym ograniczeniem, zamiast przekazywać domysł do dalszego działania. W Cognity łączymy teorię z praktyką — dlatego zagadnienia weryfikacji wyników rozwijamy także w formie ćwiczeń na szkoleniach.

AI a Six Sigma – jak sztuczna inteligencja wspiera doskonalenie procesów? 20 października 2026

DOE krok po kroku – jak zaplanować i przeprowadzić eksperyment? 18 października 2026