LangGraph, OpenAI Agents SDK e Microsoft Agent Framework: come scegliere sul proprio processo

Parti dal requisito che potrebbe escludere un candidato

Una demo che risponde bene non spiega che cosa succede quando il processo resta sospeso per una notte, cambia il revisore o il gestionale registra una scrittura senza restituire la conferma. Per scegliere un framework descrivi prima quelle situazioni. Poi chiedi quale componente le gestisce, quale codice occorre aggiungere e quale evidenza dimostrerà il risultato.

La guida generale agli agenti AI affronta architettura, strumenti e rilascio. Qui il compito è più circoscritto: costruire una decisione confrontabile fra implementazioni candidate, con riferimenti documentali e prove ancora da eseguire. Il linguaggio considerato è Python. Le omonime librerie JavaScript, .NET o Go richiedono una valutazione separata.

Nota editoriale: articolo della Redazione Niuexa realizzato con assistenza AI. Fonti verificate il 6 novembre 2026. Gli esempi sono sintetici e il protocollo è proposto: non presentiamo risultati di laboratorio o di clienti.

Dividi i requisiti in obbligatori e preferenze. Un controllo di accesso indispensabile non può essere compensato da una demo più rapida. Per ogni requisito scrivi l’effetto atteso, chi lo accetta e quale prova conserverai. “Supporta la memoria” è troppo generico; “dopo il riavvio recupera la pratica sospesa e mostra al revisore gli stessi dati” è verificabile.

Fissa versioni e confini prima di leggere la matrice

La tabella seguente identifica gli snapshot Python controllati nella documentazione e nel repository ufficiale. Non indica pacchetti installati o testati da Niuexa, né garantisce che una guida online descriva soltanto quel tag. Nel proprio pilot occorre fissare anche dipendenze, adattatori e backend di salvataggio effettivamente usati.

Conserva file delle dipendenze risolte, versione dell’applicazione, schema dei dati, istruzioni e definizioni dei tool. Annota modello e parametri esposti dal provider; se un identificativo è aggiornabile dal fornitore, non descriverlo come immutabile. Questa scheda permette di ricostruire il confronto quando cambia una libreria.

Confronta capacità documentate senza trasformarle in un voto

La matrice riassume meccanismi documentati, non qualità misurate. Una voce presente significa che esiste un punto da implementare e provare. Non stabilisce che le tre soluzioni offrano la stessa semantica o che ogni applicazione costruita con esse soddisfi il requisito.

Le fonti di lettura sono overview, persistence e interrupts di LangGraph; approvazioni e sessioni OpenAI; checkpoint e interazioni esterne Microsoft.

LangGraph non richiede LangChain: la sua documentazione lo presenta come livello di orchestrazione per controllare stato e flusso. Questa distinzione aiuta a non acquistare o progettare automaticamente un insieme di componenti solo perché compaiono negli esempi. Per ciascun candidato disegna che cosa resta nell’applicazione, che cosa viene salvato e quali servizi esterni sono necessari.

Prova separatamente conversazione, ripresa ed effetto aziendale

Tre domande sembrano simili ma chiedono prove differenti. Il sistema ricorda che cosa è stato detto? Può continuare il lavoro dal punto previsto dopo un’interruzione? L’azione nel sistema destinatario è avvenuta una sola volta, con i dati autorizzati? Un esito positivo sulla prima domanda non chiude le altre due.

Nel modello documentato da LangGraph, riprendere dopo un interrupt comporta la riesecuzione del nodo dall’inizio. Collocare una scrittura prima della pausa richiede quindi particolare attenzione al suo comportamento durante la ripresa. Il confine fra retry e idempotenza distingue la ripetizione del nodo dalla protezione dell’effetto esterno; la conferma mancante va trattata come esito sconosciuto finché non viene riconciliata.

