DeepSeek rilascia dsh-superagent, agente router-worker per GitHub
Testo scritto con l’intelligenza artificiale a partire da una fonte citata, senza revisione umana prima della pubblicazione.
Il progetto v0.1.0 MIT separa dispatch e worker isolati per accelerare ticketing su repository, disponibile come bundle locale per DeepSeek Harness.
DeepSeek ha pubblicato dsh-superagent v0.1.0, un prototipo open source con licenza MIT che esegue un agente di coding per un singolo repository GitHub con architettura router-worker1.
Il pacchetto è un bundle TypeScript per DeepSeek Harness. Ascolta GitHub e, opzionalmente, Feishu. Trasforma le richieste autorizzate in elementi di lavoro paralleli, ciascuno in una propria sessione di agente. I risultati tornano nella conversazione di origine, spesso come pull request. Un pannello web locale mostra solo ciò che richiede un intervento umano1.
Regola operativa: chiedere il minimo di attenzione umana e restituire il massimo valore. L’agente conferma una volta, poi tace mentre lavora. Scrive di nuovo solo con un risultato, una domanda o un errore. Il team ha pubblicato anche un post di design, Exploring Super-agent Design: Towards a More Autonomous Agent System1.
La motivazione dichiarata è il carico cognitivo. Gli agenti diffusi trattano una sessione come unità base. Secondo il resoconto citato, una persona segue attivamente solo da 3 a 5 sessioni alla volta. L’attenzione umana, non la capacità del modello, diventa il collo di bottiglia per il multitasking1.
L’architettura separa interazione e lavoro. Un Router long running gestisce input e dispatch. Worker isolati eseguono i Ticket. Le fonti generano Trigger, GitHub o Feishu. Un modulo di valutazione decide se la batch di Trigger richiede lavoro. Se sì, crea un Ticket con un Mandato immutabile che spiega perché può procedere. Le Subscription indirizzano i commenti successivi sul pull request al Worker giusto, senza nuova menzione1.
La sessione principale esegue il preset dsh-superagent-router con un set di strumenti ridotto. Ogni Worker esegue dsh-superagent-worker. I comandi di shell passano in background dopo 5 secondi. Così i Worker continuano a ricevere messaggi mentre i task girano in coda, come descritto nel documento di esecuzione1.
Il lavoro proattivo segue regole di autorizzazione con tre modalità: off, observe e auto. Di default è observe. In observe l’agente registra cosa avrebbe accettato, senza eseguire l’azione. L’attivazione piena resta una scelta del team1.
L’installazione richiede una macchina locale con Node.js 22.19 o 24 o superiore, git 2.32 o superiore, Python 3.8 o superiore, tmux e GitHub CLI 2.48 o superiore. Il bundle gira come profilo dedicato di DeepSeek Harness. Esegue con accesso completo all’utente del sistema operativo. Va isolato prima dell’uso1.
DeepSeek ha testato il prototipo con chat di gruppo simulate e stream CI di GitHub simulati. Ogni run aveva circa 300 messaggi, con circa 20 richieste reali di lavoro. Ogni schema ha girato 5 volte. Il super-agent ha chiuso al p50 in 12,4 minuti e al p95 in 15,7 minuti. Il baseline a sessione singola con subagent e prompt neutro ha segnato un p95 di 29,5 minuti. Motivo addotto: con quel prompt, il baseline ha chiamato uno strumento secondario 0 volte su 5 run. Con arrivi in crescita da circa 1 a 40 al minuto, la batch media del Router è salita da 1,0 a 2,8. La latenza per richiesta è cresciuta da 2,5 a 3,9 secondi. Un’ablation che rimuoveva il pass-through diretto degli eventi ha aumentato le decisioni del Router di circa il 30 per cento. I token letti da cache sono saliti di circa il 37 per cento, da 23,23 milioni a 31,77 milioni. Tutte le cifre sono auto-riportate e provengono da resoconti secondari del rapporto. La qualità del codice reale non è stata misurata. I test hanno usato messaggi e strumenti sintetici1.
Il team elenca idee oltre il prototipo: un Watchdog esterno, separazione tra storage e calcolo, un ciclo ReAct asincrono. Sono piste di ricerca, non funzioni presenti1.
La modalità observe offre un varco operativo: permette di stimare cosa verrebbe accettato prima di attivare l’automazione completa1.
Fonti
Come è nato questo articolo Scritto da un sistema di intelligenza artificiale, con controlli automatici
Millebit non ha giornalisti che scrivono gli articoli: li scrive un motore editoriale basato su modelli di intelligenza artificiale, a partire dalle fonti elencate qui sopra. Prima di uscire, ogni testo passa questi controlli:
- Rilettura. Un passaggio toglie i tic della prosa generata da un modello, come i contrasti costruiti e le frasi che annunciano invece di informare, senza toccare fatti e fonti.
- Fedeltà alle fonti. Un passaggio dedicato toglie ogni affermazione che le fonti non sostengono. Valutazione su questo pezzo: 9/10.
- Anti-cliché. Un filtro scarta frasi fatte, enfasi e tic della prosa artificiale: superato.
- Giudizio editoriale. Un modello valuta il pezzo su sette criteri (apertura, chiarezza, economia, concretezza, voce, struttura, fedeltà) e sotto 7,8/10 non si pubblica. Questo articolo ha preso 7,9/10.
I controlli riducono gli errori ma non li eliminano: un modello può fraintendere una fonte. Per le decisioni importanti, risali alla fonte originale. Se trovi un errore, segnalacelo.
Per vedere Millebit nelle notizie principali di Google, aggiungilo alle tue fonti preferite. Oppure segui l’edizione di oggi, il feed RSS o La Sintesi.