OpenHands: l'agente di coding AI open source spiegato

OpenHands è una piattaforma open source per lo sviluppo software con AI, costruita attorno a un agente che può ispezionare il tuo repository, modificare file, eseguire comandi e far girare i test. Fa parte del passaggio verso lo sviluppo software agentico: tu dai all'agente un compito completo e lui lo affronta passo dopo passo finché non termina o ha bisogno del tuo intervento.

In questo articolo ti guiderò attraverso l'architettura di OpenHands e le sue funzionalità principali, ti mostrerò come configurarlo con un modello locale e lo confronterò con Claude Code, Cursor e GitHub Copilot.

Cosa sono gli agenti AI? Iscriviti al nostro percorso AI Agent Fundamentals per scoprire come gli agenti AI possono cambiare il modo in cui lavori.

Cos'è OpenHands?

OpenHands è una piattaforma open source per creare ed eseguire agenti AI che lavorano con il codice.

Il nome copre due cose. La prima è il progetto: una raccolta di repository con un SDK, un server, un'interfaccia browser e un servizio ospitato. La seconda è l'agente di coding che gira sopra tutto questo.

Ecco come funziona:

• Software Agent SDK: Un set di API Python e REST per creare agenti che lavorano con il codice, e il motore dietro la CLI di OpenHands e OpenHands Cloud
• Agent Server: Espone esecuzione dell'agente, conversazioni, strumenti e workspace tramite API REST e WebSocket
• Agent Canvas: Un'unica UI nel browser per conversazioni, file, output del terminale, configurazione dei modelli, backend e automazioni
• OpenHands Cloud: Il servizio gestito commerciale per i team che non vogliono eseguire la propria infrastruttura di backend e sandbox

Quando la maggior parte delle persone dice "OpenHands", intende l'agente. È la parte con cui lavorerò in questo articolo.

Di solito dai all'agente un compito software, lo indirizzi a un workspace con il tuo codice e lui affronta il compito con gli strumenti che ha. Il set di strumenti predefinito è un terminale, un editor di file e un task tracker.

Il workspace non deve per forza essere il tuo laptop. Gli agenti possono usare la macchina locale come workspace o girare in workspace effimeri, ad esempio in Docker o Kubernetes.

OpenHands inoltre non ti lega a un solo provider di modelli. Puoi usarlo con Claude, GPT o qualsiasi altro LLM, inclusi i modelli locali. Agent Canvas esegue anche agenti di terze parti come Claude Code e Codex al posto dell'agente OpenHands predefinito.

In breve, OpenHands è una piattaforma di agenti aperta che puoi eseguire alle tue condizioni.

Come funziona OpenHands

OpenHands gira in un loop.

Un assistente in chat riceve il tuo prompt e restituisce testo. L'agente OpenHands riceve un compito, esegue un'azione, guarda il risultato e decide cosa fare dopo.

Il loop dell'agente OpenHands

Questa è l'idea generale:

• Riceve il compito: Descrivi l'obiettivo in linguaggio naturale, ad esempio "Correggi il report mensile in modo che non unisca mesi di anni diversi"
• Ispeziona il repository: L'agente elenca le directory, apre i file e cerca il codice relativo al compito
• Definisce un piano: Divide il compito in passaggi e li registra nel suo task tracker
• Modifica o crea file: Cambia il codice con il suo editor di file
• Esegue comandi e test: Esegue la test suite o l'app nel terminale
• Ispeziona i risultati: Legge l'output, inclusi errori e asserzioni fallite
• Itera: Se qualcosa non funziona ancora, torna indietro, aggiusta il piano e riprova

Il loop si ferma quando il compito è concluso, oppure quando l'agente ha bisogno di qualcosa che solo tu puoi fornire, come una credenziale mancante o una decisione sui requisiti.

Il punto 6 distingue OpenHands dalla concorrenza. Uno strumento di completamento del codice non vede mai cosa succede quando il suo codice gira. OpenHands sì, quindi può reagire a un test fallito e correggere la causa.

Funzionalità chiave di OpenHands

L'autocomplete suggerisce testo, OpenHands agisce sul tuo progetto. Ecco come.

Modifica del codice

OpenHands modifica i file direttamente e non è limitato a un file alla volta.

Mettiamo che una funzione abbia bisogno di un nuovo nome. L'agente aggiorna la definizione, trova ogni punto di chiamata e aggiorna i test che la referenziano, tutto come parte di un unico compito.

Terminale e uso degli strumenti

L'agente ha un suo terminale. Può installare dipendenze, eseguire script, lanciare test e leggere l'output di qualsiasi comando.

Puoi anche collegare server MCP (Model Context Protocol) per dare all'agente strumenti per cui non è stato progettato, ad esempio un issue tracker o un client per database.

Comprensione del repository

La maggior parte dei generatori di codice vede solo ciò che incolli nel prompt.

OpenHands apre il repository ed esplora. Può leggere il README, seguire gli import e guardare i test esistenti per capire come è strutturato il progetto. Questo significa che le sue modifiche hanno più probabilità di adattarsi al codice già presente.

I compiti lunghi creano un altro problema: la cronologia della conversazione cresce oltre ciò che il modello può contenere. OpenHands gestisce la cosa con un condensatore di contesto, che riassume le parti più vecchie della conversazione così l'agente può continuare a lavorare.

Scelta del modello

Le chiamate al modello passano tramite LiteLLM, quindi puoi usare qualsiasi provider e modello che supporta. La documentazione di OpenHands consiglia modelli delle famiglie Claude, GPT e Gemini, oltre a modelli open-weight con buoni punteggi nell'OpenHands Index.

Se il tuo codice non può lasciare la tua macchina, puoi eseguire un modello locale. OpenHands si connette a server locali come LM Studio, Ollama, vLLM e SGLang.

Da ricordare che il modello cambia molto i risultati. Alcuni modelli locali fanno fatica con l'uso affidabile degli strumenti, anche con una finestra di contesto ampia.

Esecuzione autonoma dei compiti

Una volta che affidi un compito, l'agente esegue il loop in autonomia. Non devi incollare errori in chat o dirgli quale file aprire dopo.

Agent Canvas fa un passo in più con le automazioni. Si integrano con Slack, GitHub, Linear e altro, e girano a orario o in risposta a eventi webhook.

Ma l'autonomia non garantisce la correttezza. Devi comunque rivedere il diff e i risultati dei test prima di fare merge di qualsiasi cosa.

Come usare OpenHands

Il modo migliore per capire OpenHands è dargli un bug e vedere cosa fa.

In questa sezione eseguirò OpenHands in locale con Docker, lo collegherò a un modello locale tramite Ollama e gli chiederò di correggere un bug in un piccolo progetto Python.

Configura OpenHands

Puoi eseguire OpenHands in un paio di modi:

• Launcher CLI: Installalo con uv tool install openhands --python 3.14, poi avvia la GUI con openhands serve

• Docker: Esegui direttamente il container dell'app con un singolo comando docker run

• Agent Canvas: Il nuovo client browser che si connette a backend locali, self-hosted, Cloud o Enterprise

• OpenHands Cloud: La versione ospitata, se preferisci non eseguire nulla in proprio

Userò l'opzione Docker con la GUI Locale. La documentazione di OpenHands ora la indica come applicazione browser basata su Docker deprecata e rimanda ad Agent Canvas come sostituto, ma è ancora documentata ed è il modo più veloce per avviare una GUI.

Ti servirà Docker Desktop su macOS, Linux o Windows con WSL. Su macOS, apri Docker Desktop, vai su Settings > Advanced e abilita la Docker socket predefinita.

Poi avvia l'app:

docker run -it --rm --pull=always \
  -e AGENT_SERVER_IMAGE_REPOSITORY=ghcr.io/openhands/agent-server \
  -e AGENT_SERVER_IMAGE_TAG=1.26.0-python \
  -e LOG_ALL_EVENTS=true \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v ~/.openhands:/.openhands \
  -p 3000:3000 \
  --add-host host.docker.internal:host-gateway \
  --name openhands-app \
  docker.openhands.dev/openhands/openhands:1.8

OpenHands usa il mount della Docker socket per avviare un container sandbox separato, e l'agente esegue i suoi comandi dentro quella sandbox, non sull'host.

Quando i log mostrano che il server è attivo, apri http://localhost:3000 nel browser.

Pagina di benvenuto di OpenHands

Collega un modello

OpenHands non farà nulla finché non gli dai un modello.

Sto usando Devstral Small 2, il modello da 24B di Mistral pensato per il coding agentico. È abbastanza leggero da girare su una singola RTX 4090 o su un Mac con 32GB di RAM. Richiede Ollama 0.13.3 o successivo.

Avvia Ollama con una finestra di contesto più grande e scarica il modello:

OLLAMA_CONTEXT_LENGTH=32768 OLLAMA_HOST=0.0.0.0:11434 ollama serve &
ollama pull devstral-small-2:24b

Non sottovalutare la lunghezza del contesto. Il valore predefinito di Ollama è 4096 token, troppo piccolo persino per contenere il system prompt di OpenHands. La documentazione chiede almeno 22000.

In OpenHands, apri Settings, vai alla scheda LLM e attiva Advanced. Poi imposta:

1. Custom Model: openai/devstral-small-2:latest

2. Base URL: http://host.docker.internal:11434/v1

3. API Key: Qualsiasi valore fittizio, ad esempio local-llm

Impostazioni LLM per un modello Ollama locale

Il prefisso openai/ dice a OpenHands di parlare con Ollama tramite la sua API compatibile con OpenAI. La chiave API non viene usata, ma il campo non può restare vuoto.

Apri un repository

OpenHands non può vedere i tuoi file per impostazione predefinita. Devi montare il progetto nella sandbox.

Per questo esempio, ti servirà una cartella chiamata budget-tracker/project con due file. Il primo somma la spesa per mese:

# budget.py
def monthly_totals(transactions):
    """Sum spending per month, keyed as 'YYYY-MM'.

    Each transaction is a (date, amount) tuple, for example ("2025-01-15", 42.0).
    """
    totals = {}
    for date, amount in transactions:
        month = date[5:7]
        totals[month] = totals.get(month, 0) + amount
    return totals

Il docstring promette chiavi YYYY-MM, ma date[5:7] tiene solo il mese. Gennaio 2025 e gennaio 2026 finiranno nello stesso bucket.

Il secondo file ha due test che intercettano il bug:

# test_budget.py
from budget import monthly_totals


def test_same_month_in_different_years():
    transactions = [
        ("2025-01-10", 50.0),
        ("2025-01-20", 100.0),
        ("2026-01-12", 60.0),
    ]
    assert monthly_totals(transactions) == {"2025-01": 150.0, "2026-01": 60.0}


def test_single_month():
    transactions = [("2026-03-01", 20.0), ("2026-03-15", 5.5)]
    assert monthly_totals(transactions) == {"2026-03": 25.5}

Trasforma la cartella in un repository Git, così potrai vedere cosa cambia l'agente più tardi:

cd budget-tracker
git init
git add .
git commit -m "Initial commit"

Se ora esegui python -m pytest, entrambi i test falliscono:

Test falliti

Per dare accesso a OpenHands, ferma il container e aggiungi una riga al comando docker run:

-e SANDBOX_VOLUMES=$HOME/budget-tracker:/workspace:rw \

Quindi il comando completo ora è:

docker run -it --rm --pull=always \
  -e AGENT_SERVER_IMAGE_REPOSITORY=ghcr.io/openhands/agent-server \
  -e AGENT_SERVER_IMAGE_TAG=1.26.0-python \
  -e LOG_ALL_EVENTS=true \
  -e SANDBOX_VOLUMES=$HOME/Desktop/budget-tracker:/workspace:rw \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v ~/.openhands:/.openhands \
  -p 3000:3000 \
  --add-host host.docker.internal:host-gateway \
  --name openhands-app \
  docker.openhands.dev/openhands/openhands:1.8

Il formato è host_path:container_path:mode. Il tuo progetto compare nella sandbox sotto /workspace e rw permette all'agente di modificarlo.

Monta solo il progetto che vuoi che l'agente cambi. Qualsiasi cosa montata in lettura-scrittura in /workspace può essere modificata dall'agente.

Dai un compito all'agente

Avvia una nuova conversazione e descrivi il problema come scriveresti un bug report:

I totali mensili uniscono la spesa dello stesso mese in anni diversi.

Trova la causa, correggila ed esegui i test per confermare che passano.

Tutto qui. Non devi indicare all'agente budget.py o dirgli quale riga è sbagliata.

Output della conversazione

Da qui in poi subentra il loop dell'agente visto prima. L'agente guarda in /workspace, legge entrambi i file ed esegue i test per vedere cosa fallisce. Poi modifica il codice ed esegue di nuovo i test.

L'agente che esegue pytest nel terminale della sandbox

Rivedi le modifiche

L'agente dice che ha finito. Ora puoi vedere le differenze aprendo l'editor del codice e ispezionando le modifiche nel codice.

La correzione giusta è una riga in budget.py:

month = date[:7]

budget.py corretto

Puoi anche fare un controllo git diff per ottenere le differenze.

Ecco cosa dovresti controllare:

• Il codice sorgente: La correzione deve essere in budget.py

• I test: Assicurati che l'agente non abbia modificato test_budget.py per far passare le asserzioni

• L'esecuzione dei test: Esegui tu stesso python -m pytest: non affidarti al riepilogo dell'agente

Architettura di OpenHands

OpenHands ha sei parti principali, e ognuna ha un singolo compito.

Come si collegano i componenti di OpenHands

Modello AI

Il modello fa il ragionamento. Riceve il compito e la cronologia della conversazione e risponde con un messaggio o una chiamata a uno strumento.

Il modello non cambia i tuoi file e non esegue nulla. Decide solo cosa dovrebbe succedere dopo. Le chiamate al modello passano tramite LiteLLM, quindi lo stesso agente funziona con un provider ospitato o un modello locale come l'impostazione Devstral dell'articolo.

Logica dell'agente

L'agente sta tra il modello e tutto il resto. Esegue il loop ragionamento-azione, cioè chiede al modello la prossima azione, esegue lo strumento e gestisce il risultato o l'errore.

Decide anche cosa può vedere il modello. L'agente gestisce la cronologia della conversazione con condensatori e aggiunge skill e prompt a ogni query al modello.

Ogni passaggio viene registrato. L'agente esegue azioni e riceve osservazioni, e la conversazione mantiene quella cronologia di eventi. Il modello vede questi eventi al turno successivo, così sa cosa è già successo.

Strumenti e azioni

Gli strumenti sono il modo in cui l'agente influenza ciò che sta fuori dal modello. Il set standard include un terminale, un editor di file e un task tracker, e puoi aggiungerne altri tramite server MCP.

Il modello richiede un'azione, tipo "esegui pytest" o "sostituisci la riga 8 in budget.py." Lo strumento la esegue e restituisce un'osservazione, come l'output dei test o il file aggiornato.

Prima che un'azione giri, passa da un controllo di sicurezza. Il security analyzer valuta ogni azione per primo e può mettere in pausa l'agente per la tua approvazione.

Ambiente di sviluppo

Gli strumenti non girano sulla tua macchina. Girano dentro una sandbox.

Nell'impostazione Docker, OpenHands esegue l'agent server dentro un suo container Docker. Ecco perché l'articolo monta la Docker socket: il container dell'app ne ha bisogno per avviare la sandbox.

La sandbox non deve per forza essere locale. Gli agenti possono anche girare in workspace effimeri, ad esempio in Docker o Kubernetes, e l'Agent Server espone esecuzione, strumenti e workspace tramite API REST e WebSocket. La logica dell'agente resta la stessa ovunque giri la sandbox.

Repository

Il repository è ciò su cui lavora l'agente. Entra nella sandbox in due modi: una cartella locale che monti, come nell'articolo, o un repo collegato tramite integrazioni con GitHub, GitLab o Bitbucket.

Un repository può anche dire all'agente come comportarsi. Un file AGENTS.md alla radice viene inserito nel system prompt all'avvio della conversazione. Istruzioni più mirate vanno in .agents/skills/, dove l'agente vede prima un riassunto e carica il contenuto completo solo quando ne ha bisogno.

Qui metti le regole di progetto che l'agente non può indovinare, tipo "esegui i test con make test, non con pytest."

Revisione umana

L'ultima parte dell'architettura sei tu.

OpenHands supporta tre policy di conferma: approvare ogni azione, non approvare nulla o approvare solo le azioni rischiose. L'ultima dipende dal security analyzer, che etichetta ogni azione come LOW, MEDIUM, HIGH o UNKNOWN risk. NeverConfirm è il valore predefinito, quindi l'agente gira senza fermarsi a meno che tu non lo cambi.

Il secondo checkpoint arriva alla fine. Il lavoro dell'agente non è finito finché non hai letto il diff e controllato i risultati dei test.

Workflow con OpenHands

Ti ho mostrato come correggere un bug da una riga, ma ovviamente OpenHands può gestire compiti molto più grandi.

Questi compiti hanno in comune il fatto che richiedono più di un passaggio. Ecco sei tipi di lavoro in cui il loop dell'agente ha senso.

Correzione di bug

Il bug mostrato in questo articolo era facile da vedere in un singolo file. Nel mondo reale è quasi mai così.

Mettiamo che i log dell'applicazione mostrino un KeyError in produzione, e lo stack trace punti a una funzione a tre chiamate di distanza da dove entrano i dati sbagliati. Incolli lo stack trace in OpenHands e chiedi una correzione.

L'agente risale la catena di chiamate fino alla fonte dei dati, scrive un test che riproduce l'errore e conferma che il test fallisce. Poi corregge il codice ed esegue l'intera test suite per verificare che non si sia rotto altro.

Un test di riproduzione è la parte da cercare. Dimostra che l'agente ha trovato il bug reale invece di limitarsi a individuare dove si manifesta l'errore.

Implementazione di funzionalità

Il lavoro sulle feature di solito modifica più file di quanto ti aspetti.

Mettiamo che uno script di report da riga di comando abbia bisogno del flag --since per filtrare le transazioni per data. L'agente deve trovare il parser degli argomenti, aggiungere il flag, passare il valore alla logica di filtro e aggiornare il testo di aiuto. Poi scrive i test per il nuovo comportamento e aggiorna il README.

Sono quattro o cinque file per una piccola feature. L'agente li tiene traccia nel suo task tracker, così non si ferma dopo che il primo funziona.

Refactoring del codice

Il refactoring riguarda il cambiare la struttura senza cambiare il comportamento, e la test suite serve a dimostrare che il comportamento non è cambiato.

Mettiamo che un progetto abbia un unico grande file utils.py con helper per date, stringhe e file tutti mescolati. Chiedi a OpenHands di dividerlo in tre moduli.

L'agente crea i nuovi moduli, sposta le funzioni e aggiorna ogni import in tutto il codebase. Esegue i test dopo ogni spostamento. In questo modo, se qualcosa si rompe, sa quale spostamento l'ha causato.

Scrittura di test

Il codice non testato è un punto di partenza comune per il lavoro degli agenti, perché il compito è chiaro e facile da verificare.

Mettiamo che un modulo di parsing delle date non abbia test. L'agente legge le funzioni, scrive casi pytest per input normali e casi limite come stringhe vuote, anni bisestili e formati non validi, e li esegue.

Se un nuovo test fallisce, l'agente deve decidere se il test è sbagliato o se il codice ha un bug. È una decisione che dovresti controllare tu.

Esplorazione di codebase esistenti

Non ogni compito richiede modifiche al codice.

Puoi chiedere a OpenHands domande come "Dove convalida questa app l'input dell'utente prima che raggiunga il database?" L'agente cerca nel codebase, segue le chiamate di funzione tra i file e risponde con percorsi e riferimenti di riga.

Questo è utile quando entri in un nuovo progetto o riprendi in mano codice che non tocchi da mesi. Per lavoro in sola lettura come questo, monta il repository in modalità :ro al posto di :rw, così l'agente non può cambiare nulla nemmeno per sbaglio.

Esecuzione e debug di applicazioni

Alcuni bug emergono solo quando l'applicazione gira.

Mettiamo che un endpoint API restituisca un errore 500 e che i test non lo coprano. L'agente avvia il server nel suo terminale, invia una richiesta con curl e legge il traceback dai log del server.

Poi corregge il codice, riavvia il server e invia di nuovo la stessa richiesta. Se la risposta è ancora sbagliata, il loop riparte da lì.

È lo stesso ciclo modifica-esegui-controlla che faresti tu, solo che l'agente gestisce ogni riavvio e ogni retry.

OpenHands vs altri agenti di coding AI

OpenHands non è l'unico strumento che può prendere un compito e lavorarci in autonomia. Claude Code, Cursor e GitHub Copilot ora hanno funzionalità di agente, ma sono diversi in aspetti importanti.

OpenHands vs Claude Code

Questi due sono i più simili. Entrambi eseguono un loop di agente che legge il codice, modifica file, lancia comandi e controlla i risultati.

La prima differenza è la proprietà. Ogni repository pubblico di OpenHands ha la sua licenza open source, e puoi leggere, modificare e fare self-hosting di tutto. Claude Code è lo strumento proprietario di coding agentico di Anthropic, disponibile nel terminale, IDE, app desktop e browser.

Da qui la questione del modello. Claude Code è costruito attorno ai modelli Claude di Anthropic. OpenHands funziona con qualsiasi provider supportato da LiteLLM, incluso il setup locale con Ollama mostrato nell'articolo.

Anche il flusso di lavoro quotidiano è diverso. Claude Code è nato come strumento da terminale, e lì è dove molti sviluppatori lo usano ancora. OpenHands si affida alla sua UI nel browser, e la sua CLI è completa ma mantenuta principalmente per la stabilità.

Entrambi gli strumenti ti permettono di controllare il comportamento dell'agente. Claude Code legge CLAUDE.md, impostazioni, hook, skill, comandi e subagent da la directory .claude. OpenHands legge AGENTS.md e le skill dal repository, e l'SDK ti consente di costruire agenti personalizzati in Python.

L'autonomia funziona in modo diverso. Claude Code controlla l'uso degli strumenti con modalità di permesso, hook e regole allow/deny, e può sandboxare i comandi. OpenHands esegue ogni comando in una sandbox Docker per impostazione predefinita e aggiunge policy di conferma sopra.

In breve, Claude Code è l'opzione più rifinita che installi e usi subito, mentre OpenHands richiede più setup e in cambio ti dà più controllo. E non sono nemmeno mutuamente esclusivi. Agent Canvas può eseguire Claude Code come agente al posto dell'agente OpenHands predefinito.

OpenHands vs Cursor

Cursor è un editor di codice AI. OpenHands è una piattaforma di agenti. Questa è la differenza principale, e la maggior parte delle altre ne conseguono.

In Cursor lavori dentro l'editor e l'agente lavora accanto a te. Vedi le modifiche apparire nei file, le accetti o le rifiuti e continui a scrivere. In OpenHands, descrivi un compito, l'agente lavora in una sandbox e tu rivedi il risultato. La GUI include una vista VS Code nella sandbox, ma non è lì che avviene la maggior parte del lavoro.

L'accesso al repository segue la stessa divisione. L'agente di Cursor lavora sul codice aperto nel tuo editor. OpenHands lavora su ciò che monti nella sua sandbox o colleghi tramite un'integrazione Git.

Il divario si riduce con i Cloud Agents di Cursor. Girano in autonomia nel cloud e restituiscono il lavoro tramite branch e pull request, e richiedono un account GitHub, GitLab, Azure DevOps o Bitbucket collegato e un piano a pagamento. È simile a ciò che fa OpenHands, ma sull'infrastruttura di Cursor.

L'estendibilità è dove i due differiscono di più. Cursor supporta server MCP e regole di progetto, ma l'editor e l'agente sono prodotti chiusi. Con OpenHands, puoi cambiare l'agente stesso, ospitarlo ovunque ed eseguirlo su un modello locale.

OpenHands vs GitHub Copilot

GitHub Copilot è nato come strumento di autocomplete nell'editor ed è cresciuto da lì fino alle funzionalità di agente. OpenHands è nato come agente.

La forza più grande di Copilot è dove vive. Funziona dentro VS Code e gli IDE JetBrains, e il suo agente cloud lavora direttamente su GitHub. OpenHands non ha quel tipo di integrazione con gli IDE.

Per i compiti a livello di repository, l'agente cloud di Copilot è il paragone più vicino. Gli assegni un'issue e lui lavora in un ambiente di sviluppo effimero alimentato da GitHub Actions, dove può eseguire test e linter prima di fare push. OpenHands Cloud fa qualcosa di simile quando menzioni @openhands in un commento a un'issue o a una pull request.

La piattaforma è la differenza principale. L'agente cloud di Copilot è disponibile per tutti i piani Copilot a pagamento nei repository ospitati su GitHub. OpenHands funziona con GitHub, GitLab, Bitbucket o una cartella locale, e gira sull'hardware che vuoi tu se preferisci.

Copilot ti permette di scegliere un modello per un compito, ma solo tra i modelli offerti da GitHub. OpenHands non ha quella restrizione.

Ecco un rapido riepilogo:

OpenHands a confronto con altri agenti AI

OpenHands per i team di ingegneria del software

Per un singolo sviluppatore, OpenHands è uno strumento che apri quando ti serve. Non è così per un team.

La maggior parte dei team organizza già il lavoro attorno alle issue, e OpenHands Cloud si inserisce in questo. Si integra con GitHub, GitLab e Bitbucket, oltre a Slack, Jira e Linear. Puoi menzionare @openhands in un commento a un'issue o a una pull request, e l'agente prende in carico il compito da lì.

Poi c'è il lavoro che nessuno chiede ma che serve a tutti. Le automazioni di Agent Canvas girano a orario o in risposta a eventi webhook. Ad esempio, un team può condividere un Agent Server per code review e aggiornamenti delle dipendenze, mentre ogni sviluppatore esegue agenti personali sul proprio laptop.

Il testing funziona come nell'articolo. L'agente esegue la test suite nella sua sandbox prima di riferire. Ma l'esecuzione in sandbox non sostituisce la CI: la tua pipeline gira comunque su ogni pull request, esattamente come per il codice scritto da umani.

Le pull request sono un altro tema. Quando OpenHands Cloud lavora con GitHub, richiede token a breve durata che scadono dopo otto ore, con accesso in lettura e scrittura a contenuti, issue, pull request e workflow. Nei setup Enterprise self-hosted, l'agente usa l'autorizzazione GitHub dell'utente che l'ha attivato, così ogni modifica è ricondotta a una persona.

È così che dovrebbe funzionare la responsabilità. L'agente può aprire la pull request, ma uno sviluppatore la approva. La protezione dei branch e le review obbligatorie si applicano alle pull request dell'agente come a quelle di tutti gli altri.

Ambienti isolati rendono tutto questo scalabile. Ogni compito gira nella propria sandbox, così due agenti che correggono due bug non si sovrascrivono i file o non si contendono la stessa porta.

Sicurezza e sandboxing in OpenHands

Uno strumento di completamento del codice suggerisce sempre testo, e poi sta a te accettarlo.

Un agente è diverso. Passa nel tuo progetto, esegue comandi, installa pacchetti e modifica file in autonomia, spesso senza chiedere. Quindi la domanda passa da "questo codice è corretto?" a "cosa ha eseguito l'agente per arrivarci?"

Ambienti di esecuzione isolati

La sandbox Docker protegge i file e i programmi dell'host, le risorse dell'host e altri container e processi. Se l'agente esegue un comando distruttivo, è limitato a un container.

C'è un'eccezione da tenere d'occhio nel setup locale. Il container dell'app monta la Docker socket dell'host per poter avviare le sandbox, e l'accesso a quella socket significa controllo di Docker sulla tua macchina.

Permessi sul repository

La sandbox protegge solo ciò che non monti. I file e le directory montati possono essere modificati o eliminati.

Monta solo il progetto su cui stai lavorando, mai la tua home. Per compiti in sola lettura come l'esplorazione del codice, usa la modalità :ro . Per le integrazioni Git, dai all'agente accesso solo ai repository specifici di cui ha bisogno e nient'altro.

Secret e credenziali

Se fornisci credenziali, come chiavi API o token, l'agente può usarle. E un agente che può leggere un secret può anche stamparlo nei log o inviarlo altrove.

Quindi non montare cartelle con file .env che contengono chiavi di produzione. Dai all'agente credenziali di test con ambito limitato e ruotale spesso.

Accesso di rete

Per impostazione predefinita, l'agente può accedere a internet dal container. Gli serve per installare pacchetti, ma può anche raggiungere qualsiasi servizio esterno.

Questo apre la porta alle prompt injection. Una pagina web o un commento a un'issue può includere istruzioni che l'agente potrebbe seguire. GitHub limita questo rischio per il suo agente cloud con un firewall che limita l'accesso a internet per impostazione predefinita, e vale la pena pensare agli stessi limiti per il tuo setup OpenHands.

Esecuzione dei comandi

Puoi controllare quali comandi girano senza approvazione. OpenHands supporta tre policy di conferma: approvare tutto, non approvare nulla o approvare solo le azioni rischiose. NeverConfirm è il valore predefinito.

L'opzione "azioni rischiose" ha un caveat. Il security analyzer LLM predefinito usa il livello di rischio che il modello assegna alle sue stesse azioni. Un modello può etichettare un comando distruttivo come LOW risk, e verrà eseguito senza chiedere. L'analizzatore classifica il rischio per il layer di policy: non blocca nulla da solo, e la documentazione raccomanda di combinarlo con l'isolamento Docker.

Revisione delle modifiche generate

Tutto quanto sopra limita cosa può fare l'agente. Ma la fase di revisione è importante perché è come controlli cosa ha fatto.

Leggi l'intero diff, non solo i file che ti aspettavi cambiassero. Fai particolare attenzione alla configurazione della CI, ai file delle dipendenze e agli script. In OpenHands Cloud, il token GitHub dell'agente include accesso in scrittura ai workflow, quindi una modifica in .github/workflows può alterare ciò che gira nella tua pipeline.

Limitazioni di OpenHands

Il codice che OpenHands scrive può comunque avere bug. Il passaggio dei test ti dice solo che il codice corrisponde ai test, e l'agente può scrivere entrambi. Se i test sono deboli, il codice può passare ed essere comunque sbagliato.

I compiti complessi spesso hanno bisogno di te nel loop. Requisiti vaghi o una decisione progettuale che l'agente non può prendere lo fermeranno o, peggio, lo manderanno nella direzione sbagliata.

Con un modello ospitato forte, OpenHands gestisce bene i compiti multi-file. Con un modello locale piccolo, vedrai chiamate agli strumenti fallite e risposte da chatbot, e anche con una finestra di contesto ampia, alcuni modelli locali non riescono a usare gli strumenti in modo affidabile.

I loop degli agenti costano anche più della chat. Ogni passaggio rimanda la cronologia della conversazione al modello, e i compiti lunghi richiedono molti passaggi. La documentazione di OpenHands avverte che l'agente invia molte prompt all'LLM e raccomanda limiti di spesa e monitoraggio dell'uso. Il condensatore di contesto aiuta, ma riassume i passaggi più vecchi, quindi i dettagli possono perdersi nei compiti lunghi.

L'accesso agli strumenti aggiunge rischio di sicurezza. Un agente con terminale e accesso alla rete può fare danni reali se segue istruzioni sbagliate, motivo per cui la sandbox e la tua revisione sono così importanti.

E ogni modifica ha comunque bisogno dell'approvazione di una persona. Tienilo sempre a mente.

OpenHands e il futuro degli agenti di coding AI

Gli strumenti di coding AI sono passati dall'autocomplete alla chat fino ad agenti che affrontano un intero compito. OpenHands è uno dei pochi progetti che spinge avanti quest'ultimo passo.

La direzione è chiara in tutto il settore. Cursor descrive un'era emergente in cui agenti cloud autonomi affrontano compiti più grandi su orizzonti temporali più lunghi. Copilot ora prende issue da GitHub e Linear. Claude Code gira nel terminale, nel browser e in Slack.

Le piattaforme open source hanno un ruolo specifico in questo cambiamento. Con OpenHands puoi ispezionare come funziona l'agente, eseguirlo sulla tua infrastruttura e scegliere il modello. Per i team con regole rigide sui dati, spesso è l'unico modo in cui è consentito usare agenti.

I compiti più lunghi portano anche nuovi problemi. Un agente che lavora per un'ora prende più decisioni di uno che lavora per un minuto, e ogni decisione è un'occasione per allontanarsi da ciò che volevi. Modelli migliori aiutano, ma anche sandbox, policy di conferma e revisione.

Conclusione

Quello che rende OpenHands diverso dai suoi concorrenti è il controllo. Puoi leggere il sorgente, ospitarlo sul tuo hardware ed eseguirlo con qualsiasi modello, incluso uno locale. Strumenti commerciali più rigidi come Claude Code, Cursor e GitHub Copilot ti danno un'esperienza migliore, ma alle loro condizioni.

Ma un agente con accesso al tuo terminale e ai tuoi repository ha comunque bisogno di una persona che controlli il suo lavoro. Ricordati sempre di leggere il diff ed eseguire i test tu stesso.

Se vuoi imparare a creare un tuo agente da zero, guarda il nostro webinar Introduction to Creating AI Agents in Python.