Introduzione al progetto dsh‑superagent
Il team DeepSeek Harness ha appena pubblicato dsh‑superagent, un prototipo di ricerca rilasciato sotto licenza MIT. Si tratta di un agente di coding proattivo progettato per operare su un singolo repository GitHub, confezionato come bundle TypeScript per DeepSeek Harness.
L’agente ascolta gli eventi provenienti da GitHub e, opzionalmente, da Feishu, trasformando le richieste autorizzate in item di lavoro paralleli, ciascuno eseguito in una sessione agente dedicata. Il rilascio è stato accompagnato da un post di design intitolato “Exploring Super‑agent Design: Towards a More Autonomous Agent System”.
Caratteristiche principali e requisiti di sistema
Che cosa è? Un bundle TypeScript, versione 0.1.0, rilasciato come singolo commit sotto MIT. Utilizza il modello configurato nel profilo Harness.
Requisiti di esecuzione:
- Node.js 22.19+ o 24+
- git 2.32+
- Python 3.8+
- tmux
- GitHub CLI 2.48+
Performance dichiarata: in simulazioni DeepSeek, i task sono stati completati significativamente più velocemente rispetto a un agente a singola sessione, con un p95 di 15,7 minuti contro 29,5 minuti (circa 1,9× più veloce).
Principi di funzionamento
Il README espone la regola centrale: “prendere il meno possibile l’attenzione umana e fornire il più possibile valore”. Il documento di filosofia applica questo principio al comportamento dell’agente, che conferma una sola volta, resta silenzioso durante l’esecuzione e risponde solo con risultato, domanda o errore.
Motivazioni dietro la creazione di un Super‑agent
DeepSeek sostiene che gli agenti tradizionali considerano una singola sessione come unità di base. Secondo un report citato da ifeng, una persona può gestire attivamente solo 3‑5 sessioni contemporaneamente; quindi l’attenzione umana, non la capacità del modello, è il collo di bottiglia per il multitasking.
Architettura Router‑Worker
L’architettura è divisa in due livelli: un router a lungo termine gestisce l’interazione e il dispatch, mentre sessioni worker isolate eseguono il lavoro vero e proprio.
Il flusso, descritto nel domain model, è:
- Source → Trigger: GitHub o Feishu generano eventi.
- Eval: valuta se un batch di trigger richiede nuovo lavoro.
- Ticket: unità di lavoro autorizzata, con un mandato immutabile.
- Subscription: commenti successivi su un pull request raggiungono il worker corretto senza nuova menzione.
La sessione principale esegue il preset dsh-superagent-router con un set di tool ridotto, mentre ogni worker usa dsh-superagent-worker. I comandi shell vengono spostati in background dopo 5 secondi per consentire ai worker di continuare a ricevere messaggi.
Modalità di autorizzazione
L’autorizzazione è regolata da tre modalità: off, observe (predefinita) e auto. In observe l’agente registra solo ciò che avrebbe accettato, senza eseguire il lavoro.
Prestazioni e benchmark
DeepSeek ha testato il sistema con una simulazione di chat di gruppo e flussi CI di GitHub, includendo circa 300 messaggi per run, di cui 20 richieste di lavoro reale. Ogni schema è stato eseguito 5 volte.
Risultati:
- Super‑agent: p50 di 12,4 minuti, p95 di 15,7 minuti.
- Singola sessione + sub‑agent (prompt neutro): p95 di 29,5 minuti (nessun p50 fornito).
- Nel caso neutro, il baseline non ha chiamato sub‑agent in 5 run.
- Carico del router: al crescere degli arrivi da 1 a 40 al minuto, la dimensione del batch è passata da 1,0 a 2,8; la latenza per richiesta è aumentata da 2,5 a 3,9 secondi.
Un’ablazione che ha rimosso il pass‑through diretto degli eventi ha incrementato le decisioni del router del 30% e i token di lettura della cache del 37%, passando da 23,23 M a 31,77 M.
Confronto con altri agenti di coding su GitHub
| Feature | DeepSeek dsh‑superagent | GitHub Copilot cloud agent | Claude Code Action | OpenAI Codex |
|---|---|---|---|---|
| Trigger | Menzione da persona autorizzata, regole scritte | Assegnazione issue, chat, API, Slack, ecc. | @claude mention, assegnazione issue, workflow prompt | @Codex in Slack; task cloud |
| Lavoro non richiesto (proattivo) | Sì, con regola; default observe | Sì, via automazioni | Sì, via eventi workflow | Non divulgato |
| Sessioni isolate parallele | Sì, 1 per Ticket | Non divulgato | Non divulgato | Non divulgato |
| Dove gira | Macchina locale (profilo Harness) | GitHub, background | Runner GitHub Actions | Cloud |
| Fonte chat | Feishu (opzionale) | Slack, Teams | Non divulgato | Slack |
| Licenza | MIT | Non divulgato | MIT | CLI agent open source |
| Disponibilità | Prototype di ricerca | Tutti i piani pagati Copilot | API key o provider cloud | ChatGPT Plus e superiori |
Conclusioni e raccomandazioni
Il rilascio di dsh‑superagent segna un passo importante verso agenti di programmazione più autonomi e scalabili. La separazione router‑worker permette di gestire più ticket in parallelo, riducendo i tempi di completamento del 50 % rispetto a un modello monolitico.
Prima di adottare l’agente in produzione, è consigliabile:
- Isolare il processo in un ambiente sandbox o container, poiché opera con pieno accesso al sistema operativo.
- Configurare attentamente le liste di utenti autorizzati e la modalità di autorizzazione (observe vs auto).
- Monitorare le metriche di latenza del router in scenari di alto volume di eventi.
Per approfondire, si consiglia di consultare il repo GitHub, la guida di installazione e la serie di documenti di design.