5 plugin DeepSeek Harness da installare su un VPS

Quali plugin di DeepSeek Harness vale la pena installare

I plugin di DeepSeek Harness sono codice di terze parti che viene eseguito all'interno dell'agent, con i privilegi dell'agent, su una macchina che paghi. L'elenco della community comprende più di venti categorie e oltre mille voci. Su un server privato virtuale (VPS) a noleggio ne servono cinque: dsh-budget per limitare la spesa, dsh-permission-rules per controllare l'accesso agli strumenti, dsh-defend per rilevare injection e secret, dsh-memory per conservare i dati che devono sopravvivere a una sessione e dsh-web-lan-access solo dopo aver deciso come eseguire l'autenticazione.

Il harness è dsh, l'agent harness open source di DeepSeek, progettato in modo che ogni componente sia un plugin. Il README del progetto lo definisce una developer preview e include l'avvertenza THERE WILL BE COMPATIBILITY-BREAKING CHANGES. Questo aspetto determina ogni scelta descritta di seguito. Blocca la versione dei componenti installati, prevedi che un aggiornamento possa renderli incompatibili e mantieni l'insieme abbastanza ridotto da poterlo esaminare interamente. Se il harness non è ancora in esecuzione, inizia da un'installazione di DeepSeek Harness su un VPS e poi torna qui. Se non sono ancora chiari i componenti in cui questi plugin si integrano, cioè il ciclo dell'agent, i suoi strumenti e la sua memoria, studia prima i concetti fondamentali, perché ogni scelta descritta di seguito è più facile da valutare quando sai quale funzione svolge ogni livello.

Come dsh installa un plugin e dove viene salvata la configurazione

dsh si assembla a partire dai plugin Cordis, quindi un'istanza in esecuzione è un albero di plugin e non un singolo programma. Un profilo è una composizione denominata di questi plugin. I due template sono web e headless. $DSH_HOME usa ~/.dsh come valore predefinito e un profilo si trova in $DSH_HOME/profiles/<name>/, dove contiene il proprio package.json, un manifest dsh.profile e un cordis.patch.yml.

dsh plugin --profile web list
dsh plugin --profile web add dsh-budget
dsh plugin --profile web remove dsh-budget

Sono supportati quattro formati sorgente: il nome semplice di un pacchetto npm, un nome con scope come @towzai/dsh-memory, un riferimento GitHub come github:PerryLink/dsh-budget#main e un percorso locale con link: o ./. È preferibile usare il formato GitHub, perché puoi sostituire #main con un commit e ottenere lo stesso codice anche il mese prossimo.

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

I livelli vengono applicati in un ordine fisso: ogni bundle nell'ordine indicato dal profilo, quindi il cordis.patch.yml del profilo, il cordis.patch.yml a livello di home e infine qualsiasi overlay --patch. L'ordine è importante perché un livello successivo può riconfigurare o rimuovere ciò che è stato impostato da uno precedente. Quindi, quando un plugin sembra installato ma non fa nulla, apri il cordis.patch.yml del profilo e verifica due aspetti: che il relativo blocco insert sia presente e che nessun livello successivo lo disabiliti.

Al 17 agosto 2026, il pacchetto npm @deepseek-ai/dsh è alla versione 0.1.0-rc.7, mentre tutti i plugin riportati di seguito dichiarano la compatibilità con 0.1.0-rc.5 fino a 0.1.0-rc.6. Questa differenza è normale in questo ecosistema ed è il motivo consueto per cui un plugin smette di essere caricato: l'harness viene aggiornato più rapidamente dei plugin che lo circondano. Aggiorna l'harness intenzionalmente, quindi verifica un plugin alla volta.

Leggi un plugin prima di considerarlo attendibile

Un plugin dsh non è isolato dal framework. Viene caricato nello stesso albero Cordis e nello stesso processo, con lo stesso utente del sistema operativo, e può accedere alle stesse credenziali del modello e allo stesso albero di lavoro. Installarlo equivale più a eseguire lo script di un'altra persona con sudo che ad aggiungere un'estensione al browser. È la stessa questione di attendibilità sollevata dai plugin di Claude Code, e la risposta è la stessa: leggi il codice oppure non installarlo.

Controlla questi quattro aspetti, in quest'ordine:

• A quali punti di estensione si collega. tools/pre-execute significa che può vedere ogni chiamata agli strumenti e bloccarla. agent/pre-step significa che può vedere i tuoi messaggi. webServer.tapIndex significa che riscrive la pagina servita al browser. Un plugin che non si collega a nessuno di questi punti può fare ben poco; un plugin che si collega a tutti è il tuo confine di sicurezza.
• Se comunica con la rete. Cerca nel codice sorgente fetch, http e qualsiasi nome host scritto direttamente nel codice. Un misuratore dei costi che invia dati al server dello sviluppatore comunica altrove il tuo modello di utilizzo.
• Se legge le credenziali. Qualsiasi componente che accede a credentials.* o a una chiave del provider deve indicare nel README un motivo preciso.
• La licenza e la data dell'ultimo commit. Un plugin senza licenza e non aggiornato da mesi, in un ecosistema che cambia ogni settimana, rappresenta un rischio operativo.

Installa quindi facendo riferimento a un commit anziché a un branch e leggi il blocco di inserimento che l'installer ha scritto in cordis.patch.yml. Quel blocco indica l'ID del plugin e la configurazione registrata; è la descrizione più breve e corretta di ciò che hai appena aggiunto. Tieni le chiavi dei provider fuori dalla portata del plugin, quando il framework lo consente, seguendo un approccio simile a tenere i secret fuori dalla portata degli agenti AI.

dsh-budget: come impedire a un agent di spendere per tutta la notte?

Un agent su un VPS viene eseguito senza supervisione. È proprio questo il motivo per cui lo si installa lì, ma è anche il rischio. dsh-budget misura i token e il costo stimato per modello, sessione e giorno, e applica limiti a questi totali.

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

I valori predefiniti sono permissivi: 10 USD per sessione, 50 al giorno e 500 al mese. Sono adatti a un team con un budget dedicato. Su un server personale sono abbastanza alti da permettere a un loop incontrollato di terminare prima che il limite venga raggiunto, quindi riducili il primo giorno.

[
  {
    "label": "Per session",
    "plugin_default_usd": 10,
    "suggested_start_usd": 2
  },
  {
    "label": "Per day",
    "plugin_default_usd": 50,
    "suggested_start_usd": 5
  },
  {
    "label": "Per month",
    "plugin_default_usd": 500,
    "suggested_start_usd": 40
  }
]

La colonna suggerita è un punto di partenza per un singolo operatore su una singola macchina, non un valore ufficiale. Aumentala quando un mese reale di utilizzo lo rende necessario. Un limite mensile di 40 USD con un limite per sessione di 2 interrompe l'esecuzione in modo esplicito e tempestivo. È ciò che serve mentre stai ancora valutando il consumo dello strumento.

- id: budget
  config:
    budgets:
      session: 2
      daily: 5
      monthly: 40
    warnRatio: 0.8
    overLimit: block

L'impostazione che modifica il comportamento della macchina è overLimit. Il valore predefinito è alert: mostra un avviso, ma continua a spendere. Di conseguenza, nella configurazione predefinita questo plugin funziona come una dashboard. Impostalo su block: l'harness rifiuta ulteriori chiamate al modello quando viene raggiunto un limite. Un job notturno si interrompe invece di continuare a generare costi fino al mattino. degrade è la terza modalità: sostituisce il modello con uno più economico definito nella mappa degradation. È la scelta corretta quando un job deve terminare, ma non richiede il modello migliore. warnRatio ha come valore predefinito 0.8, quindi ricevi una notifica quando raggiungi l'80 percento del limite.

Esistono due limiti da considerare. Il costo viene calcolato usando i prezzi forniti: prices è vuoto per impostazione predefinita e defaultPrice usa come fallback 1.0 USD per milione di token di input e 3.0 per milione di token di output. Inserisci i valori reali dei tuoi modelli, altrimenti la dashboard sarà una stima presentata come una misurazione. Inoltre, il plugin aggrega i dati nel processo in esecuzione a partire dal flusso di eventi della sessione, quindi i totali vengono azzerati quando l'harness viene riavviato. Un loop di crash, oppure un supervisor che riavvia dsh, azzera un limite giornaliero. Considera dsh-budget una protezione contro i tuoi job e imposta un limite di spesa sull'account del provider come tetto effettivo. Questo è l'argomento più ampio trattato in controllare i costi degli agent AI su un VPS.

Nell'uso quotidiano, utilizza /budget per la panoramica, /budget models per la suddivisione per modello e /budget unblock <scope> per rimuovere un blocco dopo aver deciso di proseguire.

dsh-permission-rules: quali chiamate agli strumenti non devono mai essere eseguite?

dsh-permission-rules applica regole dichiarative al flusso tools/pre-execute, quindi una regola viene valutata prima dell'esecuzione di uno strumento. Sono disponibili tre azioni. allow lascia passare la chiamata, deny la blocca e restituisce un motivo leggibile dal modello, mentre ask la inoltra al punto di approvazione ufficiale.

dsh plugin --profile web add "github:PerryLink/dsh-permission-rules#b30b4fb"

Le regole si trovano in .dsh/rules.yaml, relativo alla directory di lavoro della sessione, con un fallbackPath globale e un searchUp facoltativo per risalire verso la root del filesystem. La corrispondenza comprende glob sul nome dello strumento, glob sulle chiavi e sui valori dei parametri, glob sui percorsi relativi al workspace, selettori dell'agente come main o subagent e destinazioni di rete.

rules:
  - match: { tools: [bash], params: { command: "rm -rf*" } }
    action: deny
    reason: "No recursive deletes"
  - match: { tools: [edit, write], paths: ["**/.env*", "**/secrets/**"] }
    action: ask
    reason: "Secret files need confirmation"
  - match: { tools: ["mcp__*"] }
    action: ask
    reason: "MCP tools need confirmation"

La valutazione segue la regola della prima corrispondenza: un allow generico nelle prime righe annulla silenziosamente tutte le regole più specifiche successive. Scrivi prima i divieti e poi le regole permissive. Il glob del nome dello strumento comprende mcp__*, consentendo di controllare gli strumenti provenienti da un server Model Context Protocol (MCP) anziché dall'harness stesso. Questo è importante non appena esegui server MCP su un VPS.

È necessario prevedere un comportamento: ask richiede un risponditore. In un profilo headless potrebbe non esserci nessuno a monitorare la sessione, quindi una regola ask può sospendere un'esecuzione finché qualcuno non interviene. Usa deny per qualsiasi operazione che non approveresti mai, mantieni ask per il profilo che controlli direttamente e, se vuoi che le approvazioni funzionino senza supervisione, devi predisporre un percorso di risposta reale. Questo è l'argomento di controllare le azioni degli agenti AI con le approvazioni.

dsh-defend: e i prompt injection e i secret esposti?

dsh-defend esegue scansioni in tre punti: i messaggi in ingresso su agent/pre-step, gli argomenti degli strumenti su tools/pre-execute, incluso un controllo contro le eliminazioni distruttive, e i risultati degli strumenti su tools/post-execute. Quest'ultimo punto è particolarmente importante, perché consente di controllare i contenuti recuperati da una pagina web prima che il modello agisca su di essi.

dsh plugin --profile web add "github:PerryLink/dsh-defend#7ba3427"

Le impostazioni predefinite sono prudenti, non rigide: detection.injectionAction, detection.jailbreakAction e detection.secretAction sono tutti ask, mentre detection.secretBlockCritical è true. In questo modo un secret critico viene bloccato indipendentemente dalle altre impostazioni. Su un server non presidiato, imposta su block le azioni che vuoi controllare, perché ask senza nessuno a cui chiedere conferma non è una decisione.

Il design dell'audit è ben concepito. Gli eventi defend/detection registrano l'ID della regola, la famiglia, la categoria, la gravità, la decisione e i dati della scansione, ma non registrano mai il testo corrispondente. I secret vengono registrati solo per tipo. L'abilitazione dell'audit log non crea quindi una seconda copia della credenziale che stavi cercando di proteggere.

È importante chiarire cosa offre questo meccanismo. Il rilevamento si basa su regole e il README dichiara esplicitamente che formulazioni inedite e attacchi articolati in più passaggi possono sfuggire ai controlli. Riduce la frequenza degli attacchi più evidenti. Non rende sicuro indirizzare un agent verso contenuti non attendibili. Mantieni quindi le regole delle autorizzazioni come livello di protezione sottostante.

dsh-memory: cosa ricorda l'agente domani?

Esistono due plugin diversi chiamati dsh-memory. È utile saperlo prima di eseguire un comando di installazione. Installa specificando esplicitamente la sorgente, così otterrai quello descritto qui.

Su un server di piccole dimensioni sceglierei la build SQLite. Si registra come memory, mantiene un unico file in $DSH_HOME/memory/memory.db condiviso tra i profili ed espone memory_write, memory_search e memory_forget. La ricerca usa parole chiave nel testo e nei tag memorizzati. Non richiede un servizio di embedding, una chiave API o un processo aggiuntivo.

dsh plugin --profile web add "github:ben7am1n/dsh-memory#def7c6a"

