Ingegneria dell'imbroglio: Lo strato di esecuzione di cui gli agenti di intelligenza artificiale hanno effettivamente bisogno

Mitchell Hashimoto ha costruito la HashiCorp e ha co-creato Terraform. Nel febbraio del 2026 ha pubblicato un post sul blog in cui descriveva un'abitudine che aveva sviluppato lavorando con gli agenti AI: ogni volta che un agente commetteva un errore, lui progettava una correzione permanente nell'ambiente dell'agente. L'ha chiamata "ingegneria dell'imbracatura". Nel giro di poche settimane, OpenAI e Anthropic pubblicarono articoli di ingegneria che espandevano l'idea. Il termine Harness Engineering era arrivato.

Il termine ha risuonato perché nomina un problema che ogni ingegnere che costruisce agenti di IA ha già affrontato. L 'ingegneria tempestiva consente di ottenere risultati migliori in un solo turno. L'ingegneria del contesto gestisce ciò che il modello vede. Ma nessuno dei due si occupa di ciò che accade quando un agente funziona autonomamente per ore, prendendo centinaia di decisioni senza supervisione. È questa la lacuna che Harness Engineering colma, e quasi sempre dipende dalla ricerca ibrida (ricerca ibrida full-text e semantica) per funzionare.

Che cos'è l'Harness Engineering?

L'Harness Engineering è la disciplina che progetta l'ambiente di esecuzione di un agente AI autonomo. Definisce quali strumenti l'agente può chiamare, dove ottiene le informazioni, come convalida le proprie decisioni e quando deve fermarsi.

Per capire perché è importante, consideriamo tre livelli di sviluppo di un agente di intelligenza artificiale:

Livello	Cosa ottimizza	Ambito di applicazione	Esempio
Prompt Engineering	Cosa si dice al modello	Singolo scambio	Pochi esempi, suggerimenti a catena di pensiero
Ingegneria del contesto	Ciò che il modello può vedere	Finestra del contesto	Recupero di documenti, compressione della cronologia
Ingegneria del contesto	Il mondo in cui l'agente opera	Esecuzione autonoma di più ore	Strumenti, logica di validazione, vincoli architettonici

Prompt Engineering Ottimizza la qualità di un singolo scambio - fraseggio, struttura, esempi. Una conversazione, un output.

L'ingegneria del contesto gestisce la quantità di informazioni che il modello può vedere contemporaneamente: quali documenti recuperare, come comprimere la cronologia, cosa inserire nella finestra del contesto e cosa eliminare.

L'Harness Engineering costruisce il mondo in cui l'agente opera. Strumenti, fonti di conoscenza, logica di convalida, vincoli architettonici: tutto ciò che determina se un agente può funzionare in modo affidabile su centinaia di decisioni senza la supervisione umana.

Tre livelli di sviluppo dell'agente AI: Prompt Engineering ottimizza ciò che si dice, Context Engineering gestisce ciò che il modello vede e Harness Engineering progetta l'ambiente di esecuzione .

I primi due livelli determinano la qualità di un singolo turno. Il terzo livello determina se un agente può operare per ore senza che voi lo guardiate.

Non si tratta di approcci in competizione tra loro. Sono una progressione. Man mano che la capacità dell'agente cresce, lo stesso team passa attraverso tutti e tre, spesso nell'ambito di un unico progetto.

Come OpenAI ha utilizzato Harness Engineering per costruire una base di codice di un milione di righe e le lezioni apprese

OpenAI ha condotto un esperimento interno che mette in pratica l'Harness Engineering. Lo hanno descritto nel loro post sul blog dedicato all'ingegneria, "Harness Engineering: Leveraging Codex in an Agent-First World". Un team di tre persone ha iniziato con un repository vuoto alla fine di agosto del 2025. Per cinque mesi non hanno scritto alcun codice: ogni riga è stata generata da Codex, l'agente di codifica con intelligenza artificiale di OpenAI. Il risultato: un milione di linee di codice in produzione e 1.500 richieste di pull unite.

La parte interessante non è il risultato. Sono i quattro problemi che hanno incontrato e le soluzioni harness-layer che hanno costruito.

Problema 1: nessuna comprensione condivisa della base di codice

Quale livello di astrazione deve utilizzare l'agente? Quali sono le convenzioni di denominazione? Dov'è finita la discussione sull'architettura della settimana scorsa? In assenza di risposte, l'agente ha tirato a indovinare - e a sbagliare - ripetutamente.

Il primo istinto è stato un singolo file AGENTS.md contenente ogni convenzione, regola e decisione storica. Il tentativo è fallito per quattro motivi. Il contesto è scarso e un file di istruzioni troppo voluminoso ha messo in secondo piano l'attività vera e propria. Quando tutto viene definito importante, nulla lo è. La documentazione marcisce: le regole della seconda settimana diventano sbagliate all'ottava. E un documento piatto non può essere verificato meccanicamente.

La soluzione: ridurre AGENTS.md a 100 righe. Non regole, ma una mappa. Punta a una directory strutturata docs/ contenente le decisioni di progettazione, i piani di esecuzione, le specifiche di prodotto e i documenti di riferimento. Linters e CI verificano che i collegamenti incrociati rimangano intatti. L'agente naviga esattamente verso ciò di cui ha bisogno.

Il principio di fondo: se qualcosa non è contestualizzato in fase di esecuzione, non esiste per l'agente.

Problema 2: il QA umano non riusciva a tenere il passo con l'output dell'agente

Il team ha inserito il protocollo Chrome DevTools in Codex. L'agente poteva fare screenshot dei percorsi dell'interfaccia utente, osservare gli eventi di runtime e interrogare i log con LogQL e le metriche con PromQL. Hanno fissato una soglia concreta: un servizio doveva avviarsi in meno di 800 millisecondi prima che un'attività fosse considerata completa. I task del Codex venivano eseguiti per oltre sei ore di fila, in genere mentre gli ingegneri dormivano.

Problema 3: Deriva architettonica senza vincoli

Senza barriere di protezione, l'agente riproduceva qualsiasi modello trovasse nel repo, anche quelli sbagliati.

La soluzione: un'architettura rigorosa a strati con un'unica direzione di dipendenza - Types → Config → Repo → Service → Runtime → UI. I linters personalizzati applicano queste regole meccanicamente, con messaggi di errore che includono l'istruzione di correzione in linea.

Architettura rigorosa a strati con validazione unidirezionale delle dipendenze: I tipi alla base, l'interfaccia utente in cima, i linters personalizzati applicano le regole con suggerimenti di correzione in linea .

In un team umano, questo vincolo si presenta di solito quando l'azienda raggiunge centinaia di ingegneri. Per un agente di codifica, è un prerequisito fin dal primo giorno. Quanto più velocemente un agente si muove senza vincoli, tanto peggiore sarà la deriva architettonica.

Problema 4: Debito tecnico silenzioso

La soluzione: codificare i principi fondamentali del progetto nel repository, quindi eseguire attività Codex in background su una tabella di marcia per analizzare le deviazioni e inviare PR di refactoring. La maggior parte di esse è stata fusa automaticamente entro un minuto: piccoli pagamenti continui anziché conteggi periodici.

Perché gli agenti AI non possono valutare il proprio lavoro

L'esperimento di OpenAI ha dimostrato che Harness Engineering funziona. Ma una ricerca separata ha messo in luce una modalità di fallimento al suo interno: gli agenti sono sistematicamente incapaci di valutare i propri risultati.

Il problema si presenta in due forme.

Ansia da contesto. Quando la finestra del contesto si riempie, gli agenti iniziano a terminare i compiti prima del tempo, non perché il lavoro sia finito, ma perché sentono che il limite della finestra si sta avvicinando. Cognition, il team dietro l'agente di codifica AI Devin, ha documentato questo comportamento durante la ricostruzione di Devin per Claude Sonnet 4.5: il modello si è reso conto della propria finestra di contesto e ha iniziato a prendere scorciatoie ben prima di esaurire effettivamente lo spazio.

La loro soluzione è stata la pura ingegneria dell'imbracatura. Hanno abilitato la beta del contesto da 1 milione di token, ma hanno limitato l'utilizzo effettivo a 200.000 token, facendo credere al modello di avere un ampio margine di manovra. L'ansia è svanita. Non è stata necessaria alcuna modifica del modello, ma solo un ambiente più intelligente.

La mitigazione generale più comune è la compattazione: riassumere la storia e lasciare che lo stesso agente continui con un contesto compresso. Questo preserva la continuità, ma non elimina il comportamento sottostante. Un'alternativa è il reset del contesto: cancellare la finestra, avviare una nuova istanza e trasferire lo stato attraverso un artefatto strutturato. In questo modo si elimina completamente l'innesco dell'ansia, ma si richiede un documento di passaggio completo: le lacune nell'artefatto significano lacune nella comprensione del nuovo agente.

Pregiudizio dell'autovalutazione. Quando gli agenti valutano i propri risultati, assegnano loro un punteggio elevato. Anche su compiti con criteri oggettivi di accettazione/rifiuto, l'agente individua un problema, si convince che non è grave e approva un lavoro che dovrebbe fallire.

La soluzione prende spunto dalle GAN (Generative Adversarial Networks): separare completamente il generatore dal valutatore. In una GAN, due reti neurali competono - una genera, l'altra giudica - e questa tensione avversaria costringe a migliorare la qualità. La stessa dinamica si applica ai sistemi multi-agente.

Anthropic ha testato questo aspetto con un sistema a tre agenti - Planner, Generator, Evaluator - contro un agente solitario con il compito di costruire un motore di gioco retrò 2D. L'esperimento è descritto in "Harness Design for Long-Running Application Development" (Anthropic, 2026). Il pianificatore espande una breve richiesta in una specifica di prodotto completa, lasciando deliberatamente i dettagli di implementazione non specificati - la sovraspecificazione precoce si ripercuote in errori a valle. Il Generatore implementa le funzionalità negli sprint, ma prima di scrivere codice firma un contratto di sprint con il Valutatore: una definizione condivisa di "fatto". Il valutatore usa Playwright (il framework open source di Microsoft per l'automazione del browser) per fare clic sull'applicazione come un utente reale, testando l'interfaccia utente, le API e il comportamento del database. Se qualcosa non funziona, lo sprint fallisce.

Il solo agente ha prodotto un gioco che tecnicamente si avviava, ma le connessioni tra entità e runtime erano interrotte a livello di codice, scopribili solo leggendo il sorgente. L'imbracatura a tre agenti ha prodotto un gioco giocabile con generazione di livelli assistita dall'intelligenza artificiale, animazione di sprite ed effetti sonori.

Confronto tra l’agente singolo e l’imbracatura a tre agenti: l’agente singolo ha funzionato per 20 minuti a nove dollari con funzionalità di base non funzionanti, mentre l’imbracatura completa ha funzionato per 6 ore a duecento dollari producendo un gioco completamente funzionale con funzionalità assistite dall’intelligenza artificiale .

L'architettura a tre agenti è costata circa 20 volte di più. Il risultato è passato da inutilizzabile a utilizzabile. Questo è lo scambio fondamentale che fa l'Harness Engineering: spese generali strutturali in cambio di affidabilità.

Il problema del recupero all'interno di ogni sistema di agenti

Entrambi i modelli - il sistema strutturato docs/ e il ciclo di sprint Generatore/Valutatore - condividono una dipendenza silenziosa: l'agente deve trovare le informazioni giuste da una base di conoscenza viva e in evoluzione quando ne ha bisogno.

È più difficile di quanto sembri. Prendiamo un esempio concreto: il Generatore sta eseguendo lo Sprint 3, implementando l'autenticazione degli utenti. Prima di scrivere il codice, ha bisogno di due tipi di informazioni.

In primo luogo, una ricerca semantica: quali sono i principi di progettazione di questo prodotto sulle sessioni utente? Il documento pertinente potrebbe usare "gestione delle sessioni" o "controllo degli accessi", non "autenticazione degli utenti". Senza una comprensione semantica, il reperimento non è in grado di individuare il problema.

In secondo luogo, una query a corrispondenza esatta: quali documenti fanno riferimento alla funzione validateToken? Il nome di una funzione è una stringa arbitraria priva di significato semantico. Il reperimento basato sull'incorporazione non è in grado di trovarlo in modo affidabile. Funziona solo la corrispondenza delle parole chiave.

