Zetta: il robot non cambia, cambia chi lo sorveglia. Critici in codice che evolvono attorno a un VLA congelato

Un gruppo della Tsinghua lascia intatti i pesi di due modelli che muovono i robot e fa crescere attorno a loro un harness di controlli scritti in codice: sorvegliano ogni azione, intervengono quando la presa scivola, e diventano permanenti solo se reggono su casi mai visti. In simulazione i successi salgono di 20 punti su RoboCasa e di oltre 60 su una suite di LIBERO-Pro. I numeri, come sono stati misurati e che cosa ancora non dicono.

Chi ha preso la patente ricorda l’istruttore dell’autoscuola, e soprattutto il suo pedale. L’allievo guida: sa dove andare, conosce la strada, sbaglia di rado. L’istruttore non guida al posto suo, lo guarda. Quando la macchina si avvicina troppo al marciapiede frena, rimette l’auto in carreggiata e restituisce il volante. La sera, se è un istruttore scrupoloso, annota su un quaderno quando è dovuto intervenire, e la lezione dopo arriva prima sul punto critico. L’allievo non è cambiato. È cambiato il quaderno.

È l’idea di Zetta ζ: An Efficient Closed-Loop Embodied Harness for Self-Evolving Physical Intelligence, depositato su arXiv il 17 agosto 2026 (2608.16590) da quindici ricercatori dell’Institute for AI Industry Research della Tsinghua e di Z-Trans AI, con sei primi autori a pari merito (Xin Ding, Liang Mi, Mingzhe Huang, Zixuan Wang, Chao Zhang, Zixu Hao) e Ting Cao a capo del progetto. Il codice è pubblico e in un mese il repository ha raccolto oltre mille stelle su GitHub: il lavoro porta nel mondo dei robot un’idea che negli agenti software è già una piccola disciplina, cioè non riaddestrare il modello ma far evolvere il programma che gli sta intorno.

Il problema: riflettere a cose fatte

Oggi i robot che manipolano oggetti si reggono su due strade. La prima sono i modelli vision-language-action (VLA): una rete che guarda la scena, legge un’istruzione e produce direttamente i movimenti del braccio. Funzionano bene sui dati che hanno visto e diventano fragili appena la realtà si sposta un poco. La seconda sono gli agenti: un modello linguistico che orchestra il VLA, codice, strumenti e primitive di controllo.

Come un Transformer mette nello stesso spazio pixel e parole, base su cui è costruito ogni VLA di cui si parla qui: la multimodalità è spiegata nel libro.

Leggi «Multimodalità» nel libro →

Secondo gli autori gli harness agentici esistenti restano «a ciclo aperto». Una volta partito, il robot segue abilità fisse o traiettorie pianificate, e l’agente riflette solo alla fine dell’episodio. Il motivo è fisico: lo stato di un braccio che afferra una bottiglia cambia in millisecondi, e un grande modello linguistico non decide a quella frequenza. Ma la riflessione a posteriori ha tre difetti. Non può provare un’alternativa per vedere se la diagnosi era giusta. Deve attribuire il fallimento a un punto preciso di una traiettoria lunga. E spesso non ha più lo stato esatto del momento in cui le cose sono andate storte.

Tre anelli, tre orologi

La risposta di Zetta è separare i tempi. Il VLA resta congelato, i suoi pesi $\theta$ non si toccano ($\nabla_\theta = 0$, scrivono gli autori). Anche l’agente orchestratore, un modello multimodale che arbitra, ha una logica fissa. Quello che evolve è l’harness

$$\mathcal{H} = \{C, R, \mathcal{T}\},$$

fatto di critici $C$ (funzioni di controllo scritte in codice che scandiscono la traiettoria in corso), di un prontuario di recuperi $R$ legati a meccanismi di guasto precisi, e di un insieme di strumenti $\mathcal{T}$ (pianificatori, rilevatori di prese, controlli d’impedenza) che l’evoluzione può anche generare da zero. L’obiettivo è trovare l’harness che massimizza la probabilità di successo lasciando fermi VLA e orchestratore:

$$\max_{\mathcal{H}} \; J(\mathcal{H}) = \mathbb{E}_{g, s_0 \sim \mathcal{D}}\big[\mathrm{Success}(\tau) \mid \pi, \mathcal{A}_{orch}, \mathcal{H}\big].$$

Il primo anello gira alla frequenza delle azioni: i critici, essendo codice e non un modello da interrogare, costano poco e possono sorvegliare ogni passo. Quando trovano un’evidenza di guasto (la presa che scivola, il braccio che non avanza, una collisione) propongono un cambio di modalità, e l’orchestratore decide se concederlo. Il ritorno al VLA ha una clausola esplicita, che gli autori chiamano contratto di rientro:

$$\Psi(s_t) = \mathbb{1}(\text{guasto rimosso}) \wedge \mathbb{1}\big(\mathrm{Stability}(s_t) > \gamma\big),$$

cioè il volante torna all’allievo solo se l’evidenza del guasto è sparita e il contatto fra pinza e oggetto è di nuovo stabile, oltre una soglia $\gamma$. È l’istruttore che non restituisce la guida finché la macchina non è di nuovo dritta.

Il secondo anello gira a ogni lotto di episodi. I fallimenti vengono raggruppati per meccanismo, e per ogni gruppo si sceglie l’episodio più rappresentativo. Un agente di diagnosi scende per livelli, sempre nello stesso ordine: valutazione, critico, stato, pianificazione, recupero, e solo in fondo i parametri numerici. La regola è che se il guasto si risolve più in alto non si tocca niente di più basso. Gli autori la motivano con un’osservazione di mestiere: le riparazioni sui parametri di controllo aggiustano il caso singolo e rovinano gli altri. Non essendoci gradienti su codice e abilità, l’aggiornamento si ispira a due lavori precedenti (EmbodiSkill, firmato in parte dagli stessi autori, e SkillOpt) per fare passi piccoli e controllati, come una discesa del gradiente nello spazio del codice.

Il terzo anello è il cancello. Una patch consolidata deve risolvere il 100% dei fallimenti del suo gruppo e poi migliorare il successo su semi mai visti. Se su quei semi emergono guasti nuovi e l’harness viene ritoccato, il seme che ha fallito passa fra quelli di sviluppo e per chiudere l’iterazione se ne pescano di freschi. Le patch di un gruppo vengono fuse in un pacchetto (una cartella con un SKILL.md, gli strumenti, i prontuari e le soglie) che entra nella memoria delle abilità solo se supera il cancello.

Perché un sistema che si corregge guardando i propri errori finisce per imparare quegli errori a memoria, e perché serve un insieme che non vede mai: overfitting e validazione sono spiegati nel libro.

Leggi «Overfitting e validazione» nel libro →

Zetta: tre anelli, tre orologi, un modello che non cambia 1 · a ogni azione sorvegliare mentre succede VLA congelato pesi fermi azione critico (codice) guasto? recupero rientro solo se il guasto è rimosso e i contatti sono stabili 2 · a ogni lotto capire che cosa è andato storto fallimenti raggruppati per meccanismo di guasto diagnosi dall’alto in basso valutazione · critico · stato pianificazione · recupero parametri i parametri si toccano per ultimi patch minima su critici, recuperi, strumenti 3 · a ogni iterazione decidere che cosa resta tutti i casi del gruppo risolti (100%) meglio del VLA da solo su semi mai visti memoria delle abilità SKILL.md · tools · plans · params se emergono guasti nuovi, si pescano semi freschi l’harness aggiornato torna a sorvegliare · il modello resta lo stesso

I numeri

Gli esperimenti sono tutti in simulazione, su due benchmark di manipolazione, con otto GPU RTX 4090. Su RoboCasa (18 compiti domestici elementari, dal girare una manopola al mettere un oggetto sul fornello) la base è GR00T N1.5 di Nvidia; per ogni compito l’evoluzione lavora su 50 configurazioni casuali e il punteggio finale si misura su altre 50 mai viste. Il successo medio sale a ogni giro di riparazione, quattro in tutto.

RoboCasa, giro dopo giro successo medio · più alto è meglio
Configurazione Successo
VLA da solo 73,56%
dopo il primo giro 78,71%
dopo il secondo 84,85%
dopo il terzo 90,54%
dopo il quarto 93,56%

Il miglioramento c’è su tutti i 18 compiti, e i salti più grandi sono sui compiti ricchi di contatto o più lunghi: da 58 a 96, da 48 a 86, da 50 a 100.

Su LIBERO-Pro, la versione di LIBERO che sposta gli oggetti o cambia l’istruzione per vedere se il modello ha capito o ha memorizzato, la base è $\pi_{0.5}$ di Physical Intelligence. Qui la valutazione finale usa i semi da 1 a 20, esclusi dall’evoluzione. Sulla suite Goal con istruzione cambiata il successo va dal 31,0 al 92,5%, con oggetti scambiati di posto dal 38,0 all’89,0%. È la media di questi due, 90,8%, a finire nell’abstract. Sulla suite a orizzonte lungo, LIBERO-10, i guadagni sono più modesti: da 50,0 a 63,0 e da 9,0 a 40,0. Sui 40 abbinamenti di compito e perturbazione la media complessiva sale dal 32,00 al 71,13%: 32 migliorano, 8 restano dove erano.

Il dato più interessante è il trasferimento. Le tre abilità imparate mettendo oggetti sul fornello (allineamento prima della presa, nuova presa se l’oggetto scivola, appoggio stabile) applicate senza altro lavoro a compiti nuovi portano il successo da 58 a 82 con il lavandino, da 62 a 80 con l’armadietto e da 72 a 90 con il tostapane. Quelle imparate spegnendo il fornello, trasferite a rubinetto, anta e microonde, alzano la media da 64 a 80. Secondo gli autori funziona perché i critici guardano variabili fisiche comuni a molti compiti, come l’allineamento della pinza e la stabilità del contatto, e non traiettorie specifiche.

Poi ci sono i «momenti aha», come li chiamano gli autori: curve che restano piatte mentre l’agente ripara sintomi e poi saltano quando trova il collo di bottiglia vero. Un compito di LIBERO-Pro con una bottiglia da mettere in una ciotola passa dal 10 al 15% con la prima revisione e al 95% con la seconda, quando l’agente capisce che il problema è la presa che si perde durante il trasporto e non l’avvicinamento. Infine l’infrastruttura, Z-Infra, che separa la logica dell’agente dalle risorse di calcolo, simulatori e GPU: su otto A100, a 16 episodi concorrenti, produce 22,09 episodi al minuto. Lo stesso sistema senza Z-Infra ne produce 2,88, e RPent, un harness con l’agente nel ciclo che chiama un modello linguistico a ogni decisione, 1,72. Il tetto è 35,1 episodi al minuto a 64 concorrenti.

Che cosa non dicono

Il primo limite lo indicano gli autori stessi come lavoro futuro: tutti i numeri del paper vengono dalla simulazione, e il passaggio a robot veri è ancora da fare (i ringraziamenti citano dimostrazioni su robot reali, ma senza numeri). Pesa più di quanto sembri, perché i critici leggono segnali che il simulatore offre gratis, come le forze di contatto e l’intensità delle collisioni. Un braccio reale li ha solo se ha i sensori giusti, e con il rumore che i sensori portano.

Il secondo riguarda i confronti. L’abstract parla di stato dell’arte, ma le tabelle mettono Zetta a confronto solo con il VLA di partenza senza harness. L’unico altro harness agentico misurato, RPent, compare nella parte sull’infrastruttura, dove si misura la velocità, non il successo. E il 90,8% riguarda le due suite Goal: su LIBERO-10 quattro combinazioni di compito e perturbazione restano a zero con e senza Zetta.

Il terzo è la misura. Su LIBERO-Pro il punteggio finale si basa su 20 prove per compito, e ogni prova vale cinque punti percentuali. I «momenti aha» sono checkpoint scelti dagli autori dentro l’evoluzione, non curve complete. Mancano anche due informazioni che servirebbero a chi vuole rifare il lavoro: quale modello faccia da orchestratore e da agente evolutivo (la bibliografia cita modelli di Anthropic e OpenAI senza dire quale sia stato usato), e quanto costi un giro di evoluzione in chiamate e in ore. Ci sono infine piccole incongruenze. L’accelerazione è 11,1 volte nell’abstract e 11,9 nella sezione sperimentale. Il fattore 20,6 sul throughput mette a confronto un sistema a 64 episodi concorrenti con un altro misurato a 16, oltre cui quel sistema esaurisce la memoria. E il repository del codice, pubblicato il giorno dopo il paper, non ha un file di licenza.

Perché conta adesso

Il 2026 è l’anno in cui l’idea di migliorare un agente senza toccarne i pesi è diventata un filone: harness che si riscrivono, con o senza freni, file di abilità ottimizzati come parametri. Zetta porta quel filone dove è più difficile, perché nel mondo fisico l’errore non aspetta la fine dell’episodio. La scommessa è che la parte di intelligenza che manca a un VLA non stia nel modello ma nei controlli attorno. Sono controlli piccoli, leggibili, in codice, e si possono ispezionare, versionare e spostare da un compito all’altro. Se regge fuori dalla simulazione, cambia l’economia: invece di raccogliere altre migliaia di ore di dimostrazioni per riaddestrare il modello, si fanno girare altri episodi per fargli crescere intorno un istruttore migliore. Per ora è un risultato di simulazione, misurato contro un solo termine di paragone.

I commenti sono riservati agli iscritti.

Accedi per commentare