DeepSeek ha pubblicato dsh-superagent, un prototipo di ricerca sotto licenza MIT, presentato come un agente di programmazione proattivo destinato a un singolo repository GitHub. Impacchettato per DeepSeek Harness, ascolta GitHub e, opzionalmente, Feishu, per poi trasformare le richieste autorizzate in task paralleli, ciascuno nella propria sessione di agente.
Un agente che attende di essere sollecitato
Il funzionamento si basa sulla nozione di Ticket, un’unità di lavoro aperta quando una persona autorizzata si rivolge all’agente. Ogni Ticket viene eseguito nella propria sessione e nella propria directory, e i risultati tornano nella conversazione originale, spesso sotto forma di una pull request, cioè una proposta di modifica del codice sottoposta a revisione. Un’interfaccia web locale elenca solo gli elementi che richiedono l’intervento di una persona.
Il README del progetto fissa una regola semplice: ridurre al minimo l’attenzione umana fornendo al contempo il massimo valore. Secondo il documento di filosofia del progetto, l’agente chiede conferma una sola volta, rimane silenzioso durante il lavoro e riprende la parola solo con un risultato, una domanda o un fallimento.
Un’architettura Router-Worker
Secondo il team, gli agenti comuni considerano la sessione come unità di base. In base al rapporto citato da ifeng, una persona può seguire attivamente solo 3-5 sessioni alla volta, per cui l’attenzione umana, e non la capacità del modello, diventa il fattore limitante del lavoro in parallelo. L’architettura proposta comprende due livelli: un Router di lunga durata gestisce gli scambi e la ripartizione dei task, mentre sessioni Worker isolate svolgono il lavoro effettivo.
Il modello di dominio descrive una sequenza precisa: GitHub o Feishu producono eventi, chiamati Triggers; una fase di valutazione decide se un lotto di Triggers richiama un nuovo lavoro; ogni Ticket porta un Mandate immutabile che enuncia il motivo per cui può essere eseguito; infine, i commenti successivi su una pull request vengono instradati al Worker corretto senza nuova menzione. I comandi shell passano in background dopo 5 secondi, affinché i Workers continuino a ricevere messaggi. Il lavoro proattivo è disciplinato da tre modalità: off, observe (predefinita) e auto. In modalità observe, l’agente si limita a registrare ciò che avrebbe accettato.
Risultati derivanti da una simulazione
DeepSeek ha testato il sistema su flussi simulati di discussione di gruppo e CI GitHub, con circa 300 messaggi per prova, di cui circa 20 richieste di lavoro effettive, ogni configurazione è stata eseguita 5 volte. Il super-agent mostra un p50 di 12,4 minuti e un p95 di 15,7 minuti, contro un p95 di 29,5 minuti per una sessione singola con sotto-agenti e prompt neutro, per la quale non è stato comunicato alcun p50. In questa configurazione di riferimento, il sotto-agente non è stato chiamato nessuna volta su 5 prove.
Secondo questi stessi dati, quando il numero di arrivi è passato da circa 1 a 40 al minuto, la dimensione dei lotti è passata da 1,0 a 2,8 e la latenza per richiesta da 2,5 a 3,9 secondi. Queste cifre sono auto-dichiarate da DeepSeek e provengono da resoconti secondari del rapporto. Il progetto precisa inoltre di essere stato testato solo su messaggi sintetici e strumenti simulati, e che la qualità reale del codice prodotto non è stata misurata.
Per l’installazione, il prototipo richiede Node.js 22.19+ o 24+, git 2.32+, Python 3.8+, tmux e GitHub CLI 2.48+. Il repository indica infine che l’agente viene eseguito con tutti i diritti dell’utente del sistema operativo, il che impone di isolarlo prima di qualsiasi utilizzo.
