DeepSeek Super-Agent: cos’è, come funziona e cosa manca ancora21 min read

Apri tre agenti di codifica contemporaneamente e puoi sentire il problema. Uno è in attesa di una decisione, l’altro è terminato venti minuti fa e hai già dimenticato quale ha la correzione di autenticazione. Il team Harness di DeepSeek ci ha messo un numero: secondo la sua esperienza, una persona può seguire solo da tre a cinque sessioni di agente attivo alla volta. Superato quel punto il modello non rappresenta più il collo di bottiglia. Sei.

Il 31 ottobre 2026, il team ha pubblicato un articolo di progettazione per quello che chiama Super-agent e ha reso open source un prototipo denominato dsh-superagent. È un agente di codifica proattivo per un repository GitHub. Una sessione del router di lunga durata parla con le persone e distribuisce il lavoro e ogni richiesta accettata riceve la propria sessione di lavoro che termina con una richiesta pull o una domanda. Il repository ha superato le 12.000 stelle in circa due giorni. Il suo README è chiaro che si tratta di un codice di ricerca e non di un prodotto DeepSeek ufficiale.

Questa guida è per ingegneri e responsabili di team che desiderano sapere cosa fa il prototipo, come funziona la progettazione del router e del lavoratore, cosa dimostrano e cosa non dimostrano i numeri di benchmark e cosa controllare prima di indirizzarlo a un repository reale.

Una nota prima dei dettagli. La risposta di un lavoratore a “risolvere questo bug” è una richiesta pull e GitHub è un’ottima soluzione per questo. Il resto di ciò che gli agenti producono attorno al codice è più difficile da collocare: la descrizione della causa principale, il riepilogo del test, la tabella di confronto richiesta da un revisore.AgentGrid.ioè uno spazio di lavoro condiviso in cui persone e agenti AI creano, modificano e condividono documenti, app e file, con una versione live, attribuzione e cronologia. Torniamo al punto in cui si inserisce verso la fine.

Cos’è DeepSeek Super-Agent?

Due cose apparvero insieme. Il primo è un lungo articolo sul design, “Exploring Super-agent Design: Towards a More Autonomous Agent System”. Il team di Harness lo ha scritto in cinese e ha pubblicato una versione inglese tradotta automaticamente su X il 1° novembre. È stato visto più di 2,2 milioni di volte. Il secondo è il codice:deepseek-ai/dsh-superagent-prototipo, rilasciato sotto licenza MIT.

Esplorazione della progettazione dei super agenti: verso un sistema di agenti più autonomo

https://t.co/gwwIHtyCRQ

– Imbracatura DeepSeek (@DeepSeekHarness)1 novembre 2026

Non è un nuovo modello. dsh-superagent è un pacchetto perDeepSeek Cablaggio, il cablaggio dell’agente open source di DeepSeek, che l’azienda descrive come in anteprima pubblica in tutto il mondo. Il pacchetto controlla un repository GitHub e, se lo accendi, Feishu chatta. Quando qualcuno presente in un elenco consentito chiede lavoro all’agente, quest’ultimo apre un elemento di lavoro, lo esegue nella propria sessione e directory e risponde nella conversazione originale. Un pannello web mostra solo ciò di cui una persona ha bisogno.

Il nome è più semplice di quanto sembri. Cui Tianyi, del reparto prodotti di DeepSeek e uno dei revisori finali dell’articolo, ha spiegato in un post di Zhihu che “super” è inteso come apice contro pedice. Un Super-agente aggiunge un livello sopra l’agente che svolge il lavoro, l’opposto di un sub-agente, che ne aggiunge uno sotto. Non è una pretesa di intelligenza superiore.

Il README si apre con un avvertimento che vale la pena leggere per intero: “Prototipo di ricerca solo come riferimento, non un prodotto DeepSeek ufficiale”. Aggiunge che gran parte dell’ingegneria è stata eseguita da agenti di codifica, che il codice potrebbe contenere bug e che alcuni progetti nell’articolo sono indicazioni per il lavoro futuro e non sono implementati.

Un’altra caduta DeepSeek: dsh-superagent

Una struttura di agenti che funziona attraverso le emissioni GitHub di un repository e le PR con molti agenti in parallelo, progettata per attirare la minima attenzione umana possibile fornendo al contempo quanto più valore possibile.

pic.twitter.com/XR73mIvA0V

-Leandro von Werra (@lvwerra)31 ottobre 2026

Perché DeepSeek dice che il collo di bottiglia è l’attenzione umana?

