Computer use, browser use o Playwright per i test UI

In quanti modi un agente può vedere un’interfaccia?

Quando un agente di programmazione modifica un’interfaccia, il lavoro non è finito: deve vedere che la modifica funziona davvero. Questo ciclo, in cui l’agente controlla il proprio lavoro, l’abbiamo descritto nell’articolo sull’harness engineering. Per un’interfaccia ci sono tre modi di fare questo controllo, e tutti e tre sono già pronti negli strumenti di programmazione di oggi:

Con computer use l’agente vede lo schermo come un’immagine e lavora con mouse e tastiera. Lo strumento di Anthropic fornisce screenshot e il controllo di mouse e tastiera. Anche la documentazione di Google scrive che il modello «vede» lo schermo attraverso le immagini e genera azioni come clic e pressioni di tasti. Questa via arriva a tutto ciò che è sullo schermo: lo strumento di Google funziona nel browser, su mobile e sul desktop.

Con browser use l’agente non guarda l’immagine della pagina ma la sua struttura. Lo strumento browser use di Anthropic legge la pagina dall’albero di accessibilità: ogni elemento arriva con il suo ruolo, il suo nome e un riferimento come [ref_2], e quando clicca l’agente passa quel riferimento invece delle coordinate. Dove l’albero non vede nulla, per esempio in un canvas, torna agli screenshot e alle coordinate. Anche Playwright MCP legge la pagina da questo albero invece che dagli screenshot. La libreria open source Browser Use che compare nei risultati di ricerca è un progetto a parte; in questo articolo, con «browser use» intendiamo questo metodo.

Sulla via codice e test, l’agente guida il browser attraverso una libreria: scrive un test Playwright o chiama la CLI di Playwright. Playwright CLI non carica i dati della pagina nel modello; l’agente legge solo l’output del comando. Anche la guida a computer use di OpenAI consiglia la via del codice per GPT-6 Astra: il modello scrive codice Playwright o PyAutoGUI che guida l’interfaccia, e lo strumento strutturato computer resta un’alternativa. La vera differenza del codice è che, una volta scritto, può girare di nuovo senza modello.

Quanto costa ogni via e quanto è affidabile?

Abbiamo confrontato le tre vie su tre domande: quanti token costa un passo, quanto dura un compito e quanto spesso un compito viene portato a termine dall’inizio alla fine. La maggior parte dei numeri viene dalla documentazione dei provider; per i risultati dei benchmark diciamo chi li ha pubblicati.

Un agente che lavora dallo schermo legge uno screenshot a ogni passo, e le immagini si pagano in token. I tre provider le contano in modo diverso: Anthropic divide l’immagine in quadrati di 28 pixel, OpenAI in quadrati di 32 pixel, mentre Google usa per Gemini 4 e 3 un numero fisso, qualunque sia la dimensione. Alla risoluzione 1280×800 che Anthropic consiglia per le applicazioni web, un solo screenshot costa:

Quello che il grafico non mostra è l’accumulo. L’agente fa un nuovo screenshot a ogni passo, e quelli vecchi restano nel contesto. Secondo Anthropic, una finestra di contesto da 200K token si riempie molto prima di arrivare a 100 screenshot. Quando una richiesta contiene più di 20 immagini, ogni immagine è soggetta a un limite di dimensione più stretto. Per questo Anthropic consiglia, per i suoi modelli più recenti, di ridurre gli screenshot a 2000 pixel per lato al massimo e di eliminare quelli vecchi lato server. Che cosa dimentica l’agente quando il contesto si riempie l’abbiamo spiegato nell’articolo sull’auto compact.

Anche il set di strumenti ha un costo suo. Con Anthropic, il set di strumenti computer use aggiunge circa 4.500 token di input a ogni richiesta, il set di strumenti browser use circa 6.600. Siccome questo carico è uguale in ogni richiesta, qui il prompt caching è utile. Per l’albero di accessibilità non c’è un numero unico, dipende dalla pagina; la documentazione di Anthropic scrive che su una pagina normale leggere l’albero di solito costa meno token di input di uno screenshot. Anche l’albero può diventare grande: il team di Playwright consiglia agli agenti di programmazione la CLI invece di MCP, perché la CLI non carica nel contesto del modello grandi schemi di strumenti né lunghi alberi di accessibilità.

