Sintesi Tecnica: HarnessBridge

Definizione del Problema

I Large Language Models (LLM) vengono sempre più impiegati come agenti per compiti complessi a lungo orizzonte (ad esempio, ingegneria del software autonoma, navigazione web). Mentre i progressi si sono concentrati su modelli generatori più forti e ambienti più ricchi, un terzo asse critico — l'harness (impalcatura) che media l'interazione agente-ambiente — rimane un collo di bottiglia.

Gli harness esistenti sono largamente scaffold progettati manualmente che formattano le osservazioni, gestiscono il contesto e validano le azioni. Man mano che gli orizzonti di interazione crescono, questi sistemi statici affrontano due limitazioni primarie:

1. Dall'Ambiente all'Agente (Osservazione): Le traiettorie accumulano contesto ridondante, errori obsoleti e dettagli a basso valore, oscurando stati decisionali critici e gonfiando i costi dei token.
2. Dall'Agente all'Ambiente (Azione): I modelli possono ripetere azioni inefficaci, perseguire ipotesi invalidate o emettere comandi malformati, consumando preziosi step ambientali senza far avanzare il compito.

Gli approcci automatizzati attuali (ad esempio, Meta-Harness) tipicamente ottimizzano gli scaffold esterni o i prompt, ma non apprendono la policy di interazione a runtime che determina dinamicamente quali informazioni fluiscono verso il generatore e quali azioni vengono impegnate nell'ambiente. Gli autori si chiedono: È possibile formulare l'harness come un problema di generazione end-to-end apprendibile?

Metodologia: HarnessBridge

Gli autori propongono HarnessBridge, un controller dell'harness leggero e apprendibile che parametrizza l'interfaccia agente-ambiente come una policy di proiezione bidirezionale ($\pi_h$). La policy del generatore ($\pi_g$) rimane congelata; l'ottimizzazione avviene esclusivamente sull'harness.

1. Proiezioni Bidirezionali

HarnessBridge apprende due proiezioni distinte:

• Proiezione dell'Osservazione ($P_{obs}$): Mappa la cronologia dell'interazione grezza ($H_t$) verso uno stato visibile al generatore ($\tilde{H}_t$).

  • Meccanismo: Elabora ogni unità di cronologia $h_i$ e assegna una decisione $z_i \in \{Pass, Compress, Drop\}$.
    • Pass: Mantieni l'unità invariata.
    • Compress: Condensa l'unità preservandone il significato (ad esempio, riassumendo log verbali).
    • Drop: Rimuovi contenuti irrilevanti, obsoleti o superati.
  • Indice dello Stato Attivo: Una componente appresa ($U_t$) posizionata prima della cronologia che traccia esplicitamente errori non risolti, vincoli aperti, fatti stabiliti e obiettivi pendenti, garantendo che lo stato critico sia visibile senza doverlo ricostruire da una lunga traiettoria.

