Ce este Computer Use și Ce sunt Browser Agents

Un agent care execută corect fiecare pas în 95% din cazuri pare aproape de perfecțiune — până când afli că, pe o sarcină de douăzeci de pași, reușește de la un capăt la altul în doar aproximativ 36% din încercări. Aceasta este matematica brutală a agenților care operează un calculator ca un om: percep ecranul, decid o acțiune motrică (un click, o tastare, un scroll), o execută și reiau bucla — iar fiecare pas adaugă o probabilitate de eroare care se compune. Promisiunea este seducătoare: un agent care face orice poate face un om într-o interfață grafică, iar browser agents duc aceeași idee în fereastra browserului. Onestitatea profesională cere însă să spunem din prima propoziție tema care va însoți întreg cursul: acești agenți nu sunt deterministici și nu sunt fiabili la nivel de producție fără măsuri suplimentare de robustețe.

Definiția riguroasă a paradigmei

Un sistem de tip computer use este un agent care operează un calculator în același mod în care l-ar opera un om: privind interfața grafică și acționând asupra ei. Spre deosebire de un program clasic care apelează direct o funcție sau un endpoint, agentul de computer use nu are acces privilegiat la logica internă a aplicației. El vede exact ceea ce vede un utilizator uman — pixeli pe un ecran — și interacționează exact prin canalele unui utilizator uman — cursorul și tastatura.

Mecanismul de fond este o buclă percepție–decizie–acțiune (uneori numită bucla agentică sau loop de tip ReAct), pe care o putem descompune astfel:

1. Percepție. Sistemului i se furnizează o reprezentare a stării curente a ecranului. În practică, aceasta este fie o captură de ecran (screenshot, deci o imagine), fie o reprezentare structurată a interfeței (de exemplu arborele DOM al unei pagini web sau arborele de accesibilitate al unei aplicații), fie o combinație a celor două.
2. Decizie. Modelul, având obiectivul formulat în limbaj natural și starea curentă, raționează asupra următoarei acțiuni utile. Rezultatul deciziei este o intenție concretă: „dă click pe butonul Trimite", „scrie textul X în câmpul de email", „derulează pagina în jos".
3. Acțiune. Intenția este tradusă într-o comandă executabilă de un strat de orchestrare care controlează efectiv mausul și tastatura: o mișcare de cursor la coordonatele (x, y), un click, o secvență de taste, o apăsare de Enter, un scroll.
4. Re-observare. După executarea acțiunii, sistemul capturează din nou starea ecranului și reia bucla. Iterația continuă până când obiectivul este îndeplinit, până când agentul declară că s-a blocat, sau până când se atinge o limită de pași (un buget de turnuri) impusă din exterior.

Ceea ce face paradigma puternică este universalitatea ei: dacă un om poate face o sarcină dintr-o interfață grafică, atunci, în principiu, un agent de computer use poate încerca aceeași sarcină, indiferent dacă aplicația respectivă oferă sau nu o cale programatică de acces. Ceea ce o face fragilă este exact aceeași universalitate: agentul lucrează cu pixeli și coordonate, nu cu garanții, iar fiecare pas introduce o probabilitate de eroare care se compune de-a lungul buclei.

Computer use vs. browser agents: granița esențială

Termenii se suprapun adesea în vorbirea curentă, dar distincția lor tehnică este reală și are consecințe practice. O reținem cel mai bine prin domeniul de operare.

Ideea de reținut: computer use este categoria largă — agentul controlează un calculator întreg, la nivelul sistemului de operare, putând opera o aplicație desktop legacy, un client de email instalat local sau un terminal. Browser agents reprezintă specializarea pe browser — agentul rămâne în interiorul browserului, dar câștigă acces la structura paginii (DOM, atribute, roluri de accesibilitate), ceea ce îi permite, frecvent, să fie mai precis și mai ieftin decât un agent care raționează exclusiv din pixeli.

Un browser agent care lucrează cu DOM-ul nu trebuie să ghicească unde se află butonul „Adaugă în coș" pe baza imaginii; el poate identifica elementul după rolul, textul sau atributele lui și poate emite o acțiune țintită pe acel element. Un agent de computer use generic, care vede doar o imagine a întregului ecran, trebuie să localizeze vizual ținta și să producă coordonate — o sarcină mai dificilă și mai predispusă la erori, mai ales la rezoluții și scalări diferite.

Sursele reale ale paradigmei în 2026