Per il tempo, i provider non danno un numero per passo; in nessuna delle documentazioni che abbiamo letto ci sono i secondi per azione. Anthropic scrive che computer use può essere lento rispetto a una persona che fa le stesse operazioni a mano, e lo consiglia per i compiti in cui la velocità non conta, come i test software automatizzati. Il tempo per compito lo pubblica OpenAI: secondo la sua misurazione, GPT-6 Astra ha completato un compito di OSWorld 2.0 in circa 40 minuti, GPT-5.6 Sol in circa 75 minuti. Sono compiti lunghi: secondo il sito di OSWorld 2.0, una persona impiega circa 1,6 ore per completarne uno (mediana), e Claude Opus 4.7 fa in media 318 chiamate a strumenti per compito; nel vecchio OSWorld erano circa 30.

Per l’affidabilità, la misura più seguita è OSWorld. Tutti e tre i provider hanno misurato i loro nuovi modelli su una versione recente di OSWorld e hanno annunciato i risultati, ma ognuno su una versione o un sottoinsieme diverso, e tutti danno punteggi parziali:

Fonte: annunci e model card dei provider stessi, 20 ottobre 2026; tutti i risultati sono quelli dichiarati dal provider. Versioni e sottoinsiemi sono diversi, quindi le righe non si possono confrontare tra loro. Le model card di Google danno un mese, non un giorno.

Il punteggio parziale misura quanti dei punti di controllo di un compito vengono superati; OSWorld 2.0 valuta un compito con 27,25 punti di controllo in media. La misura principale del benchmark, però, è se il compito viene portato a termine dall’inizio alla fine. La distanza tra le due è grande. Nella tabella di OSWorld 2.0 (aggiornamento del 15 ottobre, versione v2.1), il miglior risultato tra le esecuzioni in cui il modello lavora da solo è quello di Claude Opus 5 all’effort più alto: punteggio parziale del 77,67% e 44,33% dei compiti portati a termine dall’inizio alla fine. All’effort più basso, lo stesso modello ne porta a termine il 18,81%.

Nella versione attuale la tabella non ha modelli di OpenAI; nel sottoinsieme offline della versione precedente, GPT-5.6 Sol all’effort più alto ha ottenuto il 64,13% di punteggio parziale e il 28,1% di compiti portati a termine dall’inizio alla fine. I modelli Gemini nella tabella non ci sono proprio. Quindi i numeri annunciati dai provider dicono che l’agente fa la maggior parte del lavoro; non dicono che lo porta a termine. Come leggere un punteggio l’abbiamo spiegato nell’articolo su SWE-bench.

Perché lavorare dallo schermo non dia sempre lo stesso risultato lo scrivono i provider stessi. Secondo GitHub, un cambiamento nei tempi o nello stato di una finestra può portare a un risultato diverso, e far ripetere un’azione all’agente o bloccarlo. Anthropic scrive che il modello può sbagliare quando genera le coordinate, Google che popup inattesi e cambi di layout possono confondere il modello. L’albero di accessibilità risolve una parte del problema: secondo Anthropic, un riferimento a un elemento non risente degli spostamenti di layout che rendono inaffidabili le coordinate in pixel. In un test Playwright l’elemento si trova per ruolo e nome, Playwright aspetta finché si verifica lo stato atteso, e il test fa gli stessi passi nello stesso ordine a ogni esecuzione.

Fonte: la documentazione collegata in questa sezione, 20 ottobre 2026.

Che cosa offrono i tre provider per computer use e browser use?

Se costruisci il tuo agente sull’API, tutti e tre i provider hanno uno strumento pronto. Il ciclo è lo stesso per tutti: il modello chiede un’azione, il tuo codice la esegue nel tuo browser o nella tua macchina virtuale e restituisce il risultato. Al 20 ottobre 2026:

Fonte: la documentazione su computer use, browser use e prezzi dei tre provider, 20 ottobre 2026. «La documentazione non lo dice»: nelle pagine che abbiamo letto quel giorno non abbiamo trovato una frase che lo descriva.

Da Anthropic c’è stato di recente un passaggio. Secondo le note di rilascio, computer use è uscito dalla beta il 19 agosto e lo strumento browser use è arrivato lo stesso giorno. Su Opus 5.5, uscito il 22 settembre, il vecchio strumento computer_20251124 restituisce un errore 400 nella Claude API e su Google Cloud; nemmeno Sonnet 5.5 e Haiku 5.5 accettano i vecchi strumenti. Il nuovo set di strumenti può restituire più azioni insieme in un solo turno; il tuo codice deve eseguirle in ordine e fermarsi al primo errore.

OpenAI ha due vie. La guida spiega sia lo strumento computer, con cui il modello restituisce azioni come clic e digitazione, sia la via in cui il modello scrive codice Playwright o PyAutoGUI. Sulla via del codice, il modello può combinare più azioni, un ciclo o una condizione in una sola chiamata. La guida chiede anche di controllare il risultato reale alla fine invece di fidarsi della risposta del modello. Dal 29 settembre, anche la Agents API offre computer use in un browser ospitato da OpenAI.

Lo strumento di Google è in anteprima, e Google consiglia una supervisione stretta per i compiti importanti. Il modello dà le coordinate su una griglia 1000×1000; il tuo codice le converte nella dimensione dello schermo. Se un’azione è rischiosa, nella risposta arriva require_confirmation e devi chiedere all’utente. La scansione degli screenshot contro la prompt injection è facoltativa e disattivata di default.

Sulla scelta del modello, i tre provider consigliano cose diverse. Google consiglia Gemini 3.8 Flash per computer use. Anthropic ritiene Haiku 5.5 adatto ai compiti di browser use in cui conta la velocità. La documentazione di Codex consiglia GPT-6 Astra per i compiti difficili che dipendono dagli screenshot o da un giudizio visivo. Le differenze generali tra i modelli le abbiamo spiegate nell’articolo sulla scelta del modello.

Come testano un’interfaccia gli agenti di programmazione?

In tutti e cinque gli strumenti di programmazione l’agente ha un modo per usare il browser o lo schermo, ma cambiano il posto in cui gira e le impostazioni di default. Abbiamo letto la tabella nella documentazione di ogni strumento il 20 ottobre 2026:

Fonte: la documentazione e le note di rilascio di ogni strumento, 20 ottobre 2026. «La documentazione non lo dice»: nelle pagine che abbiamo letto quel giorno non abbiamo trovato una frase che lo descriva. In Copilot, computer use è entrato in anteprima il 1 ottobre ed è disattivato di default.

Se usi ancora Gemini CLI, il suo agente browser è disattivato di default; quando lo attivi, lavora con la pagina tramite l’albero di accessibilità. Per gli utenti del livello gratuito e di Google One, Google ha sostituito Gemini CLI con Antigravity CLI il 18 giugno 2026; con chiavi API a pagamento Gemini CLI si può continuare a usare.

La documentazione di tre di questi strumenti consiglia lo stesso ordine. Claude Code considera il controllo dello schermo la via più ampia e più lenta: prova prima un server MCP, poi Bash, poi Claude in Chrome, e usa lo schermo solo se nessuno di questi basta. Secondo GitHub, se un’API, un server MCP, un comando del terminale o uno strumento del browser possono fare il lavoro, questi strumenti danno informazioni più strutturate e risultati più prevedibili. Anche la documentazione di Codex consiglia per un’app web locale prima il browser integrato, e per i compiti ripetuti un server MCP.

Una differenza riguarda anche la sessione. Claude in Chrome condivide lo stato di accesso del tuo browser e può entrare in tutti i siti in cui hai fatto l’accesso; davanti a una pagina di login o a un CAPTCHA si ferma e te lo chiede. In VS Code le pagine che apre l’agente si aprono in una sessione separata e temporanea. Il browser integrato di Codex e Antigravity IDE usano un profilo separato dal tuo.

Perché di solito è meglio far scrivere all’agente un test Playwright?

Il controllo che l’agente fa nel browser sparisce quando la sessione finisce. Se trasformi lo stesso controllo in un test Playwright, resta nel repository e gira di nuovo senza modello a ogni pull request: non spende token, non accumula screenshot e fa ogni volta gli stessi passi. La documentazione di VS Code consiglia la stessa cosa: gli strumenti del browser servono per i controlli dentro una sessione; i controlli che devono girare in CI ogni volta, o accorgersi del ritorno di un vecchio bug, vanno tenuti nel repository come test Playwright o altri test automatici.

In pratica funziona bene un metodo in due passi. Prima l’agente esplora la pagina con uno strumento del browser o con Playwright MCP e vede come sono davvero i selettori e i testi. Poi scrive quel flusso in un test, lo esegue e mostra che passa. Playwright offre anche agenti pronti per questo: i Playwright Test Agents sono un planner che esplora l’app e prepara un piano di test, un generator che scrive i test a partire dal piano e un healer che ripara i test rotti. npx playwright init-agents --loop=claude aggiunge queste definizioni per Claude Code; ci sono anche le opzioni codex e vscode. Il generator verifica selettori e asserzioni dal vivo mentre esegue lo scenario. Ecco un test che un agente potrebbe scrivere per un modulo di registrazione:

// Esempio: test scritto dall’agente, rieseguito in CI a ogni pull request.
import { test, expect } from '@playwright/test';

test('il modulo di registrazione rifiuta un’email non valida', async ({ page }) => {
  await page.goto('/signup');
  await page.getByLabel('Email').fill('indirizzo-non-valido');
  await page.getByRole('button', { name: 'Registrati' }).click();
  await expect(page.getByText('Inserisci un indirizzo email valido')).toBeVisible();
  await expect(page).toHaveScreenshot('signup-errore.png');
});

Il test fa due tipi di controllo. toBeVisible guarda il comportamento: compare il messaggio di errore? toHaveScreenshot guarda l’aspetto: la pagina viene confrontata pixel per pixel con l’immagine di riferimento nel repository. Secondo Playwright, il sistema operativo, la versione del browser e perfino l’hardware possono cambiare l’immagine; per questo genera l’immagine di riferimento nell’ambiente in cui girerà il test. Se vuoi confrontare la struttura della pagina tramite l’albero di accessibilità invece che con un’immagine, c’è toMatchAriaSnapshot.

Quando un test si rompe, lascia all’agente delle prove per capire perché. La configurazione qui sotto salva uno screenshot per ogni test fallito e una trace al primo nuovo tentativo in CI; nella trace puoi andare avanti e indietro e vedere che cosa è successo a ogni passo del test. I file finiscono nella cartella di output dei test, di solito test-results; di’ all’agente di guardare prima lì quando corregge l’errore.

// Esempio: configurazione che conserva le prove di un test fallito.
import { defineConfig } from '@playwright/test';

export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  use: {
    baseURL: 'http://localhost:3000',
    screenshot: 'only-on-failure',
    trace: 'on-first-retry',
  },
});

I controlli basati sugli screenshot servono ancora in questi casi: spostamenti di layout, errori di colore o di allineamento, un grafico o una mappa disegnati in un canvas. Anche la documentazione di Anthropic mette canvas, video incorporati e superfici di desktop remoto tra i punti che l’albero non vede. Per trovare un bug del genere basta che l’agente guardi una volta uno screenshot; perché non torni, fagli scrivere un test con toHaveScreenshot.

Quale via scegliere per ogni lavoro?

Tutti gli elementi portano allo stesso ordine: se puoi fare il lavoro con il codice, usa il codice; se la pagina è nel browser, l’albero; se non c’è altro accesso, lo schermo. Per i lavori più comuni:

Le ragioni delle schede sono qui sopra. Un test per verificare un’interfaccia web, perché il test gira in CI senza modello e ogni volta con gli stessi passi. Uno strumento del browser per un controllo una tantum, perché leggere l’albero di solito costa meno di uno screenshot e un riferimento non risente degli spostamenti di layout. Tieni computer use per le app che non hanno API, CLI né server MCP; anche GitHub lo presenta per questo tipo di app.

Per pagamenti, password e modifiche all’account, i tre provider dicono la stessa cosa: l’ultimo passo lo approvi una persona. Anthropic consiglia l’approvazione umana per decisioni come accettare i cookie, fare transazioni finanziarie o accettare i termini di servizio. OpenAI considera trasmissione di dati perfino scrivere informazioni sensibili in un modulo. Le istruzioni di esempio di Google chiedono al modello di non provare mai a risolvere un CAPTCHA. Fai girare l’agente in una macchina virtuale separata o con un profilo del browser separato, e limita i siti che può visitare con una allowlist. Come un testo in una pagina può guidare l’agente l’abbiamo spiegato nell’articolo sulla sicurezza di MCP.

diffox, uno strumento di code review con IA, legge la pull request con git; non apre l’interfaccia e non fa screenshot. Per questo il test che l’agente scrive per l’interfaccia serve a due cose nella pull request: la CI mostra che l’interfaccia funziona, e durante la review si può leggere nel diff che cosa verifica il test. Perché un test che passa non sempre verifica qualcosa l’abbiamo spiegato nell’articolo su come fare la review del codice scritto dall’IA.