Gdy autonomiczny agent bez końca odczytuje ten sam wynik zadania asynchronicznego

Agent może poprawnie korzystać z narzędzia, dostawać prawidłowe odpowiedzi i mimo to przestać wykonywać jakikolwiek postęp. Jeden z prostszych sposobów na takie utknięcie to wielokrotne odczytywanie tego samego wyniku zadania asynchronicznego z pamięci podręcznej.

Problem nie polega wtedy na błędnym odczycie. Każde wywołanie może działać dokładnie tak, jak zaprojektowano. Błąd leży w sterowaniu agentem: kolejny identyczny odczyt nie zmienia stanu i nie przybliża go do następnego działania.

Jak wygląda pętla bez postępu

Najprostszy przypadek dotyczy wyniku nieterminalnego:

Agent odczytuje wynik zadania.

Otrzymuje niezmieniony wynik nieterminalny.

Ponownie wywołuje to samo narzędzie odczytu.

Dostaje dokładnie tę samą odpowiedź.

Działanie zależne nadal się nie rozpoczyna.

Praktycznym sygnałem wykrywania takiej sytuacji są dwa kolejne identyczne wyniki tego samego narzędzia. To celowo wąska reguła. Nie próbuje definiować uniwersalnej polityki odpytywania wszystkich zadań asynchronicznych, tylko wykrywa konkretny brak postępu.

Jeszcze gorszy przypadek: wynik jest już kompletny

W rzeczywistej sesji wystąpiła również druga, odrębna awaria. Zadanie LLM osiągnęło state=complete i zwróciło pełny ładunek odpowiedzi. Mimo to agent wywołał to samo narzędzie odczytu więcej niż dziesięć razy z rzędu.

Każde wywołanie zwracało identyczny wynik z pamięci podręcznej. Dane potrzebne do dalszej pracy były już dostępne, ale zgłoszenie analizy do systemu zgłoszeń nigdy się nie rozpoczęło.

To ważne rozróżnienie. Przy wyniku nieterminalnym agent może jeszcze czekać na zmianę stanu, choć robi to nieskutecznie. Przy state=complete dalsze odpytywanie nie ma już żadnego uzasadnienia — wynik jest terminalny i kompletny, więc należy przejść do następnego działania.

Warunek zatrzymania musi być częścią sterowania agentem

W tej samej sesji natychmiastowe przejście do działania zależnego po otrzymaniu kompletnego wyniku rozwiązało problem. Z tego przypadku wynika prosta polityka:

Po dwóch kolejnych identycznych wynikach przerwij powtarzanie odczytu.

Jeżeli wynik jest terminalny i zawiera pełny ładunek, wykonaj działanie zależne zamiast ponownie odpytywać.

Jeżeli agent nie może bezpiecznie kontynuować, przekaż sprawę operatorowi.

Najważniejsza lekcja nie dotyczy więc samego cache ani częstotliwości odpytywania. Agent potrzebuje jawnego warunku zatrzymania dla narzędzi, których ponowne wywołanie może zwracać tę samą odpowiedź bez zmiany stanu świata.

Test regresyjny powinien rozdzielać dwa przypadki

Warto mieć dwa niezależne scenariusze regresyjne. Pierwszy powinien sprawdzać powtarzający się wynik nieterminalny i wykrycie braku postępu po kolejnych identycznych odpowiedziach.

Drugi powinien zaczynać się od terminalnego wyniku z pełnym ładunkiem i sprawdzać, że agent nie wywołuje ponownie narzędzia odczytu, tylko przechodzi bezpośrednio do działania zależnego.

Rozdzielenie tych przypadków ma znaczenie, ponieważ awaria występuje w dwóch różnych punktach cyklu życia zadania, choć z zewnątrz oba mogą wyglądać podobnie: agent wciąż wykonuje to samo poprawne wywołanie i niczego nie posuwa naprzód.