Claude Architect · Lektion

Modellstyrda kontra hårdkodade beslut

Låt modellen besluta och reservera kod för garantier.

Lektion 2 av 413 steg

Modellstyrda kontra hårdkodade beslut är en gratis lektion i Claude Architect på CoddyKit. Detta är lektion 2 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 att besluta

Varje agent Ni bygger måste fatta beslut. Vem som fattar dem är designvalet.

Det finns två alternativ:

  • Modelldrivet: Claude granskar situationen och väljer nästa steg.
  • Hårdkodat: Er kod tvingar fram steget, oavsett vad.

Regeln för provet är: låt modellen besluta och reservera hårdkodning för garantier som Ni inte har råd att få fel.

Varför modellen bör styra

Verkliga uppgifter är öppna. Stegens ordningsföljd är inte känd i förväg.

Ett kundmeddelande kan behöva en uppslagning eller tre. En researchuppgift kan ta grenar som Ni inte kan förutse. Claude läser den aktuella kontexten vid varje tur och anpassar sig.

Om Ni hårdkodar vägen låser Ni agenten i ett stelt skript. Det går sönder så fort verkligheten skiljer sig från planen. Därför är standardläget: ge Claude verktyg och låt den välja.

Den agentiska loopen

Här är den modelldrivna loopen. Ni skickar hela meddelandehistoriken vid varje tur (modellen sparar inget tillstånd). Sedan inspekterar Ni stop_reason:

  • tool_use → kör verktyget, lägg till resultatet och kör loopen igen.
  • end_turn → modellen är klar. Stoppa.

Modellen beslutar vad som ska göras; Er kod kör och loopar bara.

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})

Stoppa på signalen, inte på orden

Hur vet du att agenten är klar? Avsluta vid stop_reason — aldrig genom att söka i texten efter ord som "done" eller "finished".

Att tolka text för att hitta tecken på att arbetet är klart är ett klassiskt anti-mönster. Modellen kan säga "I'm done thinking" mitt i en uppgift eller aldrig säga "done" över huvud taget. Den strukturerade stop_reason är den verkliga och tillförlitliga signalen.

# 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":
    break

Iterationsgränser är ett säkerhetsnät

Ni kan lägga till ett maximalt antal loop-iterationer. Det är helt i sin ordning — men förstå dess roll.

En iterationsgräns är ett säkerhetsnät som stoppar en loop som löper amok. Den är aldrig den primära stoppmekanismen. Det primära stoppet är alltid stop_reason == "end_turn".

Om er agent normalt bara blir klar genom att nå gränsen är beslutslogiken felaktig — ni hårdkodar något som borde styras av modellen.

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 måste garantera

Nu till den andra delen av regeln. Vissa resultat är för viktiga för att lämnas åt en probabilistisk modell.

En prompt är ungefär 90 % tillförlitlig — modellen följer vanligtvis instruktionerna, men inte alltid. För regler med ekonomiska, juridiska eller säkerhetsmässiga konsekvenser räcker inte "vanligtvis".

För sådana regler använder ni hårdkodning, som är 100 % deterministisk. Det här är det enda stället där ni tar beslutet från modellen.

Hooks upprätthåller de hårda gränserna

Det deterministiska verktyget för detta är en hook. En hook fångar upp en åtgärd och kan blockera den innan den ens utförs — med 100 % säkerhet.

Ett klassiskt exempel är: "återbetala aldrig mer än 500 dollar." Ni ska inte skriva det som en promptinstruktion. Ni ska skriva det som en hook för utgående anrop, som blockerar alla återbetalningar över gränsen, varje gång.

Hooks för garantier, prompts för bedömningar.

# 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}

Programmässiga förvillkor

Samma idé gäller för förvillkor — sådant som måste vara sant innan en åtgärd körs.

Exempel: behandla aldrig en återbetalning innan kundens identitet har verifierats. Promptvägledning ("verifiera identiteten först") är bara ungefär 90 % tillförlitlig. Ett programmässigt förvillkor — blockera process_refund tills get_customer returnerar ett verifierat ID — är en deterministisk garanti.

Koden upprätthåller förvillkoret; modellen bestämmer fortfarande allt annat.

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}

Hårdkoda inte för mycket

Misstaget åt andra hållet är lika kostsamt: att hårdkoda beslut som modellen borde fatta.

Om ni omsluter varje steg med förgrenad if/else-logik har ni byggt om systemet till en rigid pipeline och kastat bort Claudes anpassningsförmåga. Agenten kan inte längre hantera oväntade fall.

Reservera hårdkodning för den begränsade uppsättningen garantier — pengar, juridik, säkerhet och obligatoriska förvillkor. Allt annat ska fortsätta vara modellstyrt.

En tydlig arbetsfördelning

Sammanfatta det som en arbetsfördelning:

  • Modellen bestämmer: vilket verktyg som ska anropas, i vilken ordning, när uppgiften är klar och hur ett oväntat resultat ska hanteras.
  • Koden garanterar: policygränser (återbetalning ≤ 500 dollar), obligatoriska förvillkor (verifierat ID) och att loopen avslutas vid stop_reason.

Modellen styr förloppet. Koden drar de hårda gränser som den aldrig får överskrida.

Fasta pipelines kontra adaptiva

En nyans är att inte alla uppgifter är öppna.

  • För en känd sekventiell process fungerar en fast pipeline (prompt chaining) bra — stegen är verkligen fasta.
  • För en öppen undersökning använder ni adaptiv uppdelning och låter modellen välja sin väg.

Alltså gäller "låt modellen bestämma" när vägen verkligen är osäker. När sekvensen faktiskt är känd är struktur lämplig — men tvinga inte fram struktur i problem som kräver anpassningsförmåga.

Snabbtest

En supportagent får aldrig utfärda en återbetalning över 500 dollar. Återbetalningar på högst 500 dollar ska hanteras smidigt i konversationen. Vilken design håller arkitektnivå?

Viktiga slutsatser

Kom ihåg regeln: låt modellen bestämma; reservera koden för garantier.

  • Utgå från modellstyrda beslut — Claude anpassar sig till den aktuella kontexten.
  • Driv den agentiska loopen och avsluta vid stop_reason, aldrig genom att tolka text.
  • Iterationsgränser är ett säkerhetsnät, inte det primära stoppet.
  • Använd hooks och programmässiga förvillkor för ekonomiska, juridiska eller säkerhetsmässiga regler — 100 % deterministiskt jämfört med en prompts ungefär 90 %.
  • Hårdkoda inte för mycket: garantier är en smal gräns, inte hela agenten.
Gratis att börja

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 ”Modellstyrda kontra hårdkodade beslut” gratis?

Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Claude Architect, inklusive ”Modellstyrda kontra hårdkodade beslut”, 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 ”Modellstyrda kontra hårdkodade beslut”?

Låt modellen besluta och reservera kod för garantier. 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 2 av 4.

Hur lång tid tar lektionen ”Modellstyrda kontra hårdkodade beslut”?

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

  1. Vad gör ett system agentbaserat
  2. Modellstyrda kontra hårdkodade beslut
  3. När ska du använda en agent
  4. Översikt över den agentbaserade loopen
← Tillbaka till Claude Architect