У світі, де великі мовні моделі вже вміють писати код, відповідати на листи й аналізувати документи, одна проблема досі залишалася дивно «ручною»: взаємодія з реальним вебом. Канал Tech With Tim у великому туторіалі розбирає Browserbase — платформу для віддалених браузерів під керуванням ШІ — і показує, як її SDK Stagehand та Model Gateway перетворюють браузер на інструмент, яким можна керувати звичайною мовою, без крихких CSS?селекторів і зоопарку API?ключів.
Цей матеріал зосереджений саме на двох ключових складових Browserbase — Stagehand та Model Gateway — і на тому, як вони змінюють підхід до веб?скрейпінгу, автоматизації та інтеграції LLM у бекенд?сервіси.
Від Playwright до Stagehand: чому «натуральна мова» перемагає селектори
Класичні інструменти на кшталт Playwright, Puppeteer чи Selenium будуються навколо однієї ідеї: розробник повинен точно знати, з чим взаємодіяє браузер. Потрібно знайти селектор кнопки, ідентифікатор поля, структуру DOM. Будь?яка зміна верстки — і скрипт ламається. Для динамічних сайтів, React?компонентів із випадковими класами або часто оновлюваних інтерфейсів це перетворюється на нескінченну гонитву за «поправками».
Stagehand, SDK від Browserbase, пропонує інший рівень абстракції. Замість того, щоб вручну вказувати page.click('button[data-id="login"]'), розробник формулює намір природною мовою: «натисни кнопку входу», «заповни поле email значенням X», «витягни заголовок першої новини». Далі вже LLM, підключена через Stagehand, аналізує сторінку, знаходить відповідні елементи й виконує дії.
Цей підхід дає дві помітні переваги.
По?перше, зникає залежність від крихких селекторів. Якщо розмітка змінюється, але семантика сторінки зберігається, модель може «самозцілюватися» — переосмислити DOM і знайти новий шлях до тієї ж дії. Це особливо важливо для довгоживучих автоматизацій, де підтримка скриптів часто коштує дорожче, ніж їх початкова розробка.
По?друге, знижується поріг входу. Розробнику не потрібно бути експертом у внутрішній структурі кожного сайту, з яким працює агент. Достатньо описати завдання на рівні бізнес?логіки, а не DOM?деталей. Це робить Stagehand привабливим не лише для інженерів, які втомилися від Selenium, а й для команд, що хочуть швидко прототипувати AI?агентів без глибокого занурення в браузерну автоматизацію.
Чотири операції Stagehand: act, extract, observe, execute
Попри те, що Stagehand працює з природною мовою, його інтерфейс не розмитий. SDK формалізований навколо чотирьох базових операцій, які покривають більшість сценаріїв взаємодії з вебом: act, extract, observe та execute.
Операція act відповідає за дії на сторінці. Це все, що можна описати як «зроби щось»: натисни кнопку, заповни форму, прокрути сторінку, перейди за посиланням. Розробник формулює інструкцію мовою завдання, а Stagehand разом із LLM вирішує, які саме елементи DOM потрібно зачепити, щоб досягти результату. У традиційних фреймворках це десятки рядків коду з селекторами; тут — одна інструкція.
Extract фокусується на витягуванні даних. Це може бути як простий текстовий фрагмент, так і складніші структури. Ключова відмінність у тому, що Stagehand дозволяє описати очікуваний результат через JSON?схему. Замість того, щоб отримати «розмазаний» текстовий опис сторінки, розробник одразу отримує типізований об’єкт із чітко визначеними полями.
Observe — це спосіб «подивитися» на сторінку без активних дій. Йдеться про розуміння контексту: які елементи присутні, що відображається, які блоки контенту є важливими. Ця операція корисна як проміжний крок у складніших сценаріях, коли агенту потрібно спочатку зорієнтуватися, а вже потім діяти або витягувати дані.
Execute об’єднує попередні можливості в багатокрокові робочі процеси. Це вже не одинична дія чи разове витягування, а послідовність кроків: зайти на сайт, авторизуватися, перейти в потрібний розділ, зібрати дані, можливо, повторити цикл для кількох сторінок. Execute дозволяє описати такі сценарії на високому рівні, а Stagehand бере на себе управління станом браузера й координацію дій.
Разом ці чотири операції формують своєрідну «мову» для керування браузером через ШІ. Вони достатньо абстрактні, щоб не прив’язуватися до конкретної верстки, але водночас достатньо структуровані, щоб інтегруватися в реальні бекенд?сервіси, де важлива передбачуваність і контроль.
JSON?схеми та «чистий» скрейпінг: як витягувати структуру, а не текст
Одна з найбільших проблем при використанні LLM для веб?скрейпінгу — відсутність структури. Модель може чудово описати сторінку словами, але бекенд?сервісу потрібні не описи, а конкретні поля: заголовок, посилання, дата, рейтинг. Без додаткового шару обробки це перетворюється на парсинг вільного тексту, що знову ж таки крихко й ненадійно.
Stagehand вирішує це через підтримку JSON?схем. Розробник заздалегідь описує, яку саме структуру даних очікує отримати: наприклад, об’єкт із полями title, url, score та commentsCount. Ця схема передається разом із інструкцією до LLM, і модель повертає результат уже у вигляді валідного JSON, що відповідає заданому типу.
Практичний ефект відчутний одразу. Замість того, щоб писати додаткові парсери для вільного тексту, бекенд?код працює з передбачуваними об’єктами. Це спрощує валідацію, зберігання в базі даних, подальшу обробку й інтеграцію з іншими сервісами. Для команд, які будують складні пайплайни збору даних, це означає менше «клейового» коду й менше місць, де все може зламатися.
Показовий приклад — витягування топ?історії з головної сторінки Hacker News. У традиційному підході це вимагало б аналізу HTML?структури, пошуку класів, які відповідають заголовкам, посиланням, рейтингу, а також написання логіки для вибору саме першого елемента. У Stagehand достатньо однієї природномовної інструкції на кшталт «знайди топ?історію на головній сторінці Hacker News» у поєднанні з JSON?схемою очікуваного результату. LLM розуміє, як виглядає список історій, і повертає вже готовий структурований об’єкт.
Це не просто зручність. Такий підхід фактично піднімає рівень абстракції веб?скрейпінгу до рівня бізнес?завдань: «дай мені топ?історію», «зібери всі продукти з цієї категорії», «витягни останні вакансії за ключовим словом». Деталі DOM?структури стають внутрішньою проблемою моделі й Stagehand, а не розробника.
Мультистековість і локальний режим: Stagehand без прив’язки до хмари
Ще одна важлива риса Stagehand — відсутність жорсткої прив’язки до конкретної мови програмування чи до хмарної інфраструктури Browserbase. SDK доступний для кількох популярних мов: TypeScript, Python, Java, Go та Ruby. Це означає, що його можна вбудувати як у сучасні TypeScript?бекенди, так і в Python?скрипти для дата?інженерії, Java?сервіси у великих підприємствах чи мікросервіси на Go.
Для команд із гетерогенним стеком це знімає бар’єр впровадження. Немає потреби будувати окремий «острів» на новій мові лише заради браузерної автоматизації. Stagehand можна підключити там, де вже є основна бізнес?логіка, і поступово розширювати використання.
Не менш показовою є можливість запускати Stagehand проти локального браузера, взагалі не використовуючи хмарний сервіс Browserbase. Це відкриває кілька сценаріїв.
По?перше, локальне прототипування. Розробник може швидко перевірити ідею на своєму ноутбуці, не налаштовуючи віддалені сесії й не турбуючись про ліміти. Це особливо корисно на ранніх етапах, коли сценарії ще часто змінюються.
По?друге, робота на власній інфраструктурі. Для компаній із жорсткими вимогами до розміщення даних або для тих, хто вже має потужні сервери з браузерами, можливість використовувати Stagehand локально означає, що AI?керування браузером можна розгорнути повністю всередині свого контуру. При цьому зберігаються всі переваги природномовних інструкцій і JSON?схем.
І, по?третє, гнучкість міграції. Команда може почати з локального режиму, а згодом, коли з’явиться потреба в масштабуванні до десятків чи сотень одночасних сесій, перейти на хмарні браузери Browserbase, не змінюючи при цьому основний код, який працює зі Stagehand.
Model Gateway: один інтерфейс для OpenAI, Anthropic та інших
Якщо Stagehand відповідає за «руки» в браузері, то Model Gateway — за «мозок», який керує цими руками. Browserbase пропонує єдиний шлюз для доступу до різних LLM?провайдерів, що дозволяє обирати моделі на кшталт OpenAI чи Anthropic без необхідності окремо керувати кожним API?ключем і SDK.
У типовому проєкті, де використовуються кілька моделей, розробники стикаються з низкою практичних проблем. Потрібно зберігати й оновлювати кілька ключів, стежити за змінами в API кожного провайдера, писати адаптери для різних форматів запитів і відповідей. Це ускладнює як розробку, так і експерименти з новими моделями.
Model Gateway спрощує цю картину. З погляду коду, є один інтерфейс, через який надсилаються запити до LLM. Вибір конкретної моделі стає параметром конфігурації, а не окремим шляхом виконання. Якщо команда хоче протестувати, як Stagehand поводиться з іншою моделлю, це не вимагає переписування інтеграції — достатньо змінити налаштування.
Це особливо важливо в контексті браузерної автоматизації, де якість «розуміння» сторінки й здатність правильно інтерпретувати інструкції безпосередньо залежать від можливостей моделі. Для одних завдань може краще підходити одна LLM, для інших — інша. Model Gateway дозволяє підбирати оптимальну модель під конкретний сценарій, не перетворюючи це на інженерний проєкт.
Крім того, централізація доступу до моделей спрощує безпеку й облік. Замість того, щоб роздавати й ротути кілька ключів у різних сервісах, команда працює з одним шлюзом, де можна контролювати використання, ліміти й політики доступу.
Висновок: браузер як сервіс, інструкції як код
Stagehand і Model Gateway разом демонструють, як може виглядати наступне покоління веб?автоматизації. Замість того, щоб писати крихкі скрипти на основі селекторів і вручну інтегруватися з кількома LLM?провайдерами, розробник описує завдання природною мовою, визначає структуру очікуваних даних через JSON?схему й обирає модель через єдиний шлюз.
Можливість використовувати Stagehand у різних мовах програмування й запускати його як із хмарними браузерами Browserbase, так і з локальними сесіями, робить цей підхід придатним як для швидких експериментів, так і для серйозних продакшн?навантажень. А приклади на кшталт витягування топ?історії з Hacker News однією інструкцією показують, що «високорівневий» скрейпінг — це вже не теоретична можливість, а практичний інструмент.
У міру того як LLM?агенти все частіше виходять за межі чат?інтерфейсів і починають взаємодіяти з реальним вебом, подібні SDK і шлюзи можуть стати стандартним шаром інфраструктури — таким самим звичним, як сьогодні HTTP?клієнти чи ORM.
Джерело
AI Web Scraping Is Insanely Good | Browserbase Full Tutorial