Agenti AI nel browser: come usare Browser Use

Browser Use permette di affidare agli agenti AI un'attività su un sito web, mantenendo l'automazione all'interno della propria applicazione. La libreria open source richiede Python 3.11 o versioni successive; Browser Use Cloud può ospitare il browser oppure l'intero agente. Conviene partire da un'attività di cui sia facile verificare l'esito, come leggere un record in un portale, prima di autorizzare l'invio di modifiche.

Contenuti verificati sul README di Browser Use su GitHub e sulla documentazione ufficiale collegata il 2 novembre 2026. La guida pratica che segue è adattata da quelle fonti: non è una prova diretta delle prestazioni.

Come funzionano gli agenti AI con Browser Use

Browser Use collega un modello linguistico a un browser: l'applicazione può così indicare un obiettivo, senza dover specificare ogni singolo clic. È adatto ad attività come cercare un record nel portale di un fornitore, leggere una dashboard o compilare un modulo in cui la schermata successiva dipende dalla risposta precedente. La libreria open source fornisce l'agente, cioè il software che sceglie ed esegue ripetutamente azioni per raggiungere l'obiettivo. README della libreria

Si può immaginare il modello linguistico come un guidatore, Browser Use come l'insieme dei comandi e dei segnali a sua disposizione, e il browser come il veicolo. La strada, però, resta il sito web di qualcun altro. Anche un bravo guidatore non può rendere accessibile una strada chiusa, né decidere che l'incarico di fare una consegna autorizzi un acquisto estraneo.

Il ciclo funziona così:

1. Osservare: raccogliere lo stato attuale della pagina, compresi gli elementi interattivi. Browser Use può anche fornire screenshot al modello.
2. Decidere: il modello linguistico di grandi dimensioni, o LLM, sceglie l'azione successiva in base al compito e allo stato corrente.
3. Agire: il browser naviga, fa clic, digita o esegue un'altra operazione disponibile.
4. Osservare di nuovo: la decisione successiva tiene conto della pagina modificata. Il ciclo prosegue finché l'agente non si ferma o non interviene un limite configurato.

Il DOM, la struttura ad albero degli elementi di una pagina, aiuta a rendere disponibili i controlli su cui l'agente può agire; gli screenshot aggiungono il contesto visivo. La documentazione di Browser Use descrive sia l'elaborazione del DOM sia le opzioni di visione configurabili. Presentarlo come un semplice modello che guarda immagini sarebbe quindi fuorviante. Controlli del browser, impostazioni dell'agente

Per chi sta sviluppando un assistente agli acquisti, un compito utile potrebbe essere «trova lo stato della spedizione di questo ordine». Per considerarlo riuscito servono l'ordine giusto, il suo stato e il record di origine. Un paragrafo convincente scritto dall'agente non basta a verificarlo.

Browser Use open source: cosa si installa

L'installazione di base comprende il pacchetto Python browser-use, un browser da controllare e l'accesso a un modello supportato. La libreria è distribuita con licenza MIT. Il README indica Python 3.11 o versioni successive, mentre la guida introduttiva usa Python 3.12. È possibile eseguire l'agente nel proprio processo e scegliere un browser locale o remoto. README e installazione

«Locale» indica dove viene eseguito il processo o il browser. Se si sceglie l'API di un modello remoto, le osservazioni vengono comunque inviate a quel servizio: avere il browser in locale non rende locale l'intero sistema.

Quali modelli si possono usare?

Browser Use offre adattatori per diversi fornitori, quindi non obbliga a usare il proprio modello:

• Browser Use BU2: ChatBrowserUse(model="bu-2-0"), con BROWSER_USE_API_KEY.
• Modelli OpenAI: ChatOpenAI, con OPENAI_API_KEY.
• Modelli Anthropic Claude: ChatAnthropic, con ANTHROPIC_API_KEY.
• Modelli Google Gemini: ChatGoogle, con GOOGLE_API_KEY.
• Modelli locali tramite Ollama: ChatOllama, collegato al servizio del modello locale.

