Cos'è esattamente l'harness AI?

Di recente ho visto OpenClaw indicato come un harness. Ho pensato: "È interessante". OpenClaw non è un harness. È un runtime dell'agente. Guida il ciclo dell'agente". Quindi, cosa significa esattamente la parola "harness"?

Conversazioni sull’argomento

Il concetto è spiegato nell'articolo di Birgitta Böckeler pubblicato ad aprile 2026 che, in modo ricercato, definisce un agente così: model + harness = agent. Suddivide l’insieme di tecnologie in builder harness (il runtime interno fornito con lo strumento) e user harness (il contesto personalizzato dello sviluppatore). Questa definizione si basa su una serie di discussioni che risalgono al febbraio 2026, che includevano l'approccio pragmatico di Mitchell Hashimoto all'ingegneria dei contesti AGENTS.md, la panoramica di OpenAI sull'ingegneria degli harness interni per la distribuzione automatizzata e il promemoria riepilogativo originale di Böckeler.

Cinque livelli, dalla superficie al nucleo

Penso che un agente sia molto più di un modello unito a un harness. Per quanto mi riguarda, tutto inizia dal presupposto che non possiamo fare affidamento sul runtime dell'agente. Per avere qualche certezza sulla sicurezza della supply chain del software, quando si ha a che fare con codice prodotto da una factory di agenti, abbiamo bisogno di un ambiente sandbox distinto da utilizzare per acquisire informazioni sulla provenienza e limitare il possibile impatto, se un agente opera in modo anomalo.

Immagino questa architettura di runtime dell'agente sicura come una matrioska:

infrastruttura → sandbox → agent harness → runtime → modello

Ogni livello ha un proprietario, una modalità di errore e un principio di progettazione diversi. Esaminiamoli.

Livello 1: infrastruttura

L'infrastruttura è l'ambiente in cui gli agenti vengono eseguiti fisicamente. Può trattarsi di GitHub Action Runner, pod Kubernetes o macchine virtuali (VM). Questo livello riguarda l'elaborazione, la rete e la gestione delle risorse ed è più importante di quanto si pensi.

Considera quello che succede quando passi da un singolo agente a decine di agenti in esecuzione simultaneamente. Roy Belio ha messo in funzione il sistema di ricerca automatica di Andrej Karpathy con 198 esperimenti autonomi su OpenShift AI, includendo la pianificazione delle GPU e l'orchestrazione dei job senza alcun intervento umano. Non è un problema di harness. Non è un problema di sandbox. È un problema di infrastruttura. La tua piattaforma è in grado di gestire richieste che si contendono le risorse, evitare che gli agenti simultanei si ostacolino a vicenda e pianificare i carichi di lavoro delle GPU?

La pianificazione delle GPU stessa sta diventando una disciplina infrastrutturale di prim'ordine. Red Hat OpenShift 4,21 ha introdotto l'allocazione dinamica delle risorse, un'API Kubernetes che consente ai carichi di lavoro di richiedere le GPU in base agli attributi (modello, memoria, capacità di elaborazione) anziché al numero effettivo. Consente inoltre la condivisione delle GPU tra i container, in modo che i sidecar di inferenza leggeri non sprechino un intero dispositivo. Si tratta di pura infrastruttura: nessuna policy della sandbox, nessuna voce AGENTS.md, nessuna scelta del modello. È solo la piattaforma che fa il suo lavoro.

Livello 2: sandbox

La sandbox limita le attività dell'agente e il potenziale impatto in caso di problemi. Applica l’isolamento. Come ha detto la mia collega, Marta Anon Ruiz: è come "dare forma all'intenzionalità dell'agente". Progetti come OpenShell di NVIDIA operano su questo livello. Dal punto di vista della sicurezza della catena di distribuzione del software, questo è il principale limite di attendibilità: la differenza tra un agente in che può eseguire rm -rf / e uno che non può farlo, o tra un agente che può usare gh issue delete per eliminare tutte le tue segnalazioni GitHub e uno che non può (o uno in grado di scrivere ed eseguire un proprio script per ottenere lo stesso risultato).

Se l'infrastruttura chiede "Dove viene eseguito l'agente?", la sandbox chiede "A cosa ha accesso l'agente?". Si tratta di domande diverse con risposte diverse.

Red Hat ha pubblicato una guida dettagliata sulla creazione di guardrail resilienti per gli agenti di IA su Kubernetes, che include restricted-v2 SCC (security context constraints), NetworkPolicy di uscita default-deny e il controllo degli accessi basato sui ruoli (RBAC) per ogni agente. Ciascuno di questi è un controllo sottrattivo: partendo da tutto ciò che l'agente è in grado di fare, si rimuovono le funzionalità fino a quando rimangono solo quelle necessarie.

Il livello della sandbox va oltre le policy di rete. I container della sandbox di Red Hat OpenShift, basati su Kata Containers e peer-pod, costituiscono una tecnologia fondamentale a questo livello, perché isolano ulteriormente il processo di un agente dal relativo host. Inoltre, consulta l'articolo a proposito di competenze degli agenti e minacce alla sicurezza, che esamina minacce e soluzioni, e parla della firma crittografica delle competenze degli agenti per verificarne la provenienza prima dell'esecuzione. Una competenza non firmata inserita nella toolchain di un agente rappresenta un attacco alla supply chain del software. Il livello della sandbox può aiutare a gestire questa eventualità.

Progetti come OpenShell di NVIDIA sono importanti in questo livello, così come le primitive di sicurezza integrate nei runtime dei container generici. Nessuno di questi è un "harness" nel senso inteso da Hashimoto: non insegni all'agente a lavorare meglio, ma gli impedisci di svolgere attività pericolose o impreviste.

Livello 3: agent harness

Questo è il livello di cui ha scritto Hashimoto, ed è quello che Birgitta Böckeler chiama user harness. È il livello di abilitazione, che include file AGENTS.md, competenze, strumenti personalizzati, linter realizzati manualmente, prompt di sistema e una valida suite per effettuare test. Questi sono gli elementi che progetti in modo iterativo per aumentare le possibilità che l'agente operi correttamente.

L'articolo di Marco Rizzi sulla progettazione dell'harness con workflow strutturati chiarisce il principio "structure in, structure out". L'articolo descrive l’analisi della struttura del progetto svolta con LSP e MCP per generare prompt sensibili al contesto, non solo indicando all'agente cosa fare, ma fornendogli le informazioni strutturali necessarie per farlo bene. Questo è il controllo in feedforward, per usare le parole di Birgitta.

L'uso di strumenti è una parte critica dell'harness che abilita quelle che Birgitta Böckeler definisce guide computazionali. L'avvento dell'uso degli strumenti e l’affermato standard MCP hanno reso possibili l’impiego di importanti agenti, offrendo al runtime dell'agente maggiori possibilità di raggiungere i propri obiettivi. L'articolo Creazione di agenti di IA efficaci con MCP approfondisce l'MCP, mostrando come abilitare gli agenti fornendo all'harness un modo per accedere dinamicamente alle risorse aziendali.

Come fai a sapere se il tuo harness funziona? Eseguendo una valutazione. Michael Dawson scrive dello sviluppo basato sulla valutazione, delineando un framework di valutazione in otto fasi che utilizza i pattern DeepEval e LLM-as-judge. Le valutazioni sono il ciclo di feedback che indica se le modifiche all'harness hanno migliorato o peggiorato l'agente. Senza di esse, la progettazione dell'harness si basa su congetture. Strumenti come evaluation hub aiutano a gestire questo processo su larga scala.

Gli artefatti dell'harness presentano un problema di gestione. Con la crescita di AGENTS.md, il moltiplicarsi degli strumenti personalizzati e l'evoluzione dei prompt di sistema, come puoi gestirne le versioni? Come puoi condividerli tra i vari progetti? L'articolo su Lola, un gestore di pacchetti di contesto IA, tratta il contesto IA come pacchetti con versione. Questo inquadramento ha senso. Se gli artefatti dell'harness sono artefatti ingegneristici, gestiscili come tali.

Livello 4: runtime dell'agente

Il runtime dell'agente è il motore che guida il relativo ciclo. Claude Code, OpenCode, Goose o una soluzione personalizzata. Gestisce l'invio degli strumenti, le finestre di contesto e la gestione delle conversazioni.

Questo è ciò che Anthropic ha definito "harness" in un'email. Credo che sia errato o, perlomeno, impreciso. Il runtime non è qualcosa che puoi progettare e migliorare, a meno che tu non ne crei uno tuo. Esegue il ciclo: invio del prompt, ricezione della risposta, invio delle chiamate agli strumenti e restituzione dei risultati. Non posso sottovalutare l'importanza di questo livello. I runtime migliorano costantemente e tutti ne traiamo vantaggio.

Tuttavia, alcune organizzazioni ne svilupperanno di propri. Se hai requisiti di sovranità, necessiti di funzionalità non offerte dai runtime standard o se il tuo scenario di utilizzo richiede un controllo elevato sul comportamento del runtime, devi crearne uno tuo e hai bisogno di API su cui basarti. È qui che risultano importanti i progetti come Llama Stack, che espone API disponibili per le risposte, la gestione dei file, la ricerca e, in futuro, la memoria. Un runtime sovrano basato su API aperte è una proposta diversa rispetto a un servizio vincolato a una soluzione proprietaria. Le piattaforme Red Hat supportano entrambi i percorsi: vi sono team che adottano un runtime esistente e progettano lo user harness intorno ad esso, e team che creano il proprio runtime con API aperte perché il contesto lo richiede.

Livello 5: modello ed endpoint di inferenza

Per quanto riguarda la distribuzione, la guida di Red Hat all'integrazione di Claude Code con Red Hat AI Inference Server su OpenShift utilizza vLLM su Red Hat AI per l'inferenza on premise. Il modello, il cluster e i dati sono tuoi. L'esecuzione dell'inferenza sul proprio hardware ha un forte impatto sul modello di attendibilità dell'intero stack di agenti.

Per quanto riguarda la provenienza, il lavoro di Red Hat sulla sicurezza della moderna supply chain del software, in particolare Red Hat Trusted Artifact Signer e la firma crittografica dei modelli, è fondamentale in questo contesto. Se non puoi verificare e gestire la provenienza del modello in esecuzione, l'intero stack su cui si basa, poggerà su fondamenta non verificate. La firma del modello rappresenta per il relativo livello ciò che la firma delle competenze rappresenta per il livello dell'harness: una garanzia crittografica dell'esecuzione di ciò che si intende eseguire.

Controllo sottrattivo e controllo additivo

La sandbox e l'harness hanno logiche di progettazione opposte. La sandbox è sottrattiva: rimuove funzionalità per ridurre i rischi. L'harness è additivo: aggiunge livelli di conoscenza e strumenti per aumentare le competenze. Se li confondiamo, rischiamo di compromettere i principi di progettazione che dovrebbero guidarli.

Presentano inoltre diverse modalità di errore. Un errore della sandbox indica che l'agente ha eseguito un'operazione che non avrebbe dovuto essere in grado di compiere. Un errore dell'harness indica che l'agente ha eseguito in modo insoddisfacente un'attività che avrebbe dovuto svolgere bene. Si tratta di problemi diversi che richiedono risposte diverse.

La sandbox può svolgere un ruolo secondario come “registratore”, un osservatore neutrale delle attività dell'agente, in grado di attestare l'operato in modo più affidabile rispetto all'autocertificazione del runtime dell'agente.

La sandbox vincola e osserva. L'harness abilita ed è possibile migliorarlo. Il runtime esegue e non dovresti crearne uno tuo, a meno che non sia strettamente necessario. Gli agenti sono sicuri e affidabili solo se lo stack alla base è sicuro e affidabile; Red Hat sta creando questo stack: open source, a ogni livello, dalla pianificazione delle GPU alla firma dei modelli crittografici. Se distribuisci agenti in produzione e desideri una base concretamente verificabile, questa è la direzione che stiamo seguendo.