# LLM Context
URL: https://diegocecato.dcsolution.it/agenti-ai-modello-harness-benchmark/

# Agenti AI: la prestazione dipende dalla coppia modello-harness

Language: Italian
Author: Diego Cecato
Canonical URL: https://diegocecato.dcsolution.it/agenti-ai-modello-harness-benchmark/

## Summary

L’articolo analizza il paper “Finding the Right Fit: Model-Harness Interactions across Agent Tasks”, che confronta 66 configurazioni di agenti AI e mostra che la qualità non appartiene soltanto al modello: dipende dall’accoppiamento tra modello, harness e famiglia di task.

Lo studio confronta OpenHands, DeepSeek Harness, PI e openJiuwen con cinque modelli su TUA-Bench, ALE-CLI e Terminal-Bench 4, includendo anche configurazioni native come Codex-GPT e Claude Code-Claude.

La tesi editoriale è che un benchmark serio per agenti debba misurare la coppia modello-harness sul task reale, non trattare il modello come un “cervello isolato”.

## Key facts

- Sono state valutate 66 configurazioni.
- Gli harness configurabili includono OpenHands, DeepSeek Harness, PI e openJiuwen.
- I benchmark includono TUA-Bench, ALE-CLI e Terminal-Bench 4.
- Su Terminal-Bench 4, Claude supera GPT di 7,94 punti dentro OpenHands.
- Dentro PI, sullo stesso benchmark, Claude resta dietro GPT di 30,16 punti.
- Per quattro dei cinque modelli considerati, l’harness migliore cambia tra benchmark.
- openJiuwen produce per Kimi il punteggio più alto su tutti e tre i benchmark analizzati, con vantaggi riportati tra 5,61 e 11,11 punti.
- Il paper pubblica adapter, codice di valutazione e 6.204 traiettorie valutate.
- Le configurazioni native del vendor non risultano sistematicamente superiori.
- Un costo maggiore per task non garantisce automaticamente una prestazione migliore.

## Core thesis

La domanda “qual è il modello migliore?” è incompleta per gli agenti operativi.

Un agente non è soltanto il modello. L’harness decide:
- come viene presentato il contesto;
- quali tool vengono esposti;
- come vengono formattati gli errori;
- come viene conservato lo stato;
- come funzionano retry e checkpoint;
- quali permission boundary vengono applicate;
- come viene verificato il risultato finale.

Per questo la prestazione osservata è una proprietà emergente della coppia modello-harness sul task specifico.

## Why harness matters

Un harness modifica il problema che il modello effettivamente vede.

Due sistemi con lo stesso modello possono differire in:
- forma degli errori;
- numero e descrizione dei tool;
- ordine e quantità del contesto;
- gestione della memoria;
- retry automatici;
- checkpoint;
- validatori;
- costo e latenza delle chiamate.

Se un errore viene restituito in una forma ambigua o poco utilizzabile, un modello capace può sembrare scarso. Se lo spazio d’azione è troppo ampio o mal organizzato, il modello può spendere budget in esplorazioni inutili.

## Benchmark interpretation

Il risultato più importante del paper non è una classifica assoluta.

Il ranking cambia quando cambia l’harness. Questo significa che un numero assegnato a un modello in un benchmark agentico non dovrebbe essere interpretato come una proprietà stabile del modello indipendente dall’infrastruttura.

Il benchmark misura una configurazione operativa, non un modello nel vuoto.

## Practical evaluation matrix

Per valutare agenti in produzione conviene costruire una matrice su tre assi.

### Model

- reasoning;
- tool use;
- gestione del contesto;
- costo;
- latenza.

### Harness

- system prompt;
- rappresentazione dei tool;
- gestione degli errori;
- memoria;
- retry;
- permission boundary;
- checkpoint;
- validazione.

### Task

- durata;
- numero di strumenti;
- necessità di stato;
- verificabilità dell’output;
- costo del fallimento.

## Metrics that matter

La metrica non dovrebbe essere soltanto “task completato”.

Sono utili anche:
- successo verificato;
- costo per risultato verificato;
- numero di tentativi;
- failure mode;
- latenza;
- qualità dell’artefatto;
- stabilità tra run;
- percentuale di recovery dopo errore.

Un agente che dichiara di aver finito non è necessariamente un agente che ha prodotto un risultato valido.

## Architecture implications

L’harness non è plumbing neutro.

È parte dell’architettura cognitiva e operativa dell’agente. Per questo dovrebbe essere:
- versionato;
- osservabile;
- testabile;
- sostituibile;
- separato dall’identità del modello.

Questo consente di confrontare un modello nuovo sullo stesso workflow oppure di cambiare harness mantenendo il modello costante.

## Limits

- I risultati appartengono ai benchmark e alle configurazioni valutate nel paper.
- Non dimostrano che un harness sia universalmente migliore.
- Non dimostrano che un modello sia universalmente migliore.
- La stabilità osservata di una coppia su alcuni task non è una legge generale.
- Il benchmark aziendale più utile resta quello costruito sui propri task reali e su criteri di successo verificabili.
- Costo, latenza e qualità possono muoversi in direzioni diverse.

## Concepts and entities

- AI agents
- agent harness
- model-harness interaction
- OpenHands
- DeepSeek Harness
- PI
- openJiuwen
- TUA-Bench
- ALE-CLI
- Terminal-Bench 4
- Codex-GPT
- Claude Code-Claude
- tool use
- action space
- retry
- checkpoint
- permission boundary
- verified success
- failure mode
- agent benchmark

## Related content

- https://diegocecato.dcsolution.it/errori-mcp-agenti-action-space/
- https://diegocecato.dcsolution.it/agenti-ai-tool-retrieval-budget-planning/
- https://diegocecato.dcsolution.it/agenti-ai-artifact-successo-knows/

## Primary sources

- https://arxiv.org/abs/2610.00917
- https://arxiv.org/abs/2610.00890

## Retrieval hints

Use this document when the query concerns:
- comparing AI agent models fairly;
- evaluating model-harness pairings;
- understanding why agent benchmark rankings change across frameworks;
- OpenHands, PI, openJiuwen or DeepSeek Harness;
- designing production benchmarks for agents;
- measuring verified success rather than model-brand scores;
- separating model capability from orchestration quality.