La documentazione sui modelli supportati elenca anche integrazioni per DeepSeek, Mistral, Microsoft Azure OpenAI, Amazon Web Services Bedrock e OpenRouter. È bene verificare quali modelli offre attualmente il fornitore, senza scambiare l'identificativo presente in un vecchio esempio per una raccomandazione.

La presenza di un adattatore non garantisce la qualità. La stessa documentazione avverte che alcuni modelli Qwen generano uno schema delle azioni errato, cioè istruzioni in un formato che l'agente non può eseguire, e al momento consiglia qwen-vl-max per quell'integrazione. Prima di affidare più responsabilità a un modello, occorre valutarlo sulle pagine effettive e sui risultati richiesti.

Browser Use Web UI

Browser Use Web UI è un progetto separato, con un'interfaccia Gradio che permette di interagire con l'agente via web. Ha una propria installazione e dipendenze specifiche. Per integrare Browser Use in un'applicazione, il punto di partenza è la documentazione aggiornata della libreria Python: le istruzioni di installazione del repository Web UI non vanno mescolate con quelle dell'SDK del servizio ospitato.

Cosa aggiunge Browser Use Cloud

Browser Use Cloud permette di delegare l'infrastruttura del browser, l'intero agente o entrambi. Da questa scelta dipende quanto codice occorre gestire direttamente. L'attuale guida introduttiva a Cloud distingue esplicitamente le opzioni:

Con un agente proprio, Browser(use_cloud=True) seleziona il browser ospitato di Browser Use e richiede BROWSER_USE_API_KEY. Il browser gestito aggiunge funzioni stealth, proxy e un'anteprima in tempo reale. Il README descrive anche la gestione dei CAPTCHA, precisando però che i risultati dipendono dal sito e dalla verifica proposta. Guida al browser Cloud, README

CDP, il Chrome DevTools Protocol, è il protocollo di connessione per il controllo remoto usato nella modalità infrastrutturale documentata. Un browser ospitato può quindi essere controllato da codice che continua a essere eseguito sui propri sistemi.

Per la modalità interamente ospitata, il pacchetto è browser-use-sdk, non browser-use. Gli esempi Cloud attuali usano l'API V4 e l'import Python from browser_use_sdk.v4 import BrowserUse. Il programma invia un compito e ne recupera il risultato, anziché eseguire il ciclo locale di Agent. Guida introduttiva all'agente ospitato

Per chi sviluppa è una scelta di distribuzione del software. Per chi gestisce il processo, la responsabilità resta la stessa: stabilire a cosa può accedere l'agente e quali prove servono per considerare concluso un lavoro.

Quando conviene un'alternativa a Browser Use

La scelta dipende da quale livello si vuole gestire. Browser Use è un buon punto di partenza quando il compito si svolge interamente su siti web e serve un ciclo di controllo dell'agente già pronto, con libertà di scelta del modello. Un'API di computer use è adatta quando si vuole costruire il sistema attorno alla sua interfaccia di azione o lavorare anche al di fuori delle pagine web.

OpenAI offre anche un'Agents API separata con un browser ospitato da OpenAI, quindi la regola «computer use significa sempre dover ospitare il proprio browser» non è più utile. Anche Browserbase propone prodotti per agenti oltre all'infrastruttura browser.

Browser Use e Browserbase non sono necessariamente alternativi: Browser Use accetta un cdp_url e Browserbase espone un URL di connessione CDP. Queste interfacce documentate offrono una strada per abbinare la libreria dell'agente a quell'ambiente di esecuzione, ma questo articolo non sostiene di aver provato l'integrazione. Impostazioni di connessione di Browser Use

Se un'API affidabile o uno script per browser con una sequenza fissa risolve già il problema, conviene mantenerlo. Un modulo stabile non trae vantaggio dal chiedere a un modello di riscoprire ogni volta gli stessi passaggi. La guida agli agenti di computer use approfondisce la scelta del sistema di controllo; il confronto tra browser per agenti AI esamina le infrastrutture.

I rischi che restano a carico dell'applicazione

In produzione, il confine più difficile da definire è ciò che il browser può fare dopo l'accesso. Ospitarlo altrove non rende attendibili le istruzioni presenti nelle pagine e non elimina le conseguenze di un invio sbagliato.

Prompt injection nei contenuti delle pagine

Si parla di prompt injection quando un contenuto letto dall'agente cerca di deviarne le istruzioni. In un portale, potrebbe essere una nota inserita da un cliente che invita l'agente a caricare un report su un'altra destinazione. La nota va trattata come un dato, anche se si presenta come un'istruzione dell'amministratore.

Servono account dedicati, con i soli permessi necessari al compito. Occorre limitare la navigazione con allowed_domains di Browser Use e rendere obbligatoria l'approvazione delle azioni con conseguenze rilevanti nell'applicazione o nell'ambiente di esecuzione. Anche un sito consentito può mostrare contenuti ostili inseriti dagli utenti: un elenco di domini, da solo, non basta a stabilire di cosa fidarsi. Restrizioni del browser, indicazioni di sicurezza per il computer use

Un prompt che dice «chiedi prima di inviare» non costituisce un controllo effettivo dei permessi. Se l'integrazione non può intercettare in modo affidabile l'azione interessata, occorre escluderla dai permessi dell'agente e affidarla a una persona. La guida alla prompt injection spiega come vincolare l'approvazione all'esatta azione autorizzata.

Accessi, dati di sessione e log

Una sessione di accesso salvata consente di entrare nell'account. Browser Use può riutilizzare Chrome tramite Browser.from_system_chrome() oppure caricare cookie e local storage salvati con Browser(storage_state="auth.json"). Quel file di stato va protetto come una credenziale ed escluso dal controllo di versione. Per un'attività aziendale non presidiata è inoltre opportuno evitare il profilo del browser personale. Documentazione sull'autenticazione

C'è un limite preciso nella migrazione: il README specifica che la sincronizzazione del profilo locale trasferisce i cookie, ma non local storage, IndexedDB o estensioni. IndexedDB è un altro sistema di archiviazione dei dati nel browser. I profili Cloud, invece, possono conservare cookie, local storage e stato di accesso tra browser cloud. Questa persistenza non significa che la sincronizzazione locale abbia copiato ogni sistema di archiviazione. Alcuni siti richiederanno un nuovo accesso. Limiti della sincronizzazione

I profili devono restare separati per ciascun utente finale. Prima di trattare dati riservati di un portale, bisogna anche controllare cosa finisce negli input del modello, negli screenshot e nelle cronologie delle conversazioni salvate. Browser Use offre controlli per gli screenshot e per il salvataggio delle conversazioni: vanno configurati con attenzione. Impostazioni dell'agente

Limiti di accesso e tentativi dall'esito incerto

Avere a disposizione una sessione browser nel cloud non dà accesso illimitato al sito di destinazione. Occorre pianificare separatamente i limiti del servizio del modello, la capacità e i limiti di richiesta di Browser Use Cloud, oltre alle restrizioni di frequenza e alle verifiche imposte dal sito stesso.

È necessario limitare le attività simultanee per ciascun sito, attendere quando viene richiesta una pausa e interrompere i tentativi ripetuti che vengono bloccati. In caso di errori dell'API Cloud, va verificato se il problema riguarda la capacità o la frequenza delle richieste, rispettando le indicazioni restituite per il nuovo tentativo. Limiti di Cloud

Soprattutto, un timeout del client non deve far partire un invio duplicato. Prima occorre controllare l'esecuzione già avviata e il record di destinazione. Il timeout può lasciare incerto l'esito di un'azione che, in realtà, è già avvenuta.

Documentazione Browser Use: una prima prova pratica

Si parte da una pagina pubblica e da un compito di sola lettura. In questo modo si verifica che pacchetto, browser e modello riescano a comunicare, senza coinvolgere accessi autenticati o transazioni aziendali. I comandi seguono la guida introduttiva open source: l'esempio usa l'ambiente Python 3.12 della guida e la selezione esplicita del modello BU2 indicata nel README.

Configurare Browser Use con Python

1. 1

   Installare il pacchetto e il browser

   Su macOS o Linux, con Python e pip disponibili, aprire una shell Bash in una nuova cartella di progetto:

   pip install uv
   uv venv --python 3.12
   source .venv/bin/activate
   uv pip install browser-use
   uvx browser-use install

   L'ultimo comando installa il browser. Su Windows, al posto di source, usare il comando di attivazione dell'ambiente indicato nella guida introduttiva.

2. 2

   Configurare la credenziale del modello

   Creare una chiave API di Browser Use nella dashboard collegata dalla guida introduttiva. Nella stessa shell Bash, inserirla senza mostrarla a schermo:

   read -rsp "Browser Use API key: " BROWSER_USE_API_KEY
   printf '\n'
   export BROWSER_USE_API_KEY

   Questa chiave abilita il servizio del modello selezionato. Non sposta automaticamente il browser su Cloud.

3. 3

   Eseguire un piccolo compito di sola lettura

   Salvare questo codice come agent.py:

   import asyncio
   from browser_use import Agent, ChatBrowserUse
   
   async def main():
       agent = Agent(
           task=(
               "Open https://example.com and report the page heading. "
               "Do not follow links or submit anything."
           ),
           llm=ChatBrowserUse(model="bu-2-0"),
       )
       history = await agent.run()
       print(history.final_result())
   
   if __name__ == "__main__":
       asyncio.run(main())

   Poi eseguire:

   python agent.py

   Confrontare direttamente con la pagina l'intestazione riportata dall'agente. L'istruzione assegnata al compito è un vincolo iniziale adeguato per questo esempio innocuo; in produzione, le restrizioni devono essere applicate al di fuori del prompt.

Se la prova fallisce, leggere l'errore prima di cambiare modello: installazione del browser, autenticazione del modello e accesso al sito sono punti di errore distinti. Quando tutto funziona, mantenere le versioni delle dipendenze utilizzate e passare a un account di test sul sito previsto.

Quali promesse vanno ridimensionate?

Un'esecuzione dell'agente conclusa non dimostra che la transazione aziendale sia stata completata. La documentazione di Browser Use sui risultati distingue chiaramente i due aspetti: is_done() indica che l'agente ha emesso un'azione di completamento; is_successful() rappresenta la valutazione dell'agente stesso. Gli esiti esterni rilevanti vanno comunque verificati nel sistema di destinazione. Significato dei risultati

Per un cambio di indirizzo, controllare l'indirizzo salvato. Per un report scaricato, verificare il file e il periodo a cui si riferisce. Per un invio, acquisire la conferma del sistema di destinazione e chiarire gli esiti incerti prima di riprovare.

La stessa cautela vale per la promessa «funziona su qualsiasi sito». Le funzioni del browser gestito possono ridurre gli ostacoli all'accesso, ma il README del progetto non promette di poter evitare o risolvere ogni CAPTCHA. Neppure un modello migliore può concedere permessi che l'utente non possiede. Il sistema va progettato sul comportamento reale del sito, compreso il punto in cui deve intervenire una persona.

Da dove iniziare lunedì

Per un fondatore con competenze tecniche, il primo progetto pilota utile è un compito circoscritto di lettura su un portale, con una risposta chiara da ottenere. Servono un account di test separato, l'elenco delle pagine consentite e una procedura scritta per verificare il record restituito. Vanno registrati sia gli errori sia le esecuzioni completate.

Solo dopo aver compreso quegli errori ha senso passare alla preparazione dei moduli. L'invio deve restare affidato a una persona finché l'applicazione non è in grado di rendere obbligatoria l'approvazione, controllare il risultato salvato e riprendersi dagli errori senza duplicare l'azione. Se un'API supportata o uno script stabile copre già il flusso di lavoro, conviene mantenere quell'integrazione più semplice.

Per consigli pratici su come costruire flussi di lavoro AI affidabili, iscriviti alla newsletter.