Lokal återställning kontra eskalering
Försök igen vid övergående fel och eskalera fel som inte kan återställas.
Lokal återställning kontra eskalering är en gratis lektion i Claude Architect på CoddyKit. Detta är lektion 4 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för Claude Architect, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Claude Architect innehåller totalt 4 lektioner.
Två sätt som ett steg kan misslyckas på
I ett agentbaserat system kan ett enskilt verktygsanrop eller underagentsteg misslyckas av mycket olika orsaker. Arkitektens uppgift är att klassificera felet innan hen agerar.
- Transient-fel — ett tillfälligt, självkorrigerande problem: en kort nätverksstörning, en hastighetsbegränsning eller en kort timeout. Det kan fungera att försöka igen med exakt samma anrop.
- Fel som inte kan återställas — ett strukturellt problem: ogiltiga autentiseringsuppgifter, en saknad behörighet, en felaktigt formaterad begäran eller ett brott mot en affärsregel. Ett nytt försök förändrar ingenting.
Kärnregeln i den här lektionen: återställ transient-fel lokalt och eskalera fel som inte kan återställas.
Lokal återställning: håll den i underagenten
I ett nav-och-ekrar-baserat multiagentsystem delegerar koordinatorn arbete till underagenter. När en underagent drabbas av ett transient-fel bör den försöka åtgärda det där det inträffade — utan att skicka onödigt brus vidare till koordinatorn.
Det håller koordinatorns fokus på orkestrering i stället för lågnivåförsök och bevarar koordinatorns kontextbudget. Lokal återställning är den första försvarslinjen.
def run_tool_with_local_recovery(tool, args, max_attempts=3):
for attempt in range(max_attempts):
result = tool(**args)
if not result.get("isError"):
return result
# Only retry faults the result says are retryable
if result.get("isRetryable") and result.get("errorCategory") == "transient":
continue
break # validation / business / permission -> stop, escalate
return result # hand the structured error upwardLåt felet tala om vad ni ska göra
Ni kan bara dirigera intelligent om felet är strukturerat. Ett generiskt "Operation failed" blockerar återställning — agenten kan inte skilja en hastighetsbegränsning från en nekad behörighet.
Ett väl utformat MCP-verktyg returnerar ett felomslag:
isError: trueerrorCategory:transient/validation/business/permissionisRetryable: booleskt värdemessage,attempted_query,partial_results
errorCategory styr beslutet: transient kan vara ett kandidatfall för ett nytt försök; validation, business och permission är det inte.
{
"isError": true,
"errorCategory": "transient",
"isRetryable": true,
"message": "Upstream timeout after 5s",
"attempted_query": "SELECT * FROM orders WHERE customer_id = 4821",
"partial_results": []
}Fel kontra tomt resultat
En subtil men tentamensviktig distinktion: ett åtkomstfel är inte samma sak som ett giltigt tomt resultat.
- Fel — frågan slutfördes aldrig (timeout, autentiseringsfel). Data är okänd. Det kan gå att försöka igen.
- Tomt — frågan kördes utan problem och hittade ingenting.
0 rowsär ett korrekt, slutgiltigt svar. Ett nytt försök är meningslöst och missvisande.
Om man blandar ihop dessa leder det till att agenter försöker igen i all oändlighet vid legitima fall där "inga matchningar hittades", eller rapporterar ett faktiskt driftavbrott som "inga data".
if result.get("isError"):
handle_failure(result) # access failure: maybe retry / escalate
elif len(result["rows"]) == 0:
return "No matching records found." # valid empty result, DONE
else:
return result["rows"]När ni ska eskalera
Eskalering innebär att lämna över problemet uppåt — till koordinatorn eller i slutänden till en människa. Bra eskaleringsutlösare är objektiva:
- En uttrycklig begäran från en människa — eskalera omedelbart utan fler försök.
- En lucka i policyn — situationen täcks inte av de regler agenten har.
- Inga framsteg efter flera försök — den lokala återställningen är uttömd.
- En tröskelöverträdelse — till exempel att en återbetalning överskrider en tillåten gräns.
Lägg märke till att allt detta kan upptäckas deterministiskt — det handlar inte om gissningar kring användarens sinnesstämning.
Dåliga eskaleringsutlösare
Det är lika viktigt att veta vad ni inte ska eskalera på grund av. Dessa utlösare kan verka rimliga, men är opålitliga och är klassiska distraktorer på tentor:
- Sentimentanalys — att eskalera för att meddelandet "låter argt".
- Modellens egen uppskattning av säkerhet — "Jag är bara 4/10 säker, så eskalera." Självskattningar är inte kalibrerade.
- Otränade klassificerare som kopplats in som grindvakter.
Följ i stället det beprövade mönstret: bekräfta känslan, föreslå en konkret lösning och eskalera endast om kunden upprepar begäran. Beteende — en upprepad uttrycklig begäran — är en mycket bättre signal än en slutsats om känslan.
Eskalera MED kontext, inte bara med en axelryckning
När en underagent eskalerar måste den vidarebefordra strukturerad kontext så att koordinatorn (eller en människa) kan agera utan att göra om arbetet:
- feltypen (errorCategory),
- den försökta frågan eller åtgärden,
- eventuella delresultat som redan har samlats in,
- och möjliga alternativ.
En eskalering som bara säger "det misslyckades" tvingar koordinatorn att börja från noll. En eskalering som innehåller delresultat låter resten av arbetsflödet fortsätta och gör att människan kan lösa problemet snabbare.
def escalate(coordinator, failure):
coordinator.report(
failure_type=failure["errorCategory"],
attempted_query=failure["attempted_query"],
partial_results=failure.get("partial_results", []),
alternatives=["retry via read-replica", "ask user for order ID"],
)Avbryt inte hela arbetsflödet
En misslyckad gren bör inte få hela jobbet att kollapsa. I ett forskningssystem med flera agenter bör koordinatorn, om en källa inte går att nå, ändå sammanställa de lyckade grenarna och tydligt annotera luckan i täckningen.
Två feltillstånd ska undvikas:
- Tyst undertryckning — felet ignoreras så att det slutliga svaret ser komplett ut, trots att det inte är det. Detta förstör förtroendet och spårbarheten.
- Avbryt hela arbetsflödet — alla andra grenar avslutas eftersom en gren misslyckades.
Mellanvägen är att fortsätta, leverera partiella resultat och vara tydlig med vad som saknas.
Begränsningar är ett skyddsnät, inte planen
En loop för nya försök behöver en gräns, men gränsen är ett skyddsnät — aldrig den primära styrmekanismen. Samma princip gäller för hela agentloopen: den avslutas när stop_reason når end_turn, och iterationsgränser förhindrar bara skenande loopar.
För nya försök gäller specifikt att avsluta eftersom det strukturerade felet anger isRetryable: false, eller eftersom framsteg har gjorts — inte enbart för att försök nummer 3 har nåtts. Begränsningen finns så att ett fel som verkar tillfälligt men i själva verket är permanent inte kan loopa för evigt.
# Cap = backstop. The REAL stop signal is the error category.
for attempt in range(MAX_ATTEMPTS): # safety net only
res = call_tool(args)
if not res["isError"]:
return res
if not res["isRetryable"]: # primary, decision-driven stop
return escalate(res)
sleep(backoff(attempt))
return escalate(res) # exhausted -> escalate, never silentDeterministiska skydd för hårda gränser
Vissa eskaleringar skyddar mot ekonomiska, juridiska eller säkerhetsmässiga konsekvenser — till exempel en återbetalning över en gräns i en policy. Här räcker inte vägledning i prompten (~90 % tillförlitlig).
Använd en hook för 100 % deterministisk tillämpning. En PostToolUse- eller utgående anrops-hook kan blockera en åtgärd som bryter mot policyn innan den någonsin körs och tvinga fram en eskalering till en människa. Prompter övertygar; hooks garanterar.
# .claude hook: block refunds over $500 -> force escalation
def on_outgoing_call(call):
if call.tool == "process_refund" and call.args["amount"] > 500:
return {
"block": True,
"reason": "Refund exceeds $500 policy limit; escalate to human.",
}
return {"block": False}Så hänger allt ihop: beslutsflödet
Följ detta flöde för varje misslyckat steg:
- 1. Tomt, inte misslyckat? Returnera det giltiga tomma resultatet. Klart.
- 2. Tillfälligt och möjligt att försöka igen? Återställ lokalt med ett begränsat antal nya försök och backoff.
- 3. Återställt? Fortsätt arbetsflödet.
- 4. Kan inte återställas (validering/verksamhet/behörighet), ett uttryckligt önskemål från en människa, en lucka i policyn, en överträdelse av en gräns eller uttömda nya försök? Eskalera med strukturerad kontext och partiella resultat.
Undertryck aldrig tyst, avbryt aldrig hela arbetsflödet och eskalera aldrig utifrån känslor eller självskattat förtroende.
Snabbkontroll
En databasfunktion hos en underagent returnerar isError: true, errorCategory: "permission", isRetryable: false, tillsammans med den försöka frågan och tomma partiella resultat. Vad bör underagenten göra?
Sammanfattning: återställ lokalt, eskalera resten
Viktiga slutsatser:
- Klassificera först: tillfälligt (möjligt att försöka igen) eller icke-återställningsbart (validering/verksamhet/behörighet).
- Återställ tillfälliga fel lokalt i underagenten med ett begränsat antal nya försök; gränsen är ett skyddsnät, medan det strukturerade felet är den verkliga stoppsignalen.
- Skilj åtkomstfel från ett giltigt tomt resultat — 0 rader är ett slutgiltigt svar, inte en anledning att försöka igen.
- Eskalera det icke-återställningsbara med strukturerad kontext: feltyp, försökt fråga, partiella resultat och alternativ.
- Eskalera utifrån objektiva utlösare (uttryckligt önskemål från en människa, lucka i policyn, avsaknad av framsteg eller överträdelse av en gräns) — aldrig utifrån känslor eller självskattat förtroende.
- Tillämpa ekonomiska, juridiska och säkerhetsmässiga gränser med hooks, inte prompter. Undertryck aldrig tyst och avbryt aldrig hela arbetsflödet på grund av ett enda fel.
Lär dig Python med en AI-lärare – gratis
Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.
- Kurser
- 26
- Lektioner
- 104
Vanliga frågor
Är lektionen ”Lokal återställning kontra eskalering” gratis?
Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Claude Architect, inklusive ”Lokal återställning kontra eskalering”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i Claude Architect innehåller totalt 4 lektioner.
Vad lär jag mig i ”Lokal återställning kontra eskalering”?
Försök igen vid övergående fel och eskalera fel som inte kan återställas. Ni övar på Claude Architect med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.
Behöver jag någon erfarenhet för att börja lära mig Claude Architect?
Du behöver inga förkunskaper. Utbildningen i Claude Architect på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 4 av 4.
Hur lång tid tar lektionen ”Lokal återställning kontra eskalering”?
De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.
Kan jag skriva och köra kod i den här Claude Architect-lektionen?
Ja. Varje Claude Architect-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.
Alla lektioner i den här kursen
- Tydliga eskaleringsutlösare
- Antimönster: Sentiment- och konfidenspoäng
- Strukturerad felkontext
- Lokal återställning kontra eskalering