Modelstyrede vs. hardcodede beslutninger
Lad modellen beslutte, og brug kode til garantier
Modelstyrede vs. hardcodede beslutninger 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 beslutte på
Enhver agent, du bygger, skal træffe beslutninger. Hvem der træffer dem, er designvalget.
Der er to muligheder:
- Modelstyret: Claude ser på situationen og vælger det næste trin.
- Hardkodet: Din kode gennemtvinger trinnet uanset hvad.
Reglen til eksamen er: Lad modellen beslutte, og gem hardkodning til garantier, som du ikke har råd til at få forkert.
Hvorfor modellen bør styre
Virkelige opgaver er åbne. Rækkefølgen af trin er ikke kendt på forhånd.
En kundemeddelelse kan kræve ét opslag eller tre. En researchopgave kan forgrene sig på måder, du ikke kan forudsige. Claude læser den aktuelle kontekst ved hvert samtaletrin og tilpasser sig.
Hvis du hardcoder vejen, låser du agenten fast i ét stift script. Det går i stykker, så snart virkeligheden afviger fra din plan. Derfor er standardvalget: Giv Claude værktøjer, og lad den vælge.
Den agentbaserede løkke
Her er den modelstyrede løkke. Du sender hele meddelelseshistorikken ved hvert samtaletrin (modellen gemmer ingen tilstand). Derefter undersøger du stop_reason:
tool_use→ Kør værktøjet, føj resultatet til, og kør løkken igen.end_turn→ Modellen er færdig. Stop.
Modellen beslutter, hvad der skal ske; din kode udfører og gentager blot løkken.
while True:
resp = client.messages.create(
model="claude-opus-4-8",
max_tokens=16000,
tools=tools,
messages=messages, # FULL history every turn
)
messages.append({"role": "assistant", "content": resp.content})
if resp.stop_reason == "end_turn":
break
if resp.stop_reason == "tool_use":
results = run_tools(resp.content)
messages.append({"role": "user", "content": results})Stop ved signalet, ikke ved ordene
Hvordan ved du, at agenten er færdig? Afslut ved stop_reason — aldrig ved at lede i teksten efter ord som "done" eller "finished".
At analysere tekst for færdighedssignaler er et klassisk antipattern. Modellen kan sige "I'm done thinking" midt i en opgave eller slet ikke sige "done". Den strukturerede stop_reason er det ægte, pålidelige signal.
# WRONG — parsing text for a completion word
if "done" in resp.content[0].text.lower():
break
# RIGHT — terminate on the structured stop signal
if resp.stop_reason == "end_turn":
breakIterationsgrænser er et sikkerhedsnet
Du kan tilføje et maksimalt antal iterationer i løkken. Det er fint — men du skal forstå dens rolle.
En iterationsgrænse er et sikkerhedsnet, der stopper en løkke, som løber løbsk. Den er aldrig den primære stopmekanisme. Det primære stop er altid stop_reason == "end_turn".
Hvis din agent normalt kun bliver færdig ved at nå grænsen, er beslutningslogikken fejlbehæftet — du hardcoder det, som burde være modelstyret.
MAX_TURNS = 20 # safety net only
for turn in range(MAX_TURNS):
resp = client.messages.create(
model="claude-opus-4-8", max_tokens=16000,
tools=tools, messages=messages,
)
messages.append({"role": "assistant", "content": resp.content})
if resp.stop_reason == "end_turn":
break # the REAL exit
messages.append({"role": "user", "content": run_tools(resp.content)})Når koden skal garantere noget
Nu kommer den anden halvdel af reglen. Nogle resultater er for vigtige til at overlade til en probabilistisk model.
En prompt er omtrent 90 % pålidelig — den følger normalt instruktionerne, men ikke altid. For regler med økonomiske, juridiske eller sikkerhedsmæssige konsekvenser er "normalt" ikke godt nok.
Til den slags reserverer du hardkodet kode, som er 100 % deterministisk. Det er det ene sted, hvor du tager beslutningen væk fra modellen.
Hooks håndhæver de faste grænser
Det deterministiske værktøj til dette er en hook. En hook opfanger en handling og kan blokere den, før den overhovedet sker — med 100 % sikkerhed.
Et klassisk eksempel: "refunder aldrig mere end 500 $". Du skriver ikke dette som en promptinstruktion. Du skriver det som en hook på udgående kald, der blokerer enhver refundering over grænsen hver eneste gang.
Hooks til garantier, prompts til vurderinger.
# Deterministic policy hook — runs before the refund tool executes
def before_process_refund(tool_input):
if tool_input["amount"] > 500:
return {
"block": True,
"reason": "Refunds over $500 require human approval.",
}
return {"block": False}Programmeringsmæssige forudsætninger
Den samme idé gælder for forudsætninger — ting, der skal være sande, før en handling køres.
Eksempel: Behandl aldrig en refundering, før kundens identitet er bekræftet. Vejledning i prompten ("bekræft identiteten først") er kun cirka 90 % pålidelig. En programmeringsmæssig forudsætning — blokér process_refund, indtil get_customer returnerer et bekræftet ID — er en deterministisk garanti.
Koden håndhæver forudsætningen; modellen beslutter stadig alt andet.
def before_process_refund(tool_input, state):
# Deterministic precondition: identity must be verified first
if not state.get("customer_verified"):
return {"block": True,
"reason": "Call get_customer and verify identity before refunding."}
return {"block": False}Hardcod ikke for meget
Fejlen i den anden retning er lige så dyr: at hardcode beslutninger, som modellen burde træffe.
Hvis du pakker hvert trin ind i forgrenet if/else-logik, har du genopbygget en rigid pipeline og smidt Claudes tilpasningsevne væk. Agenten kan ikke længere håndtere det uventede tilfælde.
Reserver hardkodet kode til det snævre sæt af garantier — penge, jura, sikkerhed og påkrævede forudsætninger. Alt andet forbliver modelstyret.
En klar arbejdsdeling
Saml det som en arbejdsdeling:
- Modellen beslutter: hvilket værktøj der skal kaldes, i hvilken rækkefølge, hvornår opgaven er færdig, og hvordan den kommer sig efter et uventet resultat.
- Koden garanterer: politiske maksimumgrænser (refundering ≤ 500 $), påkrævede forudsætninger (bekræftet ID) og at løkken afsluttes ved
stop_reason.
Modellen styrer forløbet. Koden trækker de faste grænser, som den aldrig kan overskride.
Faste pipelines kontra adaptive
Der er dog en nuance: Ikke alle opgaver er åbne.
- Til en kendt, sekventiel proces er en fast pipeline (promptkædning) fin — trinnene er faktisk faste.
- Til en åben undersøgelse skal du bruge adaptiv dekomponering og lade modellen vælge sin vej.
Så "lad modellen beslutte" gælder, hvor vejen reelt er usikker. Hvor rækkefølgen er virkelig kendt, er struktur passende — du skal bare ikke tvinge struktur ned over problemer, der kræver tilpasningsevne.
Hurtigt tjek
En supportagent må aldrig udstede en refundering på over 500 $. Refunderinger på eller under 500 $ skal håndteres problemfrit i samtalen. Hvad er designet på arkitekturniveau?
Vigtigste pointer
Husk reglen: lad modellen beslutte; reservér koden til garantier.
- Vælg som udgangspunkt modelstyrede beslutninger — Claude tilpasser sig den aktuelle kontekst.
- Styr den agentiske løkke, og afslut ved
stop_reason, aldrig ved at analysere tekst. - Iterationsgrænser er et sikkerhedsnet, ikke det primære stop.
- Brug hooks og programmeringsmæssige forudsætninger til økonomiske, juridiske eller sikkerhedsmæssige regler — 100 % deterministisk mod en prompts cirka 90 %.
- Hardcod ikke for meget: Garantier udgør en snæver grænse, ikke hele agenten.
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 “Modelstyrede vs. hardcodede beslutninger” gratis?
Ja — alle 3 lektioner i læringssporet Claude Architect, inklusive “Modelstyrede vs. hardcodede beslutninger”, 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 “Modelstyrede vs. hardcodede beslutninger”?
Lad modellen beslutte, og brug kode til garantier 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 “Modelstyrede vs. hardcodede beslutninger”?
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
- Hvad gør et system agentisk
- Modelstyrede vs. hardcodede beslutninger
- Hvornår skal De bruge en agent
- Overblik over det agentiske loop