DeepSeek apre il suo harness per agenti, così ogni componente può essere sostituito

DeepSeek ha rilasciato la prima developer preview di Harness, e il contrasto dietro il titolo di Google News è insolitamente concreto. L’azienda non sta semplicemente aggiungendo plugin a un altro agente di coding. Ha reso sostituibili l’adattatore del modello, il registro degli strumenti, il log delle sessioni, la sandbox, il ciclo dell’agente e l’interfaccia utente.

Questo progetto colloca DeepSeek Harness a un livello inferiore rispetto a prodotti come Claude Code, Codex e altri agenti di coding pronti all’uso. Quei prodotti offrono agli sviluppatori un agente assemblato con punti di estensione definiti. DeepSeek propone invece un substrato configurabile in grado di produrre molti agenti, incluso uno che può somigliare a un assistente di coding.

La distinzione mette anche in luce la maggiore incertezza del progetto. DeepSeek afferma che ogni parte può essere combinata, sostituita o estesa, ma il software rimane una developer preview. La documentazione avverte esplicitamente che si verificheranno modifiche incompatibili con le versioni precedenti. Il lancio rappresenta quindi sia una proposta architetturale sia un test ancora incompleto sulla capacità della modularità estrema di reggere l’uso in produzione.

Cosa ha annunciato davvero il titolo di Google News

DeepSeek ha aperto l’infrastruttura attorno a un modello AI, non ha rilasciato un altro modello con una nuova interfaccia di chat.

DeepSeek Harness, chiamato anche dsh, è un harness open source per agenti rilasciato con licenza MIT. Un agent harness è il software che circonda un modello e gestisce prompt, strumenti, file, stato, autorizzazioni e chiamate ripetute al modello.

Il repository ufficiale del progetto descrive un principio guida: “Everything is a Plugin.” Ciò include modelli, skill, strumenti, sessioni, sandbox, filesystem, loop, orchestrazione e l’interfaccia presentata agli utenti.

DeepSeek afferma che la versione attuale è una developer preview. Gli utenti possono avviare la sua interfaccia browser tramite un comando npm, che per impostazione predefinita serve l’applicazione in locale. Gli sviluppatori possono anche compilare il repository dal codice sorgente.

Il rilascio pubblico è seguito a segnali secondo cui DeepSeek stava creando un team dedicato agli harness. Tuttavia, il codice conta più del precedente segnale di assunzioni. Fornisce agli sviluppatori un sistema concreto da ispezionare, modificare ed eseguire senza dipendere da una dimostrazione di prodotto.

Questo spiega perché la notizia è passata su Google News come qualcosa di più del lancio di un altro repository. DeepSeek è diventata nota soprattutto per modelli competitivi, ma Harness sposta l’attenzione sul software che determina il modo in cui un modello svolge lavoro reale.

Un modello linguistico grezzo riceve input e genera output. Un agente funzionante deve anche decidere quando chiamare uno strumento, quale cronologia conservare, dove possono essere eseguiti i comandi e quando è necessaria l’approvazione umana.

Queste decisioni spiegano spesso perché due prodotti che usano modelli simili si comportano in modo diverso. Il sistema circostante può riprendersi da un comando fallito, mantenere un piano, comprimere il contesto o impedire un’operazione sui file non sicura. Può anche gestire male una qualunque di queste responsabilità.

DeepSeek sta trasformando in prodotto quel sistema circostante. La sua applicazione web distribuita è una possibile composizione dei componenti sottostanti, non un’implementazione privilegiata che ogni utente debba accettare.

Il framework è costruito su Cordis, che DeepSeek descrive come un meta-framework per software composto dinamicamente. Cordis consente ai plugin di contribuire con servizi, eventi tipizzati ed effetti reversibili a un contesto condiviso.

Un effetto reversibile è una modifica tracciata che può essere annullata quando il componente che l’ha apportata viene scaricato. Questo offre al runtime un modo strutturato per aggiungere o rimuovere capacità senza lasciare stato sconosciuto alle spalle.

Questa base sostiene la promessa più ampia di DeepSeek. Gli sviluppatori dovrebbero poter sostituire un provider di filesystem locale con un’implementazione remota, cambiare l’adattatore del modello o introdurre un altro ciclo dell’agente tramite configurazione.

Il rilascio non dimostra che ogni combinazione funzionerà in modo affidabile. Dimostra però che DeepSeek ha tracciato confini di plugin attorno a componenti che altri prodotti per agenti spesso trattano come fissi.