• Proiezione dell'Azione ($P_{act}$): Mappa una proposta di azione del generatore ($a_t$) verso un'azione rivolta all'ambiente ($a'_t$).

  • Meccanismo: Predice una decisione $d_t \in \{Pass, Reject\}$.
    • Pass: Esegue l'azione ($a'_t = a_t$).
    • Reject: Blocca l'azione ($a'_t = \emptyset$) e restituisce un feedback basato sulla traiettoria ($\rho_t$) al generatore.
  • Struttura del Feedback: I rifiuti devono includere una preoccupazione (perché l'azione è improduttiva), un'evidenza (evidence, citando parti specifiche della cronologia che supportano il rifiuto) e un suggerimento (come migliorare). Ciò evita loop improduttivi preservando al contempo un'esplorazione informativa.

2. Unified Instruction Tuning

Invezione di addestrare moduli separati, HarnessBridge unifica entrambe le proiezioni in un singolo problema di generazione condizionale utilizzando una policy condivisa ($P_\theta$).

• Dati di Addestramento: Costruiti da traiettorie risolte (ad esempio, SWE-bench Verified).
• Supervisione: Il modello è addestrato tramite instruction tuning per generare la proiezione appropriata (stato compresso o decisione pass/reject con feedback) basandosi sulla specifica del compito e sulla cronologia corrente.
• Curatela dei Dati: La supervisione di alta qualità è filtrata tramite un LLM judge per garantire che:
  • Le proiezioni dell'osservazione preservino le evidenze decisionali critiche e la coerenza dello schema.
  • Le proiezioni dell'azione siano basate sulla traiettoria (i rifiuti devono citare la cronologia specifica) e portino a guadagni di efficienza.
• Modello: Un LLM leggero (Qwen3.5-0.8B) viene sottoposto a fine-tuning per servire come controller, mentre il generatore (ad esempio, Qwen3.5-35B, GPT-5.4) rimane congelato.

Contributi Chiave

1. Harness Apprendibile End-to-End: Introduce il primo framework che sostituisce la logica di interazione progettata manualmente con una policy di harness apprendibile che media l'interfaccia agente-ambiente.
2. Unified Instruction Tuning: Dimostra la prima applicazione dell'instruction tuning unificato per apprendere mappature bidirezionali (compressione dell'osservazione e validazione dell'azione) tra agenti e ambienti.
3. Sistema HarnessBridge: Presenta un sistema funzionante che raggiunge prestazioni competitive nei compiti con una riduzione significativa dell'uso di token e della lunghezza della traiettoria.

Risultati Sperimentali

Gli autori hanno valutato HarnessBridge su Terminal-Bench 2.0 e SWE-bench Verified attraverso vari modelli open-source e commerciali.

• Performance vs. Efficienza: HarnessBridge eguaglia o supera forti harness specializzati (ad esempio, Terminus 2, OpenHands, Meta-Harness) riducendo sostanzialmente l'uso dei token.
  • Su Terminal-Bench 2.0 (Qwen3.5-35B), ha raggiunto un tasso di successo del 33,7% (rispetto al 30,3% di Terminus 2) con una riduzione del 46,8% dell'uso di token.
  • Su SWE-bench Verified, ha mantenuto un tasso di successo del 60,2% (rispetto al 61,6% di Terminus 2) con una riduzione del 23,1% dei token.
• Generalizzazione: Modelli addestrati su traiettorie di un generatore più piccolo (Qwen3.5-35B) si sono generalizzati efficacemente a modelli commerciali più grandi (ad esempio, GPT-5.4, Claude-Opus-4.7), migliorando spesso i tassi di successo e riducendo i costi dei token fino al 90% su modelli specifici.
• Studi di Ablazione: La rimozione di uno dei due moduli di proiezione (osservazione o azione) ha causato una diminuzione dei tassi di successo, confermando che entrambi i componenti sono necessari per un'interazione ottimale.
• Case Studies: L'analisi ha mostrato che HarnessBridge comprime efficacemente il ragionamento ridondante e i turni di navigazione, preservando al contempo output di test e messaggi di errore critici. Ha interrotto con successo i "loop di verifica ridondanti" dove gli agenti controllavano ripetutamente il codice senza testarlo, reindirizzandoli verso passi azionabili.

Significato e Rivendicazioni

Il documento sostiene che HarnessBridge riconsidera l'interfaccia agente-ambiente come una policy apprendibile piuttosto che come un'infrastruttura statica. La sua importanza risiede in:

• Scalabilità: Imparando a sopprimere il contesto obsoleto e a rifiutare azioni improduttive, il sistema rimane efficiente man mano che gli orizzonti dei compiti si estendono, affrontando una limitazione centrale degli attuali agenti a lungo orizzonte.
• Efficienza: Raggiunge riduzioni sostanziali nel consumo di token e nella lunghezza della traiettoria senza sacrificare (e spesso migliorando) i tassi di successo dei compiti.
• Trasferibilità: I pattern di controllo appresi si generalizzano attraverso diversi modelli generatori e ambienti, suggerendo che l'harness cattura proprietà fondamentali di un'interazione efficace agente-ambiente piuttosto che adattarsi eccessivamente agli artefatti delle traiettorie di un modello specifico.

Gli autori notano che la loro valutazione è attualmente limitata agli ambienti di coding, ma il meccanismo opera su traiettorie generiche di uso di strumenti (tool-use), implicando una potenziale applicabilità alla navigazione web e ai flussi di lavoro di ricerca multi-step.