Immaginate di assumere una persona bravissima. È sveglia, sa il mestiere, impara in fretta. Il primo giorno, però, non conosce le procedure di casa vostra: come si anonimizzano le cartelle cliniche in quel reparto, con quali passaggi, in quale ordine. Così le allungate una scheda di due pagine — non un manuale intero, una scheda: ecco come si fa qui, passo per passo, con un esempio già svolto. La domanda che ogni manager si è posto almeno una volta è banale e insieme scomoda: quella scheda serve davvero? E quanto?
Tradotta nel mondo degli agenti AI, quella scheda ha un nome: si chiama Skill. È un pacchetto di conoscenza procedurale — un file di istruzioni più eventuali script, template ed esempi — che si consegna a un agente al momento dell’uso, senza riaddestrare il modello. Anthropic ne ha formalizzato il formato nell’ottobre 2025, e da allora ne sono spuntate a migliaia: repository comunitari, ecosistemi aziendali, raccolte curate. Tutti a distribuirle, nessuno ad aver misurato la cosa più ovvia. È esattamente il vuoto che prova a colmare SkillsBench, un preprint di febbraio 2026 guidato da Xiangyi Li di BenchFlow con decine di contributori tra università e aziende: il primo benchmark che tratta le skill come oggetto di valutazione a sé, e non come contorno.
Cosa sono le skill, e cosa sostituiscono
Il paper usa un’analogia che vale la pena riprendere: pensate a un computer. Il modello di base è come la CPU, potenza grezza di calcolo; l’agente che lo governa — Claude Code, Gemini CLI, Codex — è il sistema operativo, che orchestra strumenti e contesto; le skill sono le applicazioni, la competenza specializzata per un dominio preciso. Tra le due strade classiche per rendere un modello utile su un compito di nicchia — riaddestrarlo, costoso e a spese della sua versatilità, oppure infilargli tutto nel prompt — le skill propongono una terza via: un pacchetto modulare, versionabile, portabile da un agente all’altro.
Gli autori sono rigorosi su cosa non è una skill, e la distinzione conta. Non è un system prompt (privo di struttura e risorse), non è un esempio few-shot (dichiarativo, non procedurale), non è un recupero RAG (fattuale: dice cosa, non come), non è la documentazione di uno strumento (descrive capacità, non procedure). Una skill è una procedura: come si affronta una classe di problemi. La distinzione è netta perché è ciò che il benchmark misura — se serve davvero avere le istruzioni giuste al momento giusto, o se un modello abbastanza bravo se la cava lo stesso.
Come si misura una scheda di istruzioni
L’idea metodologica è semplice e per questo forte: la valutazione appaiata. Gli altri benchmark per agenti chiedono «quanto è bravo questo modello a fare X?». SkillsBench chiede «quanto migliora su X se gli do la skill Y?». Per farlo, ogni compito viene eseguito in tre condizioni: senza alcuna skill, con la skill curata da esperti umani, e con una skill che il modello si genera da solo prima di provarci. La differenza tra la prima e la seconda misura il valore della scheda; il confronto con la terza isola una domanda diversa e più insidiosa, a cui torniamo tra poco.
Il banco di prova è concreto. 84 compiti reali distribuiti su 11 domini — dall’ingegneria del software alla sanità, dalla manifattura alla finanza — selezionati da 322 proposte di 105 contributori, ciascuno chiuso in un container Docker con i suoi dati, una soluzione oracolo che dimostra che il compito è risolvibile, e un verificatore deterministico in pytest che stabilisce pass/fail senza il rumore di un giudice-modello. In tutto, sette configurazioni agente-modello (dai Claude Opus e Haiku a Gemini 3 Pro e Flash fino a GPT-5.2) per 7.308 traiettorie valide, tutte a temperatura zero.
Per confrontare miglioramenti che partono da basi diverse, gli autori riprendono il guadagno normalizzato della didattica della fisica: quanto della strada che restava da fare è stata effettivamente percorsa. In formula,
$$g = \frac{\text{pass}_{\text{skill}} – \text{pass}_{\text{vanilla}}}{1 – \text{pass}_{\text{vanilla}}}$$
dove $\text{pass}_{\text{vanilla}}$ è il tasso di successo senza skill. Gli stessi autori ne segnalano onestamente il limite: un modello che sale dal 90% al 95% ottiene $g = 0{,}5$ esattamente come uno che sale dal 10% al 55%, ma sono fenomeni diversi — un soffitto quasi raggiunto contro un’impalcatura che regge davvero. Per questo riportano sempre anche il semplice scarto assoluto, $\Delta_{\text{abs}} = \text{pass}_{\text{skill}} – \text{pass}_{\text{vanilla}}$, in punti percentuali.
I numeri, senza arrotondare l’entusiasmo
Il risultato di copertina è positivo: le skill curate alzano il tasso di successo medio di 16,2 punti percentuali sulle sette configurazioni. Ma la media, qui, nasconde più di quanto riveli. La forbice tra sistemi va da +13,6 a +23,3 punti (il salto maggiore è di Claude Opus 4.5 dentro Claude Code, che ha l’integrazione nativa del formato skill). E soprattutto la variabilità per dominio è enorme: nella sanità le skill valgono +51,9 punti, portando il tasso di successo dal 34,2% all’86,1%; nella manifattura +41,9 punti, praticamente da zero (1,0%) al 42,9%. All’estremo opposto, sull’ingegneria del software il guadagno è di appena +4,5 punti, sulla matematica +6,0.
Le skill valgono di più dove il pre-addestramento copre poco (procedure cliniche, flussi di fabbrica) e quasi nulla dove il modello è già forte per conto suo. La media di +16,2 punti è la somma di questi estremi, non un valore tipico.
C’è di più, e va detto. Il guadagno di dominio è un’aggregazione: sotto, 16 compiti su 84 peggiorano con la skill accanto, in un caso di quasi 40 punti. Una scheda di istruzioni, se aggiunge complicazione o va in conflitto con qualcosa che il modello già sapeva fare, non è neutra: fa danno. Ed è il motivo per cui la valutazione appaiata dovrebbe diventare la regola, non l’eccezione: senza il confronto senza-skill, quei fallimenti non si vedrebbero.
Il limite che dice qualcosa sui modelli
Il risultato più interessante è quello che non fa titolo. Quando invece di ricevere una skill curata da un umano il modello viene invitato a scriversela da solo prima di risolvere il compito, il guadagno medio è di -1,3 punti: sotto lo zero. Nessun beneficio, a volte un danno — con Codex e GPT-5.2 si arriva a -5,6 punti. Solo Opus 4.6 racimola un modesto +1,4. La lettura degli autori è netta e vale come monito: i modelli non sanno produrre in modo affidabile la conoscenza procedurale di cui pure beneficiano quando gliela si fornisce.
L’analisi delle traiettorie mostra due modi di fallire. Nel primo, il modello capisce che servirebbe una procedura specifica ma la scrive vaga — «usa pandas per elaborare i dati», senza indicare quali funzioni; nel secondo, sui domini che richiedono davvero sapere specialistico (manifattura, finanza), non si accorge nemmeno che gli servirebbe una skill e tira dritto con l’approccio generalista. È la differenza tra saper eseguire una ricetta e saperla scrivere: leggere l’esperienza di chi ha già sbagliato prima di te resta un vantaggio che il modello, da solo, non ricrea.
Sul come scrivere una skill efficace, i dati suggeriscono una regola quasi controintuitiva: meno è meglio. Le skill dettagliate e quelle compatte rendono di più (+18,8 e +17,1 punti); quelle esaustive, le più lunghe e complete, arrivano a peggiorare le prestazioni di 2,9 punti. Stessa storia per la quantità: due o tre moduli sono l’ottimo (+18,6 punti), da quattro in su il beneficio crolla a +5,9. Una documentazione sterminata consuma il budget di contesto e semina indicazioni in conflitto; una scheda asciutta con un esempio funzionante fa il suo lavoro. E c’è una conseguenza pratica di peso: con le skill giuste, Claude Haiku 4.5 — un modello piccolo — arriva al 27,7%, superando Claude Opus 4.5 senza skill, fermo al 22,0%. La procedura può in parte sostituire la stazza del modello.
Le skill chiudono i buchi di procedura, non quelli di ragionamento. Aiutano dove serve sapere «i passaggi giusti in quest’ordine», non dove serve pensare meglio.
Cosa non dimostra
Gli autori sono i primi a delimitare il proprio risultato, ed è la parte che rende il paper credibile. La più onesta delle riserve riguarda la causa: una skill allunga il contesto, quindi parte del guadagno potrebbe venire semplicemente dall’avere «più testo» davanti, non dalla struttura procedurale. Il fallimento delle skill auto-generate suggerisce che la struttura conti — stesso budget di contesto, esito peggiore — ma servirebbero controlli a lunghezza appaiata, per esempio testo casuale o irrilevante, per chiuderla del tutto. Poi c’è la copertura: tutto avviene in compiti da terminale dentro container, e i risultati potrebbero non trasferirsi ad agenti che usano interfacce grafiche, a coordinamenti multi-agente o a orizzonti molto lunghi. Infine il container isola lo stato ma non garantisce determinismo perfetto né immunità dalla contaminazione dei dati di addestramento, e i sistemi commerciali cambiano comportamento nel tempo: una fotografia, non una legge.
Resta il valore di aver messo un numero dove prima c’era un’assunzione. La lezione per chi costruisce con gli agenti è pratica e poco entusiasta, nel senso migliore: le skill funzionano, ma non sempre e non ovunque; misurate il delta sul vostro compito prima di fidarvi, tenetele corte, e non chiedete al modello di scriversele da solo. La scheda di due pagine da dare al neoassunto bravo va ancora scritta da chi il mestiere lo conosce davvero.
Il paper
Xiangyi Li et al., SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks, preprint, febbraio 2026. Disponibile su arXiv: arxiv.org/abs/2602.12670.
I commenti sono riservati agli iscritti.
Accedi per commentare