Questa differenza crea la tensione centrale. Meccanismi più sostituibili danno agli sviluppatori maggiore controllo, ma creano anche più interfacce, relazioni di dipendenza e modalità di errore da gestire.

Perché DeepSeek Harness mette sotto pressione gli agenti di coding completi

DeepSeek mette in discussione l’idea che gli sviluppatori debbano personalizzare un agente solo ai margini.

La maggior parte degli assistenti di coding espone meccanismi di estensione preservando al contempo un centro progettuale definito. Gli sviluppatori possono aggiungere strumenti, connettere servizi esterni, installare skill o modificare istruzioni. Il prodotto continua però a possedere il proprio loop principale, il modello di sessione e l’interfaccia.

DeepSeek Harness sposta verso l’interno il confine di ciò che può essere sostituito. La sua documentazione sull’architettura afferma che non esiste un nucleo privilegiato che gli sviluppatori siano costretti a modificare direttamente.

Persino il loop predefinito dell’agente viene registrato attraverso lo stesso contesto condiviso delle altre capacità. Quel loop controlla come l’input dell’utente diventa richieste al modello, chiamate agli strumenti, risultati e passaggi successivi.

Questo non rende obsoleti Claude Code, Codex o prodotti simili. Gli agenti di coding maturi integrano installazione, aggiornamenti, autenticazione, accesso ai modelli, regole di sicurezza e decisioni sull’interfaccia in un’esperienza coerente.

Questa integrazione ha un valore reale. Uno sviluppatore che deve correggere un test oggi potrebbe preferire uno strumento con impostazioni predefinite sensate a un framework che richiede scelte architetturali.

DeepSeek esercita invece pressione su team di ricerca, ingegneri di piattaforma e organizzazioni che desiderano impostazioni diverse. Questi utenti potrebbero avere bisogno di una sandbox personalizzata, di un gateway interno per i modelli, di archiviazione controllata o di un percorso di esecuzione verificabile.

Un adattatore del modello sostituibile è particolarmente importante. Separa il comportamento dell’agente dalla dipendenza esclusiva da un singolo fornitore di modelli.

La documentazione API di DeepSeek discute già di harness di terze parti, incluso l’estensibile agente di coding Pi. La guida all’integrazione di Pi include anche una clausola di esclusione della responsabilità: DeepSeek non garantisce efficacia o sicurezza di terze parti.

Harness offre un’altra risposta. Invece di chiedere agli sviluppatori di adattare i modelli DeepSeek a un agente esterno, DeepSeek può fornire l’architettura circostante consentendo comunque altri provider di modelli.

Questo rende la competizione principale meno legata a DeepSeek contro una specifica azienda. È una competizione tra un substrato profondamente configurabile e un prodotto per agenti completo e progettualmente definito.

La strada del substrato consente a un’organizzazione di definire il funzionamento del proprio sistema. Un team potrebbe usare un modello per la pianificazione, un altro per la generazione di codice e un modello locale per la classificazione di dati sensibili. I provider possono stare dietro un confine di adattatore condiviso.

Lo stesso team potrebbe assegnare strumenti diversi a diversi agenti. Uno specialista di database potrebbe ricevere accesso in sola lettura, mentre un agente di deployment otterrebbe controlli di rilascio strettamente circoscritti.

Queste restrizioni possono risiedere in capacità registrate e policy di esecuzione. Non devono dipendere soltanto da una frase in un system prompt.

La strada del prodotto progettualmente definito comporta compromessi diversi. Limita il numero di scelte che gli utenti devono comprendere, concentra i test sui percorsi supportati e crea un obiettivo di supporto coerente.

DeepSeek Harness mette quindi sotto pressione i prodotti consolidati a livello architetturale, non necessariamente a livello dell’utente quotidiano. I concorrenti devono decidere quanta parte della loro infrastruttura interna gli sviluppatori dovrebbero poter sostituire.

Possono mantenere controllato il centro ed espandere le estensioni supportate. Possono esporre SDK e servizi di livello inferiore. Possono anche sostenere che la sostituzione completa crei complessità operativa senza un beneficio pratico sufficiente.

La risposta immediata richiesta potrebbe non essere un framework equivalente. Il segnale più forte sarà capire se i fornitori di agenti chiariranno i propri confini architetturali e renderanno più comportamenti ispezionabili.

