Какво представлява използването на компютър и защо е важно? Използването на компютър е проста идея с мащабни последици: вместо да искаме от моделите да отговарят на въпроси, им възлагаме да работят със софтуер — да навигират в уебсайтове, да попълват формуляри, да преминават през работни процеси и да изпълняват автономно задачи от начало до край.
Това прави възможен голям клас практически задачи, които понастоящем са разпокъсани между различни интерфейси — например цялостни резервации, приключване на покупки в електронни магазини, планиране на пътувания в няколко стъпки и вътрешни административни процеси без подходящ API еквивалент. Тези проблеми не са нови. Новото е, че вече е практически възможно да бъдат решавани с модели с общо предназначение.
Скорошни системи на Anthropic и OpenAI демонстрираха агенти, които не просто действат, а анализират състоянието, възстановяват се след грешки и създават в движение решения за конкретната задача. Това превръща браузъра в универсална среда за изпълнение за агенти, но веднага поражда въпрос при проектирането: каква част от тази среда трябва да предоставим на модела?
Първите системи решиха този въпрос, като обвиха браузъра във фиксиран набор от безопасни, предварително зададени действия. Както ще обясним в тази публикация, този подход достига границите на възможностите си.
При създаването на браузърни агенти често се проявява познат инстинкт: да не се доверяваме прекалено на модела.
Затова поставяме обвивка около браузъра. Предоставяме предварително зададени инструменти като click, type, scroll, select и read_text. Опростяваме обектния модел на документа (DOM). Намаляваме пространството на действията. Опитваме се да направим поведението разбираемо и управляемо чрез проектирани от нас абстракции.
Това е разумна отправна точка. Но все повече се оказва и неправилната дългосрочна архитектура.
С усъвършенстването на авангардните модели ограничението вече не е само в липсата на инструменти за модела. Проблемът е, че го принуждаваме да работи чрез абстракции, които премахват твърде голяма част от базовата система. Свиваме една хаотична, динамична среда до фиксиран интерфейс за действия, след което очакваме моделът да работи добре въпреки тази загуба на информация.
Този компромис става все по-непривлекателен.
Промяната, която проучваме, е лесна за описване, но има значителни последици. Вместо да разглеждаме Агента като средство за избор на предварително зададени действия, го разглеждаме като система за синтезиране на програми, работеща в ограничена среда за изпълнение.
Моделите станаха наистина добри и вече не се нуждаят от абстрактните ви защитни ограничения — нужно им е пълното пространство на действията, за да проектират, изпълняват и усъвършенстват задачата, докато постигнат целта си.
Тази публикация разглежда прехода от автоматизация на браузъра с много абстракции към ограничено използване на компютър и промените, които настъпват при такова проектиране на системите.
Проблемът не е, че фиксираните интерфейси за действия са концептуално погрешни. Проблемът е, че уеб средата не се съобразява с тях.
Съвременните интерфейси са изградени с React, Vue и Angular и включват асинхронни актуализации на състоянието, системи за синтетични събития и вградени компоненти на трети страни в iframe елементи от друг източник със собствен жизнен цикъл. Обвивка с инструкция „въведи текст в това поле“ работи правилно само ако страницата споделя вашето определение за въвеждане. При много страници това не е така. Директното задаване на стойност често изцяло заобикаля механизма на платформата за откриване на промени. Полето изглежда попълнено. Проверката за валидност изобщо не се задейства. Формулярът остава неизправен.
Можете да закърпите проблема. Можете да добавите специални случаи за полета на React, да изпращате събития blur след focus и да изчаквате мрежовата активност да приключи, преди да прочетете състоянието. Всяка отделна корекция работи правилно в конкретния случай. Взети заедно, тези корекции се натрупват в система, която става все по-трудна за поддръжка и все по-тясно пригодена към вече познатите ви сайтове.
По-дълбокият проблем е, че вграждате в слоя за абстракция допускания за начина, по който трябва да протичат взаимодействията, а после откривате, че уеб средата следва други правила.
Представете си формуляр за плащане от Stripe или Adyen, вграден в iframe елемент от друг източник. Вашата обвивка няма пряк достъп до него, защото той се намира в отделен източник. Инструментът ви read_text не може да наблюдава вътрешното му състояние. Инструментът ви type не може да взаимодейства с полетата му. Тук Агентът, базиран на обвивки, стига до задънена улица. Абстракцията е проектирана за основния документ. Реалната задача се намира на място, което абстракцията не може да види.
Подобно несъответствие възниква и при по-малко очевидни процеси. Падащо меню, управлявано от дадена платформа, може изобщо да не реагира на директни щраквания, защото видимият елемент не е действителната контрола. Възможно е да изисква поредица от клавиатурни събития, за да се задейства съответната промяна на състоянието. Отвън потребителският интерфейс изглежда интерактивен при щракване. Абстракцията казва „щракни“. Нищо не се случва.
Или си представете многостъпков процес в модален прозорец, при който актуализациите на видимия DOM изостават от промените във вътрешното състояние. Правилното следващо действие зависи от промяна на състоянието, която още не се е отразила в елементите, видими за обвивката. Агентът, базиран на обвивки, в крайна сметка действа твърде рано или прочита остаряло състояние, защото разполага с непълна представа за системата.
Във всеки от тези случаи абстракцията скрива сигналите, от които Агентът действително се нуждае.
Модел, който работи на по-ниско ниво — проверява активния DOM, анализира границите между рамките и синтезира последователността от взаимодействия за конкретния интерфейс — може да се справи с тези ситуации. Причината не е, че моделът поначало е по-интелигентен. Причината е, че има достъп до премахнатата преди това информация.
Промяната, към която се стремим, е лесна за описване: вместо да искаме от модела да избира между предварително зададени действия, му предоставяме среда за изпълнение на по-ниско ниво и я ограничаваме чрез правила за изпълнение, а не чрез проектиране на абстракции.
Това проектно решение произтича от по-широка промяна в индустрията, която започва да отдава предпочитание на базови инструменти от по-ниско ниво. Те използват присъщата способност на Агента да се коригира по време на изпълнение и да създава висококачествен код, вместо да разчитат на устойчиви, но твърдо кодирани специализирани инструменти, които ограничават способността на модела да се адаптира към различни среди.
Помислете за успеха на Claude Code като основен избор в инструментариума на много разработчици и за по-широкия преход в индустрията към терминално базирани агенти. Най-голямото предимство на Claude Code не е самият модел, а рамката на по-ниско ниво. Предоставянето на по-малко на брой, по-модулни инструменти от по-ниско ниво — т.е. терминала — води до по-добра работа при извикване на инструменти, най-вече защото Агентът може да анализира и създава персонализирани скриптове за текущата задача, вместо да се опитва да използва универсални инструменти, които замърсяват контекстния прозорец.
При автоматизацията на браузър това на практика означава, че моделът може директно да проверява текущото състояние на страницата, да преминава през рамките и да създава специализиран код за взаимодействие с конкретния интерфейс, вместо да свежда всичко до фиксиран набор от предварително изградени действия.
Моделът действа по-малко като средство за избор и повече като автор на логика по време на изпълнение. Той проверява текущото състояние, анализира интерфейса и синтезира логиката за взаимодействие за конкретната ситуация. Може да създава многостъпкови последователности, да се адаптира към необичайни процеси и да проверява резултатите, преди да продължи. Когато дадено действие се провали, моделът вижда основната грешка и се коригира сам. Това е по-мощно и по-рисково, но отразява много по-точно действителния характер на проблема.
Важно е, че премахването на слоя за абстракция не прави системата по-малко дисциплинирана. То премества дисциплината другаде.
Работата, която преди се извършваше при проектирането на обвивки и обработването на гранични случаи, се премества на три места: в подканата, която се превръща във форма на оперативно обучение; в средата за изпълнение, която налага граници като обхват на навигацията, чувствителни действия и поведение при повторни опити; и в слоя за оценяване, който проверява не само дали задачата е изпълнена успешно, но и дали междинните стъпки са били правилни. По-малко крехки абстракции. По-силни заобикалящи системи.
Един от резултатите от тази промяна е, че продуктовият код често става по-прост, макар системата като цяло да придобива повече възможности. Вместо моделите на взаимодействие да се кодират като многократно използваеми обвивки, Агентът синтезира поведението по време на изпълнение. Поддържате малък набор от мощни базови операции и ограничена среда за изпълнение вместо непрекъснато разрастващ се набор от специализирани инструменти и логика за гранични случаи.
Това променя и начина, по който системата обобщава наученото. Агент, базиран на обвивки, обобщава добре за задачи, които приличат на вече създадените обвивки. Агент с ограничена среда за изпълнение обобщава за задачи с обща инфраструктура за изпълнение дори когато видимият интерфейс е различен.
Например взаимодействието с формуляр за търсене, процес за резервация или страница с настройки може да изглежда напълно различно на ниво потребителски интерфейс. Но в основата си те споделят едни и същи модели: прочитане на състоянието, задействане на събития, проверка на резултатите и обработване на асинхронни актуализации. Система, която работи на това ниво, пренася наученото между задачите по-естествено.
Многократно използваемият компонент не е списъкът с действия, а способността на модела да проверява състоянието, да действа безопасно и да потвърждава резултатите.
Най-ясният извод от тази работа е, че надеждността не идва от предоставянето на повече помощни функции на модела. Често тя идва от предоставянето на по-малко на брой, но по-мощни базови операции, ограничени по правилния начин. Прекомерната помощ вгражда твърдо допускания за начина, по който трябва да се изпълни дадена задача. Ограниченията определят безопасни рамки за работа и позволяват на модела да открива по-добри решения за конкретния случай.
По-мощната среда за изпълнение изисква и по-прецизен модел за безопасност. Когато Агентът вече не е ограничен до малък набор от предварително зададени действия, той на практика работи директно с реален софтуер. Това незабавно променя рисковия профил.
При проектирането трябва да се вземат предвид четири аспекта:
Разкриване на данни. Когато Агентът взаимодейства с реални интерфейси, той често попада на чувствителна информация. Това изисква дисциплиниран подход към маскирането и контрола на достъпа. Данните трябва да се разкриват само когато са необходими за изпълнението, а регистрационните файлове и следите трябва да се обработват внимателно, за да не се превърне наблюдаемостта в най-чувствителната част от системата.
Обхват на изпълнението. Мощният Агент не бива да може да действа произволно. На практика това означава да се ограничат местата, до които може да навигира, домейните, до които има достъп, и системите, с които му е разрешено да взаимодейства. Тези ограничения трябва да се налагат на ниво среда за изпълнение, а не да остават само като условности в подканите.
Надеждност на средата. Съвременните интерфейси могат да съдържат подвеждащи или активно злонамерени инструкции, съдържание и процеси. Инжектирането на подкана чрез съдържанието на страницата е реален вектор за атака. Системата се нуждае от ясна йерархия на инструкциите, проверки за валидност и условия за прекратяване, за да не позволи на Агента да следва непредвидени указания.
Спектър на автономността. Не всички действия трябва да са напълно автономни. В много производствени среди е важно автономността да се разглежда като спектър. Системата може да действа с висока степен на агентност при проучването и изпълнението, като същевременно изисква одобрение за определени категории действия.
Основният принцип е ясен: предоставянето на повече възможности на модела изисква укрепване на заобикалящата го система. Автономността без правила не е готова за производствена среда.
Спряхме да питаме: кои са правилните действия в браузъра, които да предоставим?
Започнахме да питаме: как да предоставим на модела пълно пространство на действията и какви правила за средата за изпълнение да изградим около него, за да остане безопасно?
Тази нова гледна точка променя приоритетите. Таксономиите на действията и пълнотата на обвивките губят значение. Правилата за средата за изпълнение, наблюдаемостта и оценяването на всяка стъпка стават по-важни. Възможностите на модела и проектирането на системата не могат да се заменят взаимно. С усъвършенстването на моделите ролята на системата става по-важна, а не по-маловажна.
Браузърните агенти, които работят при демонстрации, често успяват, защото задачата е тясно определена, а средата не създава пречки. Производствените системи изискват друго: ограничено изпълнение, проследимо поведение и оценяване, което може да различи правилния резултат от случайния успех.
По-малко проектиране на обвивки. Повече системно инженерство.
И макар да се съсредоточихме върху браузърните агенти, това насочва към по-широк поглед върху използването на компютър като системна дисциплина.