Nell’Agents SDK, la cronologia della Session e il RunState sospeso hanno ruoli distinti. La guida alle approvazioni documenta la serializzazione e la ripresa, ma precisa anche che il caricamento non autentica lo snapshot o chi lo presenta. La verifica dell’identità, della proprietà del lavoro e dell’integrità dello stato resta un compito dell’applicazione. Conservare dati non significa aver autorizzato chi li usa.

I checkpoint dei workflow Microsoft vengono descritti in relazione ai superstep, con stato degli esecutori, messaggi e richieste. Nel pilot verifica il punto di salvataggio realmente raggiunto prima dell’arresto, non soltanto la presenza di un file. Verifica inoltre come una nuova versione del workflow tratta i lavori precedenti: un riavvio con lo stesso codice e un aggiornamento applicativo sono prove diverse.

Prepara un caso sintetico uguale per tutti i candidati

Considera il seguente scenario interamente inventato: una richiesta DEMO-17 chiede di aggiornare un recapito in un gestionale di prova. Il valore originale è SEDE-A, quello proposto è SEDE-B. Un operatore può leggere la proposta; soltanto il ruolo previsto può approvarla. Il tool di scrittura è un simulatore isolato, senza dati personali né collegamenti alla produzione.

La fixture comprende richiesta originale, dati iniziali, risposta attesa del simulatore, regola di approvazione e modalità di lettura successiva. La stessa fixture viene consegnata a ogni implementazione. Non è un test di comprensione di un indirizzo reale: serve a osservare flusso e controlli. Eventuali prove con modello vanno aggiunte come un livello separato.

Questi sono casi di accettazione proposti, non sette prove superate. Le proprietà dipendono dall’implementazione completa. Se un simulatore non può riprodurre il comportamento del gestionale reale, descrivi il limite e prepara una successiva verifica autorizzata nell’ambiente adeguato. Non sostituire l’incertezza con una spunta verde.

Compila un registro comparabile e conserva anche i casi aperti

La seguente intestazione separa versione, caso e risultato. Le due righe dimostrative non contengono misure: indicano esplicitamente una prova non eseguita. Copia il registro, sostituisci i segnaposto e conserva a parte le evidenze autorizzate. È una proposta operativa, non un formato imposto dai framework.

candidato;versione_e_lock;app_version;caso;fixture_version;modello_e_parametri;backend_stato;tentativo;esito;effetto_osservato;evidenza;limite
CANDIDATO-DEMO;DA-FISSARE;APP-DEMO;P02;FIXTURE-DEMO-1;DA-FISSARE;DA-FISSARE;NON-ESEGUITO;NON-ESEGUITO;NON-OSSERVATO;NESSUNA;scenario sintetico
CANDIDATO-DEMO;DA-FISSARE;APP-DEMO;P05;FIXTURE-DEMO-1;DA-FISSARE;DA-FISSARE;NON-ESEGUITO;NON-ESEGUITO;NON-OSSERVATO;NESSUNA;scenario sintetico

Definisci prima cosa significa “superato”, “fallito”, “non eseguito” e “inconcludente”. Un arresto prima del punto da osservare può rendere la prova inconcludente, non dimostrare che il controllo funziona. Registra quanti tentativi erano previsti, quanti sono stati eseguiti e quali sono rimasti aperti. Evita una percentuale che nasconde i casi non ottenuti.

Per isolare l’orchestrazione puoi iniziare con risposte del modello e tool simulati. Successivamente introduci il modello reale, lo stesso campione autorizzato, gli stessi strumenti e i parametri confrontabili. Se cambiano più componenti, il confronto riguarda le soluzioni complete. Mantieni le tracce sufficienti a ricostruire la decisione senza riversare credenziali o interi documenti nei log.

Misura il lavoro necessario per mantenere il controllo

L’esito tecnico va affiancato all’onere di gestione. Registra tempo di implementazione e diagnosi, componenti aggiunti, conoscenze richieste, consumi, storage e attività manuali. Fissa prima l’inizio e la fine delle misure. Non confrontare un prototipo costruito dal team esperto con una prima prova di chi sta imparando senza dichiarare la differenza.