Per gli acquirenti aziendali, questa non è una distinzione astratta. Un sistema di sessioni fisso può entrare in conflitto con requisiti di conservazione. Una sandbox fissa potrebbe non supportare l’infrastruttura di un’organizzazione. Una pipeline di strumenti fissa potrebbe non avere i necessari controlli di approvazione.

Gli sviluppatori che seguono il lancio tramite Google News dovrebbero quindi concentrarsi sulla titolarità. DeepSeek propone che i team debbano possedere una porzione maggiore dello stack dell’agente, anche quando tale titolarità comporta lavoro aggiuntivo.

Tutto è un plugin, incluso il ciclo dell’agente

Il meccanismo rilevante non è il numero di plugin, ma l’assenza di un centro protetto che i plugin non possano sostituire.

Un’istanza DeepSeek Harness in esecuzione viene assemblata come un albero di plugin. I profili definiscono composizioni con nome, mentre i bundle raccolgono righe di configurazione e il codice che tali righe montano.

DeepSeek fornisce template web e headless. Il bundle base fornisce adattatori per modelli, strumenti, persistenza, controlli sandbox, policy di approvazione, credenziali, impostazioni e telemetria.

Bundle aggiuntivi possono aggiungere un’applicazione browser o un runner a esecuzione singola. I livelli di configurazione vengono applicati in ordine e le patch successive possono sostituire righe o introdurne di nuove.

Questa disposizione consente a due agenti di condividere gran parte dello stesso codice pur esponendo capacità differenti. Un profilo potrebbe includere un’interfaccia browser e una shell locale. Un altro potrebbe essere eseguito senza server all’interno di un workflow automatizzato.

Il progetto divide il comportamento centrale in pacchetti. Le sessioni possiedono un log di eventi append-only, ossia gli eventi registrati vengono aggiunti anziché sovrascritti silenziosamente. Gli strumenti dispongono di un registro con ambito definito e di una pipeline di esecuzione protetta.

Il pacchetto system prompt assembla sezioni del prompt e schemi degli strumenti. Il pacchetto del modello linguistico fornisce il vocabolario dei messaggi e il confine dell’adattatore del provider. Il pacchetto dell’agente espone agenti attivi ed eventi correlati.

Un turno può contenere più passaggi. Ogni passaggio consiste in una richiesta al modello e negli strumenti chiamati da quella richiesta.

Prima dell’esecuzione, i plugin possono ispezionare o rifiutare il lavoro tramite eventi definiti. L’output del modello viene trasmesso nella sessione, le chiamate agli strumenti attraversano fasi precedenti e successive all’esecuzione e i risultati possono attivare un’altra richiesta al modello.

Questa struttura di eventi è importante perché la sola estensibilità non garantisce un comportamento coerente. I plugin necessitano di punti concordati in cui possano osservare, modificare o interrompere il processo.

DeepSeek usa eventi di sessione durevoli per i fatti che devono sopravvivere a un ricaricamento. Usa eventi di agenti attivi per il lavoro attualmente in corso. Gli eventi delle capacità consentono a policy e adattatori di collegarsi ai sottosistemi senza importare l’intero loop.

Il log della sessione agisce come fonte di verità per il contesto visibile al modello. DeepSeek afferma che qualsiasi elemento che raggiunga una richiesta al modello debba essere ricostruibile da quel log.

Questa scelta collega diverse funzionalità spesso implementate in modo indipendente. Ripresa, fork, trascrizioni, persistenza, replay e telemetria possono derivare dallo stesso flusso di eventi.

L’alternativa consiste nel mantenere rappresentazioni separate per l’interfaccia, il contesto del modello, la cronologia salvata e il sistema di osservabilità. Queste copie possono divergere dopo errori, annullamenti o compressione del contesto.

Il progetto di DeepSeek non può eliminare automaticamente la divergenza. Le implementazioni dei plugin possono comunque contenere bug. Tuttavia, una fonte di eventi comune offre agli sviluppatori un punto definito per ispezionare ciò che è accaduto.

Le interfacce delle capacità aggiungono un ulteriore livello. DeepSeek definisce un’interfaccia tramite un’interfaccia di servizio, un provider che implementa tale interfaccia e un consumer che utilizza il servizio.

Considerate l'accesso al filesystem. Uno strumento rivolto al modello può richiedere un'operazione su file, mentre un provider del filesystem decide dove e come avviene.

Sostituire il provider può reindirizzare la capacità da uno spazio di lavoro locale a una sandbox remota. Le relative operazioni di shell, terminale e language server possono quindi condividere quell'ambiente di esecuzione.

Si tratta di una forma di modularità più profonda rispetto all'aggiunta di un comando a un assistente esistente. Modifica il luogo e le policy del lavoro dell'assistente senza riscrivere ogni consumer.

I subagent utilizzano un confine simile. Un provider potrebbe creare un agente figlio all'interno di Harness. Un altro potrebbe delegare l'attività a un prodotto separato mantenendo l'interfaccia padre.

Cordis fornisce il modello di composizione sottostante. Il relativo framework paper descrive la componibilità temporale come la rimozione di un componente e la completa inversione dei suoi effetti.

Il paper definisce la componibilità spaziale come la dichiarazione delle dipendenze e la reazione ai cambiamenti del contesto condiviso. Cordis combina questi concetti mediante effetti tracciati, risoluzione delle dipendenze, riconciliazione della configurazione e hot module replacement.

Il paper è stato pubblicato come bozza datata 13 agosto 2026. Gli autori avvertono che si tratta di una preprint in revisione attiva e che i suoi contenuti potrebbero cambiare sostanzialmente.

Questo avvertimento è importante. Un vocabolario formale può rendere un'architettura più facile da discutere, ma non ne convalida autonomamente prestazioni, affidabilità o sicurezza.

Il meccanismo di DeepSeek resta convincente perché allinea la teoria alla struttura osservabile del repository. Il documento architetturale nomina servizi, pacchetti, eventi, livelli di configurazione e punti di sostituzione.

Il risultato assomiglia più a un ambiente operativo per agenti che a un singolo assistente. Modelli e strumenti sono applicazioni di quell'ambiente, mentre il sistema di contesto ed eventi li coordina.

Per gli sviluppatori, il vantaggio è una ricomposizione controllata. Per DeepSeek, il vantaggio è la portata strategica. I suoi modelli possono partecipare, ma Harness non richiede che l'intero ecosistema dipenda da una sola famiglia di modelli.

L'avvertenza sulla Developer Preview è il vero rischio

L'affermazione di flessibilità di DeepSeek è visibile nel codice, ma la prontezza per la produzione resta non dimostrata ed è esplicitamente esclusa.

Il repository avverte in lettere maiuscole che si verificheranno modifiche incompatibili con le versioni precedenti. Non è una nota di rilascio secondaria. Cambia il modo in cui le organizzazioni dovrebbero valutare il progetto.

Un team può sperimentare DeepSeek Harness oggi. Non dovrebbe presumere che profili, contratti dei plugin, file di configurazione o servizi interni rimangano stabili tra un aggiornamento e l'altro.

Questa incertezza è particolarmente importante per un framework progettato attorno a interfacce sostituibili. Ogni componente personalizzato dipende da qualche contratto, anche quando l'architettura riduce al minimo l'accoppiamento diretto.

Se tali contratti cambiano, gli sviluppatori di plugin devono aggiornare le proprie implementazioni. Una modularità profonda può contenere un cambiamento, ma non può eliminare il costo di mantenere i confini.

Anche la configurazione presenta un rischio sottile. Il sistema di stratificazione documentato sostituisce l'intera configurazione di una riga selezionata invece di combinare automaticamente ogni valore annidato.

Questa regola può essere prevedibile per operatori esperti. Può anche produrre impostazioni mancanti quando gli utenti presumono che una patch parziale conservi i campi non specificati.

La sfida più ampia è il test combinatorio. Un prodotto finito può convalidare una raccolta limitata di combinazioni tra modelli, strumenti, sandbox e interfacce.

Un framework che consente a ogni livello di cambiare affronta una superficie di compatibilità molto più ampia. DeepSeek non può realisticamente testare ogni adapter per modelli di terze parti con ogni pipeline di strumenti e provider di storage.

La responsabilità si sposta quindi verso gli autori dei profili e i team di deployment. Devono testare l'esatta composizione che intendono utilizzare.

La sicurezza richiede una cautela analoga. Sandbox e policy degli strumenti sostituibili creano opportunità per un isolamento più forte, ma la sostituibilità non garantisce una configurazione sicura.

Un provider di subprocess permissivo può compromettere un elenco di strumenti attentamente limitato. Un plugin personalizzato può gestire male le credenziali, esporre contesto sensibile o aggirare il comportamento di approvazione previsto.

L'open source aiuta i revisori a ispezionare questi percorsi. Non significa che ogni plugin con un topic dsh-plugin abbia ricevuto un audit di sicurezza.

