Що таке керування комп’ютером і чому воно важливе? Керування комп’ютером — проста ідея з далекосяжними наслідками: замість того щоб просити моделі відповідати на запитання, ми доручаємо їм керувати програмами — самостійно переходити між сайтами, заповнювати форми, виконувати послідовності дій і доводити завдання до кінця.
Це відкриває доступ до великого класу реальних завдань, які нині розпорошені між різними інтерфейсами: повний цикл бронювання, оформлення покупок в інтернет-магазинах, багатоетапне планування подорожей і внутрішні робочі процеси без зручного аналога у вигляді 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 — не сама модель, а низькорівнева система harness. Коли модель отримує менше, але модульніших і низькорівневіших інструментів — тобто термінал, — вона ефективніше викликає інструменти. Насамперед тому, що агент може міркувати й створювати власні сценарії для поточного завдання, а не намагатися застосувати універсальні інструменти, які захаращують ліміт контексту.
Для автоматизації браузера на практиці це означає, що модель може безпосередньо аналізувати поточний стан сторінки, переходити між фреймами та створювати спеціалізований код взаємодії для конкретного інтерфейсу, а не зводити все до фіксованого набору готових дій.
Модель поводиться не так як засіб вибору, а радше як автор логіки, що створюється під час виконання. Вона аналізує поточний стан, осмислює інтерфейс і синтезує логіку взаємодії для конкретної ситуації. Вона може будувати багатоетапні послідовності, адаптуватися до незвичних процесів і перевіряти результати, перш ніж продовжити. Коли дія завершується невдало, модель бачить базову помилку й самостійно виправляється. Такий підхід потужніший і ризикованіший, але набагато краще відповідає реальній природі проблеми.
Важливо, що усунення шару абстракції не робить систему менш дисциплінованою. Воно лише переносить дисципліну в інше місце.
Робота, яку раніше виконували під час проєктування обгорток та обробки граничних випадків, переміщується до трьох складників: запиту, що стає формою операційного навчання; середовища виконання, яке забезпечує обмеження щодо навігації, чутливих дій і повторних спроб; та шару оцінювання, який визначає не лише успішність завдання, а й правильність проміжних кроків. Менше крихких абстракцій. Потужніші системи навколо моделі.
Один із наслідків цього переходу — код продукту часто стає простішим, хоча система загалом набуває ширших можливостей. Замість того щоб кодувати шаблони взаємодії у вигляді багаторазових обгорток, агент синтезує поведінку під час виконання. Замість розширюваного набору спеціалізованих інструментів і логіки для граничних випадків ви підтримуєте невеликий набір потужних примітивів та обмежене середовище виконання.
Це також змінює те, як система узагальнює досвід. Агент на основі обгорток добре узагальнює досвід для завдань, схожих на ті, для яких ви вже створили обгортки. Агент в обмеженому середовищі виконання узагальнює досвід для завдань зі спільною інфраструктурою виконання, навіть якщо їхні видимі інтерфейси відрізняються.
Наприклад, взаємодія з формою пошуку, процесом бронювання чи сторінкою налаштувань може мати зовсім різний вигляд на рівні інтерфейсу. Однак в основі лежать спільні шаблони: зчитування стану, ініціювання подій, перевірка результатів і обробка асинхронних оновлень. Система, що працює на цьому рівні, природніше переносить досвід між завданнями.
Компонентом для повторного використання є не перелік дій, а здатність моделі аналізувати стан, діяти безпечно та перевіряти результати.
Найочевидніший висновок із цієї роботи: надійність не виникає від того, що моделі надають більше допоміжних функцій. Часто вона досягається завдяки меншій кількості потужніших примітивів і правильно підібраним обмеженням для них. Надмірна допомога жорстко закріплює припущення про те, як слід виконувати завдання. Обмеження визначають безпечні межі роботи й дають моделі змогу знаходити кращі рішення в конкретних ситуаціях.
Потужніша платформа виконання також потребує досконалішої моделі безпеки. Щойно агент перестає бути обмеженим невеликим набором наперед визначених дій, він фактично починає безпосередньо працювати з реальним програмним забезпеченням. Це відразу змінює профіль ризиків.
Під час проєктування слід урахувати чотири аспекти:
Розкриття даних. Взаємодіючи з реальними інтерфейсами, агент часто матиме справу з конфіденційною інформацією. Тому потрібен дисциплінований підхід до маскування та контролю доступу. Дані слід розкривати лише тоді, коли це необхідно для виконання, а журнали й трасування потрібно обробляти обережно, щоб засоби спостереження не стали найчутливішою частиною системи.
Обсяг виконання. Потужний агент не повинен мати змоги діяти без жодних обмежень. На практиці це означає обмежити шляхи навігації, доступні домени та системи, з якими йому дозволено взаємодіяти. Ці обмеження потрібно забезпечувати на рівні середовища виконання, а не залишати у вигляді домовленостей у запитах.
Довіра до середовища. Сучасні інтерфейси можуть містити оманливі або відверто ворожі інструкції, матеріали чи сценарії. Вставлення шкідливих запитів через вміст сторінки — це реальний вектор атаки. Системі потрібні чітка ієрархія інструкцій, перевірки та умови завершення, щоб агент не виконував небажаних вказівок.
Спектр автономності. Не всі дії мають бути цілком автономними. У багатьох робочих середовищах автономність важливо розглядати як спектр. Система може бути дуже агентною у способах дослідження та виконання, але водночас вимагати схвалення для певних категорій дій.
Основний принцип простий: що більше можливостей отримує модель, то потужнішою має бути система навколо неї. Автономність без правил не готова до промислового використання.
Ми перестали запитувати: які дії в браузері слід зробити доступними?
Натомість ми запитали: як надати моделі повний простір дій і водночас створити навколо нього правила середовища виконання, що гарантуватимуть безпеку?
Таке переосмислення змінює пріоритети. Таксономії дій і повнота обгорток стають менш важливими. Натомість зростає значення правил середовища виконання, спостережуваності й оцінювання кожного кроку. Можливості моделі та проєктування системи не замінюють одне одного. З удосконаленням моделей роль системи стає важливішою, а не менш важливою.
Браузерні агенти часто успішно працюють у демонстраціях завдяки вузькому завданню та сприятливому середовищу. Промисловим системам потрібен інший підхід: обмежене виконання, інструментована поведінка й оцінювання, здатне відрізнити правильний результат від випадкового успіху.
Менше проєктування обгорток. Більше системної інженерії.
І хоча ми зосередилися на браузерних агентах, цей підхід указує на ширше розуміння керування комп’ютером як системної дисципліни.