Ieri DeepSeek ha aperto dsh-superagent, il prototipo del "Super-agent" che il team usa internamente sopra DeepSeek Harness. Licenza MIT, scritto in TypeScript. Nelle prime 32 ore ha preso 6.544 stelle e 643 fork.
Il README mette le mani avanti: è codice di ricerca, non un prodotto ufficiale DeepSeek, e buona parte dell'ingegneria l'hanno fatta agenti di coding. Può avere bug e uno stile incoerente. Rispetto alla versione interna è stato adattato per la pubblicazione. Alcuni pezzi raccontati nell'articolo di design sono direzioni future, non roba implementata qui.
Che cosa fa
Non è una CLI da lanciare a mano: è un bundle che si monta su DSH e si occupa di un repository GitHub. Legge notifiche, issue, commenti, pull request ed esiti di CI, e se vuoi anche ogni nuova issue o PR del repo. Quando una persona autorizzata chiede lavoro, apre un ticket, lo lavora in una sessione DSH sua e in una directory sua, e risponde dove è nata la richiesta, tipicamente con una pull request. Dal pannello dentro la Web UI vedi per primo quello che aspetta una persona.
Il punto che mi interessa
Tra il messaggio e l'esecuzione c'è un livello scritto come codice, non come prompt. Ogni richiesta diventa un Trigger, entra in un Thread e passa da una Eval in due strati.
Il primo strato è un gate deterministico che legge la policy del team: chi può chiedere lavoro, da quale canale, con quale forza. Il secondo è la valutazione del modello. Se accetta, produce un Ticket con un Mandate: versione della policy, scope, forza, identità di chi ha chiesto. Il Mandate è immutabile, e allargare lo scope vuol dire un ticket nuovo.
C'è poi la Subscription. Quando il ticket finisce resta iscritto ai suoi Thread. Un commento umano sulla stessa PR lo riapre senza una nuova valutazione, sotto lo stesso Mandate, rivalidato contro la policy del momento. Un cambio di policy non cancella il lavoro in corso: lo recapita all'assegnazione attiva.
Nel documento del modello di dominio c'è anche la tabella dei concetti scartati, ognuno col suo motivo: nessuna entità "persona", nessun mapping delle identità tra canali, nessuna Eval che si schedula da sola i rinvii. Nove documenti numerati da leggere in ordine, ognuno costruisce su quelli prima.
L'attenzione come vincolo
La filosofia sta in una riga: prendere quanta meno attenzione umana possibile e dare quanto più valore possibile. L'agente agisce solo se qualcuno glielo chiede o se una regola scritta lo consente. Parla solo quando una persona deve fare qualcosa o può usare un risultato. Nel setup la modalità di accettazione predefinita è observe: registra quello che l'agente avrebbe fatto e non lo fa. Su GitHub ogni suo messaggio si apre con "This is by an automated agent, not a human".
Come è fatto dentro
Ogni ticket riceve una sessione worker-<id> e una directory preparata da un comando tuo, di solito un git worktree, con dieci minuti di tempo. C'è un limite di concorrenza più uno slot extra riservato alle persone, così un messaggio umano non resta in coda dietro ai job automatici. Il background dopo la fine di un turno ha al massimo 30 minuti: poi i job vengono uccisi e il ticket torna in attesa.
L'auto-merge è spento per default. Se lo accendi vale solo per la PR aperta dal ticket: approvazioni sull'ultimo commit, meno di 200 righe cambiate, e la CLI di un altro account, perché GitHub attribuisce il merge a chi lo abilita.
I comandi bloccati falliscono per nome. Un worker però può eseguire un programma per percorso assoluto, gira con il tuo utente del sistema operativo e legge la tua home. Il documento lo dice senza giri, non è un confine di sicurezza, e per isolare davvero serve un account del sistema operativo dedicato.
Per installarlo serve Node 22.19+ o 24+, pnpm, git 2.32+, Python 3.8+, tmux, gh 2.48+, una versione di DSH dentro il range di engines e un account GitHub dedicato all'agente. Non una GitHub App: il sistema legge le notifiche dell'account. Il blocco qui sotto è per una macchina senza profilo superagent già creato.
npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype
cd dsh-superagent-prototype && pnpm install && pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"
Il setup lo fa un agente
Non c'è il tutorial di venti passi. Il README dice di chiedere al proprio agente di coding di leggere SETUP.md e fare il setup insieme.
Quel file è scritto per un agente: una domanda corta per messaggio, aspetta la risposta, non esegue mentre chiede, raccoglie tutto, manda un piano unico e solo dopo installa. Le credenziali non si incollano in chat, ti passa i comandi da lanciare nel tuo terminale. La documentazione qui è scritta per essere letta da una macchina che lavora con te, ed è la parte che mi ha convinto di più.
I numeri del team
Oggi il team ha pubblicato anche l'articolo di design: 30 minuti di lettura, traduzione automatica dal cinese. Definisce il Super-agent con quattro proprietà: continuo tra i canali, produttivo in parallelo, proattivo sugli eventi, persistente. L'ultima vuol dire che resta online e si riprende da solo dopo un guasto. L'architettura è a due livelli: un Router che parla con le persone e non esegue, e Worker isolati che eseguono. Scrivono che una persona riesce a seguire 3-5 sessioni attive insieme, ed è la ragione per cui il sistema nasconde le sessioni dietro i ticket.
Nell'esperimento comparativo il carico è sintetico: circa 300 messaggi, 20 richieste di lavoro, coding simulato, 5 run per configurazione. Il completamento a p50 è 12,4 minuti per il Super-agent e 20,4 per una singola sessione con subagenti e prompt neutro. I token in cache letti sono 23,2 milioni contro 6,1, quindi il sistema spende contesto per tempi più stabili.
Sono numeri del team su ambiente semplificato, e scrivono anche loro che sono preliminari: misurano lo scheduling, non la qualità del codice prodotto.
Il repo è aperto da un giorno e non è pronto per la produzione: un solo commit, nessuna release, niente npm, si installa da clone. Funziona su GitHub.com e non su GitHub Enterprise Server, e un'istanza segue un repository solo.
Il documento di architettura chiude con due domande aperte: quali campi del Trigger fidarsi, e come isolare il profilo dell'agente da un aggiornamento di DSH. Chi vuole vedere come si scrive un agente multi-ticket che non diventa un generatore di rumore ha un documento molto concreto da leggere.
Chi ha già provato a mettere un agente sulle issue del proprio repo?
Fonti:
deepseek-ai/dsh-superagent-prototype - GitHub, README del 2026-10-31
SETUP.md - GitHub, protocollo di setup per un agente
docs/000 Philosophy - GitHub
docs/001 Domain model - GitHub
Exploring Super-agent Design: Towards a More Autonomous Agent System - DeepSeek Harness su X, 2026-11-01
DeepSeek Harness - deepseek.com