La scoperta dei plugin diventa essa stessa un problema di fiducia. Gli sviluppatori hanno bisogno di provenienza, compatibilità di versione, segnali di manutenzione e di un modo per capire quale codice ottiene accesso a sessioni o credenziali.

Gli ecosistemi di pacchetti tradizionali faticano già con dipendenze dannose e moduli abbandonati. Un plugin per agenti può avere un ruolo ancora più sensibile perché può osservare prompt, codice sorgente, risultati degli strumenti e stato di esecuzione.

Il log append-only crea un altro compromesso. Una cronologia dettagliata degli eventi supporta replay e audit, ma il contesto del modello archiviato può contenere codice proprietario, documenti interni o input utente sensibili.

Le organizzazioni devono decidere dove risiede quel log, chi può cercarvi, per quanto tempo rimane disponibile e come vengono applicati i requisiti di cancellazione.

Il framework offre lo storage come elemento sostituibile. La preparazione per l'enterprise dipenderà dalla possibilità, nelle implementazioni reali, di configurare conservazione e controlli di accesso senza indebolire le garanzie di replay.

L'attenzione di Google News rischia inoltre di trasformare l'entusiasmo architetturale in affermazioni sulle prestazioni non supportate. DeepSeek non ha dimostrato con questo lancio che Harness renda i suoi modelli più accurati dei concorrenti.

Il rilascio non fornisce un benchmark neutrale che dimostri che la composizione dei plugin migliori il completamento delle attività. Non prova neppure che il recupero di Cordis produca risultati migliori durante lavori di lunga durata.

Un harness capace può rendere un modello più utile fornendo gli strumenti e il contesto giusti. Non può correggere ogni limite del modello sottostante.

Una pianificazione debole resta debole. Una selezione errata degli strumenti può comunque causare un fallimento. Un agente può conservare un log perfetto di un approccio non riuscito.

I report degli utenti pubblicati subito dopo un rilascio possono identificare piste utili, ma non possono sostituire test controllati. I primi adottanti si auto-selezionano, le configurazioni variano e la novità può influenzare il giudizio.

Gli sviluppatori dovrebbero valutare il framework usando repository rappresentativi e attività ripetibili. I test dovrebbero includere operazioni interrotte, permessi negati, strumenti non riusciti, compressione del contesto e aggiornamenti dei plugin.

Dovrebbero inoltre confrontare configurazioni equivalenti di modelli e strumenti. Altrimenti, un risultato favorevole potrebbe riflettere un modello migliore, un insieme di permessi più ampio o un'attività più semplice anziché l'harness.

DeepSeek merita credito per aver etichettato accuratamente il rilascio. L'avvertenza sulla developer preview stabilisce un'aspettativa onesta: il progetto si sta evolvendo rapidamente.

La domanda successiva è se DeepSeek manterrà questa chiarezza con la crescita dell'adozione. Versioning stabile, linee guida per la migrazione, segnalazione di sicurezza e test di compatibilità conteranno più dello slogan di lancio originale.

Cosa osservare dopo l'attenzione di Google News

Tre segnali mostreranno se DeepSeek Harness diventerà un'infrastruttura duratura o resterà un esperimento ammirato.

Il primo segnale è la stabilizzazione dei contratti. Gli sviluppatori dovrebbero seguire le note di rilascio alla ricerca di policy di compatibilità definite per plugin, profili, eventi di sessione e interfacce di capacità.

I cambiamenti incompatibili sono normali durante una preview iniziale. La misura importante è se tali cambiamenti convergano verso superfici stabili documentate.

Gli strumenti di migrazione rafforzerebbero il caso. Periodi di deprecazione chiari e schemi di configurazione verificabili automaticamente ridurrebbero il costo di mantenere profili personalizzati.

Se DeepSeek stabilizza le principali giunzioni senza congelare il progresso architetturale, la sua tesi sul framework diventa più forte. Riscritture ripetute delle integrazioni dei plugin la indebolirebbero.

Il secondo segnale è l'evidenza operativa indipendente. I team hanno bisogno di test riproducibili che coinvolgano repository reali, sessioni lunghe, errori degli strumenti e sandbox limitate.

Il successo nelle attività è solo una metrica. I valutatori dovrebbero misurare anche il comportamento di recupero, il lavoro duplicato, l'accuratezza del contesto, l'applicazione dei permessi e lo sforzo necessario per diagnosticare i fallimenti.

I benchmark dovrebbero separare le capacità del modello dal comportamento dell'harness. Lo stesso modello dovrebbe essere eseguito, ove possibile, in diverse configurazioni dell'harness.

