DeepSeek Super-agent: cosa sono gli agenti di coding cloud e quale ruolo svolge

Una nuova abitudine si è diffusa tra gli strumenti per sviluppatori: lasciare un’attività da qualche parte — un Issue, una menzione in chat, una casella di prompt — chiudere il portatile e tornare a una branch o a una pull request creata da un agente mentre eravate via. GitHub, Cursor, OpenAI, Anthropic, Cognition e xAI offrono ormai tutti una qualche versione di questo servizio, con nomi come agente cloud, agente in background, sessione cloud o ingegnere software autonomo. Questo articolo spiega la categoria: cosa fanno davvero questi prodotti, come si svolge il ciclo di lavoro, a cosa si rinuncia e quale posto occupa il prototipo open source Super-agent di DeepSeek.

Cosa si intende per agente di coding cloud

L’etichetta è vaga, quindi è utile individuare i tre elementi condivisi da tutti i prodotti di questa categoria:

• Un trigger che non richiede un editor aperto. L’attività può arrivare come assegnazione di un Issue, una menzione con @ su Slack o Feishu, un prompt in un’app web, una chiamata API o un passaggio tramite CLI.
• Un ambiente esterno al proprio computer. L’agente clona il repository, installa ciò che gli serve e lavora in una sandbox o in uno spazio di lavoro gestito dal fornitore o dalla propria organizzazione.
• Un risultato verificabile. Il lavoro si conclude con una branch, un diff, una PR in bozza o un commento: qualcosa che una persona possa esaminare e su cui possa intervenire.

Questo distingue la categoria da due realtà vicine. Un agente per IDE locale gira sul portatile mentre lo si osserva; un assistente chat risponde alle domande senza intervenire sul repository. Un agente di coding cloud si colloca a metà strada: dispone di strumenti reali e di una copia di lavoro effettiva, ma è pensato perché l’utente possa assentarsi.

La parola bot descrive la stessa idea in una forma nativa per la chat. Invece di assegnare un Issue, si menziona l’agente su Slack, Teams o Feishu. Cambia il trigger, non l’ambiente remoto. Il risultato può essere una PR, un diff o una serie di file completati.

La mappa dei prodotti

Sei prodotti, descritti secondo le parole dei rispettivi fornitori:

Grok Bot è la proposta più ampia: xAI lo descrive come un compagno di squadra IA sempre disponibile, avviabile dalla chat desktop o mobile oppure menzionando @bot su X quando gli account sono collegati. Gira su una macchina cloud a livello di account ospitata da Cursor, con accesso a browser, spazio di archiviazione e riga di comando. La documentazione parla di file completati e bozze, non di un flusso di lavoro basato su repository; non documenta la creazione di branch e PR. Si colloca quindi all’estremità più orientata ai bot dello spettro.

Quattro differenze contano più della tabella:

Dove si trova il trigger. L’agente cloud di GitHub Copilot e OpenAI Codex Cloud sono progettati per attività già presenti su GitHub o nell’app ChatGPT. Cursor Cloud Agents e Devin puntano maggiormente su un’interazione nativa per la chat: il punto di accesso è una conversazione su Slack o Teams. Le sessioni cloud di Claude Code accettano trigger dal browser, dal telefono, dall’app desktop o dal comando claude --cloud in un terminale, e possono anche essere eseguite secondo una pianificazione.

Quanto il fornitore rende noto. Claude Code documenta nel dettaglio il proprio isolamento: negli ambienti ospitati da Anthropic, ogni sessione gira in una VM isolata, l’accesso alla rete è limitato per impostazione predefinita e le credenziali git restano fuori dalla sandbox; un proxy si autentica per conto della sessione. Le organizzazioni possono invece indirizzare le sessioni a un ambiente self-hosted, assumendosi la responsabilità dell’isolamento. Le sessioni cloud condividono i limiti di richieste del proprio piano, senza costi separati per le VM; richiedono l’accesso a claude.ai e non sono disponibili quando Claude Code è configurato per Amazon Bedrock, Agent Platform di Google Cloud o un altro fornitore di terze parti. Gli altri fornitori pubblicano meno informazioni sui dettagli interni: spesso «sandbox» o «VM» è tutto ciò che si trova nella documentazione pubblica.

Su cosa può intervenire l’agente. Alcuni prodotti sono limitati a un singolo repository; altri dichiarano di supportare attività su tutta l’organizzazione o su più repository. È la prima cosa da verificare rispetto alla propria configurazione: un agente capace con accesso all’ambito di repository sbagliato è inutile o pericoloso.

Per quali attività è pensato. La maggior parte dei prodotti elencati è dedicata al coding su repository specifici. Grok Bot è un compagno di squadra cloud di uso generale: la sua documentazione parla di file e bozze, non di un flusso di lavoro basato su repository. «Agente cloud» indica uno spettro, non un’unica forma di prodotto.

Come si svolge davvero il ciclo di lavoro

Al netto del branding, il ciclo è simile ovunque:

1. Acquisizione. Arriva un trigger. Il prodotto decide se si tratta di un’attività effettiva, talvolta pone una domanda di chiarimento e mette in coda una sessione.
2. Ambiente. L’agente clona il repository sul branch corretto, esegue uno script di configurazione o un’immagine e installa la toolchain. L’accesso alla rete e i segreti vengono configurati in questa fase, non in seguito.
3. Lavoro. L’agente legge il codice, modifica i file, esegue test e comandi e, talvolta, apre un browser. Le attività più lunghe proseguono anche quando il portatile va in sospensione.
4. Risultato. Pubblica una branch e apre una PR, oppure lascia un diff e un riepilogo scritto. Alcuni prodotti restituiscono PR in bozza perché ci si aspetta che l’agente si fermi prima del merge.
5. Revisione. Una persona legge il diff, lascia commenti e decide se fare il merge, chiedere modifiche o riprendere il lavoro in una sessione locale. Alcuni prodotti possono anche monitorare la PR e inviare correzioni quando la CI non passa.

Le differenze che causano problemi si trovano nei passaggi 2 e 5. Uno script di configurazione troppo lento, un repository che l’agente non riesce a clonare, una policy di rete che blocca un registro di pacchetti o una credenziale invisibile alla sandbox possono interrompere un’attività che sembrava semplice. E «risultato verificabile» significa comunque che una persona lo verifica: nessuno di questi prodotti elimina il passaggio della revisione, sposta soltanto la digitazione.

Perché questa ondata arriva proprio ora

Dovevano allinearsi tre condizioni. I modelli sono diventati abbastanza affidabili da eseguire lunghi cicli di utilizzo degli strumenti senza supervisione costante. Le sandbox e gli script di configurazione sono diventati abbastanza economici da fornire a ogni attività un ambiente dedicato. E la pull request è diventata l’interfaccia predefinita tra agente e revisore, così i team non hanno dovuto inventare un nuovo processo di revisione.

C’è anche una questione di attenzione. Il saggio di accompagnamento di DeepSeek la esplicita: un singolo compito è limitato dal modello, ma la capacità di una persona di portare avanti più attività è limitata dall’attenzione. Un agente cloud sottrae alla persona la gestione delle sessioni, il passaggio da un contesto all’altro e i tempi di attesa. Questa affermazione viene dal saggio di DeepSeek, non da uno studio indipendente, ma descrive perché questa categoria sembra utile.

A cosa si rinuncia

Ogni prodotto ospitato scambia controllo con comodità:

• Perimetro di fiducia. Il codice, e a volte anche le credenziali, escono dal proprio computer. I fornitori pubblicano livelli di dettaglio diversi su isolamento, conservazione dei dati e accesso alla rete: consultare la documentazione di ciascun prodotto, senza presumere che la categoria sia uniforme.
• Isolamento. Una VM gestita è progettata per contenere l’agente, ma resta comunque l’ambiente del fornitore. «Sandbox» può indicare di tutto, da una VM rafforzata a un container con ampio accesso alla rete.
• Personalizzazione. Gli agenti ospitati offrono impostazioni, non codice sorgente. Se il flusso di lavoro richiede un trigger, una regola di revisione o un modello diversi, ci si deve limitare a ciò che offre il prodotto.
• Modello di costo. La maggior parte di questi prodotti viene fatturata tramite un abbonamento o un piano con limiti di utilizzo; il tempo dell’agente non è una voce di costo che si può controllare direttamente. Pianificate il budget in base al piano, non ai token.
• Ambito e vincolo al fornitore. Il supporto per più repository, le integrazioni chat e i controlli aziendali variano da un fornitore all’altro, e trasferire un flusso di lavoro da un prodotto a un altro non è gratuito.

La via self-hosted: Super-agent di DeepSeek

La release di DeepSeek è interessante perché si chiede che aspetto abbia lo stesso ciclo quando il piano di controllo rimane nelle mani dell’utente. Il repository è un plugin TypeScript con licenza MIT per DeepSeek Harness (DSH), versione 0.1.0, pubblicato come prototipo di ricerca. Il README lo dice esplicitamente: è stato adattato per la pubblicazione, non è identico alla versione interna di DeepSeek e non implementa tutte le idee del saggio di progettazione.

La sua struttura prevede una sessione Router di lunga durata e una sessione Worker per ogni ticket. Gli eventi passano attraverso Source → Trigger → Thread → Eval → Mandate → Ticket → Assignment → Executor. Un team autorizza il lavoro tramite una policy; vengono accettate le menzioni esplicite con @ provenienti da persone autorizzate, mentre le attività proattive partono in modalità observe, che registra cosa avrebbe fatto l’agente senza aprire ticket. Ogni Ticket ha una sessione e una directory dedicate; un comando di preparazione può creare un worktree git per ciascun ticket.

Il modello operativo è l’opposto di una sandbox del fornitore. Ascolta un singolo repository github.com (non GitHub Enterprise Server) e, facoltativamente, Feishu. Le configurazioni predefinite di Router e Worker vengono eseguite con danger-full-access, usando l’utente del sistema operativo dell’operatore; i wrapper per gli account scelgono le credenziali dell’agente, ma non isolano il processo. La guida alla distribuzione consiglia di usare un account del sistema operativo dedicato, che contenga soltanto le credenziali dell’agente. Lo stato viene archiviato in SQLite, nella directory configurata stateDir. La filosofia è espressa come un bilancio: ridurre al minimo l’attenzione richiesta alle persone e massimizzare il valore fornito.

Il saggio riporta dati di pianificazione ottenuti da un carico di lavoro sintetico — circa 300 messaggi e 20 richieste di lavoro, strumenti simulati, cinque esecuzioni — con valori p50/p95 intorno a 12.4 / 15.7 minuti, rispetto a circa 29.5 minuti p95 per una baseline a sessione singola che non effettuava chiamate a subagenti. Sono misurazioni del saggio stesso, effettuate con strumenti simulati, non un benchmark indipendente della qualità del codice.

Ciò che dimostra il prototipo è più circoscritto e utile del lancio di un prodotto: l’agente di coding attivato da eventi e con revisione finale non è vincolato al cloud di un fornitore. Puoi gestire l’orchestratore, lo stato e la scelta del modello. Dimostra anche il costo di questa autonomia: devi eseguire il processo, proteggere l’account e accettare che il prototipo non disponga di una sandbox predefinita.

Quale scegliere

Scegli un agente cloud ospitato se vuoi evitare del tutto la gestione operativa, disporre di una sandbox gestita dal fornitore, usare funzionalità per più repository o per l’intera organizzazione e attivare l’agente da GitHub, Slack, Teams o un’app web. Il fornitore si occupa dell’isolamento e della disponibilità.

