Co je ovládání počítače a proč je důležité? Ovládání počítače je jednoduchá myšlenka s dalekosáhlými důsledky: místo toho, abychom po modelech chtěli odpovídat na otázky, je necháme autonomně ovládat software – procházet weby, vyplňovat formuláře, postupovat pracovními postupy a plnit úlohy od začátku do konce.
Tím se otevírá široká škála reálných úloh, které jsou dnes roztříštěné mezi různá rozhraní: kompletní rezervace, dokončení nákupu v e-shopu, vícekrokové plánování cest nebo interní administrativní postupy bez vhodné obdoby v podobě API. Nejde o nové problémy. Nová je možnost řešit je pomocí univerzálních modelů.
Nedávné systémy společností Anthropic a OpenAI ukázaly agenty, kteří nejen jednají, ale také uvažují o stavu, zotavují se z chyb a za běhu vytvářejí řešení pro konkrétní úlohy. Prohlížeč se tak pro agenty stává univerzálním prostředím pro provádění úloh. Ihned však vyvstává otázka návrhu: jak velkou část tohoto prostředí máme modelu zpřístupnit?
První systémy na ni odpověděly zapouzdřením prohlížeče do pevné sady bezpečných, předem definovaných akcí. Jak ukážeme v tomto článku, tento přístup naráží na své limity.
Při tvorbě agentů pro prohlížeče se běžně řídíme instinktem: modelu příliš nedůvěřovat.
Proto prohlížeč zapouzdřujeme. Zpřístupňujeme předem definované nástroje jako click, type, scroll, select a read_text. Zjednodušujeme objektový model dokumentu (DOM). Omezujeme prostor možných akcí. Pomocí vlastních abstrakcí se snažíme učinit chování srozumitelným a ovladatelným.
Pro začátek je to rozumné. Z dlouhodobého hlediska je to však stále častěji nesprávná architektura.
S tím, jak se průkopnické modely zlepšují, už omezení nespočívá jen v tom, že model nemá dostatek nástrojů. Problém spočívá v tom, že ho nutíme pracovat prostřednictvím abstrakcí, které skrývají příliš mnoho z podkladového systému. Neuspořádané a dynamické prostředí zhušťujeme do pevného rozhraní akcí a poté od modelu očekáváme dobrý výkon navzdory této ztrátě informací.
Tento kompromis je čím dál méně výhodný.
Posun, který zkoumáme, lze popsat jednoduše, ale jeho důsledky jsou zásadní. Místo abychom agenta chápali jako nástroj pro výběr předem definovaných akcí, přistupujeme k němu jako k systému syntetizujícímu programy v omezeném běhovém prostředí.
Modely se výrazně zlepšily a vaše abstraktní ochranné mantinely už nepotřebují. Potřebují úplný prostor akcí, aby mohly úlohu navrhnout, provést a opakovaně zdokonalovat, dokud nedosáhnou cíle.
Tento článek pojednává o přechodu od automatizace prohlížeče založené na mnoha abstrakcích k omezenému ovládání počítače a o tom, co se při takovém návrhu systémů mění.
Problém není v tom, že by pevná rozhraní akcí byla principiálně nesprávná. Problém je v tom, že jim web nevychází vstříc.
Moderní rozhraní využívají React, Vue a Angular, asynchronní aktualizace stavu, systémy syntetických událostí a vložené widgety třetích stran, které běží v rámcích iframe z jiných zdrojů a mají vlastní životní cykly. Wrapper s pokynem „zadej text do tohoto pole“ funguje správně, jen pokud stránka sdílí vaši definici zadávání textu. Mnohé ji nesdílejí. Přímé nastavení hodnoty často zcela obejde mechanismus frameworku pro zjišťování změn. Pole vypadá jako vyplněné. Ověření se nikdy nespustí. Formulář zůstane nefunkční.
Můžete to opravit záplatou. Můžete přidat zvláštní případy pro vstupní pole v Reactu, po události focus vysílat události blur a před načtením stavu čekat, až síť přestane být aktivní. Každá záplata je ve svém konkrétním kontextu správná. Společně však narůstají v systém, který se stále obtížněji udržuje a stále více se přizpůsobuje webům, s nimiž jste se již setkali.
Hlubší problém spočívá v tom, že do vrstvy abstrakce zakódováváte předpoklady o tom, jak mají interakce fungovat, a poté zjišťujete, že web vychází z jiných předpokladů.
Představte si platební formulář od Stripe nebo Adyen vložený do rámce iframe z jiného zdroje. Váš wrapper k němu nemůže přistupovat přímo, protože pochází z jiného zdroje. Nástroj read_text nedokáže sledovat jeho vnitřní stav. Nástroj type nedokáže pracovat s jeho vstupními poli. Agent založený na wrapperech zde narazí na překážku. Abstrakce byla navržena pro hlavní dokument. Skutečná úloha se však nachází tam, kam abstrakce nevidí.
Podobný nesoulad se objevuje i v méně nápadných postupech. Rozevírací nabídka ovládaná frameworkem nemusí na přímé kliknutí vůbec reagovat, protože viditelný prvek není skutečným ovládacím prvkem. K vyvolání podkladové změny stavu může vyžadovat posloupnost událostí klávesnice. Zvenčí vypadá uživatelské rozhraní jako klikatelné. Abstrakce říká „klikni“. Nic se nestane.
Nebo si představte vícekrokový postup v modálním okně, kde se viditelný DOM aktualizuje se zpožděním oproti změnám vnitřního stavu. Správná následující akce závisí na změně stavu, která se zatím neprojevila v prvcích viditelných pro váš wrapper. Agent založený na wrapperech pak jedná příliš brzy nebo čte zastaralý stav, protože pracuje s neúplným pohledem na systém.
Ve všech těchto případech abstrakce skrývá signály, které agent skutečně potřebuje.
Model pracující na nižší úrovni – zkoumající aktuální DOM, uvažující o hranicích rámců a vytvářející posloupnost interakcí pro dané konkrétní rozhraní – si s těmito situacemi poradí. Nejde o to, že by byl model ze své podstaty chytřejší. Má pouze přístup k informacím, které abstrakce odstranila.
Změnu, k níž směřujeme, lze popsat jednoduše: místo abychom model žádali o výběr z předem definovaných akcí, poskytujeme mu prostředí pro provádění na nižší úrovni a omezujeme je pravidly běhového prostředí, nikoli návrhem abstrakce.
Toto rozhodnutí vychází z širšího posunu v oboru směrem k základním nástrojům na nižší úrovni. Ty využívají přirozenou schopnost agenta opravovat se za běhu a vytvářet kvalitní kód, na rozdíl od robustních, napevno vytvořených specializovaných nástrojů, které model připravují o schopnost přizpůsobit se různým prostředím.
Příkladem je úspěch Claude Code, který si mnoho vývojářů zvolilo za jeden ze svých hlavních nástrojů, a obecnější posun oboru k agentům pracujícím v terminálu. Největší výhodou Claude Code není samotný model, ale nízkoúrovňový harness. Když modelu poskytnete méně modulárních nástrojů na nižší úrovni – tedy terminál –, dosáhnete lepšího výkonu při volání nástrojů. Agent totiž může uvažovat a vytvářet vlastní skripty pro aktuální úlohu, místo aby se pokoušel používat zobecněné nástroje, které zahlcují kontextové okno.
V případě automatizace prohlížeče to v praxi znamená, že model může přímo zkoumat aktuální stav stránky, procházet rámci a vytvářet interakční kód na míru současnému rozhraní, místo aby vše převáděl na pevnou sadu předem vytvořených akcí.
Model se chová méně jako nástroj pro výběr a více jako autor programu za běhu. Zkoumá aktuální stav, uvažuje o rozhraní a vytváří logiku interakce pro danou konkrétní situaci. Dokáže sestavovat vícekrokové posloupnosti, přizpůsobovat se neobvyklým postupům a před pokračováním ověřovat výsledky. Když akce selže, model uvidí podkladovou chybu a sám se opraví. Tento přístup je výkonnější a rizikovější, ale mnohem lépe odpovídá skutečné povaze problému.
Odstranění vrstvy abstrakce přitom neznamená, že systém bude méně ukázněný. Pouze se přesouvá místo, kde se tato ukázněnost prosazuje.
Práce, která dříve spočívala v návrhu wrapperů a řešení okrajových případů, se přesouvá do tří oblastí: do promptu, jenž se stává určitou formou provozního školení; do běhového prostředí, které vynucuje hranice, jako je rozsah navigace, citlivé akce a opakování pokusů; a do vyhodnocovací vrstvy, která neposuzuje jen úspěch úlohy, ale i správnost mezikroků. Méně křehkých abstrakcí. Silnější podpůrné systémy.
Jedním z důsledků tohoto posunu je, že kód produktu bývá jednodušší, i když je celý systém schopnější. Místo zakódování vzorců interakce do opakovaně použitelných wrapperů agent vytváří chování za běhu. Místo rozšiřující se škály specializovaných nástrojů a logiky pro okrajové případy udržujete malou sadu výkonných základních prvků a omezené běhové prostředí.
Mění se tím také způsob, jakým systém zobecňuje. Agent založený na wrapperech dobře zobecňuje na úlohy, které se podobají wrapperům, jež jste již vytvořili. Agent v omezeném běhovém prostředí zobecňuje na úlohy se společným základem pro provádění, i když se jejich viditelné rozhraní liší.
Například práce s vyhledávacím formulářem, rezervací nebo stránkou nastavení může na úrovni uživatelského rozhraní vypadat zcela odlišně. V pozadí však sdílejí stejné vzorce: načítání stavu, vyvolávání událostí, ověřování výsledků a zpracování asynchronních aktualizací. Systém pracující na této úrovni se mezi úlohami přenáší přirozeněji.
Opakovaně použitelnou součástí není seznam akcí. Je jí schopnost modelu kontrolovat stav, bezpečně jednat a ověřovat výsledky.
Nejzřetelnějším poučením z této práce je, že spolehlivosti nedosáhnete tím, že modelu poskytnete více pomocných funkcí. Často jí dosáhnete tím, že mu dáte méně základních, ale výkonnějších prvků a vhodně omezíte jejich použití. Přehnaná pomoc napevno zakódovává předpoklady o tom, jak se má úloha provést. Omezení vymezují bezpečné hranice provozu a umožňují modelu nacházet lepší řešení pro konkrétní situaci.
Výkonnější prostředí pro provádění akcí také vyžaduje propracovanější bezpečnostní model. Jakmile agent přestane být omezen na malou sadu předem definovaných akcí, fakticky pracuje přímo se skutečným softwarem. Tím se okamžitě mění rizikový profil.
Návrh musí zohlednit čtyři oblasti:
Odhalení dat. Pokud agent pracuje se skutečnými rozhraními, často narazí na citlivé informace. Proto je nutné důsledně řídit maskování a přístup. Data se smějí zpřístupnit pouze tehdy, když jsou k provedení úlohy nezbytná. S protokoly a trasovacími záznamy je nutné zacházet opatrně, aby se z vrstvy pro pozorovatelnost nestala nejcitlivější část systému.
Rozsah provádění. Výkonný agent nesmí mít možnost jednat libovolně. V praxi to znamená omezit, kam může přecházet, ke kterým doménám má přístup a se kterými systémy smí pracovat. Tato omezení se musí vynucovat na úrovni běhového prostředí, nikoli ponechat jako pouhé konvence v promptech.
Důvěryhodnost prostředí. Moderní rozhraní mohou obsahovat pokyny, obsah nebo postupy, které jsou zavádějící či přímo nepřátelské. Injektáž promptů prostřednictvím obsahu stránky představuje skutečný prostor pro útok. Systém potřebuje jasnou hierarchii pokynů, ověřovací kontroly a podmínky ukončení, aby agent neuposlechl nezamýšlené pokyny.
Spektrum autonomie. Ne všechny akce mají být plně autonomní. V mnoha produkčních prostředích je důležité vnímat autonomii jako spektrum. Systém může při průzkumu a provádění postupovat vysoce agentně, a přesto u některých kategorií akcí vyžadovat schválení.
Základní princip je jednoduchý: dáte-li modelu větší moc, musíte současně posílit systém, který jej obklopuje. Autonomie bez pravidel není připravena na produkční provoz.
Přestali jsme se ptát: které akce prohlížeče bychom měli zpřístupnit?
Začali jsme se ptát: jak modelu poskytnout úplný prostor akcí a zároveň kolem něj vytvořit pravidla běhového prostředí, která zajistí bezpečnost?
Tento nový pohled mění priority. Na taxonomii akcí a úplnosti wrapperů záleží méně. Více záleží na pravidlech běhového prostředí, pozorovatelnosti a vyhodnocování jednotlivých kroků. Schopnosti modelu a návrh systému se navzájem nenahrazují. Čím jsou modely lepší, tím je práce systému důležitější, nikoli méně důležitá.
Agenti pro prohlížeče, kteří fungují v ukázkách, často uspějí proto, že je úloha úzce vymezená a prostředí jim vychází vstříc. Produkční systémy vyžadují něco jiného: omezené provádění, instrumentované chování a vyhodnocování, které rozliší správný výsledek od pouhé náhody.
Méně navrhování wrapperů. Více systémového inženýrství.
A přestože jsme se zaměřili na agenty pro prohlížeče, tento přístup ukazuje širší způsob, jak o ovládání počítače uvažovat jako o systémové disciplíně.