Què és l'ús d'ordinadors i per què és important? L'ús d'ordinadors és una idea senzilla amb implicacions àmplies: en lloc de demanar als models que responguin preguntes, els demanem que facin servir programari —navegant per llocs web, emplenant formularis, avançant per fluxos de treball i completant tasques de principi a fi de manera autònoma.
Això fa possible una gran varietat de tasques del món real que actualment estan fragmentades entre diverses interfícies, com ara reserves de principi a fi, processos de compra electrònica, planificació de viatges en diversos passos i fluxos administratius sense cap API equivalent adequada. Aquests problemes no són nous. La novetat és que ara és viable resoldre'ls amb models d'ús general.
Sistemes recents d'Anthropic i OpenAI han demostrat que els agents no només actuen, sinó que també raonen sobre l'estat, es recuperen dels errors i creen sobre la marxa solucions específiques per a cada tasca. Això converteix el navegador en un entorn d'execució general per als agents, però planteja immediatament una qüestió de disseny: quina part d'aquest entorn hauríem d'exposar al model?
Els primers sistemes hi van respondre encapsulant el navegador en un conjunt fix d'accions segures i predefinides. Com argumentarem en aquest article, aquest enfocament està arribant al límit.
Quan es creen agents per a navegadors, hi ha un instint habitual: no confiar massa en el model.
Per això encapsulem el navegador. Exposem eines predefinides com click, type, scroll, select i read_text. Simplifiquem el model d'objectes del document (DOM). Reduïm l'espai d'accions. Intentem que el comportament sigui comprensible i controlable mitjançant abstraccions dissenyades per nosaltres.
És un punt de partida raonable. Però, cada cop més, també és l'arquitectura equivocada a llarg termini.
A mesura que milloren els models d'avantguarda, la limitació ja no és només que al model li faltin eines. És que l'obliguem a operar mitjançant abstraccions que eliminen massa informació del sistema subjacent. Comprimim un entorn caòtic i dinàmic en una interfície d'accions fixa i, després, demanem al model que funcioni bé malgrat aquesta pèrdua d'informació.
Aquesta contrapartida és cada cop menys atractiva.
El canvi que hem estat explorant és fàcil de descriure, però té conseqüències importants. En lloc de tractar l'agent com un selector d'accions predefinides, el tractem com un sintetitzador de programes que opera dins d'un entorn d'execució restringit.
Els models han esdevingut realment bons i ja no necessiten les vostres barreres de protecció abstractes: necessiten tot l'espai d'accions per dissenyar, executar i iterar la tasca fins que assoleixin l'objectiu.
Aquest article tracta d'aquest canvi, de l'automatització de navegadors carregada d'abstraccions a l'ús restringit d'ordinadors, i de què canvia quan els sistemes es dissenyen així.
El problema no és que les interfícies d'accions fixes siguin conceptualment incorrectes. És que el web no s'hi adapta.
Les interfícies modernes es creen amb React, Vue i Angular, amb actualitzacions d'estat asíncrones, sistemes d'esdeveniments sintètics i ginys de tercers incrustats que viuen en iframes d'origen creuat amb cicles de vida propis. Un embolcall que diu "escriu en aquest camp" només és correcte si la pàgina coincideix amb la vostra definició d'escriure. Moltes no hi coincideixen. Assignar directament un valor sovint eludeix del tot la detecció de canvis del framework. El camp sembla emplenat. La validació no s'activa mai. El formulari continua sense funcionar.
Podeu aplicar-hi un pedaç. Podeu afegir casos especials per als camps de React, emetre esdeveniments blur després de focus i esperar que la xarxa quedi inactiva abans de llegir l'estat. Cada pedaç és correcte en el seu cas concret. En conjunt, s'acumulen fins a formar un sistema cada cop més difícil de mantenir i més específic per als llocs que ja heu trobat.
El problema de fons és que codifiqueu a la capa d'abstracció supòsits sobre com haurien de funcionar les interaccions i, després, descobriu que el web parteix d'uns altres supòsits.
Penseu en un formulari de pagament de Stripe o Adyen incrustat en un iframe d'origen creuat. L'embolcall no hi pot accedir directament perquè es troba en un origen diferent. L'eina read_text no en pot observar l'estat intern. L'eina type no pot accedir als seus camps. Aquí, un agent basat en embolcalls topa amb un mur. L'abstracció es va dissenyar per al document principal. La tasca real es troba en un lloc que l'abstracció no pot veure.
En fluxos menys evidents apareix un desajust semblant. És possible que un menú desplegable controlat per un framework no respongui gens als clics directes, perquè l'element visible no és el control real. Pot requerir una seqüència d'esdeveniments de teclat per activar la transició d'estat subjacent. Des de fora, sembla que es pugui fer clic a la interfície. L'abstracció diu "fes clic". No passa res.
O penseu en un flux modal de diversos passos en què les actualitzacions del DOM visible van endarrerides respecte dels canvis de l'estat intern. La següent acció correcta depèn d'una transició d'estat que encara no es reflecteix en els elements que l'embolcall pot veure. Un agent basat en embolcalls acaba actuant massa aviat o llegint un estat obsolet, perquè opera amb una visió incompleta del sistema.
En cada cas, l'abstracció amaga els senyals que l'agent necessita realment.
Un model que opera a un nivell inferior —inspeccionant el DOM actiu, raonant sobre els límits dels marcs i sintetitzant la seqüència d'interacció per a aquella superfície concreta— pot superar aquestes situacions. No és que el model sigui intrínsecament més intel·ligent. És que té accés a la informació que s'havia eliminat.
El canvi que perseguim és fàcil de descriure: en lloc de demanar al model que seleccioni accions predefinides, li oferim una superfície d'execució de nivell inferior i la restringim mitjançant polítiques d'execució, no pas amb el disseny de l'abstracció.
Aquesta decisió de disseny prové d'un canvi més general del sector, que comença a afavorir eines primitives de nivell inferior. Aquestes aprofiten la capacitat inherent de l'agent per corregir-se en temps d'execució i produir codi d'alta qualitat, en lloc d'eines específiques i rígides que són robustes però priven el model de la capacitat d'adaptar-se a entorns diferents.
Penseu en l'èxit de Claude Code com a opció principal en les caixes d'eines de molts desenvolupadors i en el moviment general del sector cap als agents basats en terminals. El principal avantatge de Claude Code no és el model en si, sinó l'entorn d'execució de nivell inferior. Donar al model menys eines, però més modulars i de nivell inferior, és a dir, el terminal, millora el rendiment en les crides a eines, sobretot perquè l'agent pot raonar i crear scripts a mida per a la tasca concreta, en lloc d'intentar utilitzar eines generalitzades que saturen la finestra de context.
En el cas pràctic de l'automatització del navegador, això vol dir que el model pot inspeccionar directament l'estat actiu de la pàgina, recórrer els marcs i crear codi d'interacció a mida per a la interfície actual, en lloc de fer correspondre cada element amb un conjunt fix d'accions predefinides.
El model es comporta menys com un selector i més com un autor en temps d'execució. Inspecciona l'estat actual, raona sobre la interfície i sintetitza la lògica d'interacció per a aquella situació concreta. Pot crear seqüències de diversos passos, adaptar-se a fluxos poc habituals i validar els resultats abans de continuar. Quan una acció falla, el model veu l'error subjacent i s'autocorregeix. Això és més potent i més arriscat, però s'ajusta molt més a la naturalesa real del problema.
És important destacar que eliminar la capa d'abstracció no fa que el sistema sigui menys rigorós. Trasllada el rigor a un altre lloc.
La feina que abans es feia en el disseny dels embolcalls i la gestió dels casos límit es trasllada a tres llocs: la indicació, que esdevé una forma de formació operativa; l'entorn d'execució, que imposa límits com l'abast de navegació, les accions sensibles i el comportament dels reintents; i la capa d'avaluació, que no només determina si la tasca ha reeixit, sinó també si els passos intermedis han estat correctes. Menys abstraccions fràgils. Sistemes de suport més sòlids.
Un dels resultats d'aquest canvi és que el codi del producte sovint esdevé més senzill, tot i que el sistema en conjunt guanya capacitats. En lloc de codificar patrons d'interacció com a embolcalls reutilitzables, l'agent sintetitza el comportament en temps d'execució. Manteniu un conjunt reduït de primitives potents i un entorn d'execució restringit, en lloc d'una gamma creixent d'eines especialitzades i lògica per a casos límit.
Això també canvia la manera com el sistema generalitza. Un agent basat en embolcalls generalitza bé en tasques semblants a aquelles per a les quals ja heu creat embolcalls. Un agent amb un entorn d'execució restringit generalitza en tasques que comparteixen una infraestructura d'execució, encara que la interfície visible sigui diferent.
Per exemple, interactuar amb un formulari de cerca, un procés de reserva o una pàgina de configuració pot semblar completament diferent pel que fa a la interfície d'usuari. Però, per sota, comparteixen patrons: llegir l'estat, activar esdeveniments, validar resultats i gestionar actualitzacions asíncrones. Un sistema que opera en aquest nivell es transfereix de manera més natural entre tasques.
El component reutilitzable no és la llista d'accions, sinó la capacitat del model per inspeccionar l'estat, actuar amb seguretat i verificar els resultats.
La lliçó més clara d'aquest treball és que la fiabilitat no s'obté donant més funcions auxiliars al model. Sovint s'obté proporcionant-li menys primitives, però més potents, i restringint-les de la manera adequada. L'assistència excessiva codifica de manera rígida supòsits sobre com s'ha de fer una tasca. Les restriccions defineixen límits operatius segurs i permeten que el model trobi solucions locals millors.
Una superfície d'execució més potent també requereix un model de seguretat més rigorós. Quan l'agent deixa d'estar limitat a un conjunt reduït d'accions predefinides, a la pràctica passa a operar directament sobre programari real. Això canvia immediatament el perfil de risc.
Cal dissenyar el sistema tenint en compte quatre aspectes:
Exposició de dades. Si l'agent interactua amb interfícies reals, sovint trobarà informació sensible. Això exigeix un enfocament rigorós de l'emmascarament i el control d'accés. Les dades només s'han de revelar quan siguin necessàries per a l'execució, i els registres i les traces s'han de gestionar amb cura perquè l'observabilitat no esdevingui la part més sensible del sistema.
Abast de l'execució. Un agent potent no ha de poder operar arbitràriament. A la pràctica, això vol dir restringir per on pot navegar, a quins dominis pot accedir i amb quins sistemes pot interactuar. Aquestes restriccions s'han d'aplicar en l'entorn d'execució, no deixar-les com a simples convencions de les indicacions.
Confiança en l'entorn. Les interfícies modernes poden incloure instruccions, contingut o fluxos enganyosos o activament hostils. La injecció d'indicacions mitjançant el contingut de la pàgina és una superfície d'atac real. El sistema necessita una jerarquia clara d'instruccions, comprovacions de validació i condicions de finalització per evitar que l'agent segueixi indicacions no desitjades.
Espectre d'autonomia. No totes les accions han de ser completament autònomes. En molts entorns de producció, és important tractar l'autonomia com un espectre. El sistema pot actuar amb molta iniciativa en explorar i executar, però continuar exigint aprovació per a determinades categories d'accions.
El principi subjacent és senzill: donar més poder al model exigeix reforçar el sistema que l'envolta. L'autonomia sense polítiques no està preparada per a la producció.
Vam deixar de preguntar-nos: quines accions del navegador hauríem d'exposar?
Vam començar a preguntar-nos: com podem oferir al model tot l'espai d'accions i crear al seu voltant polítiques d'execució que continuïn garantint-ne la seguretat?
Aquest replantejament canvia les prioritats. Les taxonomies d'accions i l'exhaustivitat dels embolcalls perden importància. Les polítiques d'execució, l'observabilitat i l'avaluació de cada pas en guanyen. La capacitat del model i el disseny del sistema no se substitueixen mútuament. A mesura que milloren els models, la tasca del sistema esdevé més important, no pas menys.
Els agents de navegador que funcionen en demostracions sovint tenen èxit perquè la tasca és acotada i l'entorn hi col·labora. Els sistemes de producció requereixen una altra cosa: execució restringida, comportament instrumentat i una avaluació capaç de distingir un resultat correcte d'un d'afortunat.
Menys disseny d'embolcalls. Més enginyeria de sistemes.
I, tot i que ens hem centrat en els agents de navegador, això apunta a una manera més àmplia d'entendre l'ús d'ordinadors com una disciplina de sistemes.