Orkiestracja agentów AI: awarie, zatwierdzenia i ponowienia

Kilku agentów pracujących nad tym samym projektem brzmi niezwykle wydajnie. Jeden planuje pracę, drugi zajmuje się projektem graficznym, a trzeci pisze kod. Działa to do czasu, aż przestaje działać. A awarie zdarzają się częściej, niż byśmy chcieli.

Zapobieganie takim awariom wymaga starannego projektowania przepływów pracy. Przyjrzyjmy się więc, co sprawia, że orkiestrowane przepływy pracy są zawodne, i poznajmy najlepsze praktyki orkiestracji zapewniające niezawodność w środowisku produkcyjnym.

Orkiestracja agentów AI koordynuje pracę wielu agentów AI, modeli i narzędzi w celu wykonania wieloetapowego zadania. Ale ktoś — lub coś — wciąż musi zdecydować, który agent zostanie uruchomiony jako pierwszy, jakie informacje otrzyma i co stanie się po zakończeniu jego pracy. Taką rolę pełni orkiestrator — agent AI działający jako menedżer lub sterowana programowo warstwa wykonawcza.

Mówiąc najprościej, warstwa orkiestracji dzieli cel na mniejsze zadania, śledzi zależności, deleguje wykonanie do odpowiednich agentów, zarządza współdzielonym kontekstem i scala wyniki.

Diagram silnika wykonawczego orkiestracji: cel i plan, kierowanie do agentów, izolowane wykonywanie narzędzi, ustrukturyzowane wyniki, trwały stan przepływu pracy oraz etap weryfikacji i decyzji, który ponawia próbę, cofa, wstrzymuje, czeka lub przechodzi do następnego zadania.

Przyjrzyjmy się, co się dzieje po przekazaniu zadania orkiestratorowi.

Weźmy przykład z warsztatów Perplexity dotyczących Computer: tworzenie pulpitu z analizą kont klientów na podstawie informacji z Salesforce, Snowflake, poczty e-mail, kalendarza i najnowszych wiadomości.

Zrozum cel i zaplanuj pracę. Orkiestrator zaczyna od oczekiwanego rezultatu i rozkłada go na zadania z jawnie określonymi zależnościami. W naszym przykładzie z pulpitem oznacza to zebranie informacji z różnych źródeł i przekształcenie ich w gotowy produkt. Planista ustala, które kroki zależą od innych, a które mogą być wykonywane niezależnie.
Kieruj zadania do odpowiednich agentów. Orkiestrator identyfikuje zadania, których zależności zostały spełnione, i deleguje pracę do wyspecjalizowanych agentów lub modeli. Zadania zależne czekają na spełnienie warunków wstępnych. Perplexity Computer korzysta z wielu czołowych modeli, kierując różne części przepływu pracy do systemów najlepiej dopasowanych do tych zadań. Pozwala to również na równoległe wykonywanie niezależnej pracy.
Wykonuj wywołania narzędzi w kontrolowanych środowiskach. Agenci wchodzą w interakcję ze swoim środowiskiem za pomocą narzędzi, takich jak wyszukiwanie w sieci, interfejsy API, połączone aplikacje, operacje na plikach czy wykonywanie kodu. Warstwa wykonawcza uruchamia te działania i zwraca wyniki agentom.
Przekazuj wyniki i kontekst między agentami. Gdy agent zakończy swoje zadanie, kolejny agent w łańcuchu potrzebuje odpowiednich danych wyjściowych, aby kontynuować. Rekord przekazania może zawierać identyfikator zadania, odwołanie do danych wyjściowych, wersję schematu i metadane źródła. Orkiestrator koordynuje te przekazania, zachowując kontekst potrzebny w kolejnych krokach. Co ważne, agenci nie muszą przechowywać w swoich oknach kontekstowych całej historii pracy wszystkich pozostałych agentów.
Zapisuj stan wykonania oddzielnie od kontekstu agentów. Gdy agenci rozpoczynają zadania, kończą je lub ponoszą w nich niepowodzenie, silnik wykonawczy aktualizuje trwały rekord przepływu pracy, zapisując w nim statusy zadań, próby wykonania, odwołania do danych wyjściowych i pozostałą pracę. Dzięki temu rekordowi orkiestrator może śledzić postęp i wznawiać działanie po przerwach bez polegania na modelu LLM, który musiałby odtwarzać przepływ pracy z historii rozmowy.
Weryfikuj wyniki i decyduj o kolejnych krokach. Gdy zadanie zwraca wynik, warstwa orkiestracji sprawdza, czy dane wyjściowe spełniają oczekiwany kontrakt i czy zależności następnego zadania zostały spełnione. Jeśli wykryje problem, przepływ pracy może wrócić do wcześniejszego kroku w celu korekty lub zostać wstrzymany. W przeciwnym razie przechodzi dalej, aż do ukończenia.

