Ano ang computer use, at bakit ito mahalaga? Simple ang ideya ng computer use ngunit malawak ang implikasyon nito: sa halip na hilingin sa mga modelo na sumagot ng mga tanong, hinihiling natin sa kanila na magpatakbo ng software—mag-navigate sa mga website, magsagot ng mga form, mag-click sa mga workflow, at awtonomong kumpletuhin ang mga gawain mula simula hanggang katapusan.
Binubuksan nito ang maraming uri ng gawain sa totoong mundo na kasalukuyang nahahati sa iba't ibang interface, gaya ng end-to-end na booking, e-commerce checkout, maraming-hakbang na pagpaplano ng biyahe, at mga back-office workflow na walang maayos na katumbas na API. Hindi bago ang mga problemang ito. Ang bago ay ang posibilidad na malutas ang mga ito gamit ang mga general-purpose na modelo.
Ipinakita ng mga kamakailang system mula sa Anthropic at OpenAI ang mga agent na hindi lang kumikilos, kundi nangangatuwiran din tungkol sa state, nakakabawi sa mga error, at agad na bumubuo ng solusyong angkop sa gawain. Ginagawa nitong pangkalahatang execution environment para sa mga agent ang browser, ngunit nagbubukas ito ng isang agarang tanong sa disenyo: gaano kalaking bahagi ng kapaligirang iyon ang dapat nating ilantad sa modelo?
Sinagot ito ng mga naunang system sa pamamagitan ng paglalagay sa browser sa loob ng isang nakapirming hanay ng ligtas at paunang itinakdang aksyon. Gaya ng ipaliliwanag namin sa post na ito, umaabot na sa limitasyon ang paraang iyon.
May karaniwang likas na tugon kapag gumagawa ng mga browser agent: huwag masyadong pagkatiwalaan ang modelo.
Kaya nilalagyan natin ng wrapper ang browser. Naglalantad tayo ng mga paunang itinakdang tool gaya ng click, type, scroll, select, at read_text. Pinasisimple natin ang Document Object Model (DOM). Binabawasan natin ang espasyo ng mga posibleng aksyon. Sinisikap nating gawing madaling maunawaan at kontrolin ang gawi sa pamamagitan ng mga abstraction na tayo ang nagdisenyo.
Makatuwiran itong panimulang punto. Ngunit lalo rin itong nagiging maling pangmatagalang arkitektura.
Habang humuhusay ang mga frontier na modelo, hindi na lang kakulangan ng mga tool ang limitasyon. Ang problema ay pinipilit natin itong gumana sa pamamagitan ng mga abstraction na nag-aalis ng napakaraming bahagi ng pinagbabatayang system. Isinisiksik natin ang isang magulo at pabago-bagong kapaligiran sa isang nakapirming interface ng mga aksyon, saka hinihiling sa modelo na gumana nang mahusay sa kabila ng nawalang impormasyon.
Lalo nang hindi sulit ang kompromisong iyon.
Madaling ilarawan ang pagbabagong sinusuri namin, ngunit malaki ang epekto nito. Sa halip na ituring ang agent bilang tagapili ng mga paunang itinakdang aksyon, itinuturing namin itong program synthesizer na gumagana sa loob ng isang kontroladong runtime.
Talagang humusay ang mga modelo, at hindi na nila kailangan ang mga abstract na guardrail mo—kailangan nila ang buong espasyo ng mga posibleng aksyon upang idisenyo, isagawa, at paulit-ulit na pinuhin ang gawain hanggang makamit nila ang layunin.
Tungkol ang post na ito sa pagbabagong iyon—mula sa browser automation na punô ng abstraction tungo sa kontroladong computer use—at sa mga pagbabagong dulot ng ganitong disenyo ng mga system.
Hindi ang pagiging mali ng konsepto ng mga nakapirming interface ng aksyon ang problema. Ang problema ay hindi umaayon sa mga ito ang web.
Ginagawa ang mga modernong interface gamit ang React, Vue, at Angular, na may mga asynchronous na update sa state, synthetic event system, at naka-embed na third-party widget na nasa mga cross-origin iframe at may sarili nilang lifecycle. Tama lang ang wrapper na nagsasabing “mag-type sa input na ito” kung tugma sa depinisyon mo ng pag-type ang page. Marami ang hindi tugma. Kapag direktang nagtakda ng value, madalas na ganap nitong nalalampasan ang change detection ng framework. Mukhang nasagutan ang input. Hindi kailanman nati-trigger ang validation. Hindi pa rin gumagana ang form.
Maaari mo itong i-patch. Maaari kang magdagdag ng mga espesyal na kaso para sa mga React input, mag-dispatch ng mga blur event pagkatapos ng focus, at hintaying maging idle ang network bago basahin ang state. Tama ang bawat patch para sa partikular nitong sitwasyon. Ngunit kapag pinagsama-sama, nagiging system ang mga ito na lalo pang mahirap i-maintain at lalo lamang angkop sa mga site na nakita mo na.
Ang mas malalim na problema ay ini-encode mo sa abstraction layer ang mga palagay kung paano dapat gumana ang mga interaksyon, bago matuklasang iba pala ang mga palagay ng web.
Isaalang-alang ang isang payment form na naka-embed sa pamamagitan ng Stripe o Adyen sa loob ng cross-origin iframe. Hindi ito direktang maaabot ng wrapper mo dahil nasa hiwalay na origin ito. Hindi maoobserbahan ng read_text tool mo ang internal state nito. Hindi maa-access ng type tool mo ang mga input nito. Dito na hindi makausad ang wrapper-based na agent. Idinisenyo ang abstraction para sa pangunahing dokumento. Nasa lugar na hindi nakikita ng abstraction ang aktuwal na gawain.
May katulad na hindi pagtutugma sa mga daloy na hindi gaanong halata. Maaaring hindi tumugon sa direktang pag-click ang isang dropdown na kontrolado ng framework dahil hindi ang nakikitang elemento ang aktuwal na control. Maaaring mangailangan ito ng sunod-sunod na keyboard event upang ma-trigger ang pinagbabatayang pagbabago ng state. Mula sa labas, mukhang maaaring i-click ang UI. Sinasabi ng abstraction na “i-click.” Walang nangyayari.
O isaalang-alang ang isang maraming-hakbang na modal flow kung saan nahuhuli ang mga update sa nakikitang DOM kumpara sa mga pagbabago sa internal state. Nakadepende ang tamang susunod na aksyon sa isang pagbabago ng state na hindi pa nakikita sa mga elementong naaabot ng wrapper mo. Nauuwi ang wrapper-based na agent sa pagkilos nang masyadong maaga o pagbabasa ng lumang state dahil hindi kumpleto ang pagtingin nito sa system.
Sa bawat kaso, itinatago ng abstraction ang mga signal na talagang kailangan ng agent.
Kayang pangasiwaan ng modelong gumagana sa mas mababang antas—sinusuri ang live DOM, nangangatuwiran tungkol sa mga hangganan ng frame, at bumubuo ng pagkakasunod-sunod ng interaksyon para sa partikular na surface—ang mga sitwasyong ito. Hindi ito dahil likas na mas matalino ang modelo. May access lang ito sa impormasyong dating inalis.
Madaling ilarawan ang pagbabagong pinagsisikapan namin: sa halip na hilingin sa modelo na pumili mula sa mga paunang itinakdang aksyon, binibigyan namin ito ng mas mababang antas na execution surface at kinokontrol iyon sa pamamagitan ng patakaran sa runtime, hindi ng disenyo ng abstraction.
Nagmula ang desisyong ito sa mas malawak na pagbabago sa industriya na nagsisimulang pumabor sa mas mababang antas na mga primitive tool—mga tool na sinasamantala ang likas na kakayahan ng agent na magwasto habang tumatakbo at gumawa ng de-kalidad na code, sa halip na mga matatag ngunit hard-coded na espesyal na tool na nag-aalis sa kakayahan ng modelo na umangkop sa iba't ibang kapaligiran.
Isaalang-alang ang tagumpay ng Claude Code bilang pangunahing pagpipilian sa mga toolbox ng maraming developer, at ang mas malawak na paglipat ng industriya sa mga terminal-based na agent. Hindi ang modelo mismo ang pinakamalaking bentahe ng Claude Code, kundi ang mas mababang antas na harness. Ang pagbibigay sa modelo ng mas kaunti, mas modular, at mas mababang antas na mga tool—ibig sabihin, ang terminal—ay nagdudulot ng mas mahusay na performance sa pagtawag ng tool, lalo na dahil makakapangatuwiran ang agent at makakagawa ng mga custom na script para sa kasalukuyang gawain, sa halip na subukang gumamit ng mga generalized na tool na nagpapasikip sa context window.
Sa praktika ng browser automation, nangangahulugan itong direktang masusuri ng modelo ang live state ng page, makakatawid sa mga frame, at makakabuo ng natatanging interaction code para sa kasalukuyang interface, sa halip na itugma ang lahat sa nakapirming hanay ng mga dati nang ginawang aksyon.
Mas kumikilos ang modelo bilang tagalikha ng runtime kaysa bilang tagapili. Sinusuri nito ang kasalukuyang state, nangangatuwiran tungkol sa interface, at binubuo ang lohika ng interaksyon para sa partikular na sitwasyon. Makakabuo ito ng mga maraming-hakbang na pagkakasunod-sunod, makakaangkop sa mga kakaibang daloy, at makakapag-validate ng mga resulta bago magpatuloy. Kapag pumalya ang isang aksyon, nakikita ng modelo ang pinagbabatayang error at itinatama ang sarili. Mas mahusay at mas mapanganib ito—ngunit mas malapit ito sa tunay na anyo ng problema.
Mahalaga ring tandaan na hindi nababawasan ang disiplina ng system kapag inalis ang abstraction layer. Inililipat lamang nito ang disiplina.
Ang gawaing dating nasa disenyo ng wrapper at paghawak ng mga pambihirang sitwasyon ay inililipat sa tatlong lugar: sa prompt (na nagiging isang uri ng operational training), sa runtime (na nagpapatupad ng mga hangganan gaya ng saklaw ng navigation, mga sensitibong aksyon, at gawi sa muling pagsubok), at sa evaluation layer (na sumusuri hindi lang kung nagtagumpay ang gawain, kundi kung tama rin ang mga hakbang sa gitna). Mas kaunting marurupok na abstraction. Mas matatag na mga nakapaligid na system.
Isang resulta ng pagbabagong ito ang madalas na pag-simple ng code ng produkto habang nagiging mas mahusay ang buong system. Sa halip na i-encode ang mga pattern ng interaksyon bilang reusable wrapper, binubuo ng agent ang gawi habang tumatakbo ito. Nagpapanatili ka ng maliit na hanay ng mahuhusay na primitive at isang kontroladong execution environment, sa halip na patuloy na palawakin ang mga espesyal na tool at lohika para sa mga pambihirang sitwasyon.
Binabago rin nito kung paano nagge-generalize ang system. Mahusay mag-generalize ang wrapper-based na agent sa mga gawaing kahawig ng mga wrapper na nagawa mo na. Nagge-generalize ang agent na may kontroladong runtime sa mga gawaing gumagamit ng iisang execution substrate, kahit magkaiba ang nakikitang interface.
Halimbawa, maaaring ganap na magkakaiba sa antas ng UI ang paggamit ng search form, proseso ng booking, o page ng mga setting. Ngunit sa ilalim nito, magkakapareho ang kanilang mga pattern: pagbabasa ng state, pag-trigger ng mga event, pag-validate ng mga resulta, at paghawak ng mga asynchronous na update. Mas natural na naililipat sa iba't ibang gawain ang isang system na gumagana sa antas na iyon.
Hindi ang listahan ng mga aksyon ang reusable na bahagi. Ito ang kakayahan ng modelo na suriin ang state, kumilos nang ligtas, at i-verify ang mga resulta.
Ang pinakamalinaw na aral mula sa gawaing ito ay hindi nagmumula ang pagiging maaasahan sa pagbibigay sa modelo ng mas maraming helper function. Madalas itong nagmumula sa pagbibigay rito ng mas kaunti ngunit mas mahuhusay na primitive, at sa wastong pagkontrol sa mga iyon. Kapag sobra ang tulong, permanenteng nai-encode ang mga palagay kung paano dapat gawin ang isang gawain. Tinutukoy ng mga limitasyon ang ligtas na saklaw ng operasyon at hinahayaan ang modelo na tumuklas ng mas mahuhusay na solusyon para sa bawat sitwasyon.
Nangangailangan din ng mas mahigpit na modelo ng kaligtasan ang mas mahusay na execution surface. Kapag hindi na limitado ang agent sa maliit na hanay ng mga paunang itinakdang aksyon, epektibo na itong direktang nagpapatakbo ng tunay na software. Agad nitong binabago ang risk profile.
May apat na usaping dapat isaalang-alang sa pagdisenyo:
Pagkakalantad ng data. Kung nakikipag-ugnayan ang agent sa mga tunay na interface, madalas itong makakakita ng sensitibong impormasyon. Nangangailangan ito ng disiplinadong pamamaraan sa masking at access control. Dapat lang ilantad ang data kapag kailangan sa pagpapatakbo, at dapat maingat na pangasiwaan ang mga log at trace upang hindi maging pinakasensitibong bahagi ng system ang observability.
Saklaw ng pagpapatakbo. Hindi dapat makakilos nang walang limitasyon ang isang mahusay na agent. Sa praktika, nangangahulugan itong kontrolado kung saan ito makakapunta, aling mga domain ang maa-access nito, at aling mga system ang maaari nitong gamitin. Dapat ipatupad ang mga limitasyong ito sa antas ng runtime, at hindi iasa sa mga kumbensiyon sa pag-prompt.
Pagkakatiwala sa kapaligiran. Maaaring may mga tagubilin, content, o daloy ang mga modernong interface na mapanlinlang o sadyang mapaminsala. Ang prompt injection sa pamamagitan ng content ng page ay isang tunay na attack surface. Kailangan ng system ng malinaw na hierarchy ng mga tagubilin, validation check, at kondisyon sa paghinto upang hindi sundin ng agent ang hindi nilalayong gabay.
Saklaw ng awtonomiya. Hindi lahat ng aksyon ay dapat ganap na awtonomo. Sa maraming production setting, mahalagang ituring ang awtonomiya bilang isang saklaw. Maaaring maging lubos na agentic ang system sa paggalugad at pagpapatakbo, habang nangangailangan pa rin ng pag-apruba para sa ilang uri ng aksyon.
Simple ang batayang prinsipyo: kapag binigyan ng higit na kapangyarihan ang modelo, kailangang patatagin din ang nakapaligid na system. Hindi handa para sa production ang awtonomiyang walang patakaran.
Hindi na namin itinatanong: alin ang mga tamang aksyon sa browser na dapat ilantad?
Sa halip, tinanong namin: paano natin mabibigyan ang modelo ng buong espasyo ng mga posibleng aksyon—at paano tayo gagawa ng mga patakaran sa runtime na mapananatili itong ligtas?
Binabago ng pananaw na iyon ang mga bagay na mahalaga sa iyo. Hindi na gaanong mahalaga ang mga taxonomy ng aksyon at pagiging kumpleto ng wrapper. Mas mahalaga na ang patakaran sa runtime, observability, at pagsusuri sa bawat hakbang. Hindi maaaring maghalinhinan ang kakayahan ng modelo at disenyo ng system. Habang humuhusay ang mga modelo, lalong nagiging mahalaga ang gawain ng system, hindi mas kaunti.
Madalas nagtatagumpay sa mga demo ang mga browser agent dahil makitid ang saklaw ng gawain at nakikipagtulungan ang kapaligiran. Iba ang kailangan ng mga production system: kontroladong pagpapatakbo, nasusubaybayang gawi, at pagsusuring kayang tukuyin ang kaibahan ng tamang resulta sa tsambang resulta.
Mas kaunting pagdisenyo ng wrapper. Mas maraming systems engineering.
At bagama't nakatuon kami sa mga browser agent, ipinapakita nito ang mas malawak na paraan ng pagtingin sa computer use bilang isang disiplina ng systems engineering.