L’articolo parte da una semplice constatazione. Nell’ultimo anno, gli agenti di codifica sono diventati abbastanza bravi da limitare una singola attività al modello. Ma una volta che esegui più attività contemporaneamente, il limite passa a te. Ogni sessione è isolata, quindi puoi passare da una all’altra manualmente e tenere traccia di ciò che ciascuno sa. L’inserimento di una CLI, MCP o un connettore di chat in una sessione locale consente di ascoltare nuovi eventi, ma si blocca comunque su comandi lunghi, mescola contesti di attività diverse e si ferma quando il laptop dorme.

La risposta di DeepSeek è smettere di considerare la sessione come l’unità che gestisci. Elenca quattro caratteristiche che un super-agente dovrebbe avere:

• Continuo.Gli parli dove già lavori, ad esempio in chat o nei commenti GitHub, e si comporta come un unico agente. Se chiedi il piano A in chat e passi al piano B in un commento di pull request, segue.
• Produttivo.Esegue diverse attività complesse in parallelo e accetta l’istruzione successiva prima che finisca l’ultima.
• Proattivo.Osserva gli eventi, agisce su ciò che vale la pena gestire e altrimenti resta in silenzio.
• Persistente.Rimane online e si ripristina in caso di errori senza che tu lo riavvii.

Gli autori sostengono che nessun singolo loop ReAct può fornirli tutti e quattro, quindi le qualità devono provenire dall’architettura attorno al modello. Questo è il vero argomento dell’articolo e la spiegazione visiva di seguito, condivisa da Hesam, è un modo rapido per vedere l’intero design su un’unica pagina.

ecco una spiegazione visiva dell’articolo di DeepSeek su Super-Agent:https://t.co/bByKYDoq6h pic.twitter.com/BhzbBh3NrP

– ℏεsam (@Hesamation)1 novembre 2026

Come funziona la progettazione del router e del lavoratore?

Pensa a un buon responsabile tecnico che non scrive mai codice durante lo standup. Ilrouterè una sessione di lunga durata che riceve ogni messaggio da ogni canale. Non esegue attività. Decide cosa richiede un messaggio, consegna il nuovo lavoro a un lavoratore e scrive ogni risposta alle persone coinvolte. L’articolo dice che può funzionare senza uno strumento di shell e che di solito è sufficiente un modello più leggero e veloce.

Alavoratoreè una sessione separata con un contesto isolato e una serie completa di strumenti, dedicata a un’attività. I lavoratori non parlano mai direttamente con le persone. Riportano lo stato al router, che mantiene le risposte con un’unica voce. Nel prototipo, ogni ticket ottiene la propria sessione e la propria directory, in genere un worktree git, e il conteggio dei lavoratori è limitato. L’impostazione predefinita è tre alla volta, regolabile da 1 a 16, con uno slot extra mantenuto libero in modo che il messaggio di una persona possa sempre arrivare.

Due dettagli rendono questo più di una coda di attività.

I follow-up saltano il router.Una volta che un lavoratore possiede una richiesta pull o un thread di chat, si iscrive a quel thread. I commenti successivi vanno direttamente a questo, senza alcuna chiamata di modello aggiuntiva al router. Se si scopre che un commento riguarda qualcos’altro, l’operatore lo restituisce.

Le esplosioni vengono raggruppate.I trigger che arrivano durante un turno di modello vengono messi in coda e vengono inseriti insieme nella chiamata successiva. Gli autori hanno misurato l’effetto e guardiamo i numeri seguenti.

Un ulteriore punto di contrasto. L’articolo lo distingue da un team di agenti. In un team di agenti, un lead suddivide un compito complesso in fasi e coordina i ruoli che vi lavorano, il che comporta un pesante carico di ragionamento. Il router Super-agent invia solo attività indipendenti e tiene traccia di come si relazionano ad alto livello. Non decompone l’opera stessa.

Cosa fa quando nessuno lo chiede?

È qui che la filosofia del progetto diventa pratica. Il primo documento nel repository afferma il principio in una riga: attirare la minor attenzione umana possibile e dare quanto più valore possibile. Ogni messaggio inviato dall’agente richiede l’attenzione di un collega, quindi parla solo quando una persona deve agire o può utilizzare un risultato e agisce solo quando richiesto o quando una regola scritta dal team lo consente.

Il cancello che impone questo è un semplice codice, non un modello. Controlla chi sta facendo una richiesta rispetto all’elenco consentito del team e registra quanto è forte la richiesta:

Quella modalità di osservazione è la parte che mi piace di più. L’agente inizia registrando ciò che avrebbe fatto, in modo che il team possa leggere tali record nella scheda Valutazione e ampliare le proprie autorizzazioni solo quando sembrano corrette. Messaggi, commenti e documenti citati vengono trattati come input per una decisione. Non possono modificare ciò che l’agente è autorizzato a fare.

L’articolo di progettazione mostra come si presenta nella pratica il lavoro proattivo. Nel gruppo utenti interno di DeepSeek Harness, il team ha configurato una politica di “riproduzione e correzione silenziosa”. Quando qualcuno segnala un problema o discute una proposta di modifica, l’agente tenta di riprodurlo e di trovare una soluzione in background e fornisce un risultato solo dopo aver confermato il problema e trovato una soluzione semplice. Altrimenti resta tranquillo. L’articolo fornisce anche una regola secca per i canali di chat che gli autori affermano di aver verificato: limitare ogni risposta a 100 parole. Su GitHub, al contrario, le richieste pull dovrebbero essere dense, con lo sfondo del problema, la descrizione della modifica e i risultati della verifica.

Per impostazione predefinita, ogni messaggio GitHub pubblicato dall’agente inizia con la riga “Questo è inviato da un agente automatizzato, non da un essere umano”. I team possono modificarlo, insieme al resto dei suggerimenti.

I numeri dei benchmark reggono?

L’articolo comprende un piccolo esperimento e gli autori si guardano bene dal definirlo puramente indicativo. Quattro progetti venivano eseguiti fianco a fianco in un flusso di chat di gruppo e messaggi CI: circa 300 messaggi per esecuzione, circa 20 dei quali erano richieste di lavoro reali, cinque esecuzioni ciascuna. Il lavoro di codifica è stato simulato da uno strumento che richiede semplicemente tempo, quindi il test misura la pianificazione e il coordinamento, non la qualità del codice di qualcuno.

Leggi la tabella due volte, perché il titolo non racconta tutta la storia. Il design del router ha ridotto il tempo di completamento di p95 a circa la metà di quello di una singola sessione, ma ha utilizzato da due a quattro volte circa i token di lettura della cache. E la riga più interessante è la seconda: rimuovere la scorciatoia pass-through non ha fatto sì che le attività finissero più velocemente o più lentamente, ma ha solo fatto sì che il router prendesse circa il 30% in più di decisioni e bruciasse il 37% in più di token.

La mia interpretazione è che la vera scoperta si trova nelle file a sessione singola. Con un prompt neutro, il modello non ha mai chiamato un subagente in nessuna delle cinque esecuzioni. Ha fatto il lavoro da solo, nuovi messaggi continuavano a interromperlo e le attività più lente hanno richiesto 29,5 minuti. Con un suggerimento che gli diceva di delegare, ha delegato in quattro o cinque esecuzioni, e nella restante esecuzione il modello ha giudicato il lavoro “piccolo” e lo ha fatto da solo. Una singola sessione dipende dall’umore della modella. Un router a cui non è consentito eseguire il codice non può commettere questo errore.

Uno stress test separato sul solo router ha aumentato il tasso di arrivo di eventi decisionali da circa 1 a circa 40 al minuto. Il batch medio è cresciuto da 1,0 a 2,8 eventi, il tempo per richiesta è aumentato solo da 2,5 a 3,9 secondi e il tempo ammortizzato per decisione è sceso da 6,4 a 1,6 secondi. Più eventi si accumulano, più economico diventa ciascuno, fino a un limite che, secondo gli autori, dipende dalla lunghezza del contesto e dal numero di eventi che un modello può gestire con precisione in un turno.

DeepSeek ha appena reso open source il suo prototipo di super-agente. Una sessione del router parla con le persone e distribuisce il lavoro, mentre i lavoratori isolati eseguono attività in parallelo rispetto agli eventi GitHub. Nel loro test, il tempo di completamento di p95 è sceso da 29,5 a 15,7 minuti rispetto a una singola sessione utilizzando subagenti.

La balena è di nuovo open source.pic.twitter.com/mS4sRbHmyx

– Paffuto (@kimmonismus)1 novembre 2026

Questi sono risultati auto-riferiti sul lavoro sintetico. Dimostrano che l’idea di pianificazione è valida. Non mostrano che il prototipo risolve i tuoi bug più velocemente.

Cosa dicono le persone vicine al progetto riguardo ai suoi limiti?

Subito dopo il rilascio, Cui Tianyi, del reparto prodotti di DeepSeek e uno dei revisori finali dell’articolo sul design, ha scritto come vede il design. La sua inquadratura è utile perché è modesta. Egli definisce il compromesso centrale come la continuità tra le attività rispetto alla produttività delle attività.