La configurazione da modificare è ridotta: path indica il file del database, promptRecentCount (valore predefinito 10) il numero di memorie non fissate da inserire e promptMaxChars (valore predefinito 2000) il budget per il rendering. Si basa su node:sqlite, che Node 22 e 24 indicano ancora come sperimentale. Un aggiornamento di Node va quindi verificato, non dato per scontato.

Ecco cosa cambia realmente sulla macchina: le memorie inserite vengono aggiunte al prompt di sistema a ogni turno. Un budget di 2000 caratteri equivale a qualche centinaio di token di input aggiuntivi per ogni richiesta, senza scadenza. Questo incide realmente sui costi. Per questo dsh-budget deve essere presente sul server prima di dsh-memory. Mantieni contenuto promptMaxChars e usa memory_forget per eliminare le memorie obsolete, invece di lasciare crescere il file.

La build alternativa salva le memorie in un file YAML ed esegue ricerche tramite embedding con inserimento automatico nel prompt. Si installa con dsh plugin --profile web add github:towzai/dsh-memory. Richiede un'istanza locale di ollama e un modello di embedding, qwen3-embedding:0.6b per impostazione predefinita, sostituibile con DSH_MEMORY_EMBED_MODEL. Il recupero semantico è migliore di quello basato sulle parole chiave. Richiede però anche un secondo servizio e un insieme di pesi del modello residenti sullo stesso server. Su un piano di piccole dimensioni, questa memoria viene sottratta al lavoro per cui hai noleggiato il server. Sceglila quando hai RAM disponibile. Il compromesso generale tra qualità del recupero e costo delle risorse residenti è descritto in memoria locale per gli agenti.

dsh-web-lan-access: l'interfaccia web deve ascoltare oltre il loopback?

npx @deepseek-ai/dsh web pubblica l'interfaccia su 127.0.0.1:3080. I browser espongono crypto.randomUUID() soltanto in un contesto sicuro, quindi il caricamento della stessa pagina tramite HTTP non cifrato da un'altra macchina non riesce. dsh-web-lan-access risolve il problema usando webServer.tapIndex per iniettare un piccolo polyfill e modificando il binding del server in modo che ascolti su 0.0.0.0.

Leggere l'avviso del progetto prima di installarlo. Il binding su 0.0.0.0 rende l'agent raggiungibile senza autenticazione da chiunque si trovi sulla stessa rete locale (LAN); su un server con un indirizzo IP pubblico, questo significa da tutta Internet. Un breve elenco di metodi sensibili (settings.*, credentials.*, llm.discoverModels) resta vincolato al loopback e restituisce 403 alle origini remote, limitando i danni. Non li impedisce, perché la superficie per chiamare gli strumenti resta accessibile a chiunque trovi la porta.

Nella maggior parte dei casi questo plugin non serve. Inoltrare invece la porta tramite SSH.

ssh -N -L 3080:127.0.0.1:3080 you@your-server

Aprire quindi http://127.0.0.1:3080 nel browser locale. L'harness continua ad ascoltare soltanto sul loopback, quindi nulla viene esposto; inoltre, poiché i browser considerano 127.0.0.1 un'origine sicura, crypto.randomUUID() è disponibile e non serve alcun polyfill. Un comando, nessun plugin e nessuna nuova superficie di attacco.

Installare il plugin soltanto quando un port forwarding non è sufficiente, ad esempio quando un telefono sulla stessa rete deve raggiungere l'interfaccia. In tal caso, eseguirne il binding dietro un'interfaccia di rete privata, mantenere una regola firewall che consenta il traffico soltanto da quell'interfaccia e indicare i nomi da utilizzare in trustedHosts nella voce web-runtime. Per un accesso realmente multiutente è disponibile dsh-passwords, che aggiunge permessi per sottoutente, limiti orari dei token per sottoutente e quote giornaliere di tempo, certificati TLS (transport layer security) automatici tramite Let's Encrypt e un audit log cifrato. Valutarlo come una piattaforma, non come un plugin: richiede le porte 80 e 443, include un proprio installer e il percorso rapido documentato inoltra uno shell script dalla rete direttamente a bash. Preferire npm install -g dsh-passwords seguito da dsh-passwords install, così il codice resta su disco e può essere letto prima dell'esecuzione.

Come rimuovere correttamente un plugin

La disinstallazione richiede due passaggi, ma spesso il secondo viene saltato.

dsh plugin --profile web remove dsh-budget
dsh plugin --profile web list

list non dovrebbe più visualizzarlo. Quindi apri $DSH_HOME/profiles/web/cordis.patch.yml ed elimina eventuali blocchi di inserimento residui che riportano il nome del plugin, perché è questa voce a caricarlo nell'albero. Riavvia l'harness per ricostruire l'albero; un plugin già caricato resta attivo finché non lo fai. Infine, ricorda che i dati restano anche dopo la rimozione del codice. $DSH_HOME/memory/memory.db e .dsh/rules.yaml sopravvivono alla disinstallazione. Eliminali manualmente se l'obiettivo era rimuovere anche i dati.

Cosa ho consultato e quando

Ogni riferimento qui riportato indica un commit, non un branch, perché main conterrà codice diverso quando leggerai questo testo. Ho consultato tutto il 17 agosto 2026 e, quel giorno, l'harness stesso era alla versione 0.1.0-rc.7 su npm.

Verifica nuovamente questi riferimenti prima di copiare un comando. In un ecosistema in anteprima per sviluppatori, un numero di versione associato a una data è l'unico che abbia un significato preciso.

FAQ

Quali plugin DeepSeek Harness dovrei installare per primi su un VPS?

Installa prima di tutto dsh-budget e dsh-permission-rules. Un budget con overLimit: block impedisce a un'esecuzione non supervisionata di consumare risorse per tutta la notte, mentre un file .dsh/rules.yaml blocca una chiamata allo strumento che non avresti mai autorizzato. Aggiungi dsh-defend quando l'agente legge contenuti dal Web pubblico e dsh-memory quando ti accorgi di incollare lo stesso contesto in ogni sessione. Evita temi e indicatori di stato: aggiungono codice eseguito con i privilegi dell'agente senza modificare il comportamento della macchina.

I plugin dsh sono isolati dal harness?

No. Un plugin viene caricato nello stesso albero Cordis del harness, nello stesso processo, con lo stesso utente del sistema operativo, le stesse credenziali del modello e lo stesso albero di lavoro. Un plugin che intercetta tools/pre-execute può vedere e bloccare ogni chiamata allo strumento; uno che intercetta agent/pre-step può vedere i tuoi messaggi. Leggi quindi il codice sorgente, verifica la licenza e la data dell'ultimo commit, quindi installa facendo riferimento al commit anziché al branch, in modo che il codice non possa cambiare senza che tu lo sappia.

dsh-budget arresterà effettivamente l'agente o mostrerà soltanto un avviso?

Dipende da overLimit. Il valore predefinito è alert: mostra un avviso a warnRatio e continua a spendere. block rifiuta ulteriori chiamate al modello una volta raggiunto il limite, mentre /budget unblock <scope> lo rimuove quando scegli di continuare. degrade passa a un modello meno costoso definito nella mappa degradation. Esiste però un limite importante: i totali vengono aggregati dal processo in esecuzione a partire dal flusso di eventi della sessione. Il riavvio del harness li azzera e un ciclo di riavvio può aggirare un limite giornaliero. Imposta un limite di spesa sull'account del provider, che rappresenta il limite effettivo.

Come rimuovo completamente un plugin dsh?

Esegui dsh plugin --profile web remove <package-name>, conferma con dsh plugin --profile web list, quindi apri $DSH_HOME/profiles/web/cordis.patch.yml ed elimina eventuali blocchi di inserimento rimasti per quel plugin, perché è quella voce a caricarlo. Riavvia il harness per ricostruire l'albero dei plugin. I dati scritti dal plugin restano sul disco: sia $DSH_HOME/memory/memory.db sia .dsh/rules.yaml sopravvivono alla disinstallazione finché non li elimini manualmente.

È sicuro esporre l'interfaccia Web di dsh sulla rete?

Non senza ulteriori misure. dsh web è in ascolto su 127.0.0.1:3080, mentre dsh-web-lan-access modifica il binding impostandolo su 0.0.0.0. Il README del progetto specifica che questa configurazione rende l'agente raggiungibile senza autenticazione da chiunque si trovi sulla stessa rete; con un indirizzo IP pubblico, questo equivale a esporlo a Internet. Alcuni metodi (settings.*, credentials.*, llm.discoverModels) restano associati al loopback e restituiscono 403 dalle origini remote, riducendo l'impatto ma senza risolvere il problema. Usa un port forwarding SSH, ssh -N -L 3080:127.0.0.1:3080 you@your-server, oppure colloca la porta dietro un'interfaccia di rete privata e una regola firewall. Aggiungi inoltre un'autenticazione reale prima di rendere il servizio raggiungibile dall'esterno.