Per le tracce decidi destinazione, accessi e dati ammessi prima di usare informazioni aziendali. La documentazione del tracing OpenAI al tag considerato segnala che input e output possono contenere dati sensibili e descrive le opzioni di raccolta ed esportazione. Per ogni candidato verifica la configurazione effettiva: avere un pannello di osservabilità non dimostra né completezza delle prove né correttezza delle autorizzazioni.

Il modello di costo per il pilot aiuta a collegare consumi e lavoro agli esiti accettati. Per la scelta del framework aggiungi il costo di gestire casi sospesi, aggiornamenti e incidenti. Un minor numero di righe di codice non misura automaticamente queste attività, così come il prezzo del solo pacchetto non rappresenta il costo della soluzione.

Chiudi la scelta con una decisione e un motivo per riaprirla

Prepara una scheda finale con requisiti obbligatori, stato delle prove, limiti, costi osservati e responsabili. Scarta o correggi i candidati che non soddisfano un requisito necessario; confronta le preferenze soltanto tra le opzioni rimaste. Se un fatto è documentato ma non provato nel proprio ambiente, mantieni entrambe le informazioni.

È legittimo scegliere una soluzione più semplice quando il flusso non richiede l’orchestrazione aggiuntiva. È altrettanto legittimo accettare più componenti se una prova dimostra che rendono gestibile un requisito reale. Scrivi il motivo concreto: la decisione deve essere comprensibile anche a chi manterrà il sistema fra sei mesi.

Conserva infine la condizione che riapre la valutazione: nuovo requisito, modifica del gestionale, aggiornamento incompatibile, costo oltre la soglia concordata o incidente non coperto. Per collegare i sistemi usa la guida a MCP, API e webhook; per il processo completo, il runbook email/PDF verso il gestionale. Il framework è una parte della soluzione: la decisione resta verificabile quando ogni confine ha un responsabile e una prova pertinente.

Fonti, versioni e trasparenza editoriale

Fonti primarie consultate il 6 novembre 2026. I tag Python riportati identificano gli snapshot controllati; le guide online possono evolvere indipendentemente. Matrice dei requisiti, fixture e criteri di prova sono proposte della Redazione Niuexa: nessun benchmark dei tre framework è stato eseguito per questo articolo.

• LangGraph, manifest Python al tag 1.2.20, per distinguere il pacchetto core LangGraph dagli SDK e fissare il riferimento di versione.
• LangGraph, overview e controllo dello stato, per il modello a grafo e la distinzione da LangChain.
• LangGraph, persistence, per checkpointer del thread e store tra thread.
• LangGraph, interrupts, per sospensione, ripresa e riesecuzione del nodo.
• LangGraph, fault tolerance, per confine tra retry ed effetti esterni e conferme mancanti.
• OpenAI Agents SDK, approvazioni al tag v0.24.0, per richieste di approvazione, RunState, ripresa e versionamento del lavoro sospeso.
• OpenAI Agents SDK, sessions al tag v0.24.0, per cronologia conversazionale e autorizzazione dell’accesso alle sessioni.
• OpenAI Agents SDK, tracing al tag v0.24.0, per tracce, destinazioni di esportazione e contenuti potenzialmente sensibili.
• Microsoft Agent Framework, manifest core Python al tag python-1.24.0, per il riferimento del pacchetto agent-framework-core 1.24.0.
• Microsoft Agent Framework, workflow checkpoints, per stato, confini di checkpoint e compatibilità della ripresa.
• Microsoft Agent Framework, human-in-the-loop nei workflow, per richieste verso l’esterno e risposte che consentono al workflow di proseguire.

Non estendere le conclusioni ad altri linguaggi, versioni, servizi gestiti o configurazioni senza verifica. La disponibilità di una funzione non dimostra il comportamento della propria integrazione.

Approfondimenti correlati