Il wiki non è la memoria dell'agente: WikiSkill e la partita che si sposta dai pesi alle skill
WikiSkill tiene il wiki lontano dall'agente che esegue: la conoscenza serve a chi scrive le skill, e il trasferimento tra modelli sposta la partita.
Il 27 agosto su arXiv è comparso un paper di Google Research intitolato "WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution". Sei autori, tutti con affiliazione Google Research, Tu Vu anche Virginia Tech come corresponding author. Nessun annuncio sul blog di Google, nessun repository ufficiale, nessun codice: è ricerca, non un prodotto.
Eppure, a sedici giorni di distanza, il paper è già il punto di riferimento di una discussione che attraversa chi costruisce agenti. Per capire perché, conviene rimettere in ordine le date che ci portano fin qui: dal gist di Andrej Karpathy dell'aprile scorso alla spec Open Knowledge Format di Google Cloud di giugno, fino al dibattito dei practitioner di settembre. I fatti cominciano il 4 aprile 2026.
4 aprile 2026: il gist di Karpathy, la conoscenza che compone
Il 4 aprile 2026 Andrej Karpathy pubblica su GitHub Gist un file intitolato llm-wiki.md: una pagina che in poche settimane raccoglie migliaia di stelle e fork. L'idea è semplice. Invece di usare un LLM come un sistema di retrieval che a ogni domanda ricostruisce la risposta dai documenti grezzi, si fa mantenere all'LLM un wiki persistente: un insieme di file markdown interconnessi, aggiornati a ogni nuova fonte. Il punto del gist è la frase che definisce l'intera genealogia: il wiki è "a persistent, compounding artifact", un artefatto persistente che compone. La conoscenza viene compilata una volta e tenuta aggiornata, non re-derivata a ogni query. Tre strati: le fonti raw, immutabili; il wiki, scritto e mantenuto dall'LLM; lo schema, il documento che dice all'agente come mantenere il wiki. Il gist contrappone questo schema al RAG: nel RAG l'LLM riscopre la conoscenza da zero a ogni domanda, qui la sintesi si accumula e compone. Karpathy non pubblica un paper: pubblica un'idea file, e basta.
22 aprile e 12 giugno 2026: la distribuzione e il formato
Il 22 aprile 2026, al Google Cloud Next, Google annuncia il repository ufficiale google/skills: skill in markdown per i propri prodotti, da AlloyDB a GKE, installabili in agenti di terze parti, licenza Apache 2.0. È il lato distribuzione della stessa idea: chi produce conoscenza di prodotto la impacchetta in file che qualsiasi agente compatibile può caricare. Due mesi dopo, il 12 giugno 2026, Google Cloud pubblica l'Open Knowledge Format (OKF), la spec di un formato universale e vendor-neutral per rappresentare conoscenza come file markdown con frontmatter YAML. La versione 0.2, annunciata il 24 luglio 2026, aggiunge i segnali di fiducia: sources, generated, verified, status, stale_after, cioè come dire da dove arriva una conoscenza, chi l'ha confermata, se è ancora valida. Nessuno dei due artefatti parla di skill evolute da agenti. Ma entrambi mettono a posto l'infrastruttura: una conoscenza che si sposta tra agenti diversi ha bisogno di un formato condiviso e di un canale di distribuzione.
27 agosto 2026: WikiSkill, il paper
Il 27 agosto 2026 il paper WikiSkill appare su arXiv. L'architettura è a tre strati, e la somiglianza con il gist di aprile non è un caso: il paper cita esplicitamente Karpathy come ispirazione. Il Raw Layer conserva le trace di esecuzione, immutabili. Il Wiki Layer accumula pattern, log di evoluzione e un registro dell'impatto delle skill (patterns/, logs.md, skill-impact.md): non viene mai ripristinato. Il Skill Layer contiene le skill attive, e questo sì che si può ripristinare. Il gating accetta una proposta solo se la performance di validazione supera il best score (R_val > R_best), altrimenti si torna all'ultima configurazione accettata. Il ciclo è affidato a quattro componenti: l'Inference Agent esegue i rollout, il Wiki Maintainer consolida le trace in pattern, il Skill Proposer propone un aggiornamento alla volta, il gating decide.
I numeri reggono su cinque benchmark e cinque modelli: Gemini-3.5-Flash passa da 49,5% a 68,1% di media, Qwen-3.6-27B da 39,4% a 63,3%. Il risultato più interessante non è però il salto, è il trasferimento. Le skill evolute da un modello funzionano su un altro, a volte meglio di quelle auto-evolute: su ALFWorld, Qwen-3.5-9B arriva a 70,2% con una skill evoluta da Qwen-3.6-27B, contro il 63,4% della propria. E Qwen-3.5-9B con skill batte Qwen-3.6-27B senza skill: 47,4% contro 39,4%. La scoperta di una skill e la sua esecuzione sono capacità distinte.
Il wiki non è la memoria dell'agente
La configurazione di default del paper non dà il wiki all'agente che esegue i compiti: durante i rollout di training, l'Inference Agent non ha accesso al Wiki Layer. L'accesso al wiki è riservato al Skill Proposer, il componente che scrive le skill. I numeri della sezione 5.1 lo spiegano: togliere il wiki al Proposer fa crollare la media da 63,7% a 48,7%, quindici punti. Ma darlo all'Inference Agent peggiora il risultato: da 63,7% a 60,9%, con LiveMath che scende da 72,6% a 64,8%. L'ipotesi degli autori: con accesso diretto al wiki, l'agente risolve i task attingendo alla conoscenza consolidata invece che alle skill, e le traiettorie diventano meno informative per l'evoluzione. Tradotto: il wiki non è la memoria dell'agente in esecuzione, è l'archivio di lavoro del processo che scrive le skill. La lettura che ha accompagnato il paper, "Google dà la memoria agli agenti", capovolge il disegno: il paper tiene la conoscenza lontana dall'agente che lavora, perché la vuole vicina a quello che impara.
30 agosto: la comunità prova a riprodurlo
Tre giorni dopo il paper, il 30 agosto 2026, compare il primo repository comunitario: ashutoshsinghpr7/wikiskill, licenza MIT, con pacchetto PyPI pubblicato lo stesso giorno. È un'implementazione fedele dell'Algoritmo 1, con agenti reali: Hermes come backend di riferimento, poi Claude Code, Codex e GitHub Copilot CLI, e un gating in profili completamente isolati. La parte onesta sta nel log dei run. Nel Run 6, su un modello debole, il Wiki Maintainer distilla un solo pattern e il Skill Proposer rifiuta di proporre (no_action): non c'è niente da gating, il best score si conserva. Il repository lo ammette senza giri di parole: un gate di accettazione live, in cui una proposta supera davvero la baseline su un modello reale, resta la questione scientifica aperta. Il compounding non è automatico: un wiki senza pruning compone anche gli errori, e un modello debole non produce le skill che il paper dimostra sui modelli forti.
6 settembre: il dibattito dei practitioner
Il 6 settembre 2026 un thread su Hacker News, "Ask HN: How do you manage skills files?", fotografa il punto in cui è arrivata la discussione. Due posizioni ricorrenti. La prima: le capacità dei modelli generalisti crescono più in fretta di quanto chiunque possa mantenere le skill, e prima o poi le assorbiranno. La seconda: una skill densa e ben scritta batte qualsiasi inferenza del modello quando serve conoscenza interna, perché elimina l'intera fase investigativa e costa meno token. Nessuno dei due schieramenti discute l'architettura del paper. Il dibattito è tutto sulla gestione: come si trovano le skill, come si organizzano, come si mantengono, come si verifica che funzionino davvero.
È qui che i fatti di questi cinque mesi convergono.
Se le skill trasferiscono tra modelli e famiglie, e una skill evoluta da un altro modello batte quella auto-evoluta, l'asset durevole di un agente non sono i pesi del modello: è la libreria di skill e la conoscenza che le genera. Il campo di battaglia si sposta dalla scala del modello alla standardizzazione, alla portabilità, alla governance.
Le infrastrutture embrionali esistono già:
- OKF è il formato lato conoscenza, con i segnali di fiducia che permettono di verificare da dove arriva un concetto;
- google/skills è il canale di distribuzione;
- il repository comunitario mostra che il ciclo si riproduce fuori da Google.
Resta scoperto un problema, ed è il punto su cui si misurerà la prossima fase: chi approva una skill, come si verifica che funzioni, come si revoca quando smette di funzionare.
La governance delle skill, non la scala dei modelli, è il collo di bottiglia che questi numeri lasciano intravedere.
Further Reading
1
262588213843476
GoogleCloudPlatform
ashutoshsinghpr7
