Jak ověřit zpracování chyb vytvořené vaším kódovacím agentem

Váš agent pro psaní kódu říká, že přidal opakované pokusy a zpracování omezení rychlosti a jeho testy prošly. Než tomu budete důvěřovat, zkontrolujte, proti čemu byly testy spuštěny.

V testu jsme spustili 3 kódovací agenty (210 spuštění), požádali jsme je, aby upravili aplikace tak, aby zpracovávaly selhání API, a ukázali, že to funguje. V 76 % ze 140 spuštění, která požadovala funkční kód, agent sestavil selhání ručně pomocí stubů pro fetch, httpx.MockTransport nebo dočasného HTTP serveru. V 75 spuštěních, kde bylo skutečné rozhraní API k dispozici a výzva ho nevyloučila, 0 jich otestovalo aplikaci na jeho skutečné adrese URL rozhraní API. Úspěšné testy, jako jsou tyto, ukazují, že kód agenta zpracovává selhání, které si agent představoval. To je jiné selhání než to, které rozhraní API odesílá.

Kontrolní seznam

  1. Zeptejte se, vůči čemu se testovalo. Zeptejte se agenta: „Na kterou adresu URL aplikace během vašeho testu volala a co vrátilo tuto chybu?“ Pokud je odpovědí stub nebo místní server, který napsal, zacházejte s testy jako s jednotkovými testy větví, které přidal.
  2. Vyhledejte přepínače přidané pro testy. V rozdílu vyhledejte nové proměnné prostředí, nastavení základní adresy URL nebo příznaky. V našem testu 61 ze 105 spuštění aplikací, které volají GitHub, OpenAI nebo rozhraní API pro počasí, přidalo jedno. Rozhodněte se, jestli ho chcete použít v produkčním prostředí.
  3. Zkontrolujte kód se zdokumentovaným chováním rozhraní API. Každé rozhraní API selže vlastním způsobem:
    • GitHub: Když překročíte primární limit počtu požadavků, získáte hodnotu 403 nebo 429 s nastaveným 0parametrem x-ratelimit-remaining a počkáte do času uvedeného v x-ratelimit-reset, v sekundách UTC epochy. V případě sekundárních limitů požadavků počkejte na retry-after, pokud je k dispozici, jinak do x-ratelimit-reset, pokud je x-ratelimit-remaining0, jinak alespoň 1 minutu. Kód, který kontroluje pouze kód 429, nezachytí odpovědi 403.
    • OpenAI: některé chyby 429 souvisejí s fakturací a limity výdajů, například credit_balance_exhausted. Opakovat je nepomůže. Kód, který opakuje pokus při každé chybě 429, před vámi skryje problém.
    • Anthropic: spend cap 429 nemá žádné retry-after záhlaví a přetížení vrací 529, což kód, který zná pouze standardní stavové kódy, nemusí očekávat.
  4. Zkontrolujte, jak to zní Retry-After. Záhlaví obsahuje počet sekund nebo datum HTTP (RFC 9110). Zkontrolujte, jestli kód zpracovává formát, který rozhraní API odesílá, limituje počet pokusů a celkovou dobu čekání a neprovádí opakované pokusy nad rámec sady SDK, která už opakování provádí.
  5. Zkontrolujte, co uživatel uvidí, když se vyčerpají opakované pokusy. Hledejte jasnou zprávu místo trasování zásobníku nebo nekonečného indikátoru načítání a zkontrolujte, jestli uživatel nepřijde o svou práci.
  6. Spusťte aplikaci na jejích skutečných URL adresách se simulovanými chybami. Toto je jediný krok, který ukazuje, jak se spuštěná aplikace, její sada SDK a zásady opakování pokusů chovají společně.

Jak ověřit zpracování chyb napsaných agentem

Approach Co najdete Co vám chybí
Přečíst diff Zda kód vypadá správně Jestli se chová správně vůči skutečným odpovědím rozhraní API
Spusťte testy agenta Že větve, které vytvořilo, běží. Všechno, co stub implementace nemodelovala: skutečné stavové kódy, hlavičky, tělo chyb a opakované pokusy v SDK
Volejte skutečné rozhraní API, dokud se nezdaří Skutečné chování Nemůžete vyvolat selhání na požádání a utratíte skutečnou kvótu.
Spusťte aplikaci na skutečných adresách URL se simulovanými chybami Jak spuštěná aplikace, její sada SDK a její zásady opakování zpracovávají vlastní chyby rozhraní API Váš kód v izolaci. Pro to zachovejte jednotkové testy agenta.

Vyzkoušejte si ji v aplikaci

Dev Proxy zachytí požadavky, které aplikace odešle do skutečného rozhraní API, a vrátí vámi zvolené chyby beze změn kódu vaší aplikace. U oblíbených rozhraní API začněte s předvolbou. Pro kontrolu obsluhy limitu rychlosti GitHubu váš agent napsal:

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

Spusťte aplikaci a sledujte výstup dev proxy serveru. Předvolba vrátí hodnotu 429 s hlavičkami limitu požadavků GitHubu, jakmile vaše aplikace překročí limit. RetryAfterPlugin v předvolbě vám řekne, jestli vaše aplikace znovu volá rozhraní API, než uplyne čekací doba. Předvolby openai-throttling a anthropic-throttling dělají totéž pro vlastní chyby omezení rychlosti poskytovatele a openai-throttling také vrací credit_balance_exhausted 429, která by se neměla opakovat.

Pro jiná rozhraní API:

Můžete také požádat svého programovacího agenta, aby napsal konfiguraci Dev Proxy. Přidejte do agenta server MCP pro Dev Proxy, aby mohl vyhledat dokumentaci k Dev Proxy a osvědčené postupy a zkontrolovat, jakou verzi máte nainstalovanou. Zkontrolujte konfiguraci stejně jako jakýkoli jiný kód, který agent píše.

Pokud chcete nainstalovat Dev Proxy, přečtěte si téma Nastavení Dev Proxy.

Další kroky

Otestujte mou aplikaci s náhodnými chybami

Viz také

  • Poslední aktualizace v