Za pozornie prostą orkiestracją agentów AI kryje się wiele ruchomych elementów. To, jak zorganizujesz koordynację agentów, decyduje o tym, jaką kontrolę masz nad wykonaniem. Oczywiście cała ta koordynacja generuje dodatkowy narzut. Dlatego nie zawsze się opłaca.

Rozważ orkiestrację wielu agentów, gdy różne części zadania wymagają odmiennej wiedzy specjalistycznej, niezależne prace mogą być wykonywane równolegle lub nie da się z góry określić kolejnego kroku.

Orkiestracja przydaje się zatem w trzech scenariuszach:

Zadania wymagają różnych specjalizacji. Na przykład w projekcie programistycznym mogą się przydać osobni agenci do planowania, projektowania, programowania i przeglądu.
Niezależne zadania mogą być wykonywane równolegle. Zamiast jednego agenta, który wykonuje wszystko po kolei, wielu agentów może pracować jednocześnie i zwracać wyniki orkiestratorowi.
Problem ma otwarty charakter. Agenci mogą potrzebować badać różne podejścia, podejmować decyzje i współpracować, zamiast realizować z góry określoną sekwencję.

Poza tymi przypadkami orkiestracja to po prostu kosztowny trend. Więcej agentów oznacza też więcej koordynacji i potencjalnie wyższe koszty tokenów.

„Zazwyczaj zaczynam od najprostszej opcji i stopniowo ją rozbudowuję. Jeśli znamy kroki i są one powtarzalne, to prawdopodobnie jest to przepływ pracy. Powód do wprowadzenia wielu agentów widzę tylko wtedy, gdy mają różne obowiązki, uprawnienia lub użytkowników” — mówi Josh Spilker, szef marketingu w wyszukiwarkach w AirOps.

Nawet wtedy porównaj korzyści z kosztami: dodatkowymi wywołaniami modeli, przekazaniami, opóźnieniami i potencjalnymi punktami awarii.

Istnieją trzy popularne sposoby organizowania koordynacji agentów — orkiestracja scentralizowana, zdecentralizowana i hierarchiczna. Wybór właściwej architektury sprowadza się do jednego pytania: Kto kontroluje pracę i jak agenci koordynują między sobą działania?

W orkiestracji scentralizowanej procesem zarządza jeden orkiestrator. Dzieli zadanie na części, deleguje pracę do wyspecjalizowanych agentów, śledzi ich postępy i scala ich wyniki.

Diagram orkiestracji scentralizowanej: jeden orkiestrator odbiera żądanie użytkownika i deleguje zadania do agentów badawczego, analitycznego i projektowego, z których każdy korzysta z własnych narzędzi, a ich wyniki łączą się w końcowy pulpit.

Kompromis: Scentralizowana koordynacja ułatwia śledzenie wykonania i stosowanie wspólnych reguł w jednym punkcie kontroli. Orkiestrator może jednak stać się wąskim gardłem, a jego awaria może przerwać cały przepływ pracy, jeśli system nie obsługuje odzyskiwania.

W orkiestracji zdecentralizowanej agenci koordynują działania bardziej bezpośrednio, zamiast polegać na jednym menedżerze, który podejmuje każdą decyzję. Mogą wymieniać wiadomości, odczytywać współdzielony stan i samodzielnie określać kolejne kroki.

Diagram zdecentralizowanej orkiestracji: agenci odpowiedzialni za badania, analizę, projektowanie i przegląd komunikują się bezpośrednio ze sobą oraz ze współdzielonym stanem i narzędziami, aby utworzyć końcowy pulpit nawigacyjny.

Kompromis: Agenci mogą działać bez czekania na centralnego planistę, dzięki czemu to podejście sprawdza się w pracy eksploracyjnej i przy niezależnym wkładzie. Koordynacja staje się jednak trudniejsza, gdy agenci się nie zgadzają, aktualizują współdzielone informacje lub muszą osiągnąć spójny wynik.

Orkiestracja hierarchiczna rozszerza podejście menedżerskie na wiele poziomów. Orkiestrator najwyższego poziomu deleguje odpowiedzialność na podrzędne orkiestratory, które koordynują własne grupy wyspecjalizowanych agentów.

Wyobraź sobie przepływ pracy w przedsiębiorstwie, w który zaangażowane są zespoły sprzedażowe, finansowe i prawne. Orkiestrator najwyższego poziomu mógłby delegować każdy strumień prac do koordynatora wyspecjalizowanego w danej dziedzinie. Ci koordynatorzy zarządzaliby następnie własnymi agentami specjalistycznymi i przekazywali zbiorcze wyniki.

Taka struktura może pomóc, gdy przepływy pracy są zbyt rozległe, by jeden orkiestrator mógł skutecznie nimi zarządzać.

Diagram orkiestracji hierarchicznej: orkiestrator najwyższego poziomu deleguje zadania do orkiestratorów ds. sprzedaży, finansów i kwestii prawnych, z których każdy zarządza dwoma wyspecjalizowanymi agentami, a ich praca łączy się w zbiorczy wynik.

Kompromis: Hierarchie pozwalają zespołom podzielić obowiązki koordynacyjne i potencjalnie obsługiwać awarie w obrębie poszczególnych gałęzi. Wprowadzają jednak dodatkowe przekazania, bardziej złożone zarządzanie stanem i większy narzut operacyjny. Lokalne odzyskiwanie zależy również od sposobu implementacji punktów kontrolnych i stanu wykonania.

Porównanie tych architektur:

Kryteria	Scentralizowana	Zdecentralizowana	Hierarchiczna
Odpowiedzialność za wykonanie	Jeden orkiestrator kontroluje delegowanie	Agenci koordynują działania bezpośrednio między sobą lub poprzez współdzielony stan	Odpowiedzialność jest rozłożona na poziomy orkiestracji
Spójność stanu	Łatwiejsza koordynacja dzięki jednemu punktowi kontroli	Wymaga jawnej synchronizacji i obsługi konfliktów	Wymaga koordynacji w obrębie gałęzi i między nimi
Izolacja awarii	Centralny kontroler może stać się krytyczną zależnością	Poszczególni agenci mogą ulegać awariom niezależnie, ale współdzielona infrastruktura pozostaje krytyczna	Awarie mogą zostać ograniczone do gałęzi, jeśli system zaprojektowano z myślą o odzyskiwaniu
Egzekwowanie zasad	Wspólne mechanizmy kontroli można egzekwować centralnie	Zasady muszą być egzekwowane spójnie u wszystkich uczestników	Mechanizmy kontroli można stosować na poziomie globalnym i na poziomie domen
Złożoność operacyjna	Zwykle niższa	Wyższa złożoność koordynacji	Wyższa złożoność wynikająca z wielu warstw orkiestracji

Warto zrozumieć jeszcze jedno rozróżnienie. Architektura określa, kto koordynuje agentów. Wzorzec wykonania określa, jak postępują ich zadania.

Oto trzy wzorce wykonania:

Sekwencyjne przepływy pracy: agenci działają w z góry ustalonej kolejności, a wynik jednego agenta staje się danymi wejściowymi dla kolejnego.
Wykonanie równoległe: niezależni agenci pracują jednocześnie.
Wykonanie oparte na przekazywaniu: kontrola przechodzi między wyspecjalizowanymi agentami w miarę postępu zadania. Przydaje się to, gdy inny agent jest lepiej przygotowany do wykonania kolejnego kroku, choć każde przekazanie musi zachować informacje potrzebne do kontynuacji.

Te wzorce nie wykluczają się wzajemnie i nie odpowiadają jeden do jednego architekturom orkiestracji. Celem jest wybór najprostszej struktury, która uwzględnia zależności w przepływie pracy, wymagania dotyczące koordynacji i akceptowalny narzut operacyjny.

W orkiestracji wszystko może pójść nie tak — od prostych przeoczeń po złożone blokady. Czasem agent może nawet sprawiać wrażenie, że poprawnie wykonuje swoje zadanie, podczas gdy cały przepływ pracy kończy się niepowodzeniem. Na podstawie doświadczeń praktyków zebraliśmy najczęstsze błędy, które sprawiają, że orkiestrowane przepływy pracy są zawodne — warto mieć je na uwadze:

Stratne przekazania między agentami. Orkiestrator przekazuje wyspecjalizowanemu agentowi streszczony plan, ale w streszczeniu brakuje ograniczeń, zależności lub szczegółów implementacji.
Przedwczesne scalanie wyników (fan-in). Agent na dalszym etapie zaczyna agregować wyniki, zanim zakończą się wszystkie zadania na wcześniejszych etapach.
Niedeterministyczne aktualizacje współdzielonego stanu. Równolegle działający agenci zapisują dane pod tymi samymi kluczami stanu bez jasno zdefiniowanej semantyki scalania. W zależności od tego, jak framework obsługuje aktualizacje, może to prowadzić do utraty zapisów, duplikacji danych, wyników zależnych od kolejności lub sprzecznych zmian.
Rozbieżność między punktem kontrolnym a efektami ubocznymi. Zadanie wykonuje operację zewnętrzną, ale jej pomyślne wykonanie nie zostaje trwale zapisane przed awarią procesu roboczego. Podczas odzyskiwania orkiestrator widzi niedokończone zadanie i uruchamia je ponownie.
Wyścigi przy wznawianiu po zatwierdzeniu przez człowieka. Wstrzymywanie i wznawianie wykonania wprowadza własne problemy z synchronizacją.
Pętle delegowania i lawinowe ponawianie prób. Agenci wielokrotnie przekazują sobie nawzajem pracę, ponieważ ich obowiązki się pokrywają, zależności są cykliczne lub warunki ukończenia są niejednoznaczne.
Mylenie kontroli na poziomie instrukcji z bezpieczeństwem wykonania. Orkiestrator może polecić agentom, aby nie uzyskiwali dostępu do określonych zasobów ani nie wykonywali wrażliwych działań, ale instrukcje dla modelu nie wymuszają uprawnień systemu operacyjnego, ograniczeń sieciowych ani granic autoryzacji. Perplexity w swoich badaniach z zakresu inżynierii bezpieczeństwa wyjaśnia, dlaczego agenci mogą przekraczać granice bezpieczeństwa, dążąc do uzasadnionych celów, nawet bez złośliwych instrukcji

