HarnessDev: Gli LLM possono creare e far evolvere il proprio agent harness?
Il Problema: l'infrastruttura conta più del modello
Quando un agente LLM passa da prototipo a tool produttivo, la sua capacità non dipende solo dai pesi del modello, ma dall'infrastruttura di esecuzione circostante, l'agent harness. Questo include il ciclo di esecuzione, la gestione degli strumenti, il contesto, il recupero dagli errori e la verifica dei risultati.
Il dato sorprendente: con gli identici pesi, GPT-5 risolve il 35.2% dei task su Terminal-Bench 2.1 con Terminus 2, ma il 49.6% con Codex CLI. Lo stesso modello, harness diverso, performance completamente diverse. Questo rende l'harness un fattore critico e poco studiato.
Cosa propone HarnessDev
Il paper introduce HarnessDev, uno spostamento dell'unità di valutazione dai task all'infrastruttura eseguibile. Il benchmark copre due fasi:
1. Creation (Creazione)
Un LLM creator parte da un seed debole — un layer di compatibilità minimo che parse i task, espone tool passivi e scrive output, ma non esegue alcun task. Il modello deve costruire da zero un harness completo: ciclo di esecuzione, gestione degli strumenti, stato persistente, verifica.
Il seed non ha loop di esecuzione, nessuna politica sugli strumenti, nessuna gestione del contesto, nessun verificatore, nessuna logica di recupero. Il punteggio zero è il punto di partenza obbligato.
2. Evolution (Evoluzione)
Il creator prende l'harness che ha costruito nella fase Creation e lo migliora iterativamente usando il feedback dall'esecuzione su task downstream. Riceve risultati da un set di feedback (100 task SWE-Pro + 89 Terminal-Bench) e può fare fino a 10 round di miglioramento.
Benchmark e dominio
| Dominio | Benchmark | Task | Metrica |
|---|---|---|---|
| Codice | SWE-bench Pro | 731 | Task success |
| Codice | Terminal-Bench 2.1 | 89 | Task success |
| Data Analysis | MLE-bench | 75 | Medal score |
| Scrittura | EQ-Bench3 | 46 | Rubric score |
| Ricerca | BrowseComp | 1.266 | Accuracy |
Totale: 2.207 istanze uniche downstream.
Risultati principali della Creation
Performance per modello (Self-Eval, avg@3)
| Creator | SWE-Pro | Terminal-2.1 | MLE-bench | EQ-Bench3 | BrowseComp | Media |
|---|---|---|---|---|---|---|
| Opus 4.8 | 69.3 | 64.8 | 32.9 | 84.6 | 52.4 | 67.8 |
| GPT-5.5 | 32.8 | 52.1 | 19.1 | 83.0 | 52.6 | 55.1 |
| Gemini 3.1 Pro | 43.6 | 68.8 | 32.4 | 74.8 | 35.2 | 55.6 |
| DeepSeek V4 Pro | 28.9 | 35.6 | 19.6 | 75.4 | 40.9 | 45.2 |
| Qwen 3.7 Max | 33.5 | 41.3 | 3.1 | 68.7 | 32.3 | 44.0 |
| Seed 2.0 Pro | 10.8 | 6.0 | 5.3 | 71.1 | 3.2 | 22.8 |
| Riferimento humano | 80.0 | 88.8 | 24.0 | 83.7 | 92.2 | 86.2 |
Cosa funziona e cosa no
- Scrittura: gli harness generati si avvicinano al riferimento umano (Opus 84.6 vs riferimento 83.7). Il problema della scrittura è essenzialmente risolto dall'LLM.
- Machine Learning: Opus e Gemini superano il riferimento su MLE-bench (32.9 e 32.4 vs 24.0). I modelli sono capaci di costruire harness per ML experimentation meglio di quelli umani di riferimento.
- Codice: il divario resta significativo. Il miglior risultato (Opus 69.3) è ancora lontano dal riferimento umano (80.0). Serve coordinare editing multiplo, verifica e recupero su molti turni.
- Ricerca/Search: il divario è più ampio. BrowseComp richiede information seeking di lungo orizzonte, dove i modelli faticano.
Costi di esecuzione
Il consumo di token varia enormemente: su MLE-bench la differenza è di 19 volte tra gli harness più efficienti e quelli più costosi. Ma costo più alto non garantisce risultati migliori — la qualità deve essere valutata su entrambi gli assi (capacità + efficienza).
Strategie di implementazione
I sei creator seguono approcci molto diversi:
- Opus riscrive spesso l'intero stack di esecuzione
- GPT-5.5 aggiunge un agente monolitico grande
- DeepSeek, Qwen, Seed estendono il seed con moduli agent/tool/context/state
- Gemini modifica minimamente il runner in posto
Il dato chiave: Gemini aggiunge le meno righe (1.006 LOC) ma ottiene il punteggio migliore su Terminal-Bench (68.8). La quantità di codice non predice la performance.
Portabilità e trasferimento executor
Quando si cambia l'executor (modello che esegue l'harness):
- Qwen e DeepSeek migliorano sotto Gemini — i loro executor originali erano un collo di bottiglia
- Opus peggiora: SWE-Pro crolla da 69.3 a 33.0; il tasso di query duplicate su Search sale dal 10.1% all'88.2%
Un harness può essere usato da un altro modello, ma il trasferimento funziona solo se prompt, protocollo, budget e regole di stopping restano compatibili.
Risultati dell'Evolution
I guadagni si riducono sui task held-out
Tutti i creator migliorano sul set di feedback visibile, ma i guadagni si riducono sui task non visti:
| Creator (Self) | Feedback (H₀→Hdec) | Held-out 630 |
|---|---|---|
| Gemini 3.1 Pro | +8.8 | +2.70 |
| Opus 4.8 | +3.0 | +4.44 |
| Qwen 3.7 Max | +13.9 | +1.43 |
| DeepSeek V4 Pro | +13.4 | +3.17 |
| GPT-5.5 | +5.9 | +3.81 |
Il problema dell'executor fisso
Sotto Gemini fisso (senza cambiare executor), solo Opus migliora sui held-out. Gli altri tre regrediscono:
- Qwen: −1.11
- DeepSeek: −2.38
- GPT-5.5: −10.32
Questo dimostra che i guadagni dipendono fortemente dal modello che esegue l'harness.
Stabilità e selezione della versione finale
Dei 64 switch ufficiali tra versioni:
- 8 regressano su entrambi i benchmark
- 16 su un singolo benchmark
- 27 rientrano nel rumore
- Solo 2 versioni dichiarate sono le migliori sui held-out
La varianza dello stesso commit può arrivare a ±4.75 punti. Più aggiornamenti non significano necessariamente un guadagno finale positivo.
L'insight chiave: l'harness engineering è diverso dal normale coding
Quando un modello modifica un programma standalone, il comportamento target è specificato esternamente e il successo è verificabile localmente. Quando modifica il proprio harness, sta modificando il substrato di esecuzione attraverso cui agisce — la modifica altera come il modello stesso osserva, pianifica e recupera in tutti i task futuri.
Questo richiede che il modello:
- Riconosca le proprie limitazioni comportamentali dai trace di esecuzione
- Diagnostichi colli di bottiglia strutturali nel sistema in cui è inserito
- Apporti modifiche mirate che si accumulino in guadagni di capacità duraturi
Limitazioni
- Quattro domini coprono molti ma non tutti i deployment reali
- I baseline umani non sono garantiti come ottimali
- L'evoluzione ha una sola traiettoria per ogni cella creator-runtime
- Lo sviluppo è fissato su Claude Code per entrambe le fasi
Conclusione
HarnessDev sposta la valutazione degli agenti da "può un modello risolvere task dentro un sistema fisso" a "può creare e mantenere i sistemi che risolvono task futuri". L'harness è un secondo luogo in cui l'intelligenza si accumula: espesso, ispezionabile, testabile, riutilizzabile e continuamente migliorabile.
I risultati mostrano che i modelli attuali possono costruire harness funzionali da un seed debole, con prestazioni che eguagliano o superano i riferimenti umani in scrittura e ML experimentation. Ma il divario resta ampio in codice e ricerca, e l'evoluzione continua è ancora instabile e dipendente dall'executor. L'engineering di harness automatico e robusto resta una sfida aperta.
Paper: arXiv:2609.01437v1 — ByteDance Seed, SUTD, Georgia Tech, M-A-P, TokenWave.AI — Settembre 2026