Cos'è un harness per agenti? Ricerca, progetti open source e pratiche del settore

Due agenti possono usare esattamente lo stesso modello e ottenere punteggi molto diversi sullo stesso benchmark. OpenAI lo ha misurato direttamente: su SWE-bench Lite, GPT-4 ha ottenuto il 2,7% con un harness e il 28,3% con un altro, un divario di 10 volte creato interamente dall'harness. Quando il settore è passato da «quale modello è più intelligente» a «quale agente porta davvero a termine il lavoro», l'harness per agenti è diventato il livello in cui l'affidabilità si conquista o si perde. Continua a leggere per scoprire cos'è un harness per agenti, cosa dicono gli articoli e i benchmark più recenti sulla progettazione degli harness, quali harness open source meritano attenzione e come i principali laboratori di IA progettano i propri, incluso Kimi K3.1 Pro, il modello a pesi aperti che Moonshot AI abbina ai propri harness.

Un harness per agenti è l'infrastruttura circostante che consente a un modello linguistico di grandi dimensioni di operare come agent in un ambiente reale. Mentre il modello produce token, l'harness si occupa di tutto il resto: costruisce il prompt a ogni passaggio, definisce gli strumenti disponibili e il modo in cui vengono chiamati, esegue le azioni in una sandbox o in un terminale, restituisce le osservazioni al modello, applica limiti di passaggi e costi e registra l'intera traiettoria per la valutazione o il debug.

Il termine proviene dal mondo della valutazione: un "test harness" è l'infrastruttura che esegue un sistema in condizioni controllate. Nell'IA agentica, la stessa idea è stata estesa alla produzione: un harness è sia l'infrastruttura usata per misurare un agente (come in SWE-bench o Terminal-Bench) sia quella usata per eseguirlo (come in SWE-agent, OpenHands o Claude Code).

La ricerca di Anthropic su SWE-bench lo esprime chiaramente: il benchmark «non valuta soltanto il modello di IA isolatamente, bensì un intero sistema di “agente”», in cui l'agente è «la combinazione di un modello di IA e dell'infrastruttura software che lo circonda». Il loro Claude 3.5 Sonnet aggiornato ha raggiunto il 49% su SWE-bench Verified non con un framework complesso, ma con un harness minimale composto da un prompt e due strumenti generici (uno strumento Bash e uno strumento Edit).

Per anni, i miglioramenti nelle classifiche sono stati attribuiti alla scala dei modelli. Le ricerche recenti hanno messo in discussione questa ipotesi da due direzioni.

Primo, il risultato «meno è meglio»: nel luglio 2025, il team di SWE-bench ha rilasciato mini-SWE-agent, un harness di circa 100 righe di Python senza strumenti oltre a bash, con una cronologia dei messaggi completamente lineare e ogni azione eseguita come chiamata indipendente a subprocess.run. Ha raggiunto punteggi di benchmark competitivi con framework molto più complessi (trattati nella sezione sulla ricerca qui sotto). La lezione era provocatoria: quando il modello è abbastanza forte, un harness estremamente semplice e prevedibile può superare uno più pesante. È già usato come riferimento da Meta, NVIDIA, IBM, Princeton e Stanford.

Secondo, il risultato «di più è meno»: un harness scadente — output degli strumenti rumorosi, cicli senza limiti, recupero dagli errori inadeguato — può far sembrare mediocre un modello all'avanguardia. OpenAI ha rilevato che ripulire le attività difettose di SWE-bench (descritte nella sezione su OpenAI qui sotto) ha più che raddoppiato le prestazioni misurate del modello.

Ecco perché l'ingegneria degli harness è diventata una disciplina a sé stante. L'harness determina:

• Ciò che il modello vede: struttura del prompt, schemi degli strumenti, quantità dello stato dell'ambiente e della cronologia inclusa nella finestra di contesto.

• Ciò che il modello può fare: quali strumenti sono disponibili (shell, editor di file, browser, ricerca) e come le azioni vengono analizzate e convalidate prima dell'esecuzione.

• Come vengono gestiti i fallimenti: tentativi ripetuti, timeout, compattazione del contesto quando la finestra si riempie e terminazione controllata.

• Come viene misurato il lavoro: registrazione delle traiettorie, valutazione e rendicontazione dei costi, senza le quali non esistono né valutazione né ciclo di miglioramento.

Che si tratti di una configurazione di benchmark per la ricerca o di un assistente di programmazione in produzione, quasi ogni harness per agenti implementa lo stesso ciclo fondamentale:

1. Acquisizione dell'attività: leggere il problema, l'istruzione o l'obiettivo e avviare un ambiente isolato (di solito un container Docker o un'istantanea di VM).

2. Composizione del prompt: combinare il prompt di sistema, le definizioni degli strumenti, la descrizione dell'attività e la cronologia progressiva di azioni e osservazioni.

3. Analisi delle azioni: tradurre l'output del modello in una chiamata concreta a uno strumento — un comando bash, una modifica a un file, una richiesta API — e rifiutare le azioni non valide.

4. Esecuzione e osservazione: eseguire l'azione nell'ambiente, acquisire stdout/stderr o lo stato dell'interfaccia e troncarli per rientrare nel budget di contesto.

5. Flusso di controllo: applicare limiti di passaggi, costi e condizioni di arresto; decidere quando chiedere l'intervento di una persona o terminare l'episodio.

6. Registrazione e valutazione: salvare l'intera traiettoria e valutare lo stato finale — per esempio, eseguendo la suite di test del repository in SWE-bench.

Le scelte progettuali a ogni passaggio si sommano. La sola strategia di troncamento può influire sensibilmente sui punteggi nei compiti a lungo orizzonte; per questo i team più rigorosi trattano l'harness come software versionato e testabile, non come semplice codice di raccordo.

La letteratura accademica sugli harness per agenti è giunta a un ristretto numero di conclusioni maturate con fatica. Anziché elencare ogni benchmark, questa sezione ripercorre le domande di ricerca che hanno costretto il settore a prendere sul serio l'harness.

Prima degli articoli, una breve introduzione. Un benchmark è un insieme fisso di attività con una regola di valutazione, progettato per confrontare sistemi diversi a parità di condizioni. Nella valutazione degli agenti, un benchmark ha tre componenti variabili: un insieme di attività (issue GitHub reali, comandi da terminale, attività web), un ambiente di esecuzione (un container Docker, un browser, un terminale) e un valutatore (una suite di test, un controllo dello stato, una revisione umana). L'harness si colloca tra il modello e tutte e tre: è la variabile che determina se le capacità del modello si riflettono nel punteggio.

Il modo in cui i punteggi vengono effettivamente misurati conta più del numero in evidenza. In SWE-bench, un agente produce una patch di codice; il benchmark esegue quindi due suite di test: FAIL_TO_PASS (test che non funzionavano prima della correzione e che ora devono superare) e PASS_TO_PASS (test che funzionavano prima e non devono smettere di funzionare). L'attività viene considerata risolta solo se entrambe hanno esito positivo. Ecco perché funzioni dell'harness come l'esecuzione dei test e la generazione delle differenze non sono optional: è lì che si conquistano o si perdono punti.

Tre regole per interpretare qualsiasi punteggio di benchmark:

1. Chiediti cosa nasconde il punteggio. Un modello addestrato su dati GitHub pubblici potrebbe aver già visto le stesse issue su cui viene testato: la contaminazione dei dati può gonfiare i punteggi senza alcun reale aumento delle capacità. Ambienti riproducibili e insiemi di attività tenuti separati sono l'antidoto.

2. Attenzione alla legge di Goodhart: quando una misura diventa un obiettivo, smette di essere una buona misura. Un harness ottimizzato per eccellere in un benchmark potrebbe imparare trucchi specifici di quel benchmark anziché capacità generali; per questo i team più rigorosi valutano su più di uno.

3. Controlla l'harness, non solo il modello. Come mostra il resto di questa sezione, lo stesso modello può ottenere il 2,7% o il 28,3% a seconda dell'infrastruttura di supporto. Un punteggio senza un harness dichiarato è un aneddoto, non una misurazione.

