isError-flaget

Det klassiske antipattern er en generisk fejlstreng som "Operation failed". Den fortæller modellen, at noget gik galt, men ikke noget, den kan handle på.

Kan den prøve igen? Var inputtet forkert formateret? Manglede brugeren tilladelse? Er der delvise data, som kan reddes? En generisk meddelelse besvarer ingen af disse spørgsmål – derfor går agenten i stå eller improviserer dårligt.

Generiske fejl blokerer genoprettelse. Strukturerede fejl muliggør intelligent routing.

En korrekt udformet MCP-fejl kombinerer isError: true med en struktureret brødtekst. Felterne, der forventes til eksamen, er:

• errorCategory – en af transient, validation, business, permission
• isRetryable – kan det samme kald lykkes, hvis det prøves igen?
• message – forklaring, der kan læses af mennesker
• attempted_query – præcis det, værktøjet forsøgte at gøre
• partial_results – alt brugbart, som værktøjet nåede at indsamle

Tilsammen lader disse felter modellen beslutte, om den skal prøve igen, omformulere, eskalere eller fortsætte med delvise data.

De fire kategorier er ikke pynt – hver af dem peger på en forskellig næste handling:

• transient – midlertidig fejl (timeout, hastighedsbegrænsning). Kan som regel prøves igen; genopret lokalt.
• validation – ugyldigt input. Prøv ikke blindt igen; ret argumenterne først.
• business – en regel blev overtrådt (f.eks. overstiger en tilbagebetaling politikken). Kræver ofte eskalering, ikke et nyt forsøg.
• permission – den kaldende part mangler adgang. Et nyt forsøg hjælper ikke; eskalér eller bed om legitimationsoplysninger.

Kategorien forvandler en vag fejl til en routinginstruktion, som modellen kan følge.

Om en fejl er værd at prøve igen, er ofte ikke synligt ud fra meddelelsens tekst alene. Gør det tydeligt med isRetryable.

Et timeout (transient) kan prøves igen. Et forkert formateret argument (validation) kan ikke – hvis du prøver det samme ugyldige input igen, mislykkes det bare igen. Et afslag på tilladelse kan ikke prøves igen uden nye legitimationsoplysninger.

Ved at angive isRetryable direkte gør du beslutninger om genforsøg deterministiske i stedet for at overlade dem til sandsynlighedsbaseret tekstlæsning.

Når modellen beslutter, hvordan den skal komme videre, skal den vide hvad der faktisk blev forsøgt. Ved at inkludere attempted_query kan agenten omformulere intelligent i stedet for at gentage det samme fejlslagne kald.

Det er en del af god fejlvideregivelse: struktureret kontekst = fejltype, forsøgt forespørgsel, delvise resultater og alternativer. Jo rigere konteksten er, desto bedre bliver routingen af genoprettelsen.

Et værktøj kan mislykkes og stadig have indsamlet noget nyttigt. Et opslag i flere kilder kan returnere 3 af 5 poster, før den fjerde kilde får timeout.

Hvis du returnerer partial_results sammen med fejlen, kan agenten fortsætte med det, den har, markere manglen og undgå at starte forfra. Hvis du kasserer delvise data ved enhver fejl, spilder du arbejde og forringer svarene.

En vigtig forskel: En adgangsfejl er ikke det samme som et gyldigt tomt resultat.

• isError: true – værktøjet kunne ikke fuldføre arbejdet (timeout, afvist, ugyldigt input). Måske skal du prøve igen eller eskalere.
• isError: false med tomt indhold – værktøjet kørte korrekt, og det ærlige svar er "ingen match".

Det er en almindelig fejl at blande disse sammen: En tom søgning, der markeres som en fejl, udløser meningsløse genforsøg, mens en reel fejl, der markeres som tom, skjuler problemet. Hold dem adskilt.

Det strukturerede signal styrer, hvor genoprettelsen sker. I et system med flere agenter bør en underagent genoprette midlertidige fejl lokalt – prøve timeoutet igen eller udføre kaldet på ny – og kun sende fejl videre, som den virkelig ikke kan løse.

Når den eskalerer, skal den sende den strukturerede fejl med delvise resultater, så koordinatoren kan beslutte, om den skal route et andet sted hen, bede om flere identifikatorer eller vise manglen. Undertryk aldrig en fejl i stilhed, og afbryd aldrig hele arbejdsgangen på grund af én fejl, der kan genoprettes fra.

Pak arbejdet ind i en MCP-værktøjshåndtering, og returnér en struktureret fejl, hvis noget mislykkes, i stedet for at lade en undtagelse slippe igennem som en generisk streng.

Bemærk, hvordan hver gren angiver isError, en kategori og et tip om genforsøg – så den agentiske løkke har alt, hvad den skal bruge for at route næste trin deterministisk.

Vigtigste pointer om isError-flaget:

• isError: true er det strukturelle signal om, at et værktøj ikke producerede gyldige data – adskilt fra det normale output.
• Kombinér det med errorCategory (transient / validation / business / permission), isRetryable, message, attempted_query og partial_results.
• Generiske fejl som "Operation failed" blokerer genoprettelse; strukturerede fejl muliggør intelligent routing.
• Skeln mellem en adgangsfejl og et gyldigt tomt resultat – markér aldrig "ingen match" som en fejl.
• Genopret midlertidige fejl lokalt; eskalér fejl, der ikke kan genoprettes fra, med delvise resultater. Undgå at undertrykke fejl i stilhed, og undgå at afbryde hele arbejdsgangen på grund af én fejl.