Feilkategorier

Midlertidige feil er forbigående og skyldes ikke forespørselen din: et tidsavbrudd, et kortvarig nettverksbrudd eller en oppstrøms tjeneste som akkurat nå er overbelastet. Det samme kallet vil sannsynligvis lykkes hvis det gjøres på nytt litt senere.

Disse tilsvarer isRetryable: true. Det riktige er nesten alltid å prøve på nytt lokalt i underagenten – gjenopprett feilen der den oppstod, med en kort backoff, i stedet for å avbryte hele arbeidsflyten på grunn av et kortvarig problem.

Valideringsfeil betyr at selve forespørselen var feilformatert: et obligatorisk felt mangler, feil type er brukt, en verdi er utenfor tillatt område eller datoformatet er ugyldig. Verktøyet kom aldri langt nok til å utføre det egentlige arbeidet.

Hvis du prøver den identiske forespørselen på nytt uten å endre noe, vil den mislykkes igjen – derfor er isRetryable vanligvis false. Feilen kan likevel gjenopprettes: Claude kan lese meldingen, korrigere inputen og kalle verktøyet på nytt. Jo mer detaljert meldingen er (hvilket felt og hva som var forventet), desto raskere korrigerer modellen seg selv.

Forretningsfeil oppstår når forespørselen er korrekt utformet og den som kaller, har tilgang, men en forretningsregel forbyr handlingen. Tenk for eksempel på en refusjon som overskrider beløpsgrensen, for lav kontosaldo, en utsolgt vare eller en bestilling etter fristens utløp.

Dette er ikke en feil som løses ved å prøve på nytt – det er en begrensning i den virkelige verden. isRetryable er false. Agenten bør tydelig vise regelen, og hvis arbeidsflyten ikke kan fortsette innenfor retningslinjene, bør den eskalere i stedet for å forsøke å tvinge gjennom handlingen.

Tilgangsfeil betyr at tilgang ble nektet: legitimasjonen, tokenet eller rollen gir ikke tillatelse til denne handlingen eller ressursen. Forespørselen kan være helt gyldig når det gjelder struktur og hensikt – den er ganske enkelt ikke tillatt.

Hvis det samme kallet prøves på nytt med den samme legitimasjonen, vil det fortsette å mislykkes, så isRetryable er false. Agenten bør ikke gå i en løkke; den bør rapportere tilgangsmangelen og, når det er hensiktsmessig, eskalere til et menneske eller en privilegert bane.

Hele poenget med kategorisering er å rute. Når koordinatoren leser errorCategory, blir gjenopprettingsløpet entydig – den trenger ikke gjette ved å lese fritekst.

En ryddig tilordning:

• transient → prøv på nytt lokalt med gradvis lengre ventetid
• validation → korriger inndataene, og prøv deretter på nytt
• business → respekter regelen; eskaler hvis prosessen blokkeres
• permission → stopp; rapporter eller eskaler manglende tilgang

Dette er intelligent ruting som en generell "failed"-status ganske enkelt ikke kan støtte.

De trenger ikke alltid dele opp etter alle fire kategoriene. Flagget isRetryable fungerer som en rask sjekk: true betyr «det kan med rimelighet fungere å prøve igjen», mens false betyr «det samme kallet vil mislykkes på samme måte».

Som tommelfingerregel kan bare transient-feil prøves på nytt uendret. Ved valideringsfeil må inndataene endres først; forretningsregler og tillatelser endres ikke av at De prøver igjen. Betrakt isRetryable: false som et tydelig signal om å slutte å prøve på nytt og velge en annen handling – korrigere, eskalere eller rapportere.

Et subtilt, men eksamenskritisk skille: en tilgangsfeil er ikke det samme som et gyldig tomt resultat.

Hvis et oppslagsverktøy ikke får kontakt med databasen, er det en midlertidig feil – kanskje bør De prøve på nytt. Hvis verktøyet får kontakt med databasen uten problemer, men det ganske enkelt ikke finnes rader som samsvarer, er kallet vellykket og returnerer null resultater – isError er false. Hvis De blander disse to, kan det føre til meningsløse nye forsøk på «ingen treff», eller enda verre: at en reell feil i stillhet behandles som «ingenting der».

Når en feil som ikke kan gjenopprettes, må sendes videre, bør De sende med strukturert kontekst – ikke bare «det gikk galt». Ta med feiltypen, attempted_query, eventuelle partial_results som allerede er samlet inn, og realistiske alternativer.

I et system for forskning med flere agenter gjør dette det mulig for koordinatoren å merke hull i dekningen og likevel sette sammen et nyttig svar basert på det som fungerte. De to feilmodusene som må unngås, er stille undertrykking (å svelge feilen) og å avbryte hele arbeidsflyten fordi én av ti deloppgaver mislyktes.

Sett de to delene sammen til ett driftsprinsipp for feilhåndtering i agenter:

• Gjenopprett midlertidige feil lokalt – prøv på nytt i underagenten med gradvis lengre ventetid; ikke send et tidsavbrudd helt videre til brukeren.
• Eskaler feil som ikke kan gjenopprettes, sammen med delvise resultater – når forretningsregler, tillatelser eller manglende data hindrer fremdriften, sender De den strukturerte konteksten videre slik at et menneske eller en koordinator kan avgjøre hva som skal gjøres.

Utløsere for eskalering bør være konkrete (manglende retningslinjer, brudd på terskelverdier, manglende fremdrift etter flere forsøk eller uttrykkelige forespørsler fra mennesker) – aldri basert på følelser eller en modell sin egenvurderte konfidensskår.

Strukturerte feil gjør en blindvei om til en beslutning. Husk de fire kategoriene og standardrutene deres:

• transient (isRetryable: true) → prøv på nytt lokalt med gradvis lengre ventetid
• validation → korriger inndataene, og prøv deretter på nytt
• business → respekter regelen; eskaler hvis prosessen blokkeres
• permission → stopp; rapporter eller eskaler manglende tilgang

Skill alltid mellom en tilgangsfeil og et gyldig tomt resultat. Når De sender en feil videre, må De ta med attempted_query og partial_results – aldri undertrykke feilen i stillhet, og aldri avbryte hele arbeidsflyten på grunn av én feil. Generelle feil hindrer gjenoppretting; strukturerte feil med en kategori og isRetryable gjør den mulig.