Queste due interrogazioni avvengono contemporaneamente. Non possono essere separate in fasi sequenziali.

La ricerca vettoriale pura fallisce con le corrispondenze esatte. Il BM25 tradizionale fallisce nelle interrogazioni semantiche e non è in grado di prevedere quale vocabolario utilizzerà un documento. Prima di Milvus 2.5, l'unica opzione era costituita da due sistemi di reperimento paralleli - un indice vettoriale e un indice full-text - in esecuzione simultanea al momento dell'interrogazione con una logica di fusione dei risultati personalizzata. Per un repository docs/ con aggiornamenti continui, entrambi gli indici dovevano rimanere sincronizzati: ogni modifica del documento comportava una reindicizzazione in due punti, con il rischio costante di incoerenza.

Come Milvus 2.6 risolve il recupero degli agenti con un'unica pipeline ibrida

Milvus è un database vettoriale open-source progettato per i carichi di lavoro dell'intelligenza artificiale. La Sparse-BM25 di Milvus 2.6 fa collassare il problema del reperimento a doppia pipeline in un unico sistema.

Al momento dell'ingest, Milvus genera simultaneamente due rappresentazioni: un embedding denso per il recupero semantico e un vettore rado codificato in TF per il punteggio BM25. Le statistiche IDF globali si aggiornano automaticamente man mano che i documenti vengono aggiunti o rimossi, senza dover ricorrere a reindicizzazioni manuali. Al momento dell'interrogazione, un input in linguaggio naturale genera internamente entrambi i tipi di vettore di interrogazione. La Reciprocal Rank Fusion (RRF) fonde i risultati classificati e il chiamante riceve un unico set di risultati unificato.

Prima e dopo: due sistemi separati con sincronizzazione manuale, risultati frammentati e logica di fusione personalizzata rispetto alla pipeline singola di Milvus 2.6 con incorporazione densa, Sparse BM25, fusione RRF e manutenzione automatica dell’IDF che produce risultati unificati .

Un'unica interfaccia. Un solo indice da mantenere.

Nel benchmark BEIR, una suite di valutazione standard che copre 18 set di dati eterogenei, Milvus raggiunge un throughput 3-4 volte superiore a quello di Elasticsearch a parità di richiamo, con un miglioramento del QPS fino a 7 volte su carichi di lavoro specifici. Per lo scenario sprint, una singola query trova sia il principio di progettazione della sessione (percorso semantico) sia ogni documento che menziona validateToken (percorso esatto). Il repository docs/ si aggiorna continuamente; la manutenzione dell'IDF di BM25 significa che un nuovo documento scritto partecipa allo scoring della query successiva senza alcuna ricostruzione in batch.

Questo è il livello di reperimento costruito esattamente per questa classe di problemi. Quando un sistema di agenti ha bisogno di cercare in una base di conoscenza vivente (documentazione del codice, decisioni di progettazione, cronologia degli sprint), la ricerca ibrida a una sola linea non è una cosa semplice da fare. È ciò che fa funzionare il resto del sistema.

I migliori componenti del sistema sono progettati per essere eliminati

Ogni componente di un harness codifica un'ipotesi sui limiti del modello. La scomposizione in sprint era necessaria quando i modelli perdevano coerenza su compiti lunghi. Il reset del contesto era necessario quando i modelli provavano ansia in prossimità del limite della finestra. Gli agenti valutatori si sono resi necessari quando la distorsione dell'autovalutazione era ingestibile.

Queste ipotesi scadono. Il trucco della cognizione del contesto-finestra può diventare superfluo quando i modelli sviluppano una vera e propria resistenza ai contesti lunghi. Man mano che i modelli continueranno a migliorare, altri componenti diventeranno inutili spese generali che rallentano gli agenti senza aggiungere affidabilità.

Harness Engineering non è un'architettura fissa. È un sistema ricalibrato con ogni nuova versione del modello. La prima domanda da porsi dopo un aggiornamento importante non è "cosa posso aggiungere?". È "cosa posso rimuovere?".

La stessa logica si applica al recupero. Man mano che i modelli gestiscono in modo più affidabile contesti più lunghi, le strategie di chunking e i tempi di recupero cambieranno. Le informazioni che oggi necessitano di un'attenta frammentazione, domani potranno essere ingerite come pagine intere. L'infrastruttura di recupero si adatta al modello.

Ogni componente di un sistema ben costruito è in attesa di essere reso superfluo da un modello più intelligente. Non è un problema. È l'obiettivo.

Iniziare con Milvus

Se state costruendo un'infrastruttura di agenti che necessita di un reperimento ibrido - ricerca semantica e per parole chiave in un'unica pipeline - ecco da dove cominciare:

• Leggete le note di rilascio di Milvus 2.6 per tutti i dettagli su Sparse-BM25, la manutenzione automatica dell'IDF e i benchmark delle prestazioni.
• Unitevi alla comunità Milvus per porre domande e condividere ciò che state costruendo.
• Prenotate una sessione gratuita di Milvus Office Hours per analizzare il vostro caso d'uso con un esperto di database vettoriali.
• Se preferite evitare la configurazione dell'infrastruttura, Zilliz Cloud (Milvus completamente gestito) offre un livello gratuito per iniziare con 100 dollari di crediti gratuiti previa registrazione con l'e-mail di lavoro.
• Dateci una stella su GitHub: milvus-io/milvus - 43k+ stelle e in crescita.

Domande frequenti

Che cos'è l'harness engineering e in che modo è diverso dal prompt engineering?

Il prompt engineering ottimizza ciò che si dice a un modello in un singolo scambio - frasi, struttura, esempi. L'Harness Engineering costruisce l'ambiente di esecuzione attorno a un agente AI autonomo: gli strumenti che può richiamare, le conoscenze a cui può accedere, la logica di validazione che verifica il suo lavoro e i vincoli che impediscono la deriva architetturale. L'ingegneria dei prompt dà forma a un turno di conversazione. L'Harness Engineering determina se un agente può operare in modo affidabile per ore su centinaia di decisioni senza la supervisione umana.

Perché gli agenti AI hanno bisogno di ricerca vettoriale e BM25 allo stesso tempo?

Gli agenti devono rispondere contemporaneamente a due richieste di ricerca fondamentalmente diverse. Le query semantiche - quali sono i nostri principi di progettazione delle sessioni utente? - richiedono un'incorporazione vettoriale densa per abbinare contenuti concettualmente correlati, indipendentemente dal vocabolario. Query a corrispondenza esatta - quali documenti fanno riferimento alla funzione validateToken? - richiedono il punteggio delle parole chiave BM25, perché i nomi delle funzioni sono stringhe arbitrarie prive di significato semantico. Un sistema di reperimento che gestisca solo una delle due modalità, non riuscirà sistematicamente a soddisfare le interrogazioni dell'altro tipo.

Come funziona Milvus Sparse-BM25 per il recupero della conoscenza degli agenti?

Al momento dell'ingest, Milvus genera simultaneamente un embedding denso e un vettore sparse codificato in TF per ogni documento. Le statistiche IDF globali si aggiornano in tempo reale al variare della base di conoscenza, senza bisogno di reindicizzazione manuale. Al momento dell'interrogazione, entrambi i tipi di vettore vengono generati internamente, Reciprocal Rank Fusion unisce i risultati classificati e l'agente riceve un unico set di risultati unificato. L'intera pipeline viene eseguita attraverso un'unica interfaccia e un unico indice: un aspetto fondamentale per le basi di conoscenza in continuo aggiornamento, come un repository di documentazione del codice.

Quando devo aggiungere un agente valutatore al mio sistema di agenti?

Aggiungete un valutatore separato quando la qualità dell'output del vostro generatore non può essere verificata solo dai test automatici o quando l'autovalutazione ha causato difetti mancati. Il principio fondamentale è che il valutatore deve essere architettonicamente separato dal generatore: un contesto condiviso reintroduce gli stessi pregiudizi che si sta cercando di eliminare. Il valutatore deve avere accesso agli strumenti di runtime (automazione del browser, chiamate API, query al database) per testare il comportamento, non solo per rivedere il codice. La ricerca di Anthropic ha rilevato che questa separazione ispirata alla GAN ha portato la qualità dell'output da "tecnicamente lanciato ma non funzionante" a "completamente funzionante con funzionalità che l'agente solitario non ha mai tentato".