Чому агенти для програмування постійно переосмислюють браузери

Браузер, якого ніхто не просив

Програми-кодувальники демонструють певну закономірність у своїй діяльності. Маючи безкоштовний доступ до Інтернету, можливість писати та виконувати код, а також роботу, яка триває достатньо довго, вони схильні створювати щось, що нагадує браузер. Бажання мати браузер не є мотивацією; насправді ці програми шукають дешевий, багаторазово використовуваний інструмент, який може відкривати URL-адреси, натискати кнопки, заповнювати форми, чекати на дані та їх отримувати, зберігати куки та сесії, а також робити скріншот у разі збою. Якщо дивитися з цієї точки зору, це просто звичайна інженерна робота, яку б виконав людський розробник.

Chromium як продукт не є кінцевою метою. Ці програми прагнуть до функції, яку виконує браузер — перетворення веб-протоколів та конвенцій на конкретні операції.

Продукт проти абстракції

Браузер у розумінні Chrome чи Firefox — це великий додаток: вкладки, поле адреси, движок відображення, модель обробки процесів. Жоден з цих елементів не є тим, що потрібно агенту. Йому потрібно перетворити принципи роботи вебу на конкретні операції, які можна виконати.

Люди використовують цей інтерфейс, навіть не помічаючи цього. Сторінка входу очевидно просить ввести облікові дані, кнопку можна натиснути, і людина це робить, чекає на наступну сторінку та продовжує. Агент не може покладатися на це невимовлене розуміння, тому йому доводиться перетворювати ту саму роботу на чіткі операції. Якщо попросити кодувального агента працювати на довільних веб-сайтах, ви даєте йому задачу, природна абстракція якої вже відома, тож він буде рухатися у напрямку цієї абстракції.

Сучасний веб також не створюється для використання як організований API. Зазвичай існує HTML-документ, оточений JavaScript, а також сеанси входу, куки, перенаправлення, відображення на стороні клієнта, безкінечне прокручування, вікна-спливи, завантаження файлів та асинхронні запити. Простий HTTP GET — це лише початок. Реальні завдання в таких умовах зрештою вимагають низки операцій, подібних до цих.

open(url)
click(selector)
fill(selector, text)
wait_for(selector)
extract(selector)
go_back()
screenshot()

Це не графічний браузер, але це, безумовно, універсальний інтерфейс для роботи в Інтернеті.

Чому довгі завдання потребують допоміжних засобів

Короткі завдання можна виконувати спорадично. Одноразовий пошук можна здійснити методом проб і помилок без будь-якої інфраструктури, оскільки він не буде повторюватися та завершиться за кілька секунд.

"Find the current exchange rate."
"Look up this company's homepage."
"Find the opening hours of this restaurant."

Робота, яка триває довго, має іншу природу. Уявіть агента, який кожні кілька годин перевіряє сотні сайтів, постійно виконує складні алгоритми роботи, збирає інформацію з сторінок, залишаючись усередині системи, збирає докази протягом кількох днів або постійно запитує сервіс, поки щось не зміниться. Якщо модель обробляє кожну клікання та кожну перевірку, витрати стрімко зростають. Простий підхід виглядає так:

1. Відкрити браузер — інструмент для отримання сторінки.
2. Перевірити сторінку, використовуючи отриманий DOM як джерело інформації.
3. Знайти поле пошуку, ввести запит, натиснути «Пошук» та почекати.
4. Витягнути дані.
5. Проаналізувати їх.
6. Повторити процедуру.

Здатний агент реагує так, як це зробив би людський розробник, створюючи повторно використовуваний допоміжний інструмент. Тоді наступна робота виглядає так:

1. Запустити скрипт.
2. Перевірити, чи результат все ще правильний.

Звертайтеся до моделі знову лише тоді, коли це не вдається, наприклад, коли селектор повертає порожній результат, структура сторінки змінилась або вилучені дані більше не відповідають вимогам завдання.

Це значна архітектурна зміна. Модель припиняє виконувати всі операції. Вона стає тією частиною, яка визначає, яка процедура має бути виконана, тоді як звичайне програмне забезпечення використовує обраний інструмент та збирає дані. Іншими словами, агент перетворює свій власний досвід на скрипт.

Дослідження в браузері, повторне виконання у коді

Браузер — чудове місце для досліджень. Агент може досліджувати, навігувати, переглядати результати та з’ясовувати, яка послідовність дій дозволить досягти мети. Після цього знову аналізувати кожну дію є марним.

Припустимо, агент дізнається, що для пошуку продукту на інтернет-магазині завжди потрібно переходити на головну сторінку, шукати „USB-C кабелі“, застосовувати фільтри за оцінкою чотири зірки та вище, швидку доставку та максимальну ціну, проглядати результати та видобувати назви, ціни та ідентифікатори продуктів. Немає причин, чому мовна модель мусить заново виконувати ці п’ять операцій щоразу. Вона може перетворити їх на процедуру та використовувати її для подібних задач. Для цього потрібна активна сесія з кукі-файлами, тому агент обирає Puppeteer, Playwright або щось подібне як інструмент для отримання сторінок.

async function getNewProducts(query) {
  const browser = await playwright.chromium.connectOverCDP(
    `wss://${AUTH}@brd.superproxy.io:9222`,
  );
  const page = await browser.newPage();
  await page.goto("https://example.com/products");
  await page.fill("input[name=q]", query);
  await page.click("button[type=submit]");
  await page.waitForSelector(".results");
  return extractResults(page);
}

Цей фрагмент підключає Playwright до браузера, який розміщений на відстані, через протокол Chrome DevTools. Використання такого браузера є доцільним, коли агент, який працює протягом тривалого часу, мусить підтримувати свою сесію активною кожні кілька годин без участі моделі. Для цього потрібні облікові дані у форматі рядка підключення, який позначається замінником ${AUTH}.

Для структурованого збору даних на сайті, де немає готового інструменту для скрейпінгу, навіть не потрібен локальний файл Playwright. Той самий процес можна перетворити на інструмент скрейпінгу, розміщений на сервері: описати потрібні дані простою мовою, отримати створений збирач та запустити його без використання моделі під час циклу кліків. Його функції взаємодії та парсингу є такими ж, як у звичайних операціях «відкрити», «натиснути», «ввести», «чекати», «витягнути» та «зробити скріншот», просто вони виконуються на сервері.

Такий скрипт зазнає невдачі, як тільки змінюються CSS-селектори, що змушує агента знову все досліджувати та створювати новий скрипт. Якщо ця процедура знаходиться всередині хостованого інструменту, ШІ може її відремонтувати без необхідності переписування селекторів.

Людські розробники поводяться так само. Перший візит на веб-сайт допомагає зрозуміти, як він працює, і після цього ніхто не думає про кожну клікання. Коли сайт змінюється, доводиться знову його вивчати, хоча ці знання залишаються у неусвідомленому стані. У ШІ пам’ять значно дорожча. Якщо йому щоразу доводиться відновлювати процедуру на основі контексту, він постійно оплачує однакове «відкриття». Тому він зберігає навчений алгоритм у скрипті та використовує його, поки сторінка більше не відповідає критеріям.

Куки як пам’ять поза моделлю

Жодна модель мови не може зберігати тривалу веб-сесію у своєму контексті, принаймні наразі. Складання файлу .py все одно викликає модель, тоді як зберігання куки цього не робить. У міру розвитку сесії браузер самостійно накопичує пам’ять, тож вона вже не знаходиться у сховищі агента. Вона складається з трьох основних частин:

• Банка куки, що включає HttpOnly-куки та ті, які встановлює JavaScript після входу або перевірки бота. Часто модель зовсім не може їх прочитати, проте браузер зберігає їх та додає до наступного запиту.
• Сховище походження, тобто localStorage, sessionStorage та IndexedDB, які містять майже виключно дані, записані самим сайтом.
• Історія сесії — стек для переміщення назад та вперед, який дозволяє використовувати функції back() або tabs.goBack().

Деякі стани існують поза магазином браузерів, наприклад, сеанс на стороні сервера або URL, який не існує до того, як запуститься JavaScript. Агенту не обов’язково читати їх самостійно. Йому достатньо керувати шаром браузера, який вже містить сеанс.

Ризики безпеки при передачі браузера

Коли агент може читати будь-яку сторінку та будь-які куки та керувати активним сеансом, вставка запитів перестає бути проблемою кращих запитів та перетворюється на архітектурну небезпеку. Кожна система, яка працює з активним браузером, стикається з цим, але агенти, написані за допомогою коду, перебувають у гіршому становищі, оскільки вони зазвичай можуть писати та виконувати все, що зустрічається. Обмежте те, що може робити агент без нагляду людини, почавши з сандбоксу.

Хорошим шаблоном є чек-лист для роботи з комп’ютером від Anthropic: використовуйте спеціалізовану віртуальну машину або контейнер, уникайте входу, якщо це не потрібно для виконання завдання, підтримуйте списки дозволених доменів та вимагайте підтвердження людиною будь-яких дій, пов’язаних із грошима чи згодою.