Zwróć uwagę, jak bardzo różnią się te błędy. Przedwczesne przejście stanu w harmonogramie czy niejednoznaczny zapis zewnętrzny mogą prowadzić do nieprawidłowego wyniku, ale mają źródło w różnych częściach cyklu życia wykonania. Dlatego niezawodna orkiestracja wymaga czegoś więcej niż ulepszania promptów czy dodawania ponownych prób.

Niejasne cele i niesprecyzowana definicja ukończenia często prowadzą do rozczarowujących wyników generowanych przez agentów. Rozwiązaniem jest kontrakt promptu (zakres prac dla agenta): uzgodnij cel, ograniczenia, format wyników i warunki niepowodzenia przed rozpoczęciem wykonania.

Oto przykład, jak można zdefiniować kontrakt dla agenta odpowiedzialnego za naprawę sporadycznie niezaliczanego testu integracyjnego:

Cel: zidentyfikuj i usuń przyczynę niestabilnego testu integracyjnego API finalizacji zamówienia.
Dane wejściowe: kod źródłowy testu, logi błędów CI, ostatnie commity i odpowiedni kod aplikacji.
Ograniczenia: nie wyłączaj testów, nie osłabiaj asercji ani nie zmieniaj niepowiązanych zachowań aplikacji.
Oczekiwany wynik: poprawka kodu, wyjaśnienie głównej przyczyny i wyniki wykonania testów.
Kryteria akceptacji: test, który wcześniej kończył się niepowodzeniem, przechodzi w 10 kolejnych uruchomieniach, a odpowiedni zestaw testów regresyjnych również przechodzi.
Warunki niepowodzenia: nie można ustalić głównej przyczyny, poprawka wprowadza regresje lub wymagane środowisko testowe jest niedostępne.

Jest jednak jeszcze jedna ważna kwestia: kiedy agent powinien się zatrzymać?

Agent nie powinien w nieskończoność kontynuować iteracji tylko dlatego, że nie uzyskał zadowalającego wyniku. Określ, co oznacza pomyślne ukończenie, kiedy zwrócić częściowo ukończone zadanie, a kiedy się zatrzymać, ponieważ wymagania nie da się spełnić. Ustaw maksymalną głębokość delegowania i limity iteracji lub budżety wykonania, aby nierozwiązane zadania nie zamieniały się w niekończące się pętle.

Wróćmy do naszego przykładu z CI. Można zdefiniować następujące warunki zatrzymania:

Sukces: poprawka przechodzi 10 kolejnych uruchomień testu oraz odpowiedni zestaw testów regresyjnych.
Limit iteracji: agent może wypróbować nie więcej niż dwie potencjalne poprawki.
Budżet wykonania: agent musi się zatrzymać po 60 minutach, nawet jeśli problem pozostaje nierozwiązany.
Limit delegowania: agent może delegować pracę jednemu wyspecjalizowanemu agentowi, bez dalszego delegowania do subagentów.
Częściowe ukończenie: jeśli obie próby się nie powiodą lub upłynie limit czasu, agent zwraca swoje ustalenia, wypróbowane zmiany i wyniki testów.
Zablokowane wykonanie: jeśli środowisko testowe jest niedostępne, agent zatrzymuje się i zgłasza przeszkodę, zamiast deklarować sukces.

Czasem programiści nakładają na orkiestrator zbyt wiele obowiązków i zamiast koordynować wyspecjalizowanych agentów, zaczyna on sam pisać kod, debugować lub przeprowadzać szczegółowe przeglądy. Tworzy to wąskie gardło: orkiestrator zużywa swój budżet kontekstu na szczegóły implementacji, opóźnia delegowanie i rozmywa odpowiedzialność za wyniki.

Pozwól więc orkiestratorom robić swoje i wymuszaj przekazania oparte na konkretnych artefaktach: pierwotnym zadaniu, odpowiednich danych wejściowych, artefaktach wyjściowych, stanie wykonania i wszelkich nierozwiązanych problemach.

Weźmy taki przykład: status: completed odnosi się do pracy przydzielonej agentowi, a nie do całego przepływu pracy. Ponieważ testy mają nadal status pending, orkiestrator nie powinien zatwierdzać końcowego wyniku.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

Historia rozmowy agenta nie jest wiarygodnym zapisem postępu przepływu pracy. Gdy okno kontekstu się zapełni, automatyczne kompaktowanie może pominąć ważne szczegóły. A jeśli proces roboczy ulegnie awarii, kolejny agent musi wiedzieć, które kroki zostały faktycznie ukończone.

Na przykład jeśli agent programistyczny wygeneruje poprawkę, a następnie ulegnie awarii, kolejny proces roboczy powinien pobrać zapisany artefakt i kontynuować od zarejestrowanego stanu przepływu pracy. Jeśli jednak agent uruchomił również zewnętrzny przebieg CI, orkiestrator musi osobno ustalić stan tego przebiegu przed powtórzeniem działania

Dlatego oddziel stan wykonania od kontekstu roboczego agenta. Zapisuj statusy zadań, próby wykonania, ukończone kroki i odwołania do artefaktów w trwałym magazynie. Jednocześnie ładuj tylko instrukcje, dane wejściowe i wyniki istotne dla bieżącego zadania agenta, zamiast upychać całą historię wykonania w jego oknie kontekstu.

Załóżmy, że Twój agent CI uruchamia przebieg testów, ale żądanie API przekracza limit czasu. Czy przebieg testów się nie rozpoczął, czy też usługa CI umieściła go w kolejce i utraciła odpowiedź?

Przekroczenie limitu czasu nie musi oznaczać, że operacja się nie powiodła. Dlatego przed podjęciem decyzji o dalszych krokach trzeba rozróżnić rodzaje błędów:

Błędy przejściowe (429, 503): ponawiaj próby z ograniczonym wykładniczym wycofywaniem (exponential backoff) i losowym opóźnieniem (jitter), uwzględniając nagłówek Retry-After, jeśli jest dostępny.
Błędy walidacji lub uprawnień (400, 403): zatrzymaj się lub usuń przyczynę problemu, zamiast powtarzać to samo żądanie.
Niejednoznaczne wyniki (przekroczenie limitu czasu po możliwym zapisie): przed ponowną próbą sprawdź, czy operacja się powiodła.

Uwaga: nawet błędy, przy których można ponowić próbę, wymagają limitów. Ustaw limit czasu dla każdego wywołania narzędzia, ogranicz liczbę ponownych prób i ich łączny czas oraz wymuś ogólny termin dla całego przepływu pracy, aby zagnieżdżeni agenci nie mogli w kółko ponownie uruchamiać tej samej operacji. Jeśli zależność wielokrotnie zawodzi, użyj wyłącznika (circuit breaker), aby tymczasowo wstrzymać żądania.

W przypadku operacji z zewnętrznymi efektami ubocznymi przypisz każdemu logicznemu działaniu stały klucz idempotencji i używaj go ponownie przy kolejnych próbach. Jeśli API obsługuje deduplikację po stronie serwera, może rozpoznać powtórzone żądania bez dwukrotnego wykonywania działania. Jeśli nie, wyślij zapytanie do systemu zewnętrznego, używając identyfikatora korelacji lub innego wiarygodnego odniesienia.

Jeśli nie da się ustalić, co się stało, zatrzymaj się i eskaluj problem.

Przykład logiki ponawiania prób dla naszego agenta CI w postaci pseudokodu:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

Uwaga do kodu: Przykład zakłada, że API CI obsługuje wyszukiwanie przebiegów według identyfikatora żądania. Wartość request_id zapobiega duplikatom tylko wtedy, gdy dostawca wyraźnie gwarantuje idempotencję. bounded_retry() to poglądowy pseudokod. W środowisku produkcyjnym ponowne próby powinny być ograniczone zarówno budżetem ponownych prób dla każdej operacji (maksymalną liczbą prób lub czasem, który upłynął), jak i ogólnym terminem przepływu pracy.

W przypadku dłuższych przepływów pracy obejmujących wiele usług rozważ użycie wzorca Saga do koordynowania działań kompensacyjnych, gdy późniejsze kroki zakończą się niepowodzeniem. Pamiętaj jednak, że kompensacja nie zawsze oznacza pełne wycofanie zmian. Można cofnąć aktualizację bazy danych, ale nie da się cofnąć wysłania e-maila.

Trzeba tu wyważyć dwie rzeczy: ile możliwości modelu potrzebuje każde zadanie i ile zadań można uruchomić jednocześnie. Jeśli źle ocenisz którąkolwiek z nich, ryzykujesz, że agenci będą rywalizować o współdzielone limity API albo będą polegać wyłącznie na drogich modelach rozumujących.

W przypadku wyboru modelu dopasuj możliwości modelu i intensywność rozumowania do złożoności zadania — to proste, a często pomijane. Pamiętaj, że możesz samodzielnie skonfigurować reguły routingu i oceniać modele albo skorzystać z platformy orkiestracji, która wybiera model za Ciebie.

