Struktureret fejlkontekst

Den første opgave for en fejl-kontekst er at klassificere fejlen. Strukturerede MCP-fejl indeholder feltet errorCategory med et lille, fast ordforråd:

• transient — en midlertidig fejl i infrastrukturen (timeout, hastighedsbegrænsning). Kan ofte forsøges igen.
• validation — inputtet havde et ugyldigt format.
• business — en domæneregel blokerede handlingen.
• permission — adgang blev nægtet.

Den tilhørende booleske værdi isRetryable fjerner gætteriet: Koordinatoren læser den direkte i stedet for at udlede hensigten fra en frit formuleret meddelelse.

Én skelnen volder arkitekter konstante problemer: en adgangsfejl er ikke det samme som et gyldigt tomt resultat.

• Fejl: opslaget kunne ikke køres — databasen er utilgængelig, eller adgang blev nægtet. Det kan være værd at prøve igen.
• Tomt: opslaget blev kørt uden problemer og fandt nul match. Et nyt forsøg ændrer intet — svaret er reelt "ingen".

Hvis de to blandes sammen, fører det til meningsløse løkker med nye forsøg på tomme resultater eller til, at et reelt driftsudfald behandles som "ingen data fundet". Modellér dem altid som separate tilstande.

Koordinatoren kørte ikke selv den fejlslagne handling, så den kan ikke se, hvad der blev forsøgt. Medtag attempted_query ordret i fejl-konteksten.

Det tjener to formål:

• Det lader koordinatoren afgøre, om den skal prøve igen med den samme forespørgsel eller omformulere den (f.eks. udvide et filter, der var for snævert).
• Det giver den menneskelige kontrollant den nøjagtige genskabelsessag ved eskalering i stedet for en vag "søgning mislykkedes".

En fejl betyder sjældent, at der blev udført nul arbejde. En research-underagent kan have indsamlet 6 af 10 kilder, før en udbyder satte en hastighedsbegrænsning på den. At kassere det hele — eller afbryde hele arbejdsgangen — spilder reelle fremskridt.

Vedhæft det, der blev indsamlet uden problemer, som partial_results. Koordinatoren kan derefter samle det, der findes, beskrive manglen og afgøre, om resten er værd at forsøge igen.

Undertryk aldrig en fejl lydløst, og præsenter ikke delresultater, som om de var komplette.

De mest nyttige fejl-kontekster beskriver ikke bare muren — de peger på en dør. Feltet alternatives foreslår konkrete næste handlinger, som koordinatoren (eller et menneske) kan udføre.

Eksempler: "prøv igen mod læsereplikaen", "udvid datofilteret", "bed brugeren om et ordrenummer", "eskalér til et menneske med de delvise resultater vedhæftet".

Det er det, der forvandler en struktureret fejl fra en rapport til en ruteanvisning.

Struktureret kontekst driver en klar politik. Håndter transient-fejl inde i underagenten — prøv igen ved timeout, og vent længere mellem forsøg ved en hastighedsbegrænsning — så koordinatoren aldrig ser en fejl, der kan håndteres lokalt.

Først når en fejl reelt ikke kan genskabes (en politikgrænse er nået, adgang er nægtet, eller alle forsøg er opbrugt), eskalerer du den opad — og du eskalerer med de delvise resultater og alternativerne vedhæftet, ikke som en bar "mislykkedes".

Målet er ikke at afbryde hele arbejdsgangen, fordi én gren mislykkedes.

Frit formulerede fejldicts ændrer sig over tid. Håndhæv kontrakten med et JSON Schema via et værktøj / struktureret output, så underagenten skal udfylde de rigtige felter.

En vigtig regel fra design af struktureret output: Markér kun et felt som påkrævet, hvis det altid er til stede. errorCategory og message er altid til stede — gør dem påkrævede. partial_results og alternatives kan mangle — lad dem være valgfrie, ellers vil modellen opfinde dem for at opfylde skemaet.

Underagenter arver ikke koordinatorens samtalehistorik. Når en underagent derfor mislykkes, kender koordinatoren kun de oplysninger, som fejl-payloaden udtrykkeligt indeholder.

Det er netop derfor, at attempted_query og partial_results skal være i den strukturerede fejl — der findes ingen delt hukommelse, som koordinatoren kan falde tilbage på. Fejl-konteksten er hele forbindelsen mellem de to.

Begræns den til de relevante felter, men fjern aldrig de fire søjler.

En fejl-kontekst i produktionskvalitet lader koordinatoren handle uden selv at køre noget igen:

• fejltype + isRetryable → beslutning om nyt forsøg eller eskalering
• forsøgt forespørgsel → genskab eller omformulér
• delvise resultater → red de eksisterende fremskridt, og beskriv manglen
• alternativer → den konkrete næste handling

Det er forskellen mellem en skrøbelig arbejdsgang, der dør ved det første lille problem, og et modstandsdygtigt system, der håndterer forringelser på en kontrolleret måde og leder uden om skaden.

Vigtigste pointer:

• Generiske fejl blokerer gendannelse; strukturerede fejl muliggør intelligent routing.
• Medtag altid de fire søjler: fejltype, forsøgt forespørgsel, delvise resultater, alternativer.
• Brug errorCategory (transient / validation / business / permission) + isRetryable til at træffe beslutningen om nyt forsøg eller eskalering.
• Skeln mellem en adgangsfejl (måske nyt forsøg) og et gyldigt tomt resultat (ingen match — et nyt forsøg hjælper ikke).
• Genskab transient-fejl lokalt i underagenten; eskalér fejl, der ikke kan genskabes, med de delvise resultater vedhæftet.
• Undertryk aldrig fejl lydløst, og afbryd aldrig hele arbejdsgangen på grund af én fejl.
• Håndhæv strukturen med et skema, men gør kun felter påkrævede, når de er altid til stede — valgfrie søjler skal forblive valgfrie for at undgå opdigtede værdier.