Un test credibile dovrebbe pubblicare anche i propri permessi e gli strumenti disponibili. Un agente con accesso shell illimitato non dovrebbe essere confrontato con leggerezza con uno che opera in una sandbox ristretta.

Se valutazioni indipendenti mostrano un recupero affidabile e un'esecuzione ispezionabile, il meccanismo di DeepSeek guadagna sostegno. Se i risultati dipendono da un'ampia ottimizzazione manuale, il framework resterà più utile agli specialisti.

Il terzo segnale è la qualità dell'ecosistema di plugin. Il numero di repository e l'attenzione sociale misurano la curiosità, non un'offerta affidabile.

I plugin utili necessitano di documentazione mantenuta, copertura dei test, pratiche di sicurezza e informazioni esplicite sulla compatibilità. Un ecosistema affidabile necessita anche di processi per segnalare pacchetti dannosi o abbandonati.

DeepSeek incoraggia gli sviluppatori a contrassegnare i repository dei plugin per facilitarne la scoperta. Il passo successivo è un modo affidabile per valutare quali estensioni meritino l'accesso a strumenti, sessioni e credenziali.

Questo segnale determinerà chi adotterà il framework. I team di ricerca possono sottoporre ad audit autonomamente i moduli sperimentali. La maggior parte dei team enterprise necessita di un insieme più ristretto di componenti supportati e verificabili.

Le reazioni dei concorrenti meritano attenzione nell'ambito di questi tre segnali. Un rivale non deve copiare Cordis per convalidare la direzione di DeepSeek.

Sandbox più sostituibili, cronologie di eventi esportabili, cicli degli agenti documentati o SDK di orchestrazione di livello inferiore indicherebbero tutti che gli sviluppatori richiedono controllo al di sotto dell'interfaccia.

Il silenzio non significherebbe automaticamente fallimento. I prodotti affermati possono continuare a vincere grazie a usabilità, supporto e prestazioni integrate dei modelli.

L'esito più forte per DeepSeek sarebbe un mercato diviso. Gli agenti finiti servirebbero gli utenti che desiderano uno strumento coerente, mentre Harness servirebbe i team che costruiscono agenti specializzati da componenti intercambiabili.

Questa divisione rispecchia una storia più ampia del software. Framework e applicazioni finite spesso coesistono perché risolvono diversi problemi di proprietà.

I knowledge worker potrebbero non utilizzare direttamente DeepSeek Harness, ma la sua architettura li riguarda comunque. I sistemi di agenti interagiscono sempre più con file di progetto, ricerca interna, messaggi e conoscenza organizzativa.

Quando tali sistemi falliscono, gli utenti devono sapere quale contesto ha ricevuto il modello e quali strumenti hanno agito. Una cronologia degli eventi ricostruibile può rendere quell'indagine più concreta.

I team che sviluppano workflow AI correlati dovrebbero applicare la stessa disciplina alle proprie fonti informative. Una AI knowledge base mantenuta può preservare i documenti e le decisioni che circondano l'output di un agente.

Questa pratica non risolve la sicurezza in fase di esecuzione. Aiuta le persone a distinguere le conclusioni generate dalle prove e dal contesto istituzionale utilizzati per raggiungerle.

Il giudizio finale dovrebbe rimanere circoscritto. DeepSeek ha rilasciato una proposta architetturale seria con codice funzionante, documentazione dettagliata e una definizione insolitamente ampia di plugin.

Non ha ancora dimostrato che gli sviluppatori comuni possano gestire tale flessibilità in sicurezza. Non ha dimostrato che i componenti di terze parti rimarranno compatibili, né che il design produca risultati migliori nelle attività.

Il titolo di Google News coglie l'idea memorabile, ma i prossimi tre mesi dovrebbero essere giudicati attraverso contratti stabili, test operativi indipendenti e plugin affidabili.

Se stai valutando DeepSeek Harness, inizia con un flusso di lavoro circoscritto. Registra il modello, gli strumenti, le autorizzazioni, il profilo e il risultato previsto. Poi interrompi l’esecuzione, nega uno strumento, sostituisci un provider e verifica se il registro degli eventi continua a spiegare l’esito. Questo esercizio mette alla prova la tesi concreta di DeepSeek in modo più efficace di una checklist di funzionalità. La domanda non è se tutto possa essere un plugin. La domanda è se i team possano sostituire quei plugin senza perdere affidabilità, sicurezza o la capacità di comprendere cosa abbia fatto il loro agente.