Na przykład Effort Mode w Perplexity Computer pozwala określić, ile wysiłku warto poświęcić na zadanie, bez ręcznego wybierania modelu. Wybierz Light, Standard, High lub Ultra, a Perplexity automatycznie dobierze model orkiestrujący i jego poziom rozumowania. Następnie ten orkiestrator deleguje podzadania agentom pomocniczym, którzy mogą korzystać z modeli różnych dostawców.

Perplexity ocenia konfiguracje modeli pod kątem jakości i kosztów, preferując tańsze opcje, które zapewniają porównywalne wyniki. Jeśli wolisz samodzielnie wybrać model i poziom rozumowania, możesz też skorzystać z ustawień Custom.

W przypadku równoległości limit powinien wynikać z infrastruktury i zależności zewnętrznych. Sprawdź limity liczby żądań i tokenów we współdzielonych API, a następnie przeprowadź testy obciążeniowe przepływu pracy przy rosnącej współbieżności. Obserwuj, czy przepustowość rośnie, czy też żądania zaczynają trafiać do kolejki, zwalniać lub zwracać błędy 429.

Aby zużycie zasobów było przewidywalne, wymuszaj limity zasobów i mechanizmy kontroli harmonogramu:

Kontroluj współbieżność i częstotliwość żądań: ogranicz liczbę równoczesnych wywołań dla każdej usługi i kolejkuj nadmiarową pracę. Pamiętaj, że sam limit współbieżności nie wymusi limitów żądań na minutę ani tokenów na minutę.
Śledź budżety tokenów i kosztów: uwzględniaj zużycie w całym przepływie pracy, w tym przez subagentów, i przestań uruchamiać nowe zadania, gdy pozostały budżet jest niewystarczający.
Wymuszaj terminy wykonania: ustaw limity czasu dla zadań i przepływów pracy oraz przekazuj anulowanie do działających agentów, jeśli jest to obsługiwane.
Respektuj zależności: uruchamiaj zadania na dalszych etapach dopiero wtedy, gdy wymagane dane wejściowe są dostępne, zamiast uruchamiać wszystkich agentów jednocześnie.

Nigdy nie proś modelu o rozstrzygnięcie, czy jego własne działania są bezpieczne. Zamiast tego nadaj agentom uprawnienia zgodne z zasadą najmniejszych uprawnień i wymuszaj reguły zatwierdzania oparte na ryzyku w kodzie aplikacji. Jeśli agenci wykonują kod, odizoluj to wykonanie od środowiska hosta i ogranicz dostęp do plików, sieci i danych uwierzytelniających. Ogranicza to szkody, jeśli agent popełni błąd lub wykona niebezpieczny kod.

„Jestem sceptyczny wobec nadmiernie skomplikowanych systemów wieloagentowych, zwłaszcza gdy agenci przeglądają i zatwierdzają nawzajem swoją pracę. Może się skończyć tak, że kilku agentów z pełnym przekonaniem przekazuje dalej ten sam błąd, a nikt go faktycznie nie wychwytuje” — przestrzega Spilker.

Diagram przepływu zatwierdzania: agent proponuje operację wraz z parametrami, zasobem docelowym i wersją stanu; człowiek ją zatwierdza lub odrzuca; zatwierdzone operacje są ponownie weryfikowane i uruchamiane w odizolowanym środowisku z ograniczonym dostępem do plików, sieci i danych uwierzytelniających. Odrzucone lub wygasłe żądania są zamykane, a zmienione żądania wymagają nowego zatwierdzenia.

W przypadku działań wymagających zatwierdzenia przez człowieka wstrzymaj wykonanie i zapisz dokładną proponowaną operację:

jej parametry
jej zasób docelowy
jej commit lub wersję stanu
decyzję recenzenta

Określ też, co się stanie, jeśli zatwierdzenie zostanie odrzucone, wygaśnie lub będzie wymagało eskalacji. Ma to kluczowe znaczenie w przypadku frameworków umożliwiających wznawianie, ponieważ wznowienie przerwanego węzła powoduje ponowne wykonanie kodu od początku tego węzła. Wszelkie efekty uboczne sprzed przerwania mogą zostać wykonane ponownie.

Jeśli więc zatwierdzenie zostanie odrzucone lub wygaśnie, żądanie jest zamykane. Jeśli docelowy commit, parametry lub uprawnienia zmienią się przed wykonaniem, unieważnij zatwierdzenie i poproś o nowe.

Spilker nie popiera też idei w pełni autonomicznych agentów realizujących zadania od początku do końca, postrzeganych jako docelowe rozwiązanie. „Moim zdaniem lepszym podejściem jest zbudowanie kilku wyspecjalizowanych agentów z jasno określonymi obowiązkami, zdefiniowanymi uprawnieniami i przeglądem przez człowieka w odpowiednich momentach. Nadal zyskujesz na wydajności, nie rezygnując z pełnej kontroli” — podsumowuje.

