Blog sugli Agenti AI
SISTEMA DI ACCESSO COMPUTER

Modelli di ragionamento nei flussi agentici: quando il pensiero esteso vale la pena

reasoning models agentsextended thinkingagent reasoningClaude thinkingmodel selection agentshybrid architectures

Il tuo agente orchestratore pianifica un flusso di lavoro di ricerca in 10 fasi. Usando Claude Sonnet standard, produce un piano per lo più corretto ma che non coglie una dipendenza tra i passi 4 e 7: l’analisi al passo 7 ha bisogno di dati prodotti al passo 4 che non erano stati inclusi nel piano. Usando Claude con pensiero esteso, il modello individua la dipendenza, riordina i passi e produce un piano che viene eseguito correttamente al primo tentativo. La chiamata di pianificazione ha richiesto 15 secondi invece di 3 ed è costata 5 volte di più. Ne valeva la pena? Per un flusso di lavoro che fa risparmiare 20 minuti di debug umano—assolutamente sì.

I modelli di ragionamento non sono uniformemente migliori. Eccellono in capacità specifiche: pianificazione, logica a più passi, individuazione di casi limite e analisi complessa. Usarli ovunque è uno spreco. Non usarli mai lascia le performance sul tavolo. L’abilità sta nel sapere quando passare da un modello all’altro—e nel costruire architetture che rendano il passaggio trasparente.

Questo articolo illustra quando i modelli a pensiero esteso migliorano i risultati degli agenti abbastanza da giustificarne il costo, come costruire architetture ibride che usano il ragionamento in modo selettivo e un framework pratico per misurare il ROI.

Cosa fanno diversamente i modelli di ragionamento

Prima di entrare nell’architettura, è utile capire cosa offrono concretamente i modelli di ragionamento rispetto ai modelli standard. Non si tratta degli aspetti interni del modello, ma di differenze di capacità osservabili che influenzano le prestazioni del tuo agente.

Pensiero esteso

Quando abiliti il pensiero esteso su Claude, il modello genera una catena di ragionamento interna prima di produrre la risposta visibile. Sta allocando più risorse computazionali al problema: esplora alternative, verifica le ipotesi e costruisce una comprensione più completa prima di impegnarsi in una risposta.

Pensalo come la differenza tra rispondere immediatamente a una domanda e prendersi un minuto per rifletterci su carta. La risposta potrebbe essere la stessa per domande semplici. Per quelle complesse, il pensiero aggiuntivo produce risultati significativamente migliori.

Qualità della pianificazione

I modelli di ragionamento sono sostanzialmente migliori nei piani a più passi. Rilevano le dipendenze tra i passi, identificano i requisiti delle risorse, anticipano le modalità di fallimento e producono piani che vengono effettivamente eseguiti dall’inizio alla fine senza intervento umano.

I modelli standard spesso producono piani che sembrano ragionevoli ma che si sfaldano durante l’esecuzione—mancano una dipendenza dai dati qui, danno per scontata una risorsa non disponibile là. I fallimenti sono abbastanza sottili da superare una revisione rapida, ma abbastanza costosi da deragliare il flusso di lavoro.

Rilevamento dei casi limite

Il pensiero esteso dà al modello il tempo di considerare input insoliti e condizioni al contorno. Un modello standard potrebbe generare una pipeline di elaborazione dati che funziona per gli input tipici ma va in crash su dataset vuoti o record malformati. Un modello di ragionamento ha più probabilità di includere passi di validazione e gestione degli errori per quei casi.

Auto-correzione

Durante la fase di pensiero, i modelli di ragionamento spesso rilevano e correggono i propri errori. Puoi osservarlo nell’output del pensiero: il modello parte in una direzione, si accorge di sbagliare, torna indietro e prende un approccio migliore. Quando la risposta finale appare, diversi potenziali errori sono già stati individuati e corretti.

Pensiero osservabile

L’output del pensiero esteso di Claude è visibile tramite API. Questo è enormemente prezioso per il debug dei flussi di lavoro agentici. Quando un piano fallisce, puoi leggere il ragionamento del modello per capire perché ha fatto le scelte che ha fatto, invece di trattarlo come una scatola nera. Questa osservabilità da sola può giustificare il costo per flussi di lavoro complessi e ad alto rischio.

Quando il ragionamento migliora le prestazioni degli agenti

Non ogni attività degli agenti beneficia del pensiero esteso. Ecco i tipi di attività in cui i modelli di ragionamento superano costantemente i modelli standard.

Pianificazione dei flussi di lavoro

Scomporre un’attività complessa in passi ordinati con dipendenze è una delle applicazioni di maggior valore. Considera un agente che deve ricercare un argomento, raccogliere dati da più fonti, incrociare i risultati e produrre un report.

Piano con modello standard:

  1. Cerca una panoramica dell’argomento
  2. Raccogli dati dalla fonte A
  3. Raccogli dati dalla fonte B
  4. Analizza i dati
  5. Scrivi il report

Piano con modello di ragionamento:

  1. Cerca una panoramica dell’argomento per identificare i sottotemi chiave
  2. Raccogli dati quantitativi dalla fonte A (filtrando per intervallo di date)
  3. Raccogli dati qualitativi dalla fonte B (usando i sottotemi del passo 1 come query)
  4. Incrocia le fonti A e B per identificare contraddizioni
  5. Per le contraddizioni trovate, raccogli dati aggiuntivi dalla fonte C
  6. Sintetizza i risultati, annotando i livelli di confidenza
  7. Scrivi il report con una sezione sulla metodologia che spiega la provenienza dei dati

