اگر امروز برای اتوماسیون وب روی اسکریپتهای سختافزاری حساب میکنید، احتمالاً با هر تغییر کوچک در ظاهر سایتها، کل سیستم شما از کار میافتد. در سال ۲۰۲۶، پاسخ این چالش نه در جایگزینی کامل، بلکه در یک پشتهٔ ترکیبی است که وظایف را بین اسکریپتهای صلب و عاملهای استدلالی تقسیم میکند.
در این مدل، Playwright ستون فقرات پیشبینیپذیر یک گردشکار را مدیریت میکند و Browser Use تنها زمانی وارد عمل میشود که API در دسترس نباشد یا چیدمان صفحه تغییر کند. تفاوت بنیادین این است: Playwright اسکریپتهای قطعی را اجرا میکند که سریع و دقیقاند اما با تغییر DOM میشکنند؛ در مقابل, Browser Use فرمان را به یک مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — میسپارد تا بر اساس آنچه میبیند استدلال کند و مثلاً دکمهٔ «ارسال» را حتی اگر نام کلاس آن تغییر کرده باشد، پیدا کند.
سالها بود که توسعهدهندگان برای استخراج داده یا تست اپلیکیشنها به چارچوبهای قطعی تکیه میکردند. این ابزارها سریع و ارزاناند، اما لحظهای که یک توسعهدهنده نام یک کلاس CSS را تغییر دهد، متلاشی میشوند. این شکنندگی شکافی را ایجاد کرد که اکنون عاملهای هوش مصنوعی با «دیدن» صفحه شبیه به انسان، آن را پر میکنند. همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، اعتماد به استقلال کامل مدلها ریسکآور است؛ بنابراین هیچکدام از این دو ابزار جایگزین دیگری نیستند، بلکه هر کدام در جایگاه خود برنده است.
تصور کنید در یک فرآیند خرید، مراحل ورود و سبد خرید هرگز تغییر نمیکنند، اما صفحهٔ تأیید نهایی پویا و غیرقابلپیشبینی است. استفاده از LLM برای کل مسیر، بیش از حد کند و گران است و استفاده از اسکریپت برای کل مسیر، بیش از حد شکننده. راهکار، رویکرد «مغز دوقلو» است: Playwright برای ۸۰٪ کارهای خستهکننده و یک عامل هوش مصنوعی برای ۲۰٪ پیشبینیناپذیر.
ظهور Browser Use
Browser Use یک کتابخانه متنباز پایتون است که هر LLM را به یک عامل اتوماسیون مرورگر تبدیل میکند. این ابزار بهجای دنبال کردن یک مسیر کدنویسیشده، در یک حلقهٔ عاملی عمل میکند. طبق مستندات این پروژه، کتابخانه ابتدا یک اسکرینشات یا درخت دسترسی (Accessibility Tree) از صفحه میگیرد و آن را همراه با شرح وظیفه به مدل میفرستد و میپرسد: «با توجه به آنچه میبینی، اقدام بعدی چیست؟»
مدل با یک اقدام ساختاریافته — مانند کلیک، تایپ، اسکرول یا جابهجایی — پاسخ میدهد و کتابخانه آن را اجرا میکند. این چرخه تا زمان تکمیل وظیفه تکرار میشود. این یعنی عامل بر اساس ادراک و نه انتخابگرهای (Selectors) سختافزاری تصمیم میگیرد.
به نقل از بررسی سال ۲۰۲۶ وبسایت BuildFastWithAI، این چارچوب در محک WebVoyager با ۵۸۶ وظیفه، به نرخ موفقیت ۸۹.۱٪ رسید. همچنین در جدول Odysseys با میانگین ۸۷.۴٪ رتبه اول را کسب کرد و از عاملهای اختصاصی OpenAI، Anthropic، Google و Microsoft پیشی گرفت. این موفقیت در حالی رخ میدهد که برخی بنچمارکهای سختگیرانهتر نشان میدهند عاملهای هوش مصنوعی هنوز در مراحل حساس اعتبارسنجی کد با چالشهای جدی روبرو هستند.
رشد این پروژه خیرهکننده بوده است. سه ماه پس از عرضه به ۲۵ هزار ستاره در گیتهاب رسید و عضو دوره زمستان ۲۰۲۵ Y Combinator شد. اکنون با تیمی ۷ نفره، بیش از ۷۹ هزار ستاره دارد. برای تسریع در استقرار، تیمی از توسعهدهندگان بازاری ایجاد کردهاند که بیش از ۱۲۰۰ اتوماسیون ساختهشده توسط جامعه را شامل میشود.
علاوه بر کتابخانه متنباز، این شرکت مدلهای میزبانیشدهای را عرضه میکند که بهطور خاص برای اقدامات مرورگر تنظیم شدهاند، از جمله ChatBrowserUse و BU 2.0. این مدلها برای تیمهایی طراحی شدهاند که زیرساختهای مدیریتشده را به میزبانی شخصی ترجیح میدهند.
چرا Playwright همچنان پیشفرض است؟
با وجود ظهور عاملها، Playwright — چارچوب اتوماسیون مرورگر متنباز مایکروسافت — همچنان سنگبنای صنعت است. طبق مقایسه NxCode در آوریل ۲۰۲۶، این ابزار حدود ۸۵ هزار ستاره در گیتهاب دارد و برای تستهای End-to-End و استخراج داده طراحی شده است.
Playwright «استدلال» نمیکند. این ابزار از قابلیتهای انتظار خودکار و بررسی قابلیت اقدام استفاده میکند تا یک المان را در میلیثانیه پیدا کرده و روی آن کلیک کند. برای خط لولههای CI/CD با حجم بالا، این یک ویژگی است. شما نمیخواهید یک LLM تصمیم بگیرد که آیا دکمه «اکنون بخرید» باید کلیک شود یا خیر؛ شما میخواهید این اتفاق هر بار دقیقاً به یک شکل و با هزینه استنتاج (Inference) — لحظهای که مدل واقعاً جواب تولید میکند، شبیه به خودِ آشپزی و نه دورهی آموزش آشپز — صفر رخ دهد. در همین راستا، بهینهسازیهای جدید در مدلهایی مانند Claude Sonnet 5 تلاش کردهاند تا هزینه استنتاج را کاهش داده و قابلیتهای عاملمحور را برای چنین کاربردهایی افزایش دهند.
مقایسه Browser Use در برابر Playwright
برای انتخاب ابزار مناسب، این تفاوتهای فنی را در نظر بگیرید:
- رویکرد اصلی: Browser Use از استدلال LLM روی وضعیت صفحه استفاده میکند؛ Playwright از اسکریپتهای قطعی با انتخابگرهای دقیق.
- تابآوری: در Browser Use بالا است (با تغییرات چیدمان سازگار میشود)؛ در Playwright پایین است (با تغییر DOM میشکند).
- سرعت: Playwright سریع است (فراخوانیهای بومی مرورگر)؛ Browser Use کندتر است (استنتاج LLM در هر گام).
- هزینه: Playwright بهجز هزینه محاسباتی رایگان است؛ Browser Use برای هر اقدام هزینه توکن دارد.
- قطعی بودن: در Playwright بالا است (اسکریپت یکسان، نتیجه یکسان)؛ در Browser Use کمتر است (انتخابهای مدل در هر اجرا متفاوت است).
- بهترین کاربرد: Browser Use برای عاملهای پژوهشی و پر کردن فرمها در سایتهای ناشناخته؛ Playwright برای تستهای رگرسیون و استخراج داده از سایتهای شناختهشده.
پیادهسازی در محیط عملیاتی سال ۲۰۲۶
بسیاری از تیمهای پیشرو اکنون قانون «۸۰/۲۰» را اجرا میکنند. آنها از Playwright برای ۸۰٪ مسیرهای خستهکننده — مانند ورود، جابهجایی و ارسال فرم در سایتهای شناختهشده — استفاده میکنند. Browser Use را برای ۲۰٪ پیشبینیناپذیری که نیاز به قضاوت بصری دارد، مانند مدیریت یک چیدمان ناآشنا یا صفحاتی که با هر استقرار تغییر میکنند، رزرو میکنند.
این الگو، Browser Use را بهعنوان یک ابزار در ارکستراتورهای بزرگتری مانند LangGraph، CrewAI یا AutoGen ادغام میکند. ارکستراتور تنها زمانی «دستهای مرورگر» عامل را فرا میخواند که مسیر قطعی Playwright شکست بخورد. این کار باعث میشود سیستم سرعت یک اسکریپت را با قابلیت پشتیبان یک هوش مصنوعی حفظ کند.
ریسکها و محدودیتها
Browser Use یک راهکار جادویی نیست. این ابزار در حجمهای کاری بالا و حساس به تأخیر دچار مشکل میشود، زیرا هر اقدام باید یک بار از طریق API مدل رد و بدل شود. این موضوع ثانیههای زیادی به هر کلیک اضافه میکند که در هزاران اجرا، اثرش چند برابر میشود.
عیبیابی (Debugging) نیز بهمراتب سختتر است. چون مسیر مدل در هر اجرا میتواند متفاوت باشد، نمیتوانید به یک Stack Trace ساده در Playwright تکیه کنید که به یک انتخابگر خراب اشاره کند؛ بلکه باید فرآیند استدلال مدل را تحلیل کنید.
امنیت بحرانیترین نگرانی است. عاملی که روی محتوای دلخواه صفحه استدلال میکند، هر متن و دستوری را که در صفحه باشد میخواند. این موضوع عامل را در معرض تزریق پرامپت (Prompt Injection) قرار میدهد. اگر سایتی حاوی دستورات مخفی باشد، عامل ممکن است از آنها پیروی کند و سطح حمله امنیتی بزرگی ایجاد کند.
یک مثال ساده از Browser Use
در پیادهسازی Browser Use، انتخابگرها بهطور کامل حذف میشوند. بهجای استفاده از page.locator(...) یا XPath، کد به این شکل است:
from browser_use import Agent
from langchain_openai import ChatOpenAI
agent = Agent(
task="Go to codeoxi.com/blog, find the newest post about AI agents, and return its title",
llm=ChatOpenAI(model="gpt-4o"),
)
result = await agent.run()
print(result)
تمام جذابیت اینجاست: عامل خودش جابهجایی و هدفگیری المانها را پیدا میکند و فراخوانیهای بومی رایگان را با چند فراخوانی LLM در هر گام معاوضه میکند.
قیمتگذاری و مقیاسپذیری
برای کسانی که نمیتوانند میزبانی شخصی داشته باشند، Browser Use لایههای ابری مدیریتشدهای را ارائه میدهد. طبق بررسی سال ۲۰۲۶ وبسایت O-mega.ai، این لایهها عبارتاند از:
- Dev: ۲۹ دلار در ماه
- Business: ۲۹۹ دلار در ماه
- Scaleup: ۹۹۹ دلار در ماه
این لایهها هزینههای ماهانه را به اعتبارات مصرفی برای زمان مرورگر، پهنای باند و توکن تبدیل میکنند. این مدل زمانی منطقی است که میزبانی شخصی فراخوانیهای LLM به گلوگاه اصلی تبدیل شود.
برای یک ابزار داخلی کوچک یا یک پروژه استخراج داده یکباره از سایتی بدون API، مسیر متنباز و رایگان سریعترین راه است چون وظیفه را به زبان انگلیسی توصیف میکنید. اما برای یک فرآیند خرید حیاتی که در هر استقرار تست میشود، یک اسکریپت پنجخطی Playwright همچنان قابلاعتمادترین و بهصرفهترین انتخاب است.
پرسشهای متداول
Browser Use چیست؟
یک کتابخانه متنباز پایتون (با بیش از ۷۹ هزار ستاره) است که LLM را به مرورگر متصل میکند تا بهجای دنبال کردن انتخابگرهای سختافزاری، با استدلال روی صفحه جابهجا شده و داده استخراج کند.
آیا Browser Use بهتر از Playwright است؟
نه بهطور کلی. برای وظایف پیشبینیناپذیر، یکباره یا بدون API بهتر است. Playwright برای جریانهای پایدار، حجیم و تکرارپذیر که سرعت و هزینه صفر استنتاج در آنها حیاتی است، برنده است.
آیا Browser Use رایگان است؟
بله، کتابخانه اصلی رایگان و متنباز است. لایههای ابری پولی برای زیرساختهای مدیریتشده و مدلهای بهینهشده مرورگر در دسترس هستند.
آیا Browser Use میتواند جایگزین Selenium یا Puppeteer شود؟
برای وظایفی که نیاز به استدلال بصری روی صفحات متغیر دارند، بله. برای اتوماسیونهای قطعی و حجیم، Selenium، Puppeteer و Playwright سریعتر و ارزانتر میمانند.
Browser Use از چه مدلهایی پشتیبانی میکند؟
با هر LLM متصلی از جمله OpenAI، Anthropic و Google و همچنین مدلهای اختصاصی خودش مانند ChatBrowserUse و BU 2.0 کار میکند.
آیا Browser Use برای محیط عملیاتی امن است؟
برای وظایف با محدوده مشخص امن است، اما تیمها باید آن را در محیط ایزوله (Sandbox) قرار دهند تا در برابر تزریق پرامپت از صفحات مخرب محافظت کنند.
نتیجهگیری: حکم نهایی ما
Browser Use و Playwright رقیب نیستند، بلکه دو نیمه از یک مشکل را حل میکنند. حکم ما این است: برای هر چیز تکرارپذیر روی Playwright حساب کنید و برای هر چیزی که نیاز به قضاوت روی صفحهای دارد که کنترل کاملش با شما نیست، از Browser Use استفاده کنید.
تیمهایی که در سال ۲۰۲۶ بیشترین ارزش را خلق میکنند، این دو را در کنار هم اجرا میکنند؛ Playwright ستون فقرات قطعی را مدیریت میکند و عامل هوش مصنوعی تنها جایی وارد میشود که اسکریپتهای سختافزاری مدام میشکنند. برای ساخت یک پشته تابآور، ابتدا لایه قطعی خود را با Playwright تثبیت کنید و سپس Browser Use را برای بخشهایی که واقعاً به «مغز» نیاز دارند، روی آن قرار دهید.
گام بعدی شما
- اگر اسکریپتهای وب شما مدام بهدلیل تغییر UI میشکنند، بخشهای متغیر را شناسایی کرده و با Browser Use جایگزین کنید.
- برای کاهش هزینهها، از یک ارکستراتور مانند LangGraph استفاده کنید تا فقط در صورت شکست Playwright، مدل LLM فراخوانی شود.
- محیطهای اجرای عاملهای مرورگر را بهطور کامل ایزوله کنید تا ریسک تزریق پرامپت از سایتهای خارجی به حداقل برسد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو