--- title: "Ragionamento con tool: Alpha Evolve e Codex per far risolvere problemi formali a un LLM" description: "Reasoning con tool per risolvere problemi formali: Alpha Evolve, GPT-5.3 Codex, pattern pratici per delegare l'esecuzione algoritmica fuori dal modello." canonical: "https://www.mauriziofonte.it/blog/post/reasoning-tool-use-alpha-evolve-codex-llm-problemi-formali-tutorial.html" author: "Maurizio Fonte" date: "2026-04-22T08:27:44+02:00" modified: "2026-06-19T10:51:42+02:00" section: "AI Development Tools" tags: ["AI Development Tools", "Claude Code"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [AI Development Tools](https://www.mauriziofonte.it/blog/cat/ai-development-tools.html) [Claude Code](https://www.mauriziofonte.it/blog/cat/claude-code.html) # [Ragionamento con tool: Alpha Evolve e Codex per far risolvere problemi formali a un LLM](https://www.mauriziofonte.it/blog/post/reasoning-tool-use-alpha-evolve-codex-llm-problemi-formali-tutorial.html) Mercoledì 22 Aprile 2026, alle 08:27 ![Ragionamento con tool: Alpha Evolve e Codex per far risolvere problemi formali a un LLM](https://www.mauriziofonte.it/image/004320200-reasoning-tool-use-alpha-evolve-codex-llm-problemi-formali-tutorial.jpg) Il 9 aprile 2026 ho fatto un esperimento nella mia sandbox di sperimentazione AI: chiedere a Claude Sonnet 4.6 senza tool di risolvere la Torre di Hanoi con dieci dischi. Dieci minuti di ragionamento, tre tentativi, accuracy zero. La sequenza corretta richiede 1023 mosse ed è impossibile per un LLM produrla senza errori intermedi che invalidano tutto. Poi ho dato allo stesso modello un tool Python executor con la possibilità di scrivere il proprio solver. Quattordici secondi, accuracy 100%, codice pulito, soluzione corretta. Questa è la distinzione operativa fra ragionamento euristico (quello che fa l'LLM) e ragionamento formale (quello che fa un algoritmo): per i problemi formali, il tool use fa la differenza fra fallimento totale e successo certo. Qui il tutorial operativo su come strutturare il tool use per problemi formali, sui pattern reali di Claude, GPT-5 Codex e Gemini, e su come AlphaEvolve ha esteso questo paradigma alla ricerca matematica. ## Perché gli LLM falliscono sui problemi formali senza tool? Un LLM è un predittore del prossimo token. Internamente approssima soluzioni tramite pattern euristici distillati dal training. Per problemi che richiedono precisione formale (aritmetica a più cifre, ricorsione lunga, verifica di vincoli rigidi) la natura stocastica del predittore produce errori cumulativi che scalano con la lunghezza della soluzione. Il paper [The Illusion of Thinking](https://machinelearning.apple.com/research/illusion-of-thinking) di Apple, giugno 2025, ha documentato il collasso sistematico dei reasoning model sulla Torre di Hanoi oltre una certa complessità. Non è un bug del modello, è una proprietà strutturale dell'architettura Transformer: un predittore di token non esegue algoritmi, produce sequenze plausibili. Plausibili su 7 mosse, implausibili su 1023. La soluzione non è rendere l'LLM più grande o più "reasoning-trained". La soluzione è riconoscere cosa sa fare e demandare il resto a tool che eseguono algoritmi formali. ## Step 1: anatomia di un tool use request su Claude API Il protocollo standard 2026 per il tool use è formalizzato via Model Context Protocol (MCP) e via tool schema API di ciascun vendor. Qui un esempio minimo per Claude Python SDK. ```python from anthropic import Anthropic client = Anthropic() tools = [ { "name": "python_executor", "description": "Esegue codice Python in un sandbox isolato e restituisce stdout/stderr/exit_code", "input_schema": { "type": "object", "properties": { "code": {"type": "string", "description": "Codice Python da eseguire"} }, "required": ["code"] } } ] messages = [ {"role": "user", "content": "Risolvi la Torre di Hanoi con 10 dischi. Scrivi il codice, eseguilo, mostra la sequenza delle mosse (solo prime 20 e ultime 20)."} ] response = client.messages.create( model="claude-sonnet-4-6", max_tokens=4096, tools=tools, messages=messages ) ``` Il modello nella risposta include un tool_use block con il codice che vuole eseguire. Il tuo runtime (non il modello) esegue il codice in sandbox isolato, restituisce il risultato come tool_result, il modello processa il risultato e produce la risposta finale. ## Step 2: strutturare il loop agentic con error recovery Il pattern corretto non è single-shot ma un loop agentic che gestisce errori, retry, e termination conditions. ```python def run_agentic_loop(initial_prompt: str, max_steps: int = 10): messages = [{"role": "user", "content": initial_prompt}] for step in range(max_steps): response = client.messages.create( model="claude-sonnet-4-6", max_tokens=4096, tools=tools, messages=messages ) # se il modello ha finito senza tool call, abbiamo la risposta finale if response.stop_reason == "end_turn": return response.content[0].text # altrimenti eseguiamo i tool call messages.append({"role": "assistant", "content": response.content}) tool_results = [] for block in response.content: if block.type == "tool_use": result = execute_tool_safely(block.name, block.input) tool_results.append({ "type": "tool_result", "tool_use_id": block.id, "content": str(result), "is_error": result.get("error") is not None }) messages.append({"role": "user", "content": tool_results}) raise RuntimeError("Max steps reached without termination") ``` Due dettagli critici: `max_steps` è un circuit breaker obbligatorio (senza, un modello può loopare indefinitamente su errori di sua competenza); `is_error: True` nei tool_result è necessario per segnalare al modello che l'esecuzione è fallita, altrimenti il modello può interpretare output vuoti come successo. ## Step 3: sandboxing sicuro dell'executor Un Python executor esposto a un agent è una backdoor delegata se non è sandboxed correttamente. Ho trattato in dettaglio il sandboxing di agent nel mio articolo [sandboxing di agent LLM che eseguono codice arbitrario](https://www.mauriziofonte.it/blog/post/sandboxing-agent-llm-codice-arbitrario-container-effimeri-seccomp.html). Riassumo qui i vincoli minimi. Container effimero per ogni chiamata (docker container con `--rm --network none`). Seccomp filter che blocca syscall pericolose. Capability drop (CAP_NET_RAW, CAP_SYS_ADMIN). Timeout hard (30 secondi per chiamata). Memory limit (512MB). Scrittura filesystem solo in `/tmp` tmpfs ephemeral. Se il tuo executor è un semplice `exec(code)` Python in-process, stai introducendo una RCE delegata in produzione. Se vuoi approfondire come costruisco pipeline agentic con tool use sicuro e governance dei costi, nel [mio hub dedicato allo sviluppo AI](https://www.mauriziofonte.it/ai-aziende/ai-aziende-sviluppo.html) trovo articoli tecnici con metodologia applicata e perimetro dichiarato. ## Step 4: scelta del modello in base al task formale Per task formali il trade-off fra vendor non è lineare. Tre scenari ricorrenti. **Task di coding agentic di lunga durata.** GPT-5.3-Codex (rilasciato 5 febbraio 2026) è specializzato per questo. State-of-the-art su [SWE-Bench Pro](https://openai.com/index/introducing-gpt-5-3-codex/) con copertura su quattro linguaggi (Python, JavaScript/TypeScript, Java, Go). OpenAI riporta >7 ore di lavoro autonomo su refactor complessi. Se il tuo task è "risolvi 50 issue GitHub autonomamente", Codex è la scelta 2026. **Task di ragionamento matematico/scientifico.** GPT-5.4 (5 marzo 2026) al 57,7% su SWE-Bench Pro e migliore conoscenza world-knowledge del Codex. Claude Opus 4.7 al 64,3% su SWE-Bench Pro (con caveat di possibile memorization su una parte di problemi, come segnalato da OpenAI). Gemini 3.1 Pro con Computer Use nativo per workflow che richiedono browser automation. **Task con tool use molto stretto (solo executor).** Differenze fra vendor si assottigliano. Claude e GPT-5 si comportano entrambi bene. La scelta dipende più da pricing, latenza, integrazione esistente. ## Step 5: come AlphaEvolve estende il paradigma del tool use a ricerca scientifica [AlphaEvolve](https://arxiv.org/abs/2506.13131) di DeepMind (paper 17 giugno 2025, Novikov et al.) è l'esempio più rigoroso del 2025 di agent evoluzionario che combina LLM e verifier esterno. Non è un LLM, è un ensemble: Gemini Flash per ampiezza esplorativa, Gemini Pro per profondità, verifier automatico (human-coded, non LLM) che filtra le proposte. Il risultato mathematico più celebre: algoritmo per moltiplicare matrici 4x4 complesse in 48 scalar multiplications, primo miglioramento in 56 anni sull'algoritmo di Strassen. Ha risolto nuove configurazioni per il kissing number problem in 11 dimensioni (593 sfere). Ha prodotto costruzioni nuove per il finite field Kakeya problem in 3, 4, 5 dimensioni, in collaborazione con Fields Medalist Terence Tao. La lezione architetturale trasferibile a pipeline enterprise: il miglioramento viene dalla combinazione di LLM creativo + verifier deterministico + loop evoluzionario, non dall'LLM da solo. Se il tuo task ha una funzione di verifica deterministica (test unitari, check di vincoli, validatore) puoi costruire un agent che itera cento varianti finché il verifier non è soddisfatto. Non è sempre economico (costa in token) ma è il pattern che estrae valore massimo dalla creatività del modello. ## Step 6: error handling e retry policy Quattro errori ricorrenti nella mia pipeline sandbox, con contromisure. **Loop infinito di self-correction.** Il modello fallisce, riprova, rifallisce uguale, riprova. Contromisura: circuit breaker su `max_steps`, exponential backoff sul retry, se il modello ripropone lo stesso codice due volte consecutive, termina. **Allucinazione di API non esistenti.** Il modello invoca funzioni che non ha dichiarato nel proprio schema. Contromisura: validation strict dello schema tool_use_id contro la tool list registrata; rifiuta chiamate out-of-schema. **Overreliance sul reasoning trace.** Il modello ragiona correttamente e poi produce codice che non corrisponde al ragionamento. Contromisura: il codice va validato per conto suo, mai fidarti del trace come garanzia. **Tool output troncato.** Il tool restituisce 50KB di output ma solo i primi 4KB arrivano al modello per context budget. Contromisura: tool output summarization prima del feedback al modello. ## Step 7: misurare recovery rate quando il tool fallisce La metrica operativa che tengo in dashboard per ogni agent tool-enabled: il recovery rate dopo il primo fallimento. Quando un tool fallisce al primo tentativo (es. `ZeroDivisionError`), quante volte il modello riesce a risolvere nel tentativo successivo? Su Claude Sonnet 4.6 nella mia sandbox il recovery rate è circa 78%; su modelli più piccoli scende sotto il 50%. Se il recovery rate è basso, il tuo agent è in realtà un chatbot con un tool attaccato, non un sistema autonomo. Un recovery rate <60% rende l'automazione non affidabile in produzione senza human-in-the-loop intensivo. ## Pattern concreti: tre casi di tool use nella mia pipeline Tre esempi operativi da 18 mesi di agent tool-enabled nel mio laboratorio. **Caso 1: validation di partite IVA italiane.** Un agent riceve una lista di partite IVA estratte da documenti OCR, deve validarle. L'algoritmo di check-digit è deterministico (Luhn-like specifico italiano). Sprint 1: chiesto al modello di validare "ragionando". Accuracy 73% su 500 esempi a causa di errori di calcolo intermedi. Sprint 2: fornito un tool `validate_piva(code)` che implementa l'algoritmo. Accuracy 99,8%. Il 0,2% residuo è costituito da input ambigui (spazi nascosti, caratteri Unicode invisibili). Il costo operativo è sceso perché il modello chiama il tool una volta per partita IVA senza ragionare. **Caso 2: calcoli fiscali per fatturazione elettronica.** Un agent calcola aliquote, ritenute, bolli. Senza tool e a bassa complessità il modello sa rispondere; con regimi fiscali complessi (regime forfettario vs ordinario + ritenuta d'acconto + cassa professionale) accuracy crolla a 40%. Fornito un tool che chiama un calcolatore fiscale deterministico (scritto in Python da un dottore commercialista), accuracy torna al 100%. Il modello fa da orchestrator, non da calcolatore. **Caso 3: debug di stack trace PHP.** Come descritto nel mio articolo su [AI-assisted debugging](https://www.mauriziofonte.it/blog/post/ai-assisted-debugging-claude-stack-trace-root-cause-workflow.html), l'agent ha un tool `read_file(path, start, end)` e un tool `grep_codebase(pattern)`. Senza questi tool il modello può solo ragionare sul testo dello stack trace; con, naviga attivamente il codice e trova root cause in minuti invece che in ore. Qui il tool non sostituisce l'LLM, lo estende con capacità di retrieval mirate. ## Il pattern "verifier pair": come AlphaEvolve lo ha codificato Un contributo architetturale importante di AlphaEvolve è la formalizzazione del pattern *verifier pair*: il LLM produce un candidato di soluzione (creativo ma fallibile), un verifier deterministico (non-LLM, human-coded) valuta se la soluzione è corretta. Se non lo è, feedback torna al LLM, che produce un nuovo candidato. Loop evoluzionario. Questo pattern è replicabile in scala PMI. Esempio: un agent che genera regole di business per un gestionale, un verifier che esegue le regole contro un set di test case storici, feedback automatico al modello. Il verifier non deve essere sofisticato; deve essere deterministico e veloce. 50 iterazioni di LLM + verifier costano tipicamente meno di un'ora di lavoro di uno sviluppatore senior, ma producono soluzioni validate in modo oggettivo. La lezione architetturale: quando progetti un agent, chiediti sempre se il task ha un verifier deterministico. Se sì, costruiscilo prima del prompt engineering. Il verifier è il moltiplicatore di qualità; l'LLM è il generatore di candidati. Se il verifier è troppo lento per essere in loop, puoi cachare risposte verificate e far apprendere al modello via few-shot progressivo dagli esempi che passano la verifica; anche questo è un pattern scalabile su hardware modesto e preserva la qualità nel medio termine, anche quando i costi API dovrebbero imporre una riduzione del numero di iterazioni. ## Edge case: quando il tool use NON risolve il problema Tre categorie di task dove anche con tool l'LLM resta limitato. - *Problemi NP-hard con soluzione enumerativa illimitata.* L'LLM scrive il solver corretto ma il solver non termina in tempo utile. - *Problemi dove la specifica è ambigua.* Anche con executor perfetto, se la specifica del task è ambigua il modello risolve il problema sbagliato. - *Problemi dove i dati sono corrotti.* L'LLM e il tool entrambi lavorano su garbage input; il verifier detecta inconsistenza ma l'output è garbage out. Strutturare il tool use in modo corretto è la differenza tra un LLM che fa chiacchiere e un sistema AI che risolve problemi. Le otto lezioni architetturali sopra non sono opzionali: il recovery rate basso in produzione, i loop infiniti non monitorati, il Python executor in-process senza sandbox sono incidenti che capitano e che un consulente senior evita a monte. Se hai un progetto agentic in cui il tool use è componente critica e vuoi capire se l'architettura proposta regge a un task formale reale, il [modulo di preventivo gratuito](https://www.mauriziofonte.it/pages/preventivo-gratuito.html#consulenza-ai) ti risponde in due minuti se il caso rientra nel mio ambito. Il reasoning euristico dell'LLM è la parte creativa del sistema; il tool use e il verifier deterministico sono la parte che fa la differenza fra creativo ma sbagliato e creativo e corretto. L'architettura che regge in produzione nel 2026 non è "un LLM più grande", è un LLM accoppiato a tool ben sandboxed, a un verifier deterministico e a un loop agentic con recovery rate misurabile. Ogni singolo pezzo è ingegneria nota, la somma è quello che separa un chatbot da un sistema AI che sostituisce il tempo di uno sviluppatore senior. Dall'articolo al lavoro vero Se vuoi portarlo dentro la tua azienda RAG sui documenti interni, automazioni con LLM, governance e costi prevedibili. [Vedi come lavoro sull AI](https://www.mauriziofonte.it/ai-aziende.html) Ultima modifica: Venerdì 19 Giugno 2026, alle 10:51 [« Articolo precedenteLa cascata sistemica del coding AI: vulnerabilità, paradosso di produttività, collasso della carriera junior21 Aprile 2026](https://www.mauriziofonte.it/blog/post/ai-coding-cascata-sistemica-vulnerabilita-produttivita-junior.html)[Articolo successivo »Oltre lo specs-to-code: design concept, ubiquitous language e TDD per non annegare nell'output AI22 Aprile 2026](https://www.mauriziofonte.it/blog/post/oltre-specs-to-code-design-concept-ubiquitous-language-tdd.html) ### Articoli correlati a Ragionamento con tool: Alpha Evolve e Codex per far risolvere problemi formali a un LLM - [Large reasoning model e paper Apple: tre regimi di performance, collasso e confronto con i modelli base](https://www.mauriziofonte.it/blog/post/large-reasoning-model-tre-regimi-collasso-illusion-of-thinking-apple.html) The Illusion of Thinking di Apple arxiv 2506.06941, Shojaee et al. giugno 2025 ha documentato tre regimi di performance dei LRM: bassa complessità · 28 Aprile 2026 ![Large reasoning model e paper Apple: tre regimi di performance, collasso e confronto con i modelli base](https://www.mauriziofonte.it/image/004340070-large-reasoning-model-tre-regimi-collasso-illusion-of-thinking-apple.jpg) - [Agente AI per analisi tecnica di codebase PHP legacy: architettura con Claude API e tool use](https://www.mauriziofonte.it/blog/post/agente-ai-analisi-codebase-php-legacy-claude-api-tool-use.html) Il primo giorno su un progetto legacy è sempre disorientante: migliaia di file, zero documentazione, tempo limitato. Ho costruito un agente AI · 30 Marzo 2026 ![Agente AI per analisi tecnica di codebase PHP legacy: architettura con Claude API e tool use](https://www.mauriziofonte.it/image/004010070-agente-ai-analisi-codebase-php-legacy-claude-api-tool-use.jpg) - [Costruire un agente AI per l'analisi tecnica di codebase PHP legacy con Claude API](https://www.mauriziofonte.it/blog/post/agente-ai-analisi-codebase-php-legacy-claude-api.html) Quando mi consegnano un progetto PHP legacy senza documentazione, la prima settimana è sempre la stessa: leggere codice, mappare dipendenze, · 4 Novembre 2025 ![Costruire un agente AI per l'analisi tecnica di codebase PHP legacy con Claude API](https://www.mauriziofonte.it/image/002310070-agente-ai-analisi-codebase-php-legacy-claude-api.jpg) - [Lo strawberry problem e l'aritmetica degli LLM: diagnosi di quando NON usare un modello linguistico](https://www.mauriziofonte.it/blog/post/strawberry-problem-aritmetica-llm-quando-non-usare-modelli-linguistici.html) Chiedi a GPT 5.4 quante R ci sono in strawberry e può ancora sbagliare. Chiedigli di moltiplicare due numeri di venti cifre e collassa. Non è · 21 Mag 2026 ![Lo strawberry problem e l'aritmetica degli LLM: diagnosi di quando NON usare un modello linguistico](https://www.mauriziofonte.it/image/004470070-strawberry-problem-aritmetica-llm-quando-non-usare-modelli-linguistici.jpg) - [Chain-of-thought: quando attivarlo e quando disattivarlo: checklist in sette criteri](https://www.mauriziofonte.it/blog/post/chain-of-thought-llm-quando-usare-checklist-criteri-pipeline.html) Chain of thought nel 2022 ha sbloccato il ragionamento negli LLM; nel 2026 è tra i principali contributori a latenza, costi e overthinking. Il · 24 Aprile 2026 ![Chain-of-thought: quando attivarlo e quando disattivarlo: checklist in sette criteri](https://www.mauriziofonte.it/image/004330070-chain-of-thought-llm-quando-usare-checklist-criteri-pipeline.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Ragionamento con tool: Alpha Evolve e Codex per far risolvere problemi formali a un LLM", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/reasoning-tool-use-alpha-evolve-codex-llm-problemi-formali-tutorial.html Pubblicato: 2026-04-22 · Aggiornato: 2026-06-19. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.