Il piano del modello di ragionamento è più robusto perché ha anticipato la necessità dell’incrocio dei dati, ha inserito un passo contingente e ha strutturato l’output con la provenienza.

Generazione di codice

Per funzioni di utilità semplici, i modelli standard vanno bene. Per algoritmi complessi, refactoring multi-file o decisioni architetturali, i modelli di ragionamento producono codice notevolmente migliore.

Un modello standard a cui viene chiesto di implementare un rate limiter potrebbe produrre un token bucket di base. Un modello di ragionamento ha più probabilità di considerare i casi limite—cosa succede quando il clock va all’indietro, come gestire l’accesso concorrente, se il limiter debba essere distribuito—e di produrre codice che li gestisce.

Diagnosi degli errori

Quando un flusso di lavoro agentico fallisce e sono possibili più modalità di errore, i modelli di ragionamento sono migliori nell’analisi della causa principale. Possono tenere in mente più contesto simultaneamente, valutare prove da fonti diverse e tracciare catene causali che i modelli standard spesso tagliano in modo prematuro.

Decisioni con criteri multipli

Quando un agente deve valutare compromessi—scegliere tra strategie di deployment, selezionare lo strumento giusto per un’attività o decidere se riprovare o scalare—i modelli di ragionamento considerano più fattori e producono decisioni più sfumate.

Analisi dei dati

L’interpretazione di dati ambigui, la ricerca di pattern non ovvi e la generazione di ipotesi da informazioni incomplete beneficiano tutte del pensiero esteso. Il modello ha il tempo di considerare spiegazioni alternative invece di saltare alla più ovvia.

Quando il ragionamento non aiuta

Altrettanto importante è sapere quando non usare i modelli di ragionamento. Queste attività non beneficiano del pensiero esteso, e usarlo è semplicemente bruciare denaro e latenza.

Selezione semplice di strumenti

Se un utente chiede “Che tempo fa a Tokyo?” e il tuo agente deve chiamare un’API meteo, non c’è nulla su cui ragionare. I modelli standard gestiscono perfettamente il routing semplice degli strumenti.

Compilazione di template

Generare risposte da template o dati strutturati—compilare template di email, formattare risultati di database, generare notifiche standard—non richiede ragionamento a più passi.

Classificazione e routing

Il rilevamento dell’intento, la categorizzazione e il routing dei messaggi sono attività di pattern matching. I modelli standard sono eccellenti in questo. Un modello di ragionamento potrebbe addirittura pensare troppo a una classificazione semplice, considerando casi limite improbabili che riducono l’accuratezza.

Riassunto

Condensare il testo in forma più breve è un’attività ben compresa che i modelli standard gestiscono in modo affidabile. Salvo che il riassunto richieda inferenze complesse (come identificare contraddizioni tra più fonti), i modelli standard sono sufficienti.

Conversione di formato

Da JSON a CSV, da Markdown a HTML, trasformazione di dati—queste sono attività meccaniche con regole chiare. Il ragionamento non aggiunge nulla.

Regola pratica: Se un’attività ha una risposta chiara a percorso unico che non richiede di valutare alternative o rilevare dipendenze sottili, i modelli standard sono sufficienti. Riserva il ragionamento per le attività in cui sbagliare è costoso.

Architetture ibride

Il vero potere viene dalla combinazione di modelli di ragionamento e standard in un unico sistema. Ecco tre pattern collaudati.

Pattern 1: Ragionamento per la pianificazione, standard per l’esecuzione

Questo è il pattern più comune e spesso di maggior valore. Il tuo orchestratore usa il pensiero esteso per creare un piano accurato. Gli agenti worker usano modelli standard per eseguire i singoli passi all’interno di quel piano.

La logica è semplice: la pianificazione è dove gli errori sono più costosi (un piano sbagliato corrompe ogni passo successivo), e l’esecuzione è dove velocità e costo contano di più (si eseguono molti passi, ciascuno relativamente semplice).

import anthropic
import json
from datetime import datetime


client = anthropic.Anthropic()


def plan_with_reasoning(task: str) -> dict:
    """Use extended thinking for high-quality planning."""
    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=16000,
        thinking={
            "type": "enabled",
            "budget_tokens": 10000
        },
        messages=[{
            "role": "user",
            "content": f"""Create a detailed execution plan for this task.
Include step dependencies, expected outputs, and failure conditions.


Task: {task}


Return the plan as JSON with this structure:
{{
    "steps": [
        {{
            "id": 1,
            "action": "description",
            "depends_on": [],
            "expected_output": "description",
            "failure_condition": "description"
        }}
    ]
}}"""
        }]
    )


    thinking_content = ""
    result_text = ""


    for block in response.content:
        if block.type == "thinking":
            thinking_content = block.thinking
        elif block.type == "text":
            result_text = block.text


    print(f"[Planning] Thinking used: {len(thinking_content)} chars")
    print(f"[Planning] Input tokens: {response.usage.input_tokens}")
    print(f"[Planning] Output tokens: {response.usage.output_tokens}")


    # Extract JSON from the response




---


## Articoli Correlati


- [Ottimizzazione dei costi degli agenti: una guida pratica per ridurre la spesa API](/it/blog/agent-cost-optimization-a-practical-guide-to-reducing-api-spend/)
- [Pattern Multi-Agente: Orchestratori, Worker e Pipeline](/it/blog/multi-agent-patterns/)
- [Recupero Errori degli Agenti: 5 Pattern per l'Affidabilità in Produzione](/it/blog/agent-error-recovery-patterns/)
- [Risposte in Streaming degli Agenti: Output in Tempo Reale per Workflow Multi-Step](/it/blog/streaming-agent-responses-real-time-output-for-multi-step-workflows/)