Agent harness: cos'è e perché ora se lo scrivono anche i produttori di modelli

Un agent harness è il programma che sta attorno al modello e gli fa fare il lavoro: gestisce il ciclo di richieste e risposte, gli strumenti che il modello può chiamare, i permessi su quegli strumenti, la sessione e quello che resta scritto quando ha finito. Il 13 agosto 2026 ne è arrivato uno nuovo da un posto che merita attenzione: DeepSeek Harness, comando dsh, che il repository presenta come un agent harness open source sviluppato da DeepSeek AI, con licenza MIT e un'architettura in cui, cito il README, tutto è un plugin.

Che un laboratorio che produce modelli pubblichi anche l'harness non è un dettaglio organizzativo. Vuol dire che il pezzo dove si decide la partita si è spostato: il modello è la parte che tutti sanno valutare, l'harness è la parte che decide se quel modello combina qualcosa di utile o gira a vuoto per venti minuti.

Cosa fa un agent harness che il modello non fa

Il modello produce testo e chiamate a strumenti, e finisce lì. Tutto il resto lo fa l'harness: esegue davvero le chiamate, decide quali sono permesse e quali richiedono un'approvazione, tiene la conversazione dentro la finestra di contesto, gestisce cosa succede quando uno strumento fallisce e stabilisce dove finisce lo stato quando la sessione si chiude. Sono le stesse quattro o cinque cose in ogni harness serio, e sono quelle che nessun benchmark di modello misura.

Da qui viene una conseguenza che si sottovaluta di continuo: due harness diversi con lo stesso modello dietro danno risultati molto diversi. Non perché uno sia scritto meglio, ma perché la qualità di un agente dipende in buona parte da scelte che stanno fuori dal modello, e cioè quali strumenti gli metti in mano, quanto contesto gli passi e cosa gli permetti di fare senza chiedere. Una scelta come far ereditare a un subagent la conversazione invece di farlo partire da zero è esattamente questo tipo di decisione, e la prende l'harness. È la ragione per cui i confronti fra agenti di coding sono così scivolosi, e la stessa ragione per cui vale la pena guardare da vicino un meta-agente che orchestra altri agenti di coding invece di fermarsi al nome del modello che c'è sotto.

C'è poi la parte che si scopre solo mettendolo in produzione, ed è il comportamento quando nessuno guarda. Un harness che chiede conferma a ogni passo è inutilizzabile in una routine schedulata, uno che non chiede mai niente è un problema di sicurezza. Chi ha provato a far girare un agente di coding in automatico sa che è lì, nella granularità dei permessi e in cosa succede dopo un errore, che un harness si rivela o crolla.

Cosa ha pubblicato DeepSeek, in concreto

Il repository deepseek-ai/deepseek-harness si installa con npx @deepseek-ai/dsh web, oppure clonandolo e lanciando pnpm install, pnpm run build e pnpm dsh web. La licenza è MIT, le dipendenze di terze parti stanno in THIRD_PARTY_NOTICES.md, e l'architettura dichiarata è costruita su Cordis, con il modello dei plugin come principio portante invece che come punto di estensione aggiunto dopo.

Il numero che ha fatto girare la notizia è la crescita: al 14 agosto 2026 il repository dichiara circa 74.900 stelle e 6.400 fork, accumulate in pochissimi giorni. Le stelle però non misurano niente di quello che conta qui, e il README lo dice in modo più utile di qualsiasi commento esterno: DeepSeek Harness è in developer preview, sta iterando rapidamente, e ci saranno cambiamenti che rompono la compatibilità. La maiuscola in quella frase è del progetto, non mia.

Il dato che pesa davvero l'ho trovato altrove, e va guardato insieme a quell'avvertimento: sulla pagina delle release del repository, al 14 agosto 2026, non risulta pubblicata nessuna release e nessun tag. Un progetto senza tag è un progetto su cui non esiste una versione da fissare, e quindi ogni installazione punta a quello che c'era sul branch principale nel momento in cui l'hai fatta.

Come si valuta un agent harness prima di costruirci sopra

Il primo controllo è proprio quello: guarda se ci sono tag e release. Se non ce ne sono, l'unica cosa che puoi fissare è un commit, e allora fissalo esplicitamente invece di installare dal branch e scoprire fra due settimane che il comportamento è cambiato. Con npx non c'è un lockfile che ti protegga, e un harness che decide i permessi degli strumenti è l'ultimo posto dove vuoi un aggiornamento silenzioso.

Il secondo controllo è dove vive lo stato. Un harness va valutato chiedendosi cosa resta scritto sul disco quando l'agente ha finito, dove sta, chi lo può cancellare e cosa si perde se sparisce. Le risposte cambiano molto da progetto a progetto, e determinano se puoi far girare due agenti sullo stesso repository o se si pestano i piedi.

Il terzo è la granularità dei permessi, che è il vero discrimine tra un harness da demo e uno da mettere al lavoro. La domanda concreta non è se supporta i permessi, ma se puoi permettere un comando e non un altro dello stesso strumento, e se il diniego è verificabile a posteriori in un log. Se questa risposta non è nella documentazione, la risposta è no.

La mia posizione su DeepSeek Harness, con quello che è pubblico oggi, è questa: vale un pomeriggio di prova su un progetto che non ti serve, non vale una pipeline di produzione questa settimana. Non per diffidenza verso DeepSeek, ma perché il progetto stesso ha scritto che romperà la compatibilità, e ignorare un avvertimento del genere per fretta è il modo più prevedibile di perdere una giornata fra un mese.

Lo stesso ragionamento vale sul lato dei costi, e due giorni dopo è arrivata la conferma: dal 16 agosto 2026 i prezzi delle API DeepSeek sono divisi in fasce orarie, con l'output di deepseek-v4-pro passato da 0,87 a 3,96 dollari per milione di token in fascia peak. Un vantaggio che dipende da una decisione di qualcun altro, sull'harness come sul listino, non è mai un pezzo di architettura.

Sul mio sito l'harness che scrive questi articoli è deliberatamente noioso proprio per questo motivo. Le routine girano come sessioni cloud schedulate documentate in automazione-blog/cloud-agent/, ogni mattina partono da un checkout appena clonato e tutte le regole che devono seguire stanno committate in .claude/skills/articolo/. Non c'è nessuno stato fuori dal repository, e la ragione è la stessa per cui guardo i tag di un progetto nuovo: quando la macchina cambia ogni giorno, l'unica cosa di cui ti puoi fidare è quello che è versionato.

L'harness è diventato il posto dove si decide cosa fa un agente, e questo cambia anche la domanda da fare a chi ti propone una soluzione. Non quale modello usi, ma cosa gli lasci fare, con quali permessi e cosa resta scritto: è la prima cosa che guardo quando aiuto qualcuno a mettere un agente AI dentro un processo di lavoro, e in genere è anche la prima su cui non c'è una risposta pronta.