Hogyan ellenőrizhető a kódoló ügynök által írt hibakezelés

A kódolóügynök azt mondja, hogy újrapróbálkozást és kérésszámkorlát-kezelést adott hozzá, és a tesztek sikeresek. Mielőtt megbízik benne, ellenőrizze, hogy a teszteket min futtatták.

Egy 3 kódolási ügynökkel végzett tesztben (210 futtatás) arra kértük őket, hogy készítsenek olyan alkalmazásokat, amelyek kezelik az API-hibákat, és mutassák be, hogy ez működik. A működő kódot kérő 140 futtatás 76%-ában az ügynök kézzel, fetch stubokkal, httpx.MockTransport vagy egy eldobható HTTP-kiszolgálóval létrehozta a hibát. A 75 futás közül, ahol a valódi API elérhető volt, és a parancssor nem zárta ki, 0 tesztelte az alkalmazást a valódi API URL-címén. Az ilyen tesztek azt bizonyítják, hogy az ügynök kódja kezeli az ügynök által elképzelt hibát. Ez más hiba, mint amit az API küld.

Checklist

  1. Kérdezze meg, hogy mivel szemben tesztelték. Kérdezze meg az agentet: "Melyik URL-címet hívta az alkalmazás a teszt során, és mi adta vissza a hibát?" Ha a válasz egy stub vagy egy helyi kiszolgáló, amelyet írt, a teszteket a hozzáadott ágak egységtesztjeként kezelje.
  2. Keresse meg a tesztekhez hozzáadott kapcsolókat. Keressen új környezeti változókat, alap URL-beállításokat vagy jelzőket a diffben. Tesztünkben a 105 futtatásból 61 olyan alkalmazásokon, amelyek meghívják a GitHubot, az OpenAI-t vagy egy időjárási API-t, egy ilyet adott hozzá. Döntse el, hogy éles környezetben szeretné-e használni.
  3. Ellenőrizze a kódot az API dokumentált viselkedésével. Minden API a saját módján meghibásodik:
    • GitHub: ha túllépi az elsődleges lekérési korlátot, 403-at vagy 429-et kap, úgy, hogy a(z) x-ratelimit-remaining értéke 0, és várjon a(z) x-ratelimit-reset mezőben megadott időpontig, UTC epoch másodpercben. Másodlagos sebességkorlátok esetén várjon retry-after, ha ott van, ellenkező esetben x-ratelimit-reset-ig, ha x-ratelimit-remaining értéke 0, ellenkező esetben legalább 1 percet. A csak 429-et ellenőrző kód nem veszi észre a 403-at.
    • OpenAI: néhány 429s a számlázásról és a költségkorlátokról szól, például credit_balance_exhausted. Az újbóli próbálkozás ezekkel nem segít. A minden 429-re újrapróbálkozó kód elrejti a problémát.
    • Anthropic: a 429-hez tartozó költségkorlátnak nincs retry-after fejléce, a túlterhelések pedig 529-et adnak vissza, amire a csak a standard állapotkódokat ismerő kód esetleg nem számít.
  4. Ellenőrizze, hogyan olvasható.Retry-After A fejléc másodpercek számát vagy EGY HTTP-dátumot (RFC 9110) tartalmaz. Ellenőrizze, hogy a kód kezeli-e az API által küldött formátumot, korlátozza-e a kísérletek számát és a teljes várakozást, és nem próbálkozik újra egy már újrapróbálkozó SDK-val.
  5. Ellenőrizze, hogy a felhasználó mit lát, amikor az újrapróbálkozások elfogynak. Keressen egyértelmű üzenetet a veremnyomkövetés vagy a végtelenül pörgő betöltésjelző helyett, és ellenőrizze, hogy a felhasználó nem veszíti-e el a munkáját.
  6. Futtassa az alkalmazást a valós URL-címein szimulált hibákkal. Ez az egyetlen lépés, amely bemutatja, hogyan működik együtt a futó alkalmazás, az SDK és az újrapróbálkozási szabályzat.

Ügynök által generált hibakezelés ellenőrzése

Approach Mit talál? Amit elmulasztott
Különbség megtekintése A kód helyesnek tűnik-e Helyesen viselkedik-e az API valódi válaszai alapján
Az ügynök tesztjeinek futtatása Hogy az általa írt elágazások működnek Minden, amit a stub nem modellezett: valós állapotkódok, fejlécek, hibatörzsek és SDK-újrapróbálkozások
Hívja meg a valódi API-t, amíg hibát nem ad Valós viselkedés Nem tud igény szerint hibákat előidézni, és a valós kvótát használja
Futtassa az alkalmazást valós URL-címeken szimulált hibákkal Hogyan kezeli a futó alkalmazás, az SDK és az újrapróbálkozási szabályzat az API saját hibáit A te kódod elkülönítve. Arra használja az ügynök egységtesztjeit.

Próbálja ki az alkalmazásán

Dev Proxy elfogja az alkalmazás által a valódi API-nak küldött kéréseket, és visszaadja a választott hibákat, anélkül, hogy módosítanod kellene az alkalmazás kódját. Népszerű API-k esetén kezdje egy előbeállítással. A GitHub sebességkorlát-kezelésének ellenőrzéséhez az ügynöke ezt írta:

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

Futtassa az alkalmazást, és figyelje meg a Dev Proxy kimenetét. Az előbeállítás egy 429-et ad vissza a GitHub sebességkorlátozási fejléceivel, amint az alkalmazás túllépi a korlátot. Az előre beállított RetryAfterPlugin jelzi, hogy az alkalmazás a várakozási idő letelte előtt ismét meghívja-e az API-t. Az anthropic-throttling és openai-throttling presetek ugyanezt teszik a szolgáltató saját sebességkorlátozási hibái esetében, és a openai-throttling egy credit_balance_exhausted 429-et is visszaad, amelyet nem szabad újrapróbálni.

Egyéb API-k esetén:

Megkérheti a kódolóügynököt is, hogy írja meg a Dev Proxy konfigurációját. Adja hozzá a Dev Proxy MCP-kiszolgálót az ügynökhöz, hogy megkeresse a Dev Proxy dokumentációját és ajánlott eljárásait, és ellenőrizze, hogy melyik verziót telepítette. Ezt a konfigurációt ugyanúgy vizsgálja felül, mint az ügynök által írt bármely más kódot.

A Dev Proxy telepítéséhez lásd: Dev Proxy beállítása.

További lépések

Teszteld az alkalmazásomat véletlenszerű hibákkal

Lásd még

  • Utolsó frissítés időpontja: