Powtarzające się pętle wywołań narzędzi występują, gdy agent nie potrafi rozpoznać postępu, niepowodzenia ani zakończenia i dlatego wciąż wybiera tę samą akcję.
Agent hostowany samodzielnie może wielokrotnie przeszukiwać ten sam folder, ponownie uruchamiać jedno polecenie, otwierać ten sam plik albo wysyłać identyczne żądanie API, mimo że wynik nie może się zmienić. Widoczna pętla jest tylko objawem. Jej źródło może znajdować się w planie modelu, schemacie narzędzia, zwróconej obserwacji, zapisanym stanie agenta, zewnętrznym mechanizmie ponawiania lub brakującej regule zakończenia. Rozróżnienie tych warstw ma znaczenie, ponieważ większe okno kontekstu lub wyższy limit tur może wydłużyć pętlę, nie wyjaśniając jej przyczyny.
Sygnaturą pętli jest powtarzająca się akcja bez nowego stanu
Agent może prawidłowo wywołać to samo narzędzie kilka razy z innymi argumentami lub po otrzymaniu nowych dowodów. Patologiczna pętla powtarza równoważne wywołanie, gdy stan zadania, dostępne dowody i przewidywany następny krok pozostają zasadniczo niezmienione.
LangGraph opisuje limit rekurencji grafu dla procesów wykonujących zbyt wiele kroków przed osiągnięciem warunku zatrzymania, w tym dla grafów z niezamierzonymi cyklami.
Nie chodzi o samą liczbę wywołań. Rozstrzygające jest to, czy każde wywołanie tworzy nowy fakt, zmienia zasób, zawęża plan lub przybliża graf do stanu końcowego.
Niejednoznaczne wyniki narzędzi pozostawiają agenta bez pewności, czy cokolwiek się wydarzyło
Narzędzie może zwrócić pusty ciąg, ogólny komunikat o powodzeniu, częściowy ładunek danych, nieaktualną wartość z pamięci podręcznej albo czytelny dla człowieka błąd, który nie wskazuje jednoznacznie powodzenia, możliwości ponowienia ani trwałego niepowodzenia.
Model Context Protocol rozróżnia błędy wykonania narzędzi, umieszczając jawny stan błędu w wyniku narzędzia. Gdy środowisko wykonawcze spłaszcza każdy wynik do zwykłego tekstu, model musi odgadnąć, czy kolejne wywołanie może pomóc.
Pętla wywołana w ten sposób zwykle przejawia się tym samym narzędziem i argumentami po obserwacji, która nie zawiera trwałego znacznika zakończenia. Narzędzie może działać poprawnie, ale jego kontrakt odpowiedzi pozostaje zbyt niejasny, aby agent mógł zaktualizować plan.
Zapis stanu może zakończyć się powodzeniem poza agentem, ale nie w jego pamięci
Plik może zostać utworzony, wiersz w bazie danych zaktualizowany lub usługa zrestartowana, podczas gdy zapisany stan agenta nadal wskazuje, że akcja oczekuje na wykonanie. Następna tura rozumowania powtarza więc zakończoną operację.
Agenci w stylu ReAct przeplatają rozumowanie, działanie i obserwację, tak aby obserwacje aktualizowały plan działania. Jeśli obserwacja zostanie pominięta, przypisana do niewłaściwego identyfikatora wywołania narzędzia, ucięta lub wykluczona z następnego promptu, pętla sterująca traci dowody potrzebne do dalszego działania.
To źródło można odróżnić od dezorientacji modelu, ponieważ system zewnętrzny pokazuje postęp, a ślad przedstawiony modelowi — nie. Ponowne odtworzenie wyłącznie tury modelu z prawidłową obserwacją często prowadzi do innej następnej akcji.
Warstwy ponawiania mogą zamienić jedną awarię w kilka identycznych wywołań
Model może zażądać jednego wywołania narzędzia, podczas gdy framework orkiestracji, klient HTTP, pracownik kolejki lub moduł uruchamiający zadania ponowi je kilka razy. Końcowy ślad może wyglądać jak niezdecydowanie agenta, nawet jeśli powtórzenia nastąpiły poniżej warstwy modelu.
Mechanizmy ponawiania Tenacity oddzielają decyzję o ponowieniu od warunków zatrzymania i predykatów ponawiania. Zbyt szeroka reguła ponawiania może powtarzać deterministyczne błędy walidacji, odmowy uprawnień lub nieprawidłowe argumenty, które nie mogą zakończyć się powodzeniem bez zmiany danych wejściowych.
Sprawdź identyczne identyfikatory żądań, znaczniki czasu, klasy wyjątków i liczbę tur modelu. Kilka wykonań w ramach jednej tury agenta wskazuje na ponawianie przez środowisko wykonawcze; jedno wykonanie na każdą nową turę rozumowania kieruje uwagę z powrotem na planowanie agenta lub interpretację stanu.
Słabe kryteria zakończenia wciąż przekazują sterowanie routerowi narzędzi
Agent może wykonać żądany efekt uboczny, ale nie mieć maszynowo odczytywanego warunku oznaczającego zakończenie całego zadania. Router widzi kolejną wiadomość modelu obsługującego narzędzia i ponownie przekazuje sterowanie do węzła akcji.
OpenAI Agents SDK udostępnia granicę maksymalnej liczby tur, która zgłasza wyjątek, gdy przebieg przekroczy skonfigurowaną liczbę tur.
Limit tur ogranicza szkody, ale nie wskazuje przyczyny. Jeśli ślad pokazuje pomyślny wynik narzędzia, a następnie kolejne równoważne wywołanie, zwykle brakuje przejścia do stanu zakończenia, ścieżki końcowej odpowiedzi lub pola stanu faktycznie sprawdzanego przez router.
Opisy narzędzi mogą zachęcać do tego samego wyboru po każdym niepowodzeniu
Nakładające się na siebie narzędzia, niedookreślone zachowanie w przypadku błędów oraz opisy podkreślające możliwości bez ograniczeń mogą sprawić, że jedno narzędzie będzie wyglądało na optymalne w każdej turze.
CrewAI opisuje limity iteracji i ponawiania jako osobne elementy sterowania agentem, odzwierciedlając różnicę między powtarzającymi się cyklami rozumowania a ponawianymi próbami wykonania.
Ta przyczyna jest najbardziej widoczna, gdy argumenty nieznacznie się zmieniają, ale wybrane narzędzie nigdy się nie zmienia, nawet gdy obserwacja dowodzi, że nie ma ono dostępu, odpowiedniego zakresu uprawnień lub wymaganych danych. Pętla jest wtedy problemem polityki wyboru, a nie ponawianiem transportowym.
Utrata kontekstu może wymazać dowody wcześniejszego niepowodzenia wywołania
Długie ślady, duże schematy narzędzi, obszerne wyniki i limity kontekstu lokalnych modeli mogą wypchnąć wcześniejsze szczegóły błędu lub znaczniki zakończenia poza efektywny prompt.
Agent widzi wtedy pierwotne zadanie i bieżącą listę narzędzi, ale nie obserwację, która wykluczyła preferowaną akcję. Na podstawie niepełnej historii odtwarza ten sam plan i wygląda, jakby zapomniał o własnej próbie.
Artykuł ZimaSpace o agentach automatyzacji hostowanych samodzielnie wyznacza powiązaną granicę: dodanie większej liczby narzędzi zwiększa możliwości, ale niezawodna orkiestracja nadal zależy od zwartego stanu, jawnych wyników i ograniczonego wykonania.
FAQ
Czy każde powtarzające się wywołanie narzędzia jest nieskończoną pętlą?
Nie. Stronicowanie, odpytywanie, przetwarzanie porcjami i wyszukiwanie iteracyjne mogą prawidłowo wykorzystywać to samo narzędzie. Kluczowe jest to, czy między wywołaniami zmieniają się argumenty, dowody lub stan zadania.
Czy zwiększenie maksymalnej liczby tur rozwiązuje problem?
Nie. Może pozwolić na ukończenie prawidłowego, długiego procesu, ale daje też pętli bez postępu więcej czasu na powtarzanie. Ślad nadal wymaga możliwego do zweryfikowania warunku postępu lub zakończenia.
Czy silniejszy model może wyeliminować pętle wywołań narzędzi?
Może lepiej interpretować niejednoznaczne obserwacje, ale nie odzyska stanu, który nigdy nie został zwrócony, nie rozróżni ukrytych ponowień środowiska wykonawczego ani nie wyegzekwuje warunku zatrzymania nieobecnego w procesie.
Centrum Technologii i Sztucznej Inteligencji
Więcej do przeczytania

Co powoduje, że agent AI do planowania powtarza już wykonane kroki?
Śledź powtarzające się kroki planera, analizując trwałość stanu, dowody ukończenia, analizę wyników narzędzi, zachowanie kontekstu, ponowne próby, przeplanowywanie i warunki zatrzymania.

Co powoduje błędy uprawnień występujące wyłącznie w podprocesach agentów AI?
Porównaj tożsamość procesu nadrzędnego i podrzędnego, widok systemu plików, środowisko, uprawnienia, zasady bezpieczeństwa oraz ścieżkę pliku wykonywalnego, aby zdiagnozować odmowę występującą wyłącznie w podprocesie.

Co powoduje przeciążenie procesora, gdy sprzętowe transkodowanie i sztuczna inteligencja wideo działają jednocześnie?
Śledź wysycenie procesora w zakresie odciążania kodeków, konwersji pikseli, kopiowania klatek, wstępnego przetwarzania AI, dźwięku, napisów, pamięci masowej i planowania procesów.

