Decisioni guidate dal modello vs hard-coded
Lasci decidere al modello e riservi al codice le garanzie.
Decisioni guidate dal modello vs hard-coded è una lezione Claude Architect gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Claude Architect, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Claude Architect include 4 lezioni in totale.
Due modi per decidere
Ogni agent che create deve prendere decisioni. Chi le prende è una scelta progettuale.
Esistono due opzioni:
- Guidato dal modello: Claude esamina la situazione e sceglie il passaggio successivo.
- Codificato in modo rigido: il vostro codice impone il passaggio, indipendentemente dalla situazione.
La regola per l'esame è: lasciate decidere al modello e riservate il codice rigido alle garanzie su cui non potete permettervi di sbagliare.
Perché dovrebbe guidare il modello
Le attività reali sono aperte. L'ordine dei passaggi non è noto in anticipo.
Un messaggio del cliente potrebbe richiedere una sola ricerca o tre. Un'attività di ricerca potrebbe diramarsi in modi imprevedibili. Claude legge il contesto aggiornato a ogni turno e si adatta.
Se codificate il percorso in modo rigido, trasformate l'agent in uno script rigido e immutabile. Si rompe non appena la realtà differisce dal vostro piano. Perciò l'impostazione predefinita è: date a Claude dei tool e lasciate che scelga.
Il ciclo agentico
Ecco il ciclo guidato dal modello. A ogni turno inviate la cronologia completa dei messaggi (il modello non mantiene alcuno stato). Poi ispezionate stop_reason:
tool_use→ eseguite il tool, aggiungete il risultato e ripetete il ciclo.end_turn→ il modello ha terminato. Fermatevi.
Il modello decide cosa fare; il vostro codice si limita a eseguire e a ripetere il ciclo.
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})Fermarsi sul segnale, non sulle parole
Come si fa a sapere che l'agent ha terminato? Terminare in base a stop_reason — mai cercando nel testo parole come "done" o "finished".
Analizzare il testo alla ricerca di segnali di completamento è un anti-pattern classico. Il modello potrebbe dire "Ho finito di pensare" a metà dell'attività oppure non dire mai "done". stop_reason, in quanto segnale strutturato, è il riferimento reale e affidabile.
# 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":
breakI limiti di iterazione sono una rete di sicurezza
È possibile impostare un numero massimo di iterazioni del ciclo. Va bene, ma è importante comprenderne il ruolo.
Un limite di iterazione è una rete di sicurezza che interrompe un ciclo fuori controllo. Non è mai il meccanismo di arresto principale. L'arresto principale è sempre stop_reason == "end_turn".
Se normalmente l'agent termina solo raggiungendo il limite, la logica decisionale è errata: state codificando manualmente ciò che dovrebbe essere deciso dal modello.
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)})Quando il codice deve garantire
Vediamo ora l'altra metà della regola. Alcuni risultati sono troppo importanti per essere lasciati a un modello probabilistico.
Un prompt è affidabile all'incirca al 90%: in genere segue le istruzioni, ma non sempre. Per le regole con conseguenze finanziarie, legali o relative alla sicurezza, "in genere" non è sufficiente.
In questi casi si ricorre al codice rigido, che è deterministico al 100%. Questo è l'unico ambito in cui si sottrae la decisione al modello.
Gli hook impongono i limiti inderogabili
Lo strumento deterministico per questo scopo è un hook. Un hook intercetta un'azione e può bloccarla prima che venga eseguita, con certezza assoluta.
Un esempio classico: "non rimborsare mai più di 500 $". Questa regola non va scritta come istruzione nel prompt. Va implementata come hook sulle chiamate in uscita, che blocchi ogni rimborso oltre il limite, sempre.
Hook per le garanzie, prompt per il giudizio.
# 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}Precondizioni programmatiche
La stessa idea si applica alle precondizioni, cioè alle condizioni che devono essere vere prima dell'esecuzione di un'azione.
Esempio: non elaborare mai un rimborso prima di aver verificato l'identità del cliente. Le istruzioni nel prompt ("verifichi prima l'identità") sono affidabili solo per circa il 90%. Una precondizione programmatica — bloccare process_refund finché get_customer non restituisce un ID verificato — offre una garanzia deterministica.
Il codice impone la precondizione; il modello continua a decidere tutto il resto.
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}Non codificate tutto in modo rigido
L'errore nella direzione opposta è altrettanto costoso: codificare manualmente decisioni che dovrebbe prendere il modello.
Se racchiudete ogni passaggio in una logica ramificata if/else, avete ricostruito una pipeline rigida e rinunciato all'adattabilità di Claude. L'agent non è più in grado di gestire i casi imprevisti.
Riservate il codice rigido al ristretto insieme di garanzie: denaro, legge, sicurezza e precondizioni obbligatorie. Tutto il resto rimane guidato dal modello.
Una chiara divisione dei compiti
Riassumiamo questa divisione dei compiti:
- Il modello decide: quale strumento chiamare, in quale ordine, quando l'attività è completa e come recuperare da un risultato imprevisto.
- Il codice garantisce: i limiti stabiliti dalle policy (rimborso ≤ 500 $), le precondizioni obbligatorie (ID verificato) e la terminazione del ciclo in base a
stop_reason.
Il modello guida il percorso. Il codice traccia i confini invalicabili.
Pipeline fisse e adattive
Una precisazione: non tutte le attività sono aperte.
- Per un processo noto e sequenziale, una pipeline fissa (concatenazione di prompt) va bene: i passaggi sono davvero fissi.
- Per un'indagine aperta, usate una decomposizione adattiva e lasciate che sia il modello a scegliere il percorso.
Quindi "lasciate decidere al modello" si applica quando il percorso è realmente incerto. Quando la sequenza è davvero nota, una struttura è appropriata: non imponetela però ai problemi che richiedono adattabilità.
Verifica rapida
Un agent di supporto non deve mai emettere un rimborso superiore a 500 $. I rimborsi fino a 500 $ devono essere gestiti senza intoppi durante la conversazione. Qual è la progettazione corretta a livello architetturale?
Concetti chiave
Ricordate la regola: lasciate decidere al modello; riservate il codice alle garanzie.
- Per impostazione predefinita, affidate le decisioni al modello: Claude si adatta al contesto reale.
- Gestite il ciclo agentic e terminate in base a
stop_reason, mai analizzando il testo. - I limiti di iterazione sono una rete di sicurezza, non l'arresto principale.
- Usate hook e precondizioni programmatiche per le regole finanziarie, legali o relative alla sicurezza: sono deterministici al 100%, contro il circa 90% di affidabilità di un prompt.
- Non codificate tutto in modo rigido: le garanzie definiscono un confine ristretto, non l'intero agent.
Impara Python con un tutor IA — gratis
Scrivi ed esegui vero codice nel tuo browser, ricevi aiuto istantaneo da un tutor IA disponibile 24/7, e riprendi da dove hai lasciato sul web o nell'app.
- Corsi
- 26
- Lezioni
- 104
Domande Frequenti
La lezione «Decisioni guidate dal modello vs hard-coded» è gratuita?
Sì — il testo completo di «Decisioni guidate dal modello vs hard-coded» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Claude Architect, passa a CoddyKit PRO. Il corso Claude Architect include 4 lezioni in totale.
Cosa imparerò in «Decisioni guidate dal modello vs hard-coded»?
Lasci decidere al modello e riservi al codice le garanzie. Eserciti Claude Architect con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare Claude Architect?
Non è richiesta alcuna esperienza precedente. Claude Architect su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.
Quanto tempo richiede la lezione «Decisioni guidate dal modello vs hard-coded»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione Claude Architect?
Sì. Ogni lezione Claude Architect include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Cosa rende agentico un sistema
- Decisioni guidate dal modello vs hard-coded
- Quando usare un agente
- Panoramica del ciclo agentico