Чому сирий HTML є поганим вхідним даним

Сирі сторінки є жахливим вхідним даним для мовної моделі через велику кількість „шуму“. Те, що потрібно агенту, може бути приховане серед тисяч токенів маркування, стилізації та інших елементів. Тому хороший інструмент браузера повертає менший набір дій та спостережень замість повного HTML.

На малюнку показано модель об’єктів документа HTML — дерево, яке потрібно скоротити у компактному вигляді чи для забезпечення доступності. Корисний інструмент може перетворити його на щось значно менше. Замість цілого документа він може надати моделі короткий огляд, подібний до цього.

Title: Search results
Links:
  [1] Home
  [2] Next page
Forms:
  search: input[name=q]
Buttons:
  submit: button[type=submit]
Main content:
  ...

Або це може відобразити дерево доступності.

- navigation
  - link "Home"
  - link "Search"
- main
  - heading "Results"
  - list
    - listitem "Item 1"
    - listitem "Item 2"

Ця форма набагато ближча до того, що може використовувати модель міркувань. Тож шар у формі браузера робить більше, ніж просто дозволяє взаємодію: він скорочує середовище до компактного набору дій та спостережень. Агент бачить лише ті частини вебу, які стосуються його завдання, а не механізми, які відповідають за відображення сторінок. Контекст зберігається, процес висновків стає дешевшим, а помилки часто, хоча й не завжди, зменшуються.

Є один недолік: повний знімок доступності з усіма посиланнями може виявитися більшим за видимий текст. Компресія має сенс лише тоді, коли обгортка дійсно повертає короткий, керований список елементів керування. Наскільки він короткий, залежить від моделі. Мала модель не може використовувати сирий DOM, а потужна може, але все одно платить за токени. Жодна з них не потребує повного HTML.

Коли достатньо звичайного HTTP

Після того, як агент з’ясує, як працює сайт, найдешевша надійна реалізація може взагалі не вимагати автоматизації браузера. Іноді виявляється, що браузер насправді виконує щось досить просте. Кнопка „Наступна сторінка“ може в кінцевому підсумку виконувати саме це.

GET /api/products?page=2

У такому випадку відображення сторінки є марним, і агент може безпосередньо звернутися до кінцевої точки. Результатом є ієрархія варіантів.

human interface
      ↓
browser automation
      ↓
discovered workflow
      ↓
direct HTTP/API calls   ← only if the site still allows it

Його цінність полягала у тому, що він демонстрував, як поводиться додаток. Коли це зрозуміло, агент може прибрати додаткові шари та іноді перейти до простого HTTP. Агент, який ніколи не працює з веб-сторінками, насиченими JavaScript, може повністю уникати автоматизації браузера та використовувати лише HTTP, бажано з сервісом для подолання блокувань у разі відхилення запитів. Яким би не був шлях, автономні агенти потребують запасного варіанту, адже на відкритому Інтернеті майже напевно існують бар’єри від Cloudflare чи перевірки на наявність ботів. Без недорогих спроб повторного запуску модель блукає, витрачає токени та підвищує рахунок.

Існують дві складнощі.

По-перше, багато сайтів неможливо перевести на HTTP. Більшість з них не дозволяють проводити зворотну інженерію: вони обмежують трафік, що не походить від браузера, змінюють селектори, визначають унікальні характеристики клієнтів та додають перевірки на наявність ботів чи CAPTCHA. Для таких випадків потрібен повний підхід з використанням браузера, чи то локального, чи то хостованого.

По-друге, використання альтернативних рішень не завжди є ефективним. Документований публічний JSON API має чітку структуру, обмежені можливості та простий для логування формат. Інший варіант – внутрішній ендпоїнт без документації, який агент знаходить самостійно: такий варіант дешевший у використанні, але складніший для перевірки людиною порівняно з скриптом, який натискає видиму кнопку, причому у такого варіанту менше записів у логах. Відповідь з кодом 200, наповнена непотрібними даними, легко залишається непоміченою, тоді як несправна сторінка відразу привертає увагу.

У кінцевому підсумку агент не є вірним певним браузерам. Він прагне найдешевшого інтерфейсу для взаємодії з навколишнім середовищем, який все одно буде функціонувати:

• Якщо цей інтерфейс – це JSON-ендпоїнт та сайт його підтримує, використовуйте JSON.
• Якщо потрібна робота з JavaScript та зберігання стану сесії, використовуйте справжній браузер через Puppeteer або Playwright, або хостований браузер.
• Якщо потрібен лише завантажений HTML, використовуйте HTTP, з проксі або засобом для подолання блокувань, якщо запит GET заблокований.