Sui limiti la recensione è diretta. Il prototipo implementa solo una parte del progetto proposto. Al momento della sua recensione, DeepSeek Harness non disponeva di memoria a lungo termine incorporata tra le sessioni. E il sistema è stato validato solo in un ambiente piccolo e affidabile all’interno dell’azienda. La sezione sui problemi aperti dell’articolo elenca il dimensionamento del router, la memoria nel corso di mesi, il lavoro senza sessioni, i confini del contesto tra gli agenti e il modo in cui gli agenti isolati dovrebbero comunicare tra loro, nonché la sicurezza.

Cosa dovresti controllare prima di eseguirlo?

La documentazione è più schietta della maggior parte dei post di lancio e vale la pena considerare i suoi avvertimenti come requisiti.

• I lavoratori hanno ampio accesso.Entrambe le preimpostazioni di autorizzazione, per il router e per i lavoratori, vengono eseguite condanger-full-accesscome utente del sistema operativo dell’operatore. I wrapper dell’account scelgono quali credenziali GitHub utilizza l’agente, ma i documenti affermano che sono impostazioni predefinite e non un limite di sicurezza, perché un lavoratore può comunque eseguire un programma tramite percorso assoluto o leggere la directory home. Si consiglia un account del sistema operativo dedicato che contenga solo le credenziali dell’agente.
• L’input non attendibile è la domanda di sicurezza aperta.L’articolo avverte che se una pronta iniezione o un’intrusione del server compromette il ciclo dell’agente cloud, ogni dispositivo connesso potrebbe essere raggiunto e che le credenziali che entrano nel contesto del modello potrebbero fuoriuscire.
• Gli esseri umani si uniscono per impostazione predefinita.L’agente non abilita mai l’unione automatica nel proprio account. L’unione automatica richiede la CLI di un secondo account denominata nella richiesta dei requisiti di consegna e le istruzioni predefinite lo consentono solo per richieste pull approvate di piccole dimensioni inferiori a 200 righe modificate.
• È costruito attorno a un repository.Ciascuna configurazione monitora un singolo repository GitHub e Feishu, uno strumento di chat sul posto di lavoro comune in Cina, è l’altra fonte di prima classe.
• Hai bisogno del cablaggio DeepSeek e di un fornitore di modelli.La configurazione elenca Node.js 22.19 o successivo, pnpm, git 2.32 o successivo, tmux, Python 3.8 o successivo e GitHub CLI 2.48 o successivo. La configurazione di un provider di modelli è un passaggio dell’operatore.
• Il rumore è un costo.Il documento filosofico dice di non utilizzare l’agente per produrre volume. Le richieste pull di massa e i messaggi broadcast costano al tuo team più di quanto danno.

Come lo proveresti senza rischiare il tuo repository principale?

L’installazione prevede molti passaggi, quindi il progetto ti chiede di lasciare che un agente di codifica lo faccia con te. Secondo il README, l’agente pone una breve domanda alla volta, mostra il piano completo una volta, quindi installa e configura tutto. Una prima esecuzione prudente si presenta così:

1. Scegli un repository usa e gettae un utente macchina dedicato o un account del sistema operativo. Non utilizzare il tuo login.
2. Crea un account GitHub separato per l’agente.Tutto ciò che scrive appare sotto quel nome.
3. Apri il repository nel tuo agente di codifica e incolla il messaggio di seguito.Rispondi alle sue domande una alla volta.
4. Tieni per te l’elenco dei consentitie lasciare la modalità di accettazione su Osserva.
5. Richiedi qualcosa di piccolo.Da un account consentito, commenta@<agent login> <request>su una questione. Un ticket dovrebbe apparire nella Panoramica del pannello entro circa un minuto.
6. Leggi la scheda Valutazione per una settimana.Amplia l’elenco o passa alla modalità automatica solo quando i record “accetterebbero” sembrano corretti.

Read SETUP.md in this repository and set up dsh-superagent with me.

Il documento filosofico del progetto fornisce agli operatori quattro regole che vale la pena ripetere: iniziare in modo limitato, sintonizzarsi per meno rumore, non utilizzare l’agente per produrre volume e possedere ciò che dice a proprio nome.

Dove dovrebbe finire il resto del lavoro dell’agente?

