Continuo a imbattermi in OpenHands come livello infrastrutturale sottostante TheAgentCompany, InvestorBench e una lista crescente di articoli di valutazione — eppure non ho ancora letto l'articolo principale. Questa è l'infrastruttura su cui il resto del settore sta silenziosamente costruendo, quindi capire cosa offre realmente, e dove mostra i suoi limiti, è più importante di qualsiasi singolo risultato di benchmark costruito su di essa.
L'articolo
OpenHands (Wang et al., 2024; ICLR 2025) è una piattaforma open-source per costruire e valutare agenti LLM che agiscono come sviluppatori software generalisti. Guidato da Xingyao Wang e Graham Neubig con un team di 24 autori, l'affermazione centrale dell'articolo è che la maggior parte dei framework esistenti per agenti sono troppo ristretti per la ricerca (cicli di attività hard-coded) o troppo ristretti per la produzione (closed-source o monouso) per servire come base condivisa per la comunità di ricerca. OpenHands cerca di risolvere questo problema fornendo un runtime standardizzato, un'astrazione pulita per gli agenti e 15 benchmark di valutazione integrati in un unico repository con licenza MIT.
Il runtime è un ambiente sandbox Docker contenente una shell bash, un server Jupyter IPython e un browser Chromium controllato da Playwright. Gli agenti interagiscono tramite tre tipi di azione principali: IPythonRunCellAction per Python, CmdRunAction per comandi shell e BrowserInteractiveAction per la navigazione web. Un primitivo di coordinamento multi-agente, AgentDelegateAction, permette a un agente principale di generare sotto-agenti specializzati. La spina dorsale predefinita è CodeAct — originariamente pubblicato come articolo a sé stante che sostiene che il codice sia lo spazio di azione unificato ideale per gli agenti LLM — e la piattaforma include diverse implementazioni di agenti, tra cui un CodeActAgent generale e un BrowsingAgent specializzato.
Idee chiave
- Codice come spazio di azione universale: CodeAct consolida tutte le azioni dell'agente (modifiche a file, chiamate API, trasformazioni di dati) in Python o bash, permettendo all'LLM di ragionare nello stesso mezzo su cui è stato maggiormente addestrato. Questo evita la fragilità degli schemi JSON che affligge gli agenti basati su chiamate a funzioni.
- Runtime Docker in sandbox: ogni agente viene eseguito in un contenitore isolato, quindi gli agenti possono eseguire liberamente codice arbitrario senza compromettere la macchina host — un prerequisito per qualsiasi agente finanziario in produzione che potrebbe ricevere credenziali reali.
- 15 benchmark in un unico ambiente: SWE-Bench Lite (riparazione codice), HumanEvalFix (correzione bug), WebArena (navigazione web), GPQA (ragionamento a livello di laurea), GAIA (risoluzione di compiti generali) e altri dieci. Avere questi benchmark nello stesso posto previene valutazioni selezionate ad arte.
- CodeActAgent + claude-3.5-sonnet raggiunge il 26% su SWE-Bench Lite e il 79,3% su HumanEvalFix; BrowsingAgent raggiunge il 15,5% su WebArena — competitivo zero-shot senza alcun addestramento specifico per il compito.
- Prestazioni su GAIA: 32,1% con GPTSwarm, ben al di sotto della linea di base umana del 92% — coerente con ogni altro benchmark per agenti generali che mostra un divario del 60-70 punti tra umani e agenti.
- Scala comunitaria: 71.4K stelle GitHub e oltre 188 contributori al momento della sottomissione a ICLR; TheAgentCompany ha adottato OpenHands come suo ambiente di valutazione, conferendogli di fatto lo status di infrastruttura di benchmark.
Cosa regge — e cosa no
Il design del runtime in sandbox è una solida ingegneria. Isolare l'esecuzione dell'agente in Docker è l'impostazione predefinita corretta per qualsiasi sistema a cui potrebbe essere successivamente concesso l'accesso in scrittura a registri finanziari reali, ed è genuinamente utile che i benchmark siano co-ubicati piuttosto che sparsi in repository incompatibili.
La copertura dei benchmark, tuttavia, è più aspirazionale che sistematica. I 15 benchmark spaziano su tipi di compiti e livelli di difficoltà estremamente diversi, senza un quadro chiaro su come i risultati dovrebbero essere aggregati o confrontati. Riportare il 26% su SWE-Bench Lite insieme al 79,3% su HumanEvalFix nello stesso articolo rischia di creare l'impressione che lo stesso agente sia simultaneamente mediocre ed eccellente — i compiti semplicemente non sono comparabili. Gli autori non forniscono una metodologia di aggregazione multi-benchmark basata su principi.
L'assunzione di CodeAct — che il codice sia il formato di azione universale corretto — è contestata. Funziona bene per compiti di sviluppo, ma impone uno strato di mediazione Python/bash su ogni azione, che aggiunge latenza e si rompe quando la semantica dell'azione non si mappa pulitamente al codice (istruzioni ambigue per l'utente, API solo in linguaggio naturale). L'articolo non confronta con spazi di azione non basati su codice per dimostrare che il vantaggio sia reale piuttosto che confuso dalla spina dorsale LLM.
Forse il divario più importante è la separazione tra valutazione e implementazione. Il numero del 26% su SWE-Bench proviene da un benchmark relativamente pulito e ben specificato. Rapporti della comunità e thread di issue su GitHub descrivono costantemente un'affidabilità molto più bassa su compiti del mondo reale ambigui o a lungo orizzonte — lo stesso modo di fallimento documentato da TheAgentCompany. L'articolo non affronta come misurare o migliorare la robustezza sotto rumore di specifica dei compiti realistico.
Perché questo è importate per l'AI finanziaria
OpenHands è la cosa più vicina che la comunità abbia a un substrato condiviso per agente. Se Bean Labs costruisce un'infrastruttura di valutazione per agente Beancount, l'architettura del runtime qui — sandbox Docker, azioni Python/bash, backend LLM pluygabili — vale la pena di essere adotatta piuttosto che ricostruita. Il primitivo AgentDelegateAction si mappa naturalmente a una pipeline di agente finanziario in cui un orchetratore di alto livello delega a sotto-agenti specializzati: uno per le letture del libro mastro, uno per la segnalazione di anomali, uno per le proposte di scrittura che un umano riesamina.
I numeri di SWE-Bench e TheAgentCompany, letti insieme, stabiliscono una priore sobria: anche i migliori agenti disponibili completano circa il 26–30% di compiti software realistici e non ambigui. L'automazione della contabilità finanziaria è più difficile — le transazioni sono spesso ambigue, il raggio d'azione degli errori è reale, e l'intenzione dell'utente è frequentemente sotto-specificata. L'infrenza correta non è che gli agenti non sian pronti, ma che le prime implementazioni produtive saranno flussi di lavoro scrivi-una-volta strettamente circoscritti (suggerimenti di categorizzazione, segnalazione di riconciliazioni) piuttosto che modifiche autonome a più fasi del libro mastro.
Cosa leggere dopo
- ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — abbina un modello economic con uno costoso e defrisce al modello costoso solo quando l'incertezza è alta; affronta direttamente come un agente stile OpenHands dovrebbe decidere quando escalare una scrittura su Beancount a una riesione umana.
- FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Taks (arXiv:2604.10015) — 800 sequenze di compiti annotate da esperi su 34 scenari finanziari; la metodologia di valutazione che a OpenHands manca per l'uso di strumenti finanziari a lungo orizzonte specifico.
- FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 613 campioni su 65 strumenti finanziari MCP reali, direttamente rilevante per come un agente Beancount costruito sul runtime di OpenHands verrebbe valutato in una implementazione MCP reale.