L'articolo originale su SWE-bench ("Can Language Models Resolve Real-World GitHub Issues?") ha introdotto la valutazione ormai canonica: fornire a un modello una vera issue GitHub e l'intero repository, quindi verificare se la sua patch fa superare i test che prima fallivano. Il suo risultato più citato viene spesso interpretato male: il miglior modello dell'epoca, Claude 2, ha risolto solo l'1,96% delle attività. Gli autori stessi hanno affermato che il benchmark testava un "ragionamento complesso che va ben oltre la tradizionale generazione di codice" — ma i lavori successivi hanno chiarito che gran parte del divario non dipendeva dalla capacità di ragionamento, bensì dall'assenza di un harness in grado di esplorare un repository, eseguire test e iterare. In altre parole, SWE-bench non si è limitato a misurare i modelli: ha rivelato che mancava l'harness che li circondava.

L'articolo su SWE-agent ("Agent-Computer Interfaces Enable Automated Software Engineering") è il documento fondativo del settore per la progettazione degli harness. La sua tesi centrale è che la progettazione dell'interfaccia è una variabile di primo ordine: gli autori hanno introdotto il termine Agent-Computer Interface (ACI) e mostrato che un'interfaccia progettata appositamente — un editor di file con controlli del linter, feedback conciso della shell e protezioni contro comandi non validi — ha portato pass@1 su SWE-bench da basse percentuali a una cifra al 12,5%, il massimo risultato dell'epoca. Il contributo duraturo dell'articolo è l'argomento secondo cui gli "agenti LM rappresentano una nuova categoria di utenti finali" che necessita di software realizzato per loro, proprio come gli esseri umani hanno bisogno degli IDE. Ogni successivo articolo sugli harness cita questo risultato.