Supponiamo che un lavoratore trascorra un’ora su un test di integrazione instabile. La richiesta pull è la soluzione. Ma l’indagine che sta dietro, quali test hanno fallito, quali ipotesi sono state escluse, cosa ha mostrato la tabella dei tempi, non rientra in una descrizione PR ed è esattamente ciò che il revisore vuole contestare. Se questo risiede solo in una risposta in chat, il prossimo agente o compagno di squadra inizierà da zero.

AgentGrid.ioè costruito per quel trasferimento. Gli esseri umani e gli agenti IA lavorano sugli stessi documenti, app e file live, con un indirizzo stabile, accesso controllato e una cronologia delle versioni. I documenti di AgentGrid.io descrivono la connessione di un agente con funzionalità di comando eseguendonpx @animaapp/cli@latest login. Un essere umano approva il nome dell’agente, il team e ciò che può fare: leggere, scrivere, condividere o pubblicare. Successivamente le modifiche apportate dall’agente appariranno nella cronologia sotto il suo nome. Il prototipo non ha integrazione AgentGrid.io incorporata, quindi trattalo come un modello da provare con i suoi lavoratori, non come una funzionalità documentata.

In pratica, l’operatore scrive la sua indagine come file Markdown, il revisore commenta una riga della tabella, un altro assistente restringe il riepilogo e la richiesta pull si collega a una versione corrente anziché a tre copie incollate.

Per un’altra interpretazione di più persone che condividono un unico agente, consulta la nostra guida aBot della squadra Grok Bot. E se ti chiedi cosa funziona sotto un agente ospitato, la nostra guida aClaude Managed Agentsesamina la versione di Anthropic dello stesso cervello e mani divise, citata nell’articolo di DeepSeek.

Quando dovresti usare dsh-superagent e quando qualcos’altro?

• Utilizzare dsh-superagentimparare da un progetto serio e documentato, eseguire un esperimento contenuto su un repository a basso rischio o prendere in prestito le sue idee: un router che non esegue mai codice, ticket con un ambito dichiarato, modalità di osservazione prima della modalità automatica.
• Utilizzare un unico agente di codifica interattivoquando lavori un compito alla volta e vuoi guidare passo dopo passo. Il Super-agente è costruito per la situazione opposta.
• Utilizza AgentGrid.ioquando l’output è un documento, un report o un’app che diverse persone e agenti devono rivedere, modificare e pubblicare, indipendentemente dall’agente che lo ha prodotto.

Domande frequenti

Cos’è DeepSeek Super-Agent?

Si tratta di un prototipo di ricerca denominato dsh-superagent, rilasciato dal team Harness di DeepSeek il 31 ottobre 2026 sotto la licenza MIT. È un agente di codifica proattivo per un repository GitHub. Una sessione del router di lunga durata accetta le richieste e assegna ciascuna di quelle accettate alla propria sessione di lavoro, che risponde nella conversazione originale, solitamente con una richiesta pull.

DeepSeek Super-Agent è un prodotto DeepSeek ufficiale?

No. Il README lo definisce un prototipo di ricerca solo come riferimento e non un prodotto DeepSeek ufficiale e dice di rivederlo e adattarlo prima di utilizzarlo nel proprio ambiente. Inoltre, non è identico alla versione interna o all’implementazione descritta nell’articolo di progettazione.

In cosa differisce un super-agente da un sub-agente?

Un sub-agente aggiunge un livello sotto l’agente funzionante. Un Super-agente aggiunge uno strato sopra di esso. In questo progetto, il router si trova sopra molti lavoratori, parla con le persone e distribuisce le attività, mentre ogni lavoratore gestisce un’attività in modo isolato. Il nome riguarda la posizione, non una pretesa di maggiore intelligenza.

È necessario Feishu o solo GitHub?

GitHub da solo è sufficiente. Feishu è una seconda fonte opzionale e la documentazione afferma che un errore di configurazione Feishu disabilita solo la fonte Feishu.

È sicuro eseguirlo su un repository aziendale?

Non così com’è. I documenti affermano che i lavoratori funzionano con accesso completo come utente del sistema operativo dell’operatore e che gli account wrapper non rappresentano un limite di isolamento. Consigliano un account del sistema operativo dedicato, un account dell’agente dedicato su GitHub, un breve elenco consentito e una modalità di osservazione mentre impari come si comporta l’agente.

È più veloce di una singola sessione dell’agente di codifica?

Nel test simulato degli autori, il design del router ha completato le attività più lente in 15,7 minuti contro i 29,5 minuti di una singola sessione con uno strumento subagent, utilizzando più token. Il test ha utilizzato un lavoro di codifica simulato e cinque esecuzioni per progetto, quindi mostra i vantaggi della pianificazione, non la qualità del codice.