Zdarzyło Ci się, że agent zgłaszał Success, choć w rzeczywistości mu się nie udało? To irytujące, a nawet doprowadzające do szału, a naprawa nie jest szybka, bo końcowy komunikat agenta niekoniecznie wskaże, gdzie coś poszło nie tak.

Aby to zbadać, prześledź, co działo się podczas wykonywania, i niezależnie zweryfikuj wyniki. Poświęćmy więc trochę czasu na wyizolowanie i rozwiązanie problemu.

Zanim zaczniesz debugować prompty agenta, zarejestruj całą ścieżkę wykonania. Potrzebujesz śladu (trace), który łączy wywołania agentów, wywołania narzędzi, błędy i ponowne próby w ramach tego samego przebiegu przepływu pracy.

Konwencje semantyczne GenAI standardu OpenTelemetry zapewniają ustandaryzowany sposób opisywania tych operacji. Na przykład invoke_workflow oznacza wykonanie przepływu pracy, invoke_agent — wywołanie agenta, a execute_tool — wywołanie narzędzia. Każdą operację można zarejestrować jako span wraz z czasem trwania, statusem i odpowiednimi metadanymi.

Ten krok daje ślad ścieżki wykonania, dzięki któremu możesz ustalić, w którym miejscu agent napotkał problem.

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

Przykładowy ślad wykonania.

Wszędzie, gdzie to możliwe, stosuj kontrole programowe. Weryfikuj wyniki względem schematów JSON, uruchamiaj testy jednostkowe i integracyjne, sprawdzaj, czy wymagane artefakty istnieją, i wysyłaj zapytania do systemów zewnętrznych, aby potwierdzić, że działania faktycznie się powiodły.

W przypadku wyników wymagających subiektywnej oceny — których nie da się zatem zweryfikować za pomocą kontroli programowych — wprowadź niezależnego agenta recenzującego. Jednym z podejść jest pętla implementator–recenzent–naprawiający, w której jeden agent tworzy artefakt, recenzent działający w świeżym kontekście identyfikuje problemy, a agent naprawiający je usuwa, zanim walidacja zostanie ponownie uruchomiona.

Nadal należy w miarę możliwości weryfikować ustalenia recenzenta, a jeśli do wielokrotnych ewaluacji używasz modułów oceniających opartych na LLM, kalibruj ich werdykty względem przykładów sprawdzonych przez ludzi.

Do tej pory prześledziliśmy, co wykonali agenci, i sprawdziliśmy, czy ich wyniki były poprawne. Ale co się dzieje, gdy proces roboczy ulegnie awarii w połowie zadania albo API przekroczy limit czasu po przyjęciu żądania? Co zaskakujące, Twój przepływ pracy może działać bez zarzutu w normalnych warunkach, ale zawieść podczas odzyskiwania.

Aby to sprawdzić, celowo wprowadzaj awarie w środowisku testowym:

Symuluj przekroczenia limitu czasu API
Wywołuj awarie procesów roboczych między zapisami w systemach zewnętrznych a punktami kontrolnymi
Zwracaj nieprawidłowo sformatowane wyniki narzędzi
Doprowadzaj do wygaśnięcia zatwierdzeń

Po każdym teście przeanalizuj ślad wykonania, aby sprawdzić, które kroki zostały uruchomione, w którym miejscu przepływ pracy został wznowiony oraz czy jakieś działania zostały powtórzone lub pominięte. Następnie przejrzyj rzeczywiste wyniki.

Załóżmy, że Twój agent CI wysyła żądanie uruchomienia przebiegu testów, ale odpowiedź API przekracza limit czasu. Agent ponawia próbę, otrzymuje pomyślną odpowiedź i zgłasza Success. Wszystko wygląda dobrze, dopóki nie sprawdzisz usługi CI i nie odkryjesz, że zamiast jednego przebiegu testów utworzono dwa.

Dlatego należy weryfikować zarówno zapisany stan przepływu pracy, jak i rzeczywiste zmiany w systemach zewnętrznych. Test odzyskiwania powinien zakończyć się powodzeniem tylko wtedy, gdy przepływ pracy osiągnie oczekiwany stan bez niezamierzonych skutków ubocznych.

Dodawaj wykryte błędy do testów regresyjnych, aby przyszłe zmiany nie wprowadziły ich ponownie.

Ostatecznie sukces oznacza, że przepływ pracy przeszedł wymagane kontrole, a jego zewnętrzne rezultaty zostały zweryfikowane.

