Jak zweryfikować obsługę błędów, którą napisał agent programistyczny

Twój agent programistyczny mówi, że dodał ponawianie prób i obsługę ograniczeń limitu żądań, a jego testy kończą się powodzeniem. Zanim zaufasz temu, sprawdź, względem czego przeprowadzono testy.

W teście przeprowadziliśmy testy z 3 agentami kodowania (210 przebiegów), poprosiliśmy ich, aby aplikacje obsługiwały awarie API i pokazały, że to działa. W 76% ze 140 przebiegów, w których poproszono o działający kod, agent ręcznie odtworzył awarię przy użyciu stubów fetch, httpx.MockTransport, lub tymczasowego serwera HTTP. W 75 uruchomieniach, w których rzeczywisty interfejs API był dostępny, a monit go nie wykluczał, w 0 przypadkach przetestowano aplikację pod rzeczywistym adresem URL interfejsu API. Testy takie jak te dowodzą, że kod agenta obsługuje błąd, który wyobrażał sobie agent. Jest to inny błąd niż ten, który wysyła interfejs API.

Lista kontrolna

  1. Zapytaj, względem czego to testowano. Zapytaj agenta: „Jaki adres URL aplikacja wywołała podczas testu i co zwróciło błąd?” Jeśli odpowiedź jest stubem lub lokalnym serwerem, który napisał, traktuj testy jako testy jednostkowe gałęzi, które dodał.
  2. Wyszukaj przełączniki dodane na potrzeby testów. Wyszukaj różnice pod kątem nowych zmiennych środowiskowych, ustawień podstawowego adresu URL lub flag. W naszym teście 61 z 105 uruchomień w aplikacjach wywołujących GitHub, OpenAI lub interfejs API pogody dodało jeden. Zdecyduj, czy ma być w środowisku produkcyjnym.
  3. Sprawdź kod pod kątem udokumentowanego zachowania interfejsu API. Każdy interfejs API kończy się niepowodzeniem w sposób własny:
    • GitHub: po przekroczeniu podstawowego limitu liczby żądań otrzymasz 403 lub 429 z x-ratelimit-remaining ustawionym na 0, i czekasz do czasu z x-ratelimit-reset, wyrażonego w sekundach epoki UTC. W przypadku wtórnych limitów szybkości zaczekaj na retry-after, jeśli jest dostępne, w przeciwnym razie do x-ratelimit-reset, jeśli x-ratelimit-remaining ma wartość 0, w przeciwnym razie co najmniej 1 minutę. Kod, który sprawdza tylko 429, pomija kody 403.
    • OpenAI: niektóre 429 dotyczą rozliczeń i limitów wydatków, takich jak credit_balance_exhausted. Ponawianie ich nie pomoże. Kod, który ponawia próbę po każdym błędzie 429, ukrywa przed tobą problem.
    • Anthropic: limit wydatków 429 nie retry-after ma nagłówka, a przeciążenia zwracają 529, czego kod znający tylko standardowe kody stanu może nie oczekiwać.
  4. Sprawdź, jak to brzmi Retry-After. Nagłówek zawiera liczbę sekund lub datę HTTP (RFC 9110). Sprawdź, czy kod obsługuje format, który wysyła interfejs API, ogranicza liczbę prób i łączny czas oczekiwania i nie ponawia prób dodatkowo, jeśli zestaw SDK już je ponawia.
  5. Sprawdź, co użytkownik widzi po zakończeniu ponownych prób. Poszukaj jasnego komunikatu zamiast śladu stosu lub niekończącego się wskaźnika ładowania i sprawdź, czy użytkownik nie traci swojej pracy.
  6. Uruchom aplikację na rzeczywistych adresach URL z symulowanymi awariami. Jest to jedyny krok pokazujący, jak wspólnie zachowują się uruchomiona aplikacja, jej SDK i zasady ponawiania prób.

Jak zweryfikować obsługę błędów utworzoną przez agenta

Approach Co znajdziesz Co tracisz
Wyświetl diff Czy kod wygląda prawidłowo Czy zachowuje się ona prawidłowo względem rzeczywistych odpowiedzi interfejsu API
Uruchom testy agenta Że gałęzie, które napisał, działają Wszystko, czego stub nie modeluje: rzeczywiste kody stanu, nagłówki, treści błędów i ponowne próby SDK
Wywołuj rzeczywiste API do momentu niepowodzenia Rzeczywiste zachowanie Nie możesz wyzwalać błędów na żądanie i zużywasz rzeczywisty przydział
Uruchom aplikację na rzeczywistych adresach URL z symulowanymi błędami Jak działająca aplikacja, jej zestaw SDK i zasady ponawiania prób obsługują własne błędy interfejsu API Twój kod w izolacji. Zachowaj do tego testy jednostkowe agenta.

Wypróbuj ją w aplikacji

Dev Proxy przechwytuje żądania wysyłane przez aplikację do rzeczywistego interfejsu API i zwraca wybrane błędy bez zmian w kodzie aplikacji. W przypadku popularnych interfejsów API zacznij od ustawienia wstępnego. Aby sprawdzić GitHub limit szybkości obsługi agenta napisał:

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

Uruchom aplikację i obejrzyj dane wyjściowe Dev Proxy. Preset zwraca wartość 429 z nagłówkami limitu żądań GitHub, gdy aplikacja przekroczy limit. Parametr RetryAfterPlugin w presecie informuje, czy aplikacja ponownie wywołuje interfejs API przed upływem czasu oczekiwania. Ustawienia wstępne openai-throttling i anthropic-throttling działają tak samo w przypadku błędów limitu żądań dostawcy, a openai-throttling także zwraca credit_balance_exhausted kod 429, którego nie należy ponawiać.

W przypadku innych interfejsów API:

Możesz również poprosić agenta programistycznego o napisanie konfiguracji Dev Proxy. Dodaj serwer MCP Dev Proxy do agenta, aby mógł wyszukać dokumentację Dev Proxy i najlepsze praktyki oraz sprawdzić, która wersja została zainstalowana. Sprawdź tę konfigurację tak jak każdy inny kod, który pisze agent.

Aby zainstalować Dev Proxy, zobacz Set up Dev Proxy.

Następne kroki

Przetestuj moją aplikację z losowymi błędami

Informacje dodatkowe

  • Ostatnia aktualizacja o