Для повторюваної структурованої екстракції на сайті, де немає готового скрейпера, необхідно організувати роботу в рамках хостованого процесу скрейпінгу, де кодовий працівник відповідає за виконання HTTP-запитів, а працівник браузера — за роботу у живій сесії.

Якщо важливою є інформація про структуру доступності, її можна передати безпосередньо.

Веб-агенти з тривалим терміном існування зазвичай використовують кілька з цих методів одночасно. Ключовою навичкою є здатність змінювати підхід відповідно до ситуації, що виникає.

Чи пояснюють це дані для навчання?

Відповідь є змішаною. Дані для навчання можуть пояснити, чому модель використовує Playwright чи Puppeteer, проте вони не можуть пояснити необхідність створення інструментів, схожих на браузери, з самого початку.

Дослідження 2026 року, проведене Оксфордським університетом та Microsoft під назвою BiasBusters, перевіряло схоже запитання: чи впливає вплив під час навчання на вибір інструменту моделлю. Команда продовжила навчати невелику модель на корпусі даних, насиченому метаданими для одного API погоди, одного з кількох, що надають однакові послуги.

• Раніше модель майже ніколи не обирала цей API — приблизно у 0,6% випадків, що відповідає ймовірності, яка б існувала сама по собі.
• Після навчання на цьому спотвореному корпусі даних його обирали приблизно у 12% випадків, тобто у двадцять разів частіше.

Коротко кажучи, саме вплив під час навчання, незалежно від завдання, значно впливає на те, який інструмент чи продукт віддасть перевагу модель. Однак йдеться лише про вибір інструменту. Абстракція (відкрити, натиснути, заповнити, почекати, витягнути у вигляді форми – що б не пропонувала бібліотека) визначається середовищем. Модель, яка ніколи не бачила Playwright, все одно потребує засобу для відкриття сторінок, очікування вмісту та повідомлення про результати, адже інтерактивні сторінки це вимагають.

Діють два окремі фактори:

• Абстракція операцій open, click, fill, wait та extract нав’язується середовищем. Інтерактивні сторінки містять навігацію, таймінг, елементи керування та відформатований вихід, незалежно від того, чи є Playwright у параметрах моделі.

Інструмент Playwright на відміну від власного клієнта походить з того, що бачив модель, як показали BiasBusters щодо взаємозамінних API.

Дані для навчання охоплюють останній варіант та не враховують перший. Вони не можуть пояснити, чому проблема постійно спрямовується до абстракцій, схожих на браузери. Основна причина полягає у тому, що веб вже організований саме так.

Адаптери з найкращими результатами

Такі агенти, як Claude Code, насправді не створюють браузери. Вони створюють адаптери між системою міркувань та середовищем, яке випадково має форму браузера.

У еволюційній біології існує поняття карцинізації: дивна тенденція неспоріднених ракоподібних з часом набувати форми, схожої на рака.

Ці види не дійшли висновку, що бути крабом — це розумний варіант. Їхнє оточення просто постійно надавало винагороду за приблизно однакові рішення приблизно однакових проблем. Агенти, які кодують, можуть йти схожим шляхом. Вони помічають, що поточний підхід є повільним, тож пишуть скрипт, додають спроби повторного виконання у разі невдачі, забезпечують збереження стану сеансу після автентифікації та додають функції обробки DOM чи забезпечення доступності, коли сторінки стають занадто великими для логічного аналізу.

The task requires the web.
        ↓
The web exposes a browser-shaped interface.
        ↓
The agent needs a way to operate that interface.
        ↓
Repeated operations make ad-hoc reasoning expensive.
        ↓
The agent writes reusable tools.
        ↓
Those tools accumulate state, retries, and abstractions.
        ↓
The tools start looking like a browser.
        ↓
Known workflows get compiled into deterministic code.
        ↓
The page changes so the agent re-explores.
        ↓
If an API exists, use it to get the data.
If not, and the site allows it, fall back to regular HTTP.
If not, stay on the browser.

При достатній кількості ітерацій результат дуже нагадує невеликий браузер. Це краща ментальна модель для автономних агентів, ніж уявлення про цифрових людей із дивною зацікавленістю у браузерах. Вони поводяться як справжні інженери: досліджують складне середовище, виявляють справжній інтерфейс, який воно пропонує, та створюють абстракції для всього того, що є повторюваним, залежним від стану та вимагає значних зусиль. У Інтернеті вже існує стара та надзвичайно ефективна абстракція для цієї мети — її називають браузером.