Pentru a evita orice confuzie, ancorăm definițiile în implementări și resurse verificabile.

Tool-ul computer use de la Anthropic

Anthropic oferă un instrument dedicat de tip computer use, documentat pe platforma oficială (platform.claude.com/docs, secțiunea agents-and-tools/tool-use/computer-use-tool). Acesta permite modelelor Claude — în 2026, familia Opus 4.8 și 4.7, alături de Sonnet 4.6 — să primească o captură de ecran și să returneze acțiuni de tip click, tastare, scroll și mișcare de cursor. Capabilitatea este oferită în regim beta, semnalizată printr-un antet de cerere (beta header) cu valoarea computer-use-2025-11-24. Faptul că este beta și că versiunea este datată nu este un detaliu cosmetic: el spune explicit că instrumentul evoluează, că semnătura acțiunilor și comportamentul se pot schimbă între versiuni și că orice integrare trebuie să fixeze versiunea pe care a testat-o.

Important de subliniat: tool-ul în sine nu „mișcă" mausul. Modelul propune acțiuni; un strat de execuție din afara modelului (rulat de tine, dezvoltatorul) le transpune în comenzi reale într-un mediu controlat — de regulă o mașină virtuală sau un container izolat. Aceasta este o distincție de siguranță fundamentală la care revenim în modulele următoare.

Biblioteca open-source browser-use

Pe versantul browser agents, proiectul open-source browser-use (github.com/browser-use/browser-use) este una dintre cele mai folosite biblioteci. Caracteristicile relevante:

• Este licențiat MIT, deci permisiv pentru utilizare comercială.
• Este model-agnostic: nu te leagă de un singur furnizor. Poți conecta modele de la furnizori diferiți — Claude, GPT-5.5 sau Gemini 3.1 Pro — în spatele aceleiași bucle de agent.
• Operează la nivel de browser, exploatând structura paginii, ceea ce îl plasează clar în categoria browser agents.

Caracterul model-agnostic ilustrează un principiu de arhitectură sănătoasă: bucla agentică (percepție, decizie, acțiune) este separată de creierul care ia deciziile, astfel încât poți schimbă modelul fără a rescrie întreaga orchestrare.

Tool-ul CUA al OpenAI și nota istorică despre Operator

OpenAI oferă o capabilitate de tip computer use (denumită CUA — Computer-Using Agent) integrată în produsul ChatGPT Agent. Aceasta urmează aceeași logică: agentul vede ecranul, decide, acționează.

O singură precizare istorică, necesară pentru igienă factuală: produsul standalone OpenAI Operator a fost închis pe 31 august 2025 și absorbit în ChatGPT Agent împreună cu tool-ul CUA. Îl menționăm aici exclusiv ca reper istoric. Nu îl trata și nu îl prezenta ca pe un produs viu, utilizabil de sine stătător — orice astfel de prezentare ar fi greșită. Capabilitatea există, dar sub forma actuală, integrată.

Benchmark-ul OSWorld

Pentru a măsura cât de bine se descurcă acești agenți, comunitatea folosește benchmark-uri dedicate. Cel mai relevant pentru computer use este OSWorld (os-world.github.io), un set de evaluare construit pe 369 de sarcini reale executate în medii Ubuntu autentice (benchmark-ul include și un set separat de 43 de sarcini pe Windows). Sarcinile nu sunt jucării: ele implică operarea de aplicații reale (suite office, browsere, unelte de sistem) și verificarea automată a faptului că obiectivul a fost atins.

De ce contează un benchmark precum OSWorld? Pentru că oferă o măsură onestă a distanței dintre demonstrația impresionantă și fiabilitatea de producție. Pe sarcini realiste de sistem de operare, ratele de succes ale agenților rămân, în 2026, departe de nivelul uman. Această realitate empirică ne aduce direct la tema centrală a cursului.

Tema centrală: fiabilitatea și non-determinismul

Promisiunea computer use — un agent care face orice poate face un om într-o interfață — este seducătoare. Onestitatea profesională cere însă să spunem clar limita: acești agenți nu sunt deterministici și nu sunt fiabili la nivel de producție fără măsuri suplimentare de robustețe.

Sursele non-determinismului sunt multiple:

• Modelul însuși este probabilistic. La aceeași stare a ecranului, modelul poate alege acțiuni diferite la rulări diferite. Chiar și la temperatură zero, schimbări minore în context (o reformulare, un pixel diferit) pot devia traiectoria.
• Eroarea se compune pe buclă. Dacă fiecare pas are o probabilitate de reușită p, atunci o sarcină de n pași are o probabilitate aproximativă de succes care scade exponențial. O sarcină corectă în 95% din pași dar care necesită 20 de pași reușește global în aproximativ 0,95^20 ≈ 36% din cazuri. Acesta este motivul matematic pentru care sarcinile lungi sunt fragile.
• Mediul se schimbă. Interfețele se actualizează, apar ferestre de tip pop-up, dialoguri de cookie, reclame, întârzieri de încărcare. O acțiune corectă ieri poate eșua azi pentru că butonul s-a mutat cu câțiva pixeli.

Concluzia practică nu este descurajarea, ci proiectarea responsabilă. De la prima lecție stabilim un principiu pe care îl vom respecta în tot cursul: nu promitem automatizare perfectă. Construim agenți cu verificări, cu pași de validare, cu limite de buget, cu posibilitatea de a cere intervenție umană (human-in-the-loop) și cu monitorizare. Fiabilitatea nu este o trăsătură pe care o primești gratuit din model; este o proprietate pe care o inginerești în jurul lui.

Un exemplu conceptual de buclă

Pentru a fixa mecanismul, iată o schiță în pseudocod a buclei agentice, neutră față de furnizor. Nu este cod de producție, ci o ilustrare a structurii pe care o vom rafina în modulele tehnice.

def agent_loop(obiectiv, mediu, model, max_pasi=25):
    istoric = []
    for pas in range(max_pasi):
        # 1. Percepție: capturăm starea ecranului
        observatie = mediu.captureaza_ecran()  # imagine si/sau DOM

        # 2. Decizie: modelul propune o actiune
        decizie = model.urmatoarea_actiune(
            obiectiv=obiectiv,
            observatie=observatie,
            istoric=istoric,
        )

        if decizie.tip == "FINALIZAT":
            return decizie.rezultat  # agentul declara succes

        if decizie.tip == "BLOCAT":
            return cere_interventie_umana(decizie.motiv)

        # 3. Acțiune: stratul de executie aplica actiunea in mediul izolat
        rezultat = mediu.executa(decizie.actiune)  # click, tastare, scroll...

        # 4. Re-observare implicita la urmatoarea iteratie
        istoric.append((decizie, rezultat))

    return "Esec: buget de pasi epuizat fără a atinge obiectivul"

Observă trei elemente de robustețe încastrate deja în schiță: limita de pași (max_pasi), ieșirea explicită prin cerere de intervenție umană (BLOCAT) și păstrarea unui istoric care permite modelului să nu repete la nesfârșit aceeași acțiune eșuată. Acestea sunt rudimentele unei proiectări responsabile.

Ce NU este computer use (delimitări)

Pentru a evita confuziile cu alte teme:

• Nu este simpla apelare a unui API. Dacă aplicația oferă un endpoint, calea directă este aproape întotdeauna preferabilă (subiectul lecției următoare).
• Nu este automatizarea no-code clasică în care presupui că un API există deja și doar îl conectezi.
• Nu este arhitectura generală de agenți LLM cu unelte arbitrare; aici unealta specifică este controlul ecranului.

Computer use intervine tocmai în zona rămasă neacoperită de aceste abordări: când nu există API, când aplicația este legacy sau desktop, când singura interfață disponibilă este cea grafică.

Recapitulare

Ai acum harta paradigmei: computer use ca agent care percepe ecranul, decide o acțiune motrică și o execută în buclă; browser agents ca specializarea pe browser, frecvent mai precisă datorită accesului la DOM; sursele reale care o ancorează în 2026 — tool-ul computer use de la Anthropic (beta, antet computer-use-2025-11-24), biblioteca open-source browser-use (MIT, model-agnostică), tool-ul CUA al OpenAI integrat în ChatGPT Agent și benchmark-ul OSWorld (369 de sarcini reale); și tema care va însoți tot cursul — fiabilitatea și non-determinismul. Dar a ști că un agent poate opera orice interfață nu îți spune încă când merită să-l pui la treabă. Lecția următoare începe exact cu întrebarea pe care orice inginer serios și-o pune înaintea primului agent: dacă aplicația oferă un API, de ce ai controla-o prin pixeli? De acolo construim, pas cu pas, robustețea pe care modelul, singur, nu ți-o dă gratuit.