Odizolowani agenci mogą poprawnie wykonywać swoje indywidualne zadania, a mimo to razem dawać niespójne wyniki. Wyobraź sobie, że agent sprzedażowy pobiera warunki klienta o 10:00, agent cenowy oblicza ofertę na podstawie zaktualizowanych cen o 10:05, a agent prawny sprawdza umowę, która zmieniła się o 10:07. Każdy agent pracuje na innej migawce stanu firmy, więc ich wyniki mogą sobie wzajemnie przeczyć.

Problem staje się wyraźniejszy w skali przedsiębiorstwa, ponieważ agenci wchodzą w interakcję z wieloma systemami, które aktualizują się niezależnie od siebie, działają z różnymi uprawnieniami i niekoniecznie współdzielą kontekst czy stan wykonania.

Ustaw limity na wielu poziomach: maksymalną liczbę ponowień wywołań narzędzi, maksymalną liczbę iteracji agenta, głębokość delegowania oraz ogólny termin dla całego przepływu pracy. Przed ponowieniem próby sklasyfikuj błędy. W przypadku przejściowych odpowiedzi 429 respektuj nagłówek Retry-After, jeśli został podany. W przeciwnym razie stosuj ograniczony wykładniczy backoff z losowym rozrzutem (jitter).

Po błędach walidacji lub uprawnień przestań ponawiać niezmienione żądania. Jeśli usługa podrzędna wielokrotnie zawodzi, wyłącznik obwodu (circuit breaker) może zapobiec generowaniu przez agentów dodatkowego obciążenia.

Mechanizm odzyskiwania zależy od używanego środowiska uruchomieniowego. W LangGraph trwały checkpointer, taki jak PostgresSaver, przechowuje stan grafu pod identyfikatorem thread_id, co pozwala kontynuować wykonanie od utrwalonego stanu. W Temporal inny proces roboczy może odbudować przepływ pracy, odtwarzając jego historię zdarzeń. Podczas odtwarzania ponownie wykorzystuje wcześniej zapisane wyniki aktywności.

Jeśli aplikacja zostanie ponownie wdrożona, gdy przepływy pracy wciąż działają, zapisany stan i historie wykonania mogą przestać być zgodne. Temporal rozwiązuje ten problem za pomocą funkcji Worker Versioning i łatania przepływów pracy (workflow patching). W systemach opartych na punktach kontrolnych zaplanuj migracje schematu i przetestuj odzyskiwanie na istniejących zapisanych stanach, zanim wdrożysz niezgodne zmiany.

Uruchamiaj te same reprezentatywne zadania wielokrotnie i odróżniaj pass@k (czy co najmniej jedna z k prób kończy się powodzeniem) od pass^k (czy każda z k prób kończy się powodzeniem)

Mierz wyniki według kategorii zadań i wersji przepływu pracy, zamiast polegać na jednym zagregowanym wskaźniku sukcesu. Śledź odsetek sukcesów przy pierwszej próbie, spójność w powtarzanych przebiegach, opóźnienie p95, koszt jednego ukończonego zadania oraz odsetek zadań wymagających interwencji człowieka. Podawaj liczebność prób i przedziały niepewności dla wskaźników sukcesu.

Czym jest orkiestracja agentów AI?

Jak działa orkiestracja agentów AI: wewnątrz silnika wykonawczego

Kiedy warto stosować orkiestrację agentów AI?

Architektury orkiestracji agentów AI i ich kompromisy

Orkiestracja scentralizowana

Orkiestracja zdecentralizowana

Orkiestracja hierarchiczna

Wykonanie sekwencyjne, równoległe i oparte na przekazywaniu

Typowe błędy w orkiestracji agentów AI

7 najlepszych praktyk orkiestracji agentów AI zapewniających niezawodność w środowisku produkcyjnym

1. Zdefiniuj jednoznaczne kontrakty zadań, kryteria akceptacji i warunki zatrzymania

2. Nie przeciążaj orkiestratorów i wymuszaj ustrukturyzowane przekazania

3. Utrwalaj stan przepływu pracy i kontroluj przyrost kontekstu

4. Projektuj ponowne próby uwzględniające rodzaj błędu i wykonywanie narzędzi z możliwością odzyskania

5. Kieruj i zrównoleglaj pracę z jawnymi budżetami zasobów

6. Wymuszaj zatwierdzenia i izoluj środowisko wykonawcze agentów

7. Niezależnie weryfikuj wyniki i testuj zachowanie podczas odzyskiwania

Prześledź przepływ pracy, aby ustalić, co poszło nie tak

Niezależnie sprawdź wyniki

Wstrzykuj awarie, aby przetestować odzyskiwanie

Orkiestracja agentów AI: najczęściej zadawane pytania

Dlaczego odizolowani agenci AI zawodzą w skali przedsiębiorstwa?

Jak zapobiegać nieskończonym pętlom ponowień w agentach AI?

Jak wznowić przepływ pracy agenta AI po awarii?

Jak testować niezawodność orkiestracji agentów AI?