Valuta il prototipo self-hosted se il codice non può uscire dalla tua infrastruttura, devi modificare l’orchestrazione o vuoi scegliere il modello per ciascun ruolo. Prevedi una macchina dedicata o un account del sistema operativo dedicato e considera il codice software di ricerca.

Una combinazione pratica: agenti ospitati per le attività di routine sui repository, un agente self-hosted solo per i repository in cui il controllo dei dati è fondamentale. In entrambi i casi, il passaggio di revisione è lo stesso.

Una nota sui modelli

Il prototipo non imposta un modello in modo rigido. Usa il modello predefinito nel profilo Harness, a meno che Eval o Execution non specifichino un modello diverso: un team può quindi assegnare un modello più leggero al Router e uno più potente ai Workers. AIHubMix connette DeepSeek Harness tramite un endpoint compatibile con OpenAI all’indirizzo https://aihubmix.com/v1; l’esempio nella guida a DeepSeek Harness usa il fornitore aihubmix e il modello auto. La guida tratta la connessione di base a DSH, non il plugin Super-agent, mentre i prodotti ospitati sopra gestiscono autonomamente la scelta del modello.

FAQ

Che cos’è un agente cloud di coding?
Un software che riceve un’attività di coding da un Issue, una menzione in chat o una chiamata API, la esegue in un ambiente esterno alla tua macchina e restituisce un branch, un diff o una pull request da revisionare.

È la stessa cosa di un agente di coding locale?
No. Un agente locale opera nel terminale o nell’IDE mentre lo tieni d’occhio. Un agente cloud continua a lavorare anche dopo che chiudi il portatile ed è pensato per essere revisionato in un secondo momento.

Bisogna comunque revisionare il codice?
Sì. Tutti i prodotti qui descritti producono un diff o una PR che una persona deve revisionare. L’agente si occupa di scrivere il codice, non di approvarlo.

Dove viene eseguito il codice?
Nell’ambiente del fornitore. I dettagli variano: Copilot indica una sandbox cloud o un ambiente Actions, Cursor usa VM isolate, Codex un workspace cloud, Claude Code una VM isolata gestita da Anthropic o un ambiente self-hosted dell’organizzazione, e Devin un workspace con terminale, editor e browser. Leggi la documentazione sulla sicurezza di ciascun fornitore prima di affidargli codice privato.

Che cos’è un bot di coding?
È la versione integrata nelle chat della stessa idea: menzioni l’agente in Slack, Teams o Feishu invece di assegnargli un Issue. Continua a lavorare in un ambiente remoto; il risultato può essere una PR o un diff oppure, nel caso di un assistente generalista come Grok Bot, file completati e bozze.

Cosa aggiunge il Super-agent di DeepSeek?
Un’implementazione self-hosted della stessa procedura, con licenza MIT, architettura Router–Worker, un modello basato su policy e ticket e supporto opzionale a Feishu. È un prototipo di ricerca, non un prodotto ospitato.

È pronto per la produzione?
No. Il README lo definisce codice di ricerca, i preset funzionano con danger-full-access e non è prevista una sandbox predefinita. Se vuoi provarlo, usa un account dedicato del sistema operativo e un account GitHub dedicato all’agente.

Fonti

1. deepseek-ai/dsh-superagent-prototype — README, il saggio di progettazione citato e docs/000–008
2. Connettere DeepSeek Harness ad AIHubMix — AIHubMix
3. Agente cloud di GitHub Copilot — GitHub Docs
4. Cursor Cloud Agents — Cursor Docs
5. Codex Cloud — ChatGPT Learn / OpenAI
6. Claude Code nel cloud — Anthropic
7. Documentazione di Devin — Cognition
8. Documentazione di Grok Bot — xAI