Due articoli del 2024 hanno esteso la ricerca sugli harness dai repository di codice all'intero computer. OSWorld ha creato il primo ambiente scalabile su computer reali per Ubuntu, Windows e macOS, con 369 attività che coprono applicazioni web e desktop. Il suo dato principale — gli esseri umani completano il 72,36% delle attività, il miglior modello il 12,24% — ha individuato nel grounding GUI (tradurre l'output del modello in clic e pressioni dei tasti corretti) la modalità di errore dominante: un problema di harness, non di conoscenza. WebArena ha adottato un'altra prospettiva: un ambiente web self-hosted e completamente riproducibile (e-commerce, forum, GitLab, CMS) in cui GPT-4 ha raggiunto solo il 14,41% di successo end-to-end contro il 78,24% degli esseri umani. Entrambi gli articoli hanno stabilito che la valutazione degli harness deve essere basata sull'esecuzione (verificando lo stato finale dell'ambiente), non basata sulla corrispondenza di pattern negli output del modello.

Il τ-bench di Sierra ("A Benchmark for Tool-Agent-User Interaction in Real-World Domains") ha evidenziato un aspetto più sottile: in produzione, l'harness non si limita a racchiudere il modello e l'ambiente, ma media anche l'utente. Il benchmark simula conversazioni dinamiche tra un utente modello linguistico e un agente dotato di API di dominio e linee guida sulle policy, quindi valuta lo stato finale del database. La sua metrica chiave, pass^k (successo su k prove indipendenti), ha mostrato quanto siano incoerenti gli agenti: GPT-4o ha risolto meno del 50% delle attività in una singola prova e pass^8 è sceso sotto il 25% nel commercio al dettaglio. La lezione per chi sviluppa harness è che l'affidabilità è una proprietà distribuzionale, non una proprietà della singola esecuzione: un harness che funziona una volta non è un harness che funziona davvero.

"Measuring AI Ability to Complete Long Software Tasks" di METR ha introdotto l'orizzonte temporale di completamento delle attività al 50%: la durata di un'attività (misurata in base al tempo di completamento umano) che un modello porta a termine con affidabilità del 50%. Tra il 2019 e il 2025, i modelli di frontiera sono passati da pochi minuti a circa un'ora, raddoppiando approssimativamente ogni sette mesi. Per l'ingegneria degli harness, questa è la scoperta più significativa del decennio: l'harness che limita un modello del 2024 è un peso inutile per un modello del 2026. Secondo Anthropic, ogni componente di un harness incorpora un'ipotesi su ciò che il modello non sa fare — e queste ipotesi diventano obsolete man mano che i modelli migliorano.

Il benchmark originale è diventato un ecosistema che traduce queste lezioni in pratica:

• SWE-bench Verified (con OpenAI, 2024): un sottoinsieme di 500 istanze filtrato da persone, che ha rimosso le attività poco specificate o valutate ingiustamente — il 68,3% del pool originale è stato escluso, più che raddoppiando i punteggi misurati e diventando la classifica di riferimento.

• SWE-smith (2025): una pipeline per generare attività di addestramento sintetiche, affinché i modelli possano essere addestrati per harness agentici, non solo valutati su di essi.

• mini-SWE-agent (2025): l'harness di circa 100 righe che ora supera il 74% su SWE-bench Verified, dimostrando che, una volta che il modello è sufficientemente potente, è sufficiente un ciclo minimo basato solo su bash con cronologia lineare — e diventando il riferimento predefinito della community.

• Terminal-Bench (Stanford × Laude, 2025): valutazione di attività da terminale basata sul framework Harbor, che porta gli harness oltre la modifica del codice verso l'amministrazione di sistema.

• CodeClash (2025) e ProgramBench (2026): creazione di software orientata agli obiettivi e da zero, che estende gli harness dalle correzioni di singole issue allo sviluppo aperto.

Il filo conduttore di tutti questi lavori è coerente: l'harness non è infrastruttura di contorno, è l'oggetto di studio. Riporta l'harness insieme al punteggio, mantieni l'ambiente riproducibile e diffida di qualsiasi risultato il cui harness non possa essere ispezionato.

Gli harness open source sono il punto di partenza per la maggior parte dei team. I progetti seguenti combinano ampie community su GitHub (decine di migliaia di stelle per i principali) con una manutenzione attiva:

Nella scelta tra queste soluzioni, l'euristica della community è: usare l'harness minimo che esprime il proprio compito (la filosofia di mini-SWE-agent) e aggiungere complessità solo quando lo richiede un fallimento misurato. DeepSeek Harness si colloca all'estremo opposto dello spettro: una piattaforma interamente basata su plugin per team che desiderano che ogni livello sia sostituibile. Le due soluzioni condividono però una disciplina comune: un log di sessione durevole, append-only, come unica fonte di verità su ciò che il modello ha visto.

I laboratori di frontiera considerano l'ingegneria degli harness una proprietà intellettuale fondamentale, e molti hanno pubblicato il proprio approccio con un livello di dettaglio insolito.

Anthropic ha pubblicato la documentazione pubblica più completa sull'ingegneria degli harness, e la sua architettura — illustrata in dettaglio in Building Effective Agents (2024), il post sull'harness SWE-bench (2024) e Managed Agents (2026) — può essere letta come tre livelli concentrici.

Il livello di esecuzione è volutamente minimale: uno strumento Bash per eseguire comandi e uno strumento Edit per visualizzare e modificare file. Lo sforzo di progettazione si è concentrato sul rendere questi strumenti a prova di errore — richiedendo percorsi assoluti, troncando gli output lunghi e applicando le modifiche solo in presenza di una corrispondenza di stringa univoca — affinché il modello debba raramente recuperare da errori degli strumenti evitabili.

Il livello di sessione è un log di eventi durevole, append-only, che risiede al di fuori della finestra di contesto del modello. Ogni azione e osservazione viene registrata lì; il contesto del modello è una proiezione di quel log, non il log stesso. Questa separazione consente di riavviare e riprendere un processo harness fallito a metà attività e rende l'harness un "bestiame" sostituibile anziché un animale da compagnia.

Il livello di orchestrazione — quello che Anthropic chiama "meta-harness" — separa il "cervello" (il modello e il suo ciclo) dalle "mani" (sandbox e strumenti) tramite interfacce esplicite. Poiché il cervello non risiede più nel contenitore di esecuzione, le sandbox possono essere predisposte su richiesta e le credenziali possono essere conservate in un vault a cui la sandbox non accede mai. Il vantaggio che riportano è strutturale, non cosmetico: il tempo p50 al primo token è diminuito di circa il 60% e il p95 di oltre il 90%, perché le sessioni non attendono più contenitori che potrebbero non usare mai.

Tre documenti tracciano questa evoluzione: Building Effective Agents (2024), il post sull'harness SWE-bench (2024) e Managed Agents (2026).

OpenAI ha collaborato con il team di SWE-bench per creare la suddivisione Verified convalidata da persone, proprio perché gli harness richiedono attività pulite: la loro campagna di annotazione (93 sviluppatori, 1.699 campioni) ha rilevato che il 68,3% delle attività del benchmark originale presentava problemi e che la loro rimozione ha più che raddoppiato le prestazioni misurate. Lo stesso post osserva che la sola scelta dell'harness ha portato GPT-4 dal 2,7% al 28,3% su SWE-bench Lite — una differenza che citano per sostenere che le valutazioni debbano tenere conto dei progressi negli harness sviluppati dalla community.

Sul versante open source, Codex CLI viene distribuito come harness di riferimento completo. La sua architettura è stratificata in modo analogo agli altri sistemi di questa sezione: un ciclo centrale dell'agent gestisce pianificazione e chiamate agli strumenti; un livello sandbox isola l'esecuzione con policy configurabili per attività; un livello di sessione conserva le conversazioni affinché possano essere riprese, diramate o compattate; e un livello degli strumenti espone sia l'accesso alla shell locale sia strumenti esterni basati su MCP. Anziché codificare rigidamente un'unica interfaccia, lo stesso motore è esposto tramite tre modalità — un'interfaccia utente da terminale per il lavoro interattivo, un app server JSON-RPC per client avanzati come VS Code e un servizio remoto di esecuzione del codice per sandbox cloud — così l'harness può essere eseguito localmente o controllato tramite programmazione. Il design adotta gli stessi compromessi raccomandati dalla letteratura di ricerca: ciclo minimale, sandbox robusta, gestione esplicita del contesto e una chiara separazione tra il modello e il mondo esterno.

Con Agent Development Kit (ADK) e il protocollo Agent2Agent (A2A) — lanciati nell'aprile 2025 con oltre 50 partner tecnologici, tra cui Atlassian, Salesforce, SAP e ServiceNow — Google sta trasformando il livello di harness in un prodotto. A2A standardizza il modo in cui gli agenti dichiarano le proprie capacità (tramite "Agent Cards" JSON), gestiscono attività di lunga durata, scambiano artefatti e negoziano i formati dell'interfaccia utente, affinché gli harness diventino infrastrutture interoperabili anziché integrazioni ad hoc. È progettato esplicitamente per integrarsi con il Model Context Protocol (MCP) di Anthropic, che standardizza il lato strumenti dell'harness.

AutoGen e Magentic-One di Microsoft includono harness in cui un agente orchestratore gestisce un registro di fatti e progressi: un progetto pubblicato per prevenire i cicli illimitati che affliggono gli harness ingenui. GAIA di Meta e Hugging Face ha creato un benchmark per assistenti generici il cui harness valuta domande del mondo reale che richiedono navigazione web e gestione di file; Open Agent Leaderboard di Hugging Face prosegue la spinta verso classifiche comparabili e consapevoli dell'harness.

DeepSeek Harness (dsh) porta l'idea del meta-harness oltre, rendendola componibile. La sua architettura si basa sul framework Cordis e la sua tesi centrale è che ogni componente dell'harness è un plugin sostituibile — inclusi l'adattatore del modello, il registro degli strumenti, il registro della sessione e il ciclo dell'agente stesso.

Il progetto si basa su tre elementi fondamentali. Il primo è un registro di sessione durevole, unica fonte di verità su ciò che il modello ha visto; tutto ciò che raggiunge il modello deve poter essere ricostruito dal registro, come invariante di runtime. Il secondo sono le interfacce di capacità: un'interfaccia provider sostituibile tra l'agente e il mondo esterno, così che indirizzare i provider del filesystem e dei sottoprocessi a una sandbox remota trasferisca con essi l'accesso a Bash, al terminale e al language server, senza creare un fork dell'harness. Il terzo è un esplicito ciclo di vita turno/passaggio, con eventi di estensione denominati (agent/pre-step, tools/execute, agent/turn-stopping) che consentono ai plugin di intercettare o riscrivere il ciclo senza modificare il codice principale.

Il risultato è la più vicina realizzazione open source del meta-harness di Anthropic: un harness la cui struttura non è un framework fisso, ma una composizione di plugin sostituibili tramite configurazione. Con oltre 170.000 stelle su GitHub nei primi mesi, segnala che l'agent harness sta diventando una categoria di prodotto a sé stante.

Il modello condiviso da tutti: mantenere semplice il ciclo, isolare tutto in sandbox, registrare ogni passaggio e non fidarsi mai di un punteggio senza l'harness che lo ha prodotto.

Tutto ciò che abbiamo visto finora in questa sezione — i cicli minimi, i registri di sessione durevoli, l'esecuzione in sandbox, le architetture a plugin — condivide un presupposto: l'ambiente dell'agente è un computer. Un terminale, un browser, un filesystem, un repository. L'harness esiste affinché l'agente possa operare su quella macchina in modo affidabile.

Ma la traiettoria della ricerca delineata sopra punta altrove. τ-bench ha collocato l'utente all'interno dell'harness. METR ha mostrato agenti alle prese con lavori che durano giorni, non minuti. OSWorld e WebArena hanno spostato l'ambiente da un repository pulito al disordine del mondo reale. La direzione è coerente: man mano che gli agenti passano da strumenti di programmazione ad assistenti per il lavoro reale, l'ambiente che devono esplorare non è più soltanto silicio — sono le persone. Utenti con aspettative, team con una storia, organizzazioni con permessi e conoscenza istituzionale.

Questo cambiamento coinvolge soprattutto un sottosistema dell'harness: la gestione del contesto. Una sessione di terminale ha un solo operatore e una cronologia limitata; un impegno di lunga durata ha dieci stakeholder, mesi di decisioni e un repository che continua a crescere. Un filesystem è passivo; una relazione di lavoro è un flusso di impegni impliciti, pensieri lasciati a metà e scelte fatte di sfuggita. Tutto questo deve essere riassunto, compattato o eliminato prima di raggiungere il modello, e ciascuna di queste decisioni è un punto in cui l'agente perde qualcosa di necessario al compito.

Un harness può comprimere, ma non può farlo arbitrariamente. Per questo la dimensione della finestra di contesto ha smesso di essere una specifica del modello ed è diventata un parametro di progettazione dell'harness.

Il portafoglio di harness di Moonshot AI applica a uno stack gestito l'anatomia definita in precedenza in questo articolo. Per il problema Agente × Computer, i suoi harness estendono il ciclo standard: Kimi Browser Extension controlla una sessione browser reale tramite Chrome DevTools Protocol anziché una sandbox sterile, un'interfaccia Chiedi prima di agire impone il consenso a livello di filesystem e un Agent Swarm estende l'orchestrazione a 300 sotto-agenti per attività di lunga durata.

A guidare quel ciclo è Kimi K3.1 Pro — il primo modello della serie K3.1 e il modello open-weight di Moonshot AI della classe 3T più capace finora, con una finestra di contesto di 1.048.576 token. Tre delle sue proprietà riguardano direttamente la progettazione dell'harness:

• Una finestra abbastanza ampia da rimandare la compattazione. Un milione di token contiene contemporaneamente un repository di lavoro, la traiettoria in corso e i documenti di riferimento. L'harness continua a troncare — deve sempre farlo — ma la soglia alla quale la sintesi inizia a distruggere informazioni si sposta abbastanza in là da evitare che le attività di lunga durata si degradino silenziosamente a metà strada.

• Lo sforzo di ragionamento come parametro dell'harness. K3.1 Pro ragiona sempre e reasoning_effort accetta low, high o max, con max come impostazione predefinita. In questo modo il costo di ragionamento del modello diventa un budget per attività definito dall'harness, anziché un costo fisso di accesso.

• Strumenti disponibili a metà episodio. Il caricamento dinamico degli strumenti consente all'harness di inserire una definizione completa dello strumento all'interno di un messaggio di sistema, rendendolo disponibile da quel messaggio in poi — senza riavvio e senza pagare il suo schema a ogni turno di una conversazione che non lo usa mai.

Moonshot riporta l'harness insieme al modello, la disciplina sostenuta dal resto di questo articolo. In Terminal-Bench 4.0 — che valuta gli agenti di programmazione su attività realistiche da terminale con risorse limitate, sottoposte a rigorosi test specifici per attività — K3.1 Pro raggiunge il 65,7%, davanti a GPT-6 Astra (58,2%) e appena dietro Claude Opus 5.5 (66,4%). In Kimi Code Bench 3.0 Long-horizon, un benchmark interno per l'esecuzione in più passaggi, l'uso di strumenti e la risoluzione end-to-end dei problemi, ottiene il 61,2% contro il 55,95% di K3. La documentazione è altrettanto esplicita sul vincolo nella direzione opposta: parametri di campionamento come temperature e top_p sono fissi e devono essere omessi dalle richieste, mentre il messaggio completo dell'assistente deve essere restituito invariato tra un turno e l'altro — un harness che riscrive il messaggio perde il ragionamento da cui dipende la successiva chiamata allo strumento.

Lo stesso modello gestisce l'intera superficie. Puoi provare la versione web gestita tramite Kimi Agent, eseguire l'harness locale completo con Kimi Work, lavorare nel terminale con Kimi Code o chiamare direttamente kimi-k3.1-pro tramite la Kimi API. Una variante kimi-k3.1-pro-highspeed scambia un prezzo per token approssimativamente doppio con una velocità di output da due a tre volte superiore.

Che tu stia valutando modelli o lanciando un prodotto, vale la stessa checklist:

1. Parti dall'attività, non dal framework. Se i tuoi agenti modificano codice, un harness Bash più editor come l'ACI di SWE-agent è collaudato. Se controllano GUI o il web in tempo reale, servono osservazioni di sessioni reali e azioni a livello di clic.

2. Rendi gli ambienti riproducibili. Immagini Docker, dipendenze bloccate a versioni specifiche e dati inizializzati con seed sono ciò che distingue un benchmark da un aneddoto.

3. Pianifica deliberatamente il budget della finestra di contesto. Il troncamento delle osservazioni, la sintesi della cronologia e la compattazione sono funzionalità dell'harness che incidono direttamente su punteggi e costi — e spiegano perché i modelli a contesto lungo riducono quanto l'harness deve scartare.

4. Imponi limiti rigidi. Limiti al numero di passaggi, timeout di tempo reale e budget in dollari per episodio mantengono gli agenti sicuri e le valutazioni comparabili.

5. Registra le traiettorie complete fin dal primo giorno. Ogni serio ciclo di miglioramento — revisione umana, raggruppamento dei fallimenti, fine-tuning — utilizza dati sulle traiettorie. Managed Agents di Anthropic e DeepSeek Harness vanno entrambi oltre: mantengono il registro di sessione esterno al ciclo dell'harness come flusso di eventi in sola append, così l'harness stesso è sostituibile e il contesto del modello è sempre ricostruibile.

6. Valuta su più di un harness. Se il tuo agente funziona solo all'interno di un harness, hai creato un comportamento specifico per quell'harness, non una capacità.

7. Tieni le credenziali fuori dalla sandbox — o interamente fuori dal cloud. Considera non affidabile l'ambiente di esecuzione dell'agente; conserva i token in un vault e inseriscili tramite un proxy, oppure esegui l'intera sessione in locale affinché credenziali e contenuti delle pagine non lascino mai il dispositivo — l'approccio adottato da Kimi con i suoi harness locali.

L'agent harness è diventato silenziosamente il livello più importante dello stack agentico. Le ricerche di SWE-bench, mini-SWE-agent, Terminal-Bench e METR mostrano che la progettazione dell'harness può rivaleggiare con gli aggiornamenti dei modelli per impatto; progetti open source come DeepSeek Harness, OpenHands, SWE-agent e Aider rendono gli harness di livello produttivo accessibili a tutti; e Anthropic, OpenAI, Google, Microsoft e Moonshot AI considerano ormai l'ingegneria degli harness un'attività di primo piano.

Ma il cambiamento più profondo è concettuale. La prima generazione di harness ha risolto il problema Agente × Computer: dare a un modello mani affidabili per un terminale, un browser, un filesystem. La generazione successiva sta risolvendo il problema di contesto creato da quegli ambienti — lavoro che attraversa giorni, stakeholder e repository, che nessun riassuntore può comprimere senza perdite. L'harness si sta evolvendo da impalcatura ad ambiente operativo, e il confine tra ciò che l'harness deve gestire e ciò che il modello può semplicemente mantenere continua a spostarsi. La finestra di un milione di token di Kimi K3.1 Pro è l'esempio attuale più chiaro: un cambiamento nel modello che elimina lavoro che l'harness doveva svolgere.

Che tu ne realizzi uno tuo, adotti un framework open source o gestisca un harness in produzione, i team che trattano l'harness come software progettato, versionato e misurabile sono quelli i cui agenti portano davvero a termine il lavoro.