DeepSeek Harness e i super-agent: l’architettura a due livelli per agenti sempre attivi

Per anni abbiamo lavorato con gli agenti AI come si lavora con una chat: apri una sessione, dai un compito, aspetti il risultato, poi ne apri un’altra. DeepSeek Harness ha pubblicato su X un lungo articolo tecnico, tradotto automaticamente dal cinese, che mette in discussione proprio questo schema. Il titolo è “Exploring Super-agent Design” e propone un’idea precisa: un agente unico e continuo, sempre online, che gestisce più compiti insieme senza che sia l’utente a fare da smistatore.

Il testo non è la presentazione di una funzione esistente, ma una riflessione sull’architettura, come precisano gli stessi autori. Vale la pena leggerlo con attenzione, perché tocca un limite che chi usa gli agenti ogni giorno conosce bene.

Il problema: la sessione come unità di lavoro

Secondo DeepSeek Harness, i coding agent e gli altri agenti a compito singolo hanno dimostrato che i modelli sanno usare strumenti per risolvere problemi complessi con sempre meno supervisione. Il ruolo umano si sposta quindi verso le decisioni di alto livello e l’approvazione finale. Nel frattempo sono comparsi molti agenti personali, collegati a messaggistica, calendario, email e piattaforme di lavoro, che monitorano i flussi e aiutano nelle attività.

Il nodo, però, è che i progetti mainstream usano ancora la singola sessione come unità base, e le sessioni sono isolate tra loro. Chi lancia più attività in parallelo deve passare a mano da una all’altra e ricordarsi cosa contiene ciascuna. Nella loro esperienza, una persona riesce a seguire al massimo da 3 a 5 sessioni attive contemporaneamente.

La conclusione del team è netta: il singolo compito è limitato dalla capacità del modello, ma il multitasking è limitato dall’attenzione umana.

Le quattro caratteristiche di un super-agent

Per superare il limite, gli autori propongono di scollegare l’agente da ogni sessione guidata a mano. L’agente diventa un’entità continua che mantiene il contesto tra una sessione e l’altra e lavora su più compiti complessi senza che si disturbino a vicenda. A questa architettura danno il nome di Super-agent, e le attribuiscono quattro proprietà.

La prima è la continuità: parli con l’agente dove già lavori, per esempio nelle chat di gruppo o su GitHub, e lui capisce quando cambia qualcosa e adatta ciò che sta facendo. La seconda è la produttività: risponde in fretta, porta avanti più attività complesse in parallelo e può ricevere un’istruzione nuova prima di aver finito la precedente.

La terza è la proattività: non aspetta istruzioni passo passo, osserva gli eventi dell’ambiente, interviene su ciò che merita e tace negli altri casi. La quarta è la persistenza: è sempre online, si collega agli ambienti di lavoro reali e si riprende da solo dalle anomalie durante le operazioni lunghe.

Un singolo ciclo ReAct non può offrire tutte e quattro le proprietà insieme, ed è per questo che devono arrivare dall’architettura che sta attorno al modello.

L’architettura a due livelli: Router e Worker

Il cuore della proposta è la divisione in due strati. Se instradi ogni evento verso un’unica sessione, ottieni la massima continuità, ma tutto si accumula nello stesso contesto e i risultati peggiorano. Se invece assegni a ogni evento una sessione nuova, massimizzi il parallelismo, ma i compiti non indipendenti perdono il contesto globale e più sessioni finiscono per rispondere separatamente all’utente, creando confusione.

La soluzione è un livello Router di lunga durata, che gestisce tutta l’interazione umana e il coordinamento globale, affiancato da un livello Worker fatto di sessioni isolate che eseguono i compiti in modo concorrente. L’utente parla sempre con lo stesso agente e raramente deve pensare alle sessioni.

Il Router riceve le richieste da ogni punto di ingresso e funziona da punto di sequenza, di coordinamento e di memoria globale. Per non diventare un collo di bottiglia, non esegue compiti: dialoga con gli umani e smista il lavoro. Nell’esperienza degli autori il suo lavoro è spesso più semplice del previsto, e un modello più leggero basta a garantire velocità e qualità.

Cosa cambia rispetto agli Agent Team

Il documento confronta l’idea anche con gli Agent Team, dove un Team Lead pianifica le sottoattività e coordina i membri, con un carico di ragionamento elevato. Nel Super-agent il Router tiene traccia solo, ad alto livello, di come i compiti si collegano tra loro e non li scompone. Gli autori notano anche che un Agent Team può funzionare come architettura a due livelli, purché i prompt impediscano alla sessione principale di eseguire lavoro in prima persona.

Eventi al posto dei prompt

La proattività nasce da un cambio di ciò che muove il sistema. L’input principale non è più il prompt digitato da una persona, ma una serie di eventi semi-strutturati dell’ambiente, chiamati Trigger: messaggi di chat, email, promemoria del calendario, commenti di code review, risultati della CI.

Il percorso di un evento è descritto in quattro passaggi. Prima arrivano politiche a due stadi che combinano codice e modelli per scartare il rumore. Poi un meccanismo di sottoscrizione e pass-through instrada gli eventi verso i Worker. Infine tecniche chiamate Inline & Spill e Chain of Recall portano contesto denso al modello e permettono di richiamarne altro su richiesta.

Come esempio, gli autori citano un’istanza interna di Super-agent basata su DeepSeek Harness che prosegue lo stesso lavoro di sviluppo tra una chat di gruppo e una pull request su GitHub. Controlla anche il feedback in un gruppo pubblico e, senza essere menzionata, individua la causa di un bug e apre una pull request per correggerlo.

Calcolo, stato e ambienti separati

Gli agenti locali legano tre elementi a un solo dispositivo: il calcolo che esegue il ciclo dell’agente, lo stato di sessione da conservare e l’ambiente di esecuzione, cioè repository e toolchain. Se il computer va in sospensione o perde la rete, l’agente si ferma, e non può raggiungere gli ambienti di altri dispositivi.

DeepSeek Harness riprende allora l’idea di separare calcolo e archiviazione dai sistemi informatici. Prima separa il calcolo dallo stato di sessione, così l’agente vive nel cloud senza dipendere dal ciclo di vita di una macchina. Poi separa il ciclo dell’agente nel cloud dagli ambienti pesanti di stato, che restano dove sono e vengono raggiunti da remoto.

Il Watchdog contro i blocchi silenziosi

Restare online a lungo richiede anche un controllo esterno. Molte anomalie, spiegano gli autori, non sono crash: il processo gira, ma il modello è bloccato in un ciclo improduttivo o ha perso l’obiettivo. Per questo serve una sessione indipendente chiamata Watchdog, fuori dal sistema principale e guidata da messaggi pianificati, che gestisce errori di API e ripristini falliti e usa il modello per capire se ogni Worker sta davvero facendo progressi.

I numeri dell’esperimento preliminare

Gli autori avvertono che i risultati sono solo indicativi: i carichi sono sintetici, gli ambienti semplificati e il lavoro di coding è simulato da uno strumento che consuma tempo. Quattro configurazioni hanno lavorato in parallelo su un flusso di circa 300 messaggi di chat di gruppo e CI su GitHub, di cui circa 20 vere richieste di lavoro. Ogni configurazione è stata eseguita 5 volte.

Il Super-agent ha chiuso i compiti con tempi p50 e p95 di 12,4 e 15,7 minuti. Senza pass-through i valori sono 12,6 e 15,5 minuti. Una sessione singola con lo strumento subagent e un prompt neutro è arrivata a 20,4 e 29,5 minuti, mentre con un prompt orientato alla delega i valori sono stati 13,8 e 29,0 minuti.

Il dettaglio più istruttivo riguarda la delega. Con il prompt neutro il modello non ha mai chiamato un subagent in nessuna delle 5 esecuzioni, e i nuovi messaggi hanno continuato a interrompere il lavoro. Con il prompt orientato alla delega ha delegato in 4 esecuzioni su 5, ma nell’altra ha giudicato il lavoro “piccolo” e lo ha fatto da solo, con una lunga coda di ritardo.

C’è anche un costo: più sessioni indipendenti significano più token letti dalla cache, 23,2 milioni per esecuzione nel Super-agent contro 6,1 milioni nella sessione singola con prompt neutro. È uno scambio di token contro velocità e stabilità.

Perché ti riguarda

Il tema non è solo accademico. Negli ultimi mesi abbiamo raccontato su queste pagine la direzione degli agenti proattivi, per esempio con Claude Duet, l’agente proattivo di Anthropic, e degli standard per farli dialogare, come il Personal Agent Protocol di Meta e Sierra. Il documento di DeepSeek Harness offre una chiave di lettura tecnica di quel movimento.

Anche sul fronte della voce il tema della conversazione continua è attuale, come mostra il modello Dessa di Block. Per capire il contesto del team dietro l’articolo puoi ripassare l’ultimo aggiornamento su DeepSeek V4.1 Flash e le sue API.

Questioni ancora aperte

Gli autori elencano in modo onesto ciò che resta da risolvere: come scalare l’architettura a due livelli, come lavorare con un agente senza sessioni, come definire i confini del contesto e collaborare tramite A2A, e come garantire sicurezza e privacy. Sono domande che condizionano la fiducia nei sistemi sempre attivi, soprattutto quando gli agenti toccano email, repository e chat aziendali.

Conclusioni

La lezione pratica è che l’agente del futuro, secondo DeepSeek Harness, non sarà una chat più potente, ma un sistema che separa chi parla con te da chi esegue il lavoro. Se sviluppi o scegli strumenti agentici per la tua attività, chiediti oggi dove finisce il contesto, chi smista i compiti e cosa succede quando un agente si blocca senza fare rumore. Puoi leggere l’articolo originale su X e poi dirci nei commenti quale parte ti convince di più.