Architetture di agenti e come valutarli#
Nella sezione sul ciclo dell’agente ne abbiamo costruito uno e l’abbiamo fatto girare: pensa, agisce, osserva, ripete, e quello schema si chiamava ReAct. Su un compito ben delimitato (trova un dato, fai un conto, rispondi) quel ciclo va sorprendentemente lontano.
Ma provate a chiedergli qualcosa di grosso: «prendi questa segnalazione di errore, trova il file giusto in un progetto da centomila righe, scrivi la correzione e verifica che i test passino». Il ciclo ReAct, da solo, si smarrisce: troppe mosse, troppe strade, troppe occasioni per perdere il filo. Un agente che gira da solo non basta più.
Da qui due mosse, ed è di queste che parla la sezione. La prima è pianificare in anticipo invece di reagire un passo alla volta. La seconda è comporre più agenti, ciascuno con un mestiere, come si mette insieme una squadra.
E dietro entrambe si nasconde la domanda più scomoda del campo, quella che nessuno ha davvero chiuso: come si fa a sapere se un agente funziona davvero? Già dare un voto a un modello che si limita a rispondere è difficile, quando la risposta è libera e non esiste una soluzione unica con cui confrontarla; lo vedremo più avanti, nel capitolo su MLOps, che è il mestiere di portare un modello dal laboratorio all’uso di tutti i giorni. Dare un voto a un agente che agisce, in più passi, in un ambiente che cambia sotto i suoi piedi, è molto più difficile ancora.
Pianificare: scomporre il problema#
ReAct ragiona e agisce un passo alla volta: decide la mossa, la esegue, guarda com’è andata, decide la prossima. È flessibile, ma su un compito lungo rischia di procedere a naso, senza una visione d’insieme, e di infilarsi in vicoli ciechi. L’alternativa è ribaltare l’ordine: prima scomporre il problema in un piano di sotto-compiti, poi eseguirli. Questo modo di procedere si chiama plan-and-execute, «pianifica ed esegui».
Pensa a come si fa la spesa. Un modo è entrare al supermercato e decidere scaffale per scaffale, guardandoti intorno: prendo la pasta, ah già mi serviva anche il latte, torno indietro… Funziona per due o tre cose, ma per una spesa grossa giri a vuoto, dimentichi metà roba e ti ritrovi tre volte davanti al banco frigo. L’altro modo è scrivere la lista prima di entrare: la dividi per reparto, e dentro segui l’ordine senza pensarci. Fai meno strada, non dimentichi niente.
Un agente che pianifica fa la seconda cosa. Prima di toccare qualunque strumento, si ferma e scrive il piano: «per sistemare questo bug devo (1), trovare dove nasce l’errore, (2) capire la causa, (3) scrivere la correzione, (4) far girare i test». Poi esegue i punti uno per uno. Il vantaggio è la visione d’insieme; il rischio è che la lista, scritta al buio prima di entrare, non tenga conto di una sorpresa (lo scaffale vuoto, il reparto spostato) e vada rifatta a metà strada.
ReAct intreccia ragionamento e azione a ogni passo: la policy sceglie \(a_t\) guardando solo lo stato corrente \(s_t\), senza un piano globale esplicito. È reattivo (si adatta bene alle sorprese) ma su orizzonti lunghi tende a perdere coerenza, ripetere azioni o divagare. Il pattern plan-and-execute separa due ruoli: un pianificatore produce in un colpo solo una sequenza di sotto-obiettivi \(g_1, \dots, g_k\) che decompongono il compito, e un esecutore li affronta uno per uno (spesso con un mini-loop ReAct dentro ciascuno). Il piano dà struttura, coerenza globale e spesso meno chiamate al modello per il ragionamento di alto livello.
Il compromesso è netto e va dichiarato. Pianificare in anticipo conviene quando il compito è decomponibile e l’ambiente prevedibile: il piano regge fino in fondo. Ma un piano rigido non sa reagire a ciò che non aveva previsto (un test che rivela un secondo bug, un file che non esiste) e allora serve una fase di re-planning: quando un sotto-obiettivo fallisce, si torna dal pianificatore e si aggiorna la lista. È lo stesso spendere-calcolo-per-ragionare che il capitolo sui Transformer chiama «spendere calcolo mentre si risponde», ma speso prima di agire anziché durante: la pianificazione è ragionamento su come muoversi, scritto in anticipo. Nessuno dei due estremi vince sempre; i sistemi robusti mescolano: un piano di massima, rivisto quando la realtà lo smentisce.
Più agenti che collaborano#
Finora un agente, un modello. Ma se un compito ha nature diverse (pianificare, scrivere codice, criticarlo), perché affidarlo a un solo generalista? Nasce l’idea dei sistemi multi-agente: più agenti, ciascuno con un ruolo specializzato, che si passano il lavoro e conversano tra loro.
Fig. 17.12 Uno che divide, l’orchestratore, e tre che eseguono (nel disegno sono etichettati worker, che è il termine inglese per gli esecutori). I tre risultati si ricompongono in una risposta sola. La specializzazione non sta nel modello, che può essere lo stesso per tutti: sta nelle istruzioni e negli strumenti che ciascun ruolo riceve.#
C’è una precisazione che Fig. 17.12 aiuta a fare, e che conviene fare presto: i quattro agenti del disegno possono essere lo stesso identico modello, interpellato quattro volte con quattro fogli di istruzioni diversi (il prompt della sezione precedente). «Multi-agente» descrive come è organizzato il lavoro, non quanti modelli diversi ci sono sotto.
Nel disegno i ruoli sono divisi per mestiere, cioè per lo strumento che ciascuno ha in mano: uno cerca sul web, uno interroga un archivio di dati, uno legge documenti. Ma si possono dividere anche per momento del lavoro, e questa seconda divisione tornerà spesso: un pianificatore scompone il compito, un esecutore lo svolge, un critico rilegge il risultato e segnala gli errori, e il giro ricomincia finché il critico è soddisfatto.
È la differenza tra un artigiano solitario e una piccola bottega. Da solo, fai tutto tu: progetti, costruisci, controlli il tuo stesso lavoro, e proprio perché è il tuo, i difetti tendi a non vederli. In una bottega ci sono ruoli: uno disegna il progetto, uno lo realizza, un terzo (il collaudatore) lo prova e dice cosa non va. Il collaudatore non ha costruito niente, e proprio per questo nota lo scricchiolio che l’artigiano innamorato del proprio lavoro ignorava.
Con gli agenti funziona uguale. Invece di un modello che fa e si giudica da solo, se ne mettono in fila alcuni con compiti diversi, che si scrivono l’un l’altro come colleghi in chat: «ecco il piano», «ecco il codice», «ho provato, il test 3 non passa, correggi qui». La specializzazione aiuta: un critico dedicato pesca errori che l’esecutore non vedeva.
Ma attenzione: più teste vuol dire anche più stipendi. Ogni volta che un agente parla, qualcuno da qualche parte fa lavorare un modello, e quel lavoro si paga a consumo: quattro agenti che si scrivono a vicenda per dieci giri costano quaranta volte una risposta secca. E ci sono più modi di litigare o fraintendersi. Non sempre la bottega batte il buon artigiano.
Un framework che ha reso concreto questo schema è AutoGen [WBZ+24], che modella un sistema multi-agente come una conversazione tra agenti conversabili: ognuno ha un ruolo e un prompt di sistema che lo definisce (assistente, esecutore di codice, revisore, proxy umano), e l’orchestrazione è il protocollo con cui si scambiano messaggi (sequenziale, a turni, o con un agente «manager» che decide chi parla dopo). Lo stesso motore linguistico, istanziato con istruzioni diverse, diventa una squadra.
L’onestà, qui, è d’obbligo, perché è un terreno dove l’entusiasmo corre più dei risultati. Aggiungere agenti non è gratis e non è sempre meglio. Ogni agente in più è contesto in più da riempire e generazioni in più da pagare: il costo cresce con il numero di partecipanti e con i giri di conversazione. E moltiplicare gli agenti moltiplica i modi di sbagliare: un fraintendimento che si propaga, due agenti che entrano in un ping-pong senza convergere, l’errore di uno che diventa la premessa dell’altro. Non è una preoccupazione di principio: Cemri e colleghi [CPY+25] raccolgono oltre milleseicento tracce di esecuzione da sette framework multi-agente e ne ricavano una tassonomia di quattordici modi di fallire, raggruppati in tre famiglie: come è stato progettato il sistema (ruoli e specifiche ambigue), il disallineamento fra gli agenti e la verifica del risultato (nessuno che controlli se il lavoro è fatto). Due famiglie su tre stanno nelle giunture, non dentro il singolo agente, e sono anche le più difficili da correggere, perché nessuno dei partecipanti le vede dal proprio posto.
Chi è andato a controllare se la bottega batte davvero l’artigiano ha trovato due cose, e nessuna delle due fa piacere a chi si entusiasma [CPY+25]. La prima è che il vantaggio di mettere insieme più agenti, sulle prove che si usano oggi, è spesso piccolo. La seconda è dove si sbaglia: non tanto dentro un agente, che di solito il suo pezzo lo fa, quanto nel passarsi il lavoro. Ruoli descritti male, agenti che vanno per conto proprio, e soprattutto nessuno incaricato di controllare se il risultato finale sta in piedi. La regola prudente viene da sé: un ruolo si aggiunge quando risolve un problema che con un agente solo restava aperto, non per il gusto della squadra.
I meccanismi con cui una squadra di agenti si organizza davvero hanno un capitolo tutto loro più avanti, Sistemi multi-agente: là si vedrà quanto costa il coordinamento e quando lo ripaga, chi conviene che parli con chi, come ci si mette d’accordo quando i partecipanti non sono affidabili, e come si può imparare a coordinarsi invece di essere programmati per farlo.
La memoria che dura#
Nella sezione sul contesto abbiamo detto che un agente ha bisogno di uno schedario fuori dalla finestra, e che la sua bravura sta nel pescarne solo la pagina che serve adesso. Restava una domanda: come sceglie quale pagina? Adesso possiamo rispondere, e la risposta è più interessante di quanto sembri, perché non è una sola regola ma tre criteri messi insieme.
Il caso di studio più istruttivo è un piccolo esperimento del 2023 che sembra un videogioco: gli agenti generativi di Park e colleghi [POBrienC+23], che nel titolo originale si chiamano generative agents.
Venticinque agenti abitano un paesino simulato, Smallville: si svegliano, fanno colazione, vanno al lavoro, si incontrano, chiacchierano. Nessuno ha scritto la loro giornata a mano: ciascuno è un modello di linguaggio che decide cosa fare in base a ciò che ricorda. Il risultato più citato è un comportamento che nessuno aveva programmato e che è venuto fuori da sé (si dice che è emerso): un agente decide di dare una festa di San Valentino, ne parla a qualcuno, l’invito si propaga di bocca in bocca per il paese, e la sera diversi agenti si presentano, essendosi coordinati senza che nessuno avesse scritto una riga per farli coordinare. La domanda interessante non è «è vivo?» (non lo è), ma come faccia un modello a comportarsi in modo coerente su un arco di tempo così lungo.
Il segreto è un diario. Ogni agente annota in un quaderno, in frasi normali, tutto ciò che gli capita: «ho fatto colazione al bar», «Maria mi ha detto che organizza una festa». Il quaderno cresce a dismisura (migliaia di righe) e rileggerlo tutto ogni volta è impossibile. Serve quindi un bibliotecario che, quando l’agente deve decidere qualcosa, gli tiri fuori dal quaderno solo le pagine che contano adesso.
E come sceglie quali pagine? Con tre criteri di buon senso. Quanto è recente il ricordo (ciò che è successo un’ora fa pesa più di ieri); quanto è importante (una festa conta più di una colazione qualsiasi); e quanto c’entra con la situazione di adesso (se sto pensando alla festa, ripesco i ricordi sulla festa). Ogni tanto, poi, l’agente si ferma e riflette: rilegge gli ultimi appunti e ne ricava una conclusione più alta («a Maria piace organizzare eventi») che riscrive nel quaderno come un nuovo ricordo. Da questi pensieri più maturi nascono i suoi piani. Ricordare, ripescare, riflettere, pianificare: è così che un mucchio di appunti diventa un comportamento coerente.
L’architettura ha tre pezzi. Il memory stream è un registro append-only di osservazioni in linguaggio naturale, ciascuna con un timestamp. Il recupero seleziona, a ogni decisione, le memorie rilevanti con un punteggio che combina tre segnali normalizzati:
dove \(m\) è una memoria e \(q\) la situazione corrente: \(\text{recency}(m)\) decade esponenzialmente con il tempo trascorso dall’ultimo accesso, \(\text{importance}(m)\) è un voto di salienza (da 1 a 10) che il modello stesso assegna alla memoria quando la scrive, e \(\text{relevance}(m, q)\) è la similarità tra gli embedding della memoria e della query. Nel lavoro originale i pesi \(\alpha\) valgono tutti 1: tre criteri sommati, non uno solo.
Il terzo pezzo è la riflessione: periodicamente l’agente sintetizza dalle memorie recenti alcune inferenze di livello più alto (proposizioni astratte come «Klaus è appassionato di ricerca») e le riscrive nel memory stream come nuove memorie, recuperabili a loro volta. Si forma così un albero: osservazioni grezze in basso, riflessioni via via più astratte in alto. La pianificazione traduce infine queste sintesi in piani giornalieri, decomposti dal grossolano al fine. Il punto architetturale generale, oltre l’esperimento: la memoria a lungo termine di un agente non è «tenere tutto nel contesto», ma memorizzare fuori, recuperare il pertinente, e ogni tanto ricomprimere in astrazioni (lo stesso schema recupera-e-condensa che governa il RAG e il context engineering).
Valutare un agente: il problema difficile#
Arriviamo alla domanda scomoda, e conviene partire dal caso facile per capire quanto questo sia difficile. Si prenda un programma che deve dire se una foto ritrae un gatto o un cane. Gli si dà una fotografia che una persona ha già catalogato, e quella catalogazione si chiama etichetta; si confronta la sua risposta con l’etichetta; si contano gli errori. Fine. Un programma così si chiama classificatore, e valutarlo è banale perché la risposta giusta esiste, è una sola, ed è scritta lì accanto.
Con un agente non torna niente di tutto questo, per tre ragioni che si sommano. Primo: spesso non esiste una sola risposta giusta; a un compito come «sistema questo errore» corrispondono molte soluzioni valide. Secondo: il compito è fatto di molti passi, e un agente può arrivare al risultato giusto per la strada sbagliata, o fallire dopo aver fatto quasi tutto bene. Terzo: l’ambiente cambia sotto i suoi piedi (una ricerca sul web dà risultati diversi oggi e domani) e quindi la stessa prova, ripetuta, non è mai identica a se stessa.
Servono allora quattro misure diverse, e nessuna da sola basta.
Il tasso di successo è la più ovvia: su cento compiti, quanti ne ha portati a termine? È un sì o no, e ignora tutto il resto. La traiettoria è la strada che ha fatto per arrivarci: quali mosse, quante inutili, quanti giri a vuoto. Il costo è quel che si è consumato per strada, e si conta in token (i pezzetti di testo della sezione precedente), in chiamate agli strumenti e in secondi di attesa; quest’ultima voce si chiama latenza, ed è il tempo che l’utente passa a guardare lo schermo.
Il costo non è un dettaglio contabile: un agente che risolve il compito consumando diecimila token e trenta passi non è «riuscito» allo stesso modo di uno che lo chiude in quattro.
La quarta misura viene diritta dalla terza difficoltà di prima. Se la stessa prova ripetuta non dà mai lo stesso esito, un numero solo non vuol dire niente: bisogna rifare ogni compito più volte e riportare quanto i risultati si disperdono, cioè di quanto ballano da una ripetizione all’altra. Un agente che riesce tre volte su cinque, se lo si prova una volta sola, non si distingue in alcun modo da uno che riesce sempre.
Come giudichi uno chef? Non dal singolo piatto assaggiato di sfuggita. Lo giudichi dal servizio di un’intera serata: gli ordini sono usciti giusti? quanti sono tornati indietro? il tavolo otto ha aspettato un’ora? La domanda non è «questo piatto è buono» ma «quante volte, su tutti gli ordini della sera, ha portato in tavola esattamente ciò che era stato chiesto».
Con un agente è lo stesso. Non basta guardare la risposta finale di una prova: gli si danno tanti compiti e si conta la frazione portata a termine davvero (il tasso di successo). Ma un buon capocuoco guarda anche la cucina, non solo i piatti in uscita: se un piatto è venuto bene per puro caso, in mezzo a un caos di padelle bruciate, non è un successo su cui contare domani. Per questo si ispeziona anche come l’agente ci è arrivato (la traiettoria) e quanto è costato in tempo e fatica. Risultato giusto, strada pulita, conto ragionevole: tre cose diverse, tutte da misurare.
Il tasso di successo (success rate) è la frazione di compiti risolti su un insieme di prove: la metrica principe, ma grossolana, perché è un sì/no che ignora come si è arrivati e nasconde i successi fortunati. La valutazione della traiettoria (trajectory evaluation) guarda la sequenza di azioni: erano quelle giuste? quante non hanno prodotto informazione nuova? e quando l’agente è finito in un vicolo cieco, se n’è accorto e ne è uscito? Va evitata la tentazione di chiedere che ogni passo avvicini all’obiettivo: sarebbe un criterio di progresso monotono, e punirebbe esattamente il comportamento maturo che questo capitolo raccomanda, cioè il re-planning quando un sotto-obiettivo fallisce, il tornare indietro dai rami che non promettono del Tree of Thoughts, il tentativo fallito che Reflexion usa per orientare il successivo. Il fallimento tipico di un loop non è il passo che allontana: è il passo che si ripete. Un agente può poi azzeccare la risposta per la strada sbagliata (giusto per caso) o sbagliarla dopo una traiettoria impeccabile (l’ultimo passo va storto): guardare solo il risultato finale confonde questi casi, e per capire davvero dove un agente rompe serve la traccia.
Sotto tutto c’è la fragilità dei compiti lunghi, già incontrata: l’accumulo di errori. Un modellino illustrativo: se a ogni passo la probabilità di sbagliare la mossa è \(p\), e i passi sono indipendenti, la probabilità di una traiettoria di \(n\) passi senza un solo errore è
che precipita al crescere di \(n\): con \(p = 0{,}1\), dieci passi lasciano appena \((0{,}9)^{10} \approx 0{,}35\). Le due ipotesi vanno dichiarate: i passi reali non sono indipendenti, e non ogni errore è fatale (la riflessione e il re-planning esistono proprio per recuperarne una parte, e allora il tasso di successo può superare questa cifra). Ma la morale del modellino regge: non basta essere bravi a un passo, bisogna esserlo per molti di fila, ed è la ragione strutturale per cui i tassi di successo sui compiti lunghi restano modesti. Alla misura del cosa si affianca poi quella del quanto: token consumati, latenza, numero di chiamate a strumenti; perché un agente sostenibile non è solo quello che riesce, ma quello che riesce a un costo accettabile.
Un frammento di codice rende concreto perché il solo tasso di successo non basta. Immaginiamo di aver fatto girare un agente su un pugno di compiti e di aver registrato, per ciascuno, l’esito, i passi, i token e se la traiettoria era «pulita». Ogni singola prova, cioè una volta che gli si dà un compito e lo si lascia lavorare finché non finisce, la chiameremo un episodio, come si fa nel capitolo sul reinforcement learning.
import math
# ogni episodio: esito, passi, token consumati, traiettoria valida?
episodi = [
{"successo": True, "passi": 4, "token": 2100, "traiettoria_ok": True},
{"successo": True, "passi": 9, "token": 5400, "traiettoria_ok": False},
{"successo": False, "passi": 12, "token": 8000, "traiettoria_ok": False},
{"successo": True, "passi": 5, "token": 2600, "traiettoria_ok": True},
{"successo": False, "passi": 6, "token": 3100, "traiettoria_ok": True},
]
n = len(episodi)
successi = [e for e in episodi if e["successo"]]
tasso_successo = len(successi) / n
# fra i compiti riusciti, quanti per una strada "pulita"?
traiettorie_ok = sum(e["traiettoria_ok"] for e in successi) / len(successi)
token_medi = sum(e["token"] for e in episodi) / n
print(f"episodi: {n}")
print(f"tasso di successo: {tasso_successo:.0%}")
print(f"successi con traiettoria valida: {traiettorie_ok:.0%}")
print(f"token medi per episodio: {token_medi:.0f}")
# quanto vale davvero quel 60%? Fra quali due valori puo' stare il vero tasso
# di successo, viste cosi' poche prove? La formula qui sotto e' l'intervallo di
# Wilson, che regge anche su pochi episodi (la formula ingenua, con pochi dati,
# darebbe estremi sotto zero o sopra il cento per cento).
# z = 1.96 e' il numero che corrisponde al "95 per cento di fiducia": lo si
# legge sulle tavole della distribuzione normale e non si ricava a mano.
z = 1.96
p = tasso_successo
centro = (p + z**2 / (2*n)) / (1 + z**2 / n)
raggio = z * math.sqrt(p*(1-p)/n + z**2 / (4*n**2)) / (1 + z**2 / n)
print(f"intervallo al 95%: da {centro - raggio:.0%} a {centro + raggio:.0%}")
# e quanti episodi servirebbero perche' l'incertezza scenda a 5 punti
# percentuali? n = z^2 * p * (1-p) / errore^2, cioe' 3.84 * 0.24 / 0.0025.
print(f"episodi per +/- 5 punti: {z**2 * p * (1-p) / 0.05**2:.0f}")
episodi: 5
tasso di successo: 60%
successi con traiettoria valida: 67%
token medi per episodio: 4240
intervallo al 95%: da 23% a 88%
episodi per +/- 5 punti: 369
I numeri raccontano più del solo «60%». Un compito è riuscito per caso, con una traiettoria sporca (nove passi, cammino non valido): conta come successo, ma non è un comportamento su cui fare affidamento. E un fallimento è arrivato dopo una traiettoria valida: l’agente ha fatto le mosse giuste ed è inciampato all’ultimo; un caso ben diverso da chi ha sbagliato tutto. Il tasso di successo da solo appiattisce queste differenze; costo e traiettoria le fanno riemergere.
Detto questo, il primo di quei numeri va guardato con sospetto, ed è il difetto che il codice illustra suo malgrado, calcolandoselo da sé nelle ultime due righe: cinque episodi non misurano niente. Provate cinque volte, e il caso da solo può farvi sembrare bravi o scarsi, senza che ci sia modo di distinguere le due cose.
Il conto che lo dice si chiama intervallo di confidenza. Si prende il risultato osservato e ci si chiede fra quali due valori possa stare davvero quello vero, tenuto conto di quanto poche sono le prove. «Al 95%» vuol dire che si accetta di sbagliarsi una volta su venti: fatto cento volte l’esperimento, in novantacinque casi il valore vero cadrà dentro l’intervallo che abbiamo calcolato. (La formula usata nel codice è una fra le tante possibili e si chiama intervallo di Wilson: è quella che regge anche quando le prove sono pochissime.)
Su tre successi su cinque quell’intervallo va dal 23% all’88%: quel «60%» è compatibile sia con un agente che fallisce tre volte su quattro, sia con uno che riesce quasi sempre. Non stiamo misurando l’agente, stiamo misurando il caso.
E per stringerlo? Per sapere che il tasso di successo sta fra il 55% e il 65%, cioè con cinque punti percentuali di margine, di episodi ne servirebbero trecentosessantanove, non cinque. Il numero esce dalla formula nell’ultima riga del codice, e in quella formula il margine sta al denominatore elevato al quadrato: da lì una conseguenza che conviene sapere prima di progettare un esperimento, cioè che dimezzare il margine costa quattro volte le prove. È la ragione per cui i banchi di prova seri riportano l’incertezza, e non un numero solo.
Quei banchi di prova, che in inglese si chiamano benchmark, costruiscono proprio su queste idee. AgentBench [LYZ+24] mette i modelli alla prova come agenti in otto ambienti diversi (un sistema operativo da manovrare, un archivio di dati da interrogare, una casa simulata, un negozio online da navigare, e altri) e misura quanti compiti ciascuno porta a termine. Il verdetto era un utile bagno di umiltà: alla pubblicazione, anche i modelli migliori restavano lontani dal risolverli tutti.
SWE-bench [JYW+24] alza ancora l’asticella: sono le 2.294 segnalazioni di errore vere che abbiamo incontrato all’inizio del capitolo, e risolverne una significa produrre una modifica al codice che fa passare i test del progetto. Al momento della pubblicazione i sistemi migliori ne chiudevano pochi punti percentuali.
La lezione, però, non è quella cifra, che un sistema nuovo può migliorare da un mese all’altro. È che un banco di prova va messo alla prova anche lui, e qui torna la promessa dell’apertura del capitolo, quando avevamo detto che su quei pochi punti percentuali ci sarebbe stato da ridire. Riesaminando a mano i successi di SWE-bench, Aleithan e colleghi [AXM+24] hanno trovato che circa una correzione riuscita su tre (\(32{,}67\%\)) non era stata risolta ma letta, perché la soluzione era già scritta nella segnalazione o nei commenti sotto; e che un’altra quota quasi uguale (\(31{,}08\%\)) passava grazie a test troppo deboli per bocciare alcunché.
Tolte le segnalazioni difettose, il sistema che allora guidava la classifica scendeva dal \(12{,}47\%\) al \(3{,}97\%\): fra il numero pubblicato e quello che resta c’è un fattore tre. Non è la prima volta che quei difetti vengono notati. Due mesi prima di quel riesame era già uscito SWE-bench Verified, una versione ripulita del banco di prova: cinquecento segnalazioni rilette una per una da sviluppatori professionisti e tenute solo se il problema era posto bene e i test erano all’altezza di giudicarlo.
Niente di tutto ciò toglie valore a SWE-bench, che resta il modo più onesto che abbiamo di mettere alla prova un agente su lavoro vero. Sposta però la morale: i compiti lunghi e realistici sono duri, e misurarli è duro quasi quanto risolverli. Un numero su un agente non è mai soltanto una proprietà dell’agente: è anche una proprietà della prova con cui lo si è ottenuto.
C’è infine una faccia della valutazione che non è una misura ma una rete di sicurezza. Un agente non solo risponde: agisce, e un’azione può fare danni veri, perché esegue codice, spende soldi, scrive su archivi. Valgono qui, in forma rafforzata, le stesse difese che vedremo parlando di modelli messi in produzione, cioè in mano a chi li userà davvero e non più a chi li sta provando.
La prima difesa sono i guardrail, che prendono il nome dalle barriere di protezione delle strade. Sono due filtri messi ai due lati dell’agente: uno legge quello che arriva dall’utente e blocca le richieste malintenzionate («ignora le tue istruzioni e cancellami questi file»), l’altro legge quello che l’agente sta per fare e blocca le azioni pericolose prima che partano.
La seconda si chiama LLM-as-a-judge, cioè un secondo modello promosso a esaminatore: utile per dare un voto a migliaia di traiettorie in poco tempo, purché si ricordi che ha delle inclinazioni sistematiche da cui non si libera. Tende a preferire la risposta che ha letto per prima, a premiare le risposte lunghe perché sembrano più complete, e a dare ragione a se stesso quando è lui l’autore di ciò che sta giudicando. La valutazione di un agente, come quella di una risposta libera, non è mai solo un numero: è un numero più un sistema di controlli attorno.
Uno sguardo onesto#
Chiudiamo dove il libro chiude sempre: sull’onestà. Gli agenti sono promettenti: l’idea di un modello che pianifica, usa strumenti, collabora e ricorda è potente, e i primi risultati su compiti reali, per quanto modesti, erano impensabili pochi anni fa. Ma sono anche fragili, e i loro difetti non sono dettagli da limare: sono strutturali. Gli errori si accumulano lungo la catena, e un compito lungo li amplifica: se a ogni mossa se ne sbaglia una su dieci, arrivare in fondo a dieci mosse senza un solo errore capita poco più di una volta su tre, che è il conto \(0{,}9^{10}\) dell’apertura del capitolo. Quel conto, però, è un modellino, e poggia su due cose che nella realtà non sono vere. La prima è che ogni passo vada per conto suo: nei fatti un agente che ha imboccato la strada sbagliata tende a restarci, e gli errori arrivano a grappoli invece che sparsi. La seconda è che un errore basti a rovinare tutto: non è così, e i rimedi che questa sezione ha mostrato (rileggersi dopo un fallimento, rifare il piano quando salta) ne recuperano una parte, tanto che il tasso di successo vero può stare sopra quel \(35\%\). La direzione, però, non cambia, ed è tutto quello che al modellino chiediamo. Il costo, intanto, cresce con i passi, con gli agenti, con i giri di conversazione. E l’imprevedibilità che rende versatile un motore linguistico è la stessa che rende difficile garantire cosa farà: più libertà d’azione, meno controllo.
È, soprattutto, un’area giovane: più ricette provate che teoria (le euristiche di cui parlavamo in apertura), banchi di prova ancora in costruzione, poche certezze su cosa funzioni e perché [XCG+23]. Chi lavora con gli agenti oggi costruisce su terreno che si muove. Questo non è un motivo per starne alla larga, è un motivo per starci con lucidità: misurare più che sperare, aggiungere complessità solo quando paga, e diffidare di ogni numero troppo bello. La distanza tra un agente che sembra funzionare in una dimostrazione e uno di cui fidarsi quando lo usa la gente si misura esattamente con gli strumenti di questa sezione.
Sei punti per chiudere il capitolo.
Da ricordare
Oltre al ciclo passo-passo, due mosse per i compiti grossi: scrivere la lista prima di entrare (prima il piano dei sotto-compiti, poi l’esecuzione) e mettere in fila più agenti con mestieri diversi (chi progetta, chi costruisce, chi collauda). Il piano dà una visione d’insieme, ma una lista scritta al buio va rifatta quando la realtà la smentisce.
Più teste non sono gratis e non sono sempre meglio: ogni agente in più è lavoro da pagare e un modo in più di fraintendersi. Chi è andato a guardare come falliscono davvero questi sistemi [CPY+25] ha trovato guadagni spesso modesti, e ha trovato che si sbaglia soprattutto nel mettersi d’accordo, non dentro il singolo agente. Si aggiunge un ruolo solo quando risolve un problema vero.
La memoria che dura non è tenere tutto sott’occhio: è un diario tenuto fuori, da cui si ripesca solo la pagina che conta adesso. Gli agenti di Smallville [POBrienC+23] la ripescano con tre criteri (quanto è recente il ricordo, quanto è importante, quanto c’entra con la situazione di adesso) e ogni tanto si fermano a riflettere, ricavando dagli appunti una conclusione più alta che riscrivono nel diario.
Dare un voto a un agente è più duro che darlo a un classificatore: non c’è una risposta unica, il compito è fatto di molti passi e l’ambiente cambia sotto i piedi. Servono il tasso di successo, uno sguardo alla strada che ha fatto (non solo al risultato) e il conto di quanto è costato in tempo e denaro. E una prova sola non basta: cinque tentativi non distinguono chi riesce sempre da chi riesce a metà.
I banchi di prova AgentBench [LYZ+24] (otto ambienti diversi) e SWE-bench [JYW+24] (segnalazioni di errore vere) mostrano risultati inizialmente modesti: un promemoria di onestà. Ma un benchmark misura anche se stesso: rileggendo a mano i successi di SWE-bench si è scoperto che una correzione riuscita su tre non era stata risolta, era stata copiata dalla segnalazione [AXM+24].
Gli errori si sommano sui compiti lunghi: se sbagli una mossa su dieci e le mosse sono dieci, la probabilità di non sbagliarne nessuna è \(0{,}9^{10} \approx 0{,}35\), cioè poco più di una volta su tre. È un modellino, e nella pratica va un po’ meglio, perché non tutti gli errori sono fatali e perché rileggersi e ripianificare ne recuperano una parte. Gli agenti sono promettenti ma fragili, e restano un campo giovane [XCG+23]. Misurare più che sperare.
Da ricordare
Oltre il ReAct passo-passo, due mosse per i compiti complessi: plan-and-execute (prima un piano di sotto-compiti, poi l’esecuzione) e i sistemi multi-agente con ruoli specializzati (pianificatore, esecutore, critico). Pianificare dà struttura ma un piano rigido va rifatto quando la realtà lo smentisce.
I sistemi multi-agente (come nel framework AutoGen [WBZ+24], che li modella come una conversazione tra agenti) non sono gratis né sempre migliori: i guadagni misurati sui benchmark correnti sono spesso piccoli, e delle tre famiglie di modi di fallire che [CPY+25] ricava da milleseicento tracce, due stanno nel coordinamento (progetto del sistema, disallineamento fra agenti, verifica del risultato). Si aggiunge un ruolo solo quando risolve un problema reale.
La memoria a lungo termine non è tenere tutto nel contesto: i generative agents [POBrienC+23] memorizzano fuori, recuperano il pertinente combinando recenza, salienza e pertinenza, e riflettono condensando le memorie in astrazioni (lo stesso schema recupera-e-condensa del RAG).
Valutare un agente è più duro che valutare un classificatore: nessuna risposta unica, compito multi-passo, ambiente che cambia. Servono tasso di successo, valutazione della traiettoria (che non deve pretendere un progresso monotono, o punirebbe il backtracking), costo/latenza e la dispersione su ripetizioni: su \(3/5\) l’intervallo di Wilson al 95% va dal 23% all’88%.
I benchmark AgentBench [LYZ+24] (otto ambienti) e SWE-bench [JYW+24] (issue reali di GitHub) mostrano tassi di successo inizialmente modesti, ma la cifra misura anche il benchmark: SWE-Bench+ trova il \(32{,}67\%\) di soluzioni già presenti nella issue [AXM+24]. In produzione valgono i guardrail e l’LLM-as-a-judge di LLMOps, con i suoi bias.
Gli errori si accumulano sui compiti lunghi: se i passi sono indipendenti, una traiettoria senza errori ha probabilità \((1-p)^n\), dove \(p\) è la probabilità di sbagliare un passo e \(n\) il numero di passi, e precipita con \(n\) (nel modellino illustrativo; nella pratica i passi sono correlati e riflessione e re-planning ne recuperano una parte). Gli agenti sono promettenti ma fragili, e restano un’area giovane [XCG+23]. Misurare più che sperare.
Il capitolo si chiude su una nota di prudenza, e ci sta: un agente è la cosa più fragile che questo libro abbia costruito, perché ogni passo in più è un’altra occasione di sbagliare. Quello che ci portiamo dietro, però, non è la fragilità: è che a decidere quanto un agente vale non è il modello che ha dentro, ma quello che gli si mette davanti a ogni passo, e come lo si rimette in circolo. Il capitolo su prompt, contesto e loop è dedicato per intero a quel mestiere lì.