Deterministisk håndhævelse vs. prompts
Hooks er 100 % sikre; prompts er cirka 90 % sandsynlige
Deterministisk håndhævelse vs. prompts er en gratis Claude Architect-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i Claude Architect, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Claude Architect-kurset indeholder 4 lektioner i alt.
To måder at håndhæve en regel på
Når du har brug for, at en agent altid følger en regel, har du to grundlæggende forskellige værktøjer.
- Forespørgsler beder modellen om at opføre sig på en bestemt måde. Modellen føjer sig som regel — men den er stadig et sandsynlighedsbaseret system, der træffer en vurdering.
- Hooks er deterministisk kode, der kører omkring værktøjskald. De beder ikke — de håndhæver.
Denne lektion lærer dig det vigtigste tal inden for håndhævelse af arbejdsgange: En velskrevet forespørgsel giver omtrent ~90 % efterlevelse; en hook giver 100 %.
Forespørgsler er sandsynlighedsbaserede
En systemforespørgsel er vejledning. Selv en fremragende forespørgsel — med eksplicitte kriterier og få-skuds-eksempler — styrer modellen mod den rigtige adfærd, men garanterer den aldrig.
På tværs af tusindvis af forespørgsler viser de resterende ~10 % sig: et særtilfælde, en usædvanlig formulering eller en lang kontekst, hvor reglen befinder sig i området lost-in-the-middle. Modellen generaliserer ud fra dine instruktioner, og netop derfor kan den også generalisere forkert.
Det er fint for det meste af adfærden. For regler, hvor én enkelt overtrædelse er uacceptabel, er ~90 % en risiko.
system = (
"You are a refund agent. "
"NEVER issue a refund above $500 without manager approval."
)
# This is guidance. The model will *usually* obey —
# but 'usually' is not 'always'. There is no code path
# that physically blocks a $501 refund.Hooks er deterministiske
En hook er almindelig kode, der er koblet ind i agentens livscyklus. Den kører hver gang, evaluerer en betingelse på samme måde hver gang, og dens beslutning afhænger ikke af modellens ræsonnement.
- PostToolUse-hooks opfanger et værktøjs resultat, før modellen overhovedet ser det.
- Hooks til udgående kald blokerer handlinger, der overtræder politikker, før de udføres.
Fordi logikken er hårdkodet, er garantien absolut: 100 % deterministisk håndhævelse. En blokeret handling er blokeret — uanset hvad modellen beslutter.
def block_large_refund(tool_name, tool_input):
if tool_name == "process_refund" and tool_input["amount"] > 500:
return {"allow": False,
"reason": "Refunds over $500 require manager approval"}
return {"allow": True}
# Runs on EVERY process_refund call. $501 is blocked, every time.Beslutningsreglen
Her er reglen, du skal huske til eksamen og til ægte arkitektur:
Brug hooks, når en fejl har økonomiske, juridiske eller sikkerhedsmæssige konsekvenser.
Hvis én enkelt overtrædelse koster penge, bryder loven eller udsætter nogen for fare, er ~90 % ikke acceptabelt — du har brug for 100 %. Det er en hooks opgave. Forespørgsler er til vejledning, tone, præferencer og de utallige bløde adfærdsformer, hvor en lejlighedsvis fejl kan håndteres.
Håndhæv ikke en kritisk forretningsregel udelukkende med forespørgsler. Det er et af de mest almindelige forkerte svar på scenariespørgsmål.
Programmerbare forudsætninger
Det samme deterministiske princip gælder for forudsætninger — regler for, hvad der skal ske, før en handling må udføres.
Eksempel fra scenariet med kundesupport: Kør aldrig process_refund, før get_customer har returneret et verificeret kunde-id. Du kan skrive det som en promptinstruktion ... eller håndhæve det i kode, så det fysisk ikke kan springes over.
En programmatisk forudsætning giver en deterministisk garanti, som promptvejledning ikke kan give. Identitetskontrollen sker 100 % af gangene, ikke 90 %.
def require_verified_identity(tool_name, tool_input, state):
if tool_name == "process_refund" and not state.get("verified_customer_id"):
return {"allow": False,
"reason": "Block refund until get_customer returns a verified ID"}
return {"allow": True}Hvorfor ikke bare skrive en stærkere prompt?
En fristende fælde: "Jeg skriver bare en virkelig stærk prompt — med versaler, gentaget tre gange og med eksempler." Det forbedrer efterlevelsen, men ændrer ikke kategorien. Du befinder dig stadig på den sandsynlighedsbaserede side af skellet.
Few-shot-eksempler og eksplicitte kriterier er effektive — de øger kvaliteten, reducerer hallucinationer og fastholder outputformatet. Men de hæver loftet på omkring 90 %; de når aldrig den deterministiske 100 %, som finansielle, juridiske og sikkerhedsmæssige regler kræver.
Hvis kravet er en garanti, kan ingen mængde promptudvikling erstatte kode.
Hooks erstatter ikke modellens beslutninger
En vigtig balance: Hooks er ikke en tilladelse til at hardkode alt. Det agentiske loop er modelstyret — modellen beslutter, hvilke værktøjer der skal kaldes og hvornår, baseret på stopårsager.
Du reserverer hardkodning til garantier, ikke til rutinemæssig beslutningstagning. Se det som en tynd, deterministisk sikkerhedsgrænse omkring en intelligent og fleksibel kerne.
Den samme indsigt gælder for iterationsgrænser: En grænse er et sikkerhedsnet, aldrig den primære stopmekanisme. Afslut på stop_reason, og brug kun deterministisk kode, hvor der reelt kræves en hård garanti.
PostToolUse: Beskyttelse af input til modellen
En PostToolUse-hook opfanger et værktøjsresultat, før modellen ser det. Det handler om mere end blokering — det er et deterministisk kontrolpunkt for data, der strømmer tilbage til samtalen.
Brug den til at håndhæve ting som at fjerne hemmeligheder fra output, validere at et påkrævet felt findes eller nægte at vise et resultat, der overtræder en politik. Fordi den kører deterministisk for hvert resultat, får modellen ikke engang mulighed for at håndtere data forkert, når du har besluttet, at den ikke må se dem i rå form.
def post_tool_use(tool_name, result):
if tool_name == "lookup_order":
# Deterministically strip PII before the model sees it
result.pop("raw_credit_card", None)
return resultHooks til udgående kald: Beskyttelse af handlinger
Spejlbilledet af PostToolUse er en hook til udgående kald: Den sidder mellem modellens beslutning om at handle og den faktiske udførelse af handlingen.
Det er her, du blokerer handlinger, der overtræder politikken — en tilbagebetaling på over 500 $, en e-mail til et ikke-godkendt domæne eller sletning af en beskyttet ressource. Modellen kan anmode om handlingen; hooken beslutter, om den udføres.
Denne adskillelse er arkitekturen: Modellen foreslår, og deterministisk kode afgør — men kun for det lille sæt regler, der reelt kræver en garanti.
def on_outgoing_call(action):
if action.type == "refund" and action.amount > 500:
raise PolicyViolation("Refund exceeds $500 ceiling")
if action.type == "refund" and not action.customer_verified:
raise PolicyViolation("Customer identity not verified")Sådan aflæser du signalet i et scenarie
Opgavescenarier afslører svaret gennem deres formuleringer. Træn dig selv i at få øje på det:
- Ord som "må aldrig," "finansiel," "compliance," "sikkerhed," "lovgivningsmæssig," eller en fast beløbsgrænse → svaret omfatter en hook / deterministisk håndhævelse.
- Ord som "foretræk," "tone," "stil," "som regel," "når det er passende" → en prompt er fin.
Hvis en mulighed foreslår at håndhæve en hård og dyr regel med "en stærkere systemprompt", er den næsten helt sikkert en distraktion.
Kombinér begge lag
De stærkeste designs bruger begge. Prompten får modellen til at ville gøre det rigtige 90 % af tiden — færre blokerede forsøg, mere gnidningsfri samtaler og bedre UX. Hooken fanger de resterende 10 % med en hård garanti.
Brug en prompt til god standardadfærd og en hook til den grænse, der ikke kan fraviges. Du får et system, der både er intelligent og dokumenterbart sikkert — vejledning i det almindelige tilfælde og deterministisk håndhævelse i det katastrofale.
# Layer 1 (prompt, ~90%): set the right default behavior
system = "Confirm customer identity before any refund, and keep refunds under $500."
# Layer 2 (hook, 100%): the guarantee the prompt can't make
hooks = [require_verified_identity, block_large_refund]Hurtigt tjek: Håndhævelse af tilbagebetalingspolitik
Anvend beslutningsreglen på et virkeligt scenarie.
Opsummering: 100 % mod ~90 %
Vigtigste pointer:
- Prompts er ~90 % sandsynlighedsbaseret vejledning; hooks er 100 % deterministisk håndhævelse.
- Brug hooks, når fejl har finansielle, juridiske eller sikkerhedsmæssige konsekvenser; brug prompts til tone, præferencer og blød adfærd.
- PostToolUse-hooks beskytter resultater, før modellen ser dem; hooks til udgående kald blokerer handlinger, der overtræder politikken, før de udføres.
- Programmatisk forudsætninger (blokér en tilbagebetaling, indtil identiteten er verificeret) giver garantier, som prompts ikke kan give.
- Reserver hardkodning til garantier — hold loopet modelstyret, og kombinér en god prompt (standardadfærd) med en hook (hård grænse).
- Vær skeptisk over for ethvert svar, der håndhæver en kritisk og dyr regel med "en stærkere prompt" alene.
Lær Python med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 26
- Lektioner
- 104
Ofte stillede spørgsmål
Er lektionen “Deterministisk håndhævelse vs. prompts” gratis?
Ja — alle 3 lektioner i læringssporet Claude Architect, inklusive “Deterministisk håndhævelse vs. prompts”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Claude Architect-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Deterministisk håndhævelse vs. prompts”?
Hooks er 100 % sikre; prompts er cirka 90 % sandsynlige Du øver dig i Claude Architect med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på Claude Architect?
Der kræves ingen tidligere erfaring. Claude Architect på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.
Hvor lang tid tager lektionen “Deterministisk håndhævelse vs. prompts”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne Claude Architect-lektion?
Ja. Alle Claude Architect-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- PostToolUse- og outgoing-call-hooks
- Deterministisk håndhævelse vs. prompts
- Programmatiske forudsætninger
- Strukturerede overdragelsesprotokoller