اگر امروز در حال ساخت یک عامل پژوهشی هستید که باید مقالات پولی را بخواند یا قیمت رقبا را رصد کند، احتمالاً به دیواری سخت برخورد کرده‌اید: مرورگری که روی یک ماشین مجازی ابری باز می‌شود، هیچ شباهتی به لپ‌تاپ یک انسان ندارد. وب‌سایت‌های مدرن به‌گونه‌ای طراحی شده‌اند که این تفاوت را در کسری از ثانیه تشخیص دهند و دسترسی شما را ببندند. توسعه‌دهنده‌ای که در اوت ۲۰۲۶ یک عامل پژوهشی می‌سازد، متوجه می‌شود که یک اسکریپت استاندارد Playwright دیگر برای دور زدن سیستم‌های مدرن تشخیص بات کافی نیست. شکاف بین مرورگری که در یک VM ابری باز می‌شود و مرورگری که روی لپ‌تاپ یک انسان اجرا می‌شود، به نقطه شکست اصلی در مرورگری عامل‌محور (Agentic Browsing) تبدیل شده است. اگر در حال ساخت دستیار پژوهشی هستید که باید مقالات پشت دیوار پرداخت (Paywall) را بخواند، یا بات قیمت‌گذاری که جریان‌های پرداخت رقبا را بررسی می‌کند، یا یک عامل عملیاتی که فرم‌های وب بدون API را پر می‌کند، به همان دیوار برخورد کرده‌اید: مرورگر شما در ابر، شبیه انسان نیست و وب‌سایت‌ها برای تشخیص این تفاوت ساخته شده‌اند.
این وضعیت باعث ایجاد یک تفکیک معماری در پشته‌ی فناوری هوش مصنوعی شده است. اکنون توسعه‌دهندگان باید دو جزء مجزا را انتخاب کنند: یک لایه‌ی استدلالی برای تصمیم‌گیری درباره‌ی اقدامات و یک لایه‌ی زیرساختی برای اجرای آن‌ها بدون مسدود شدن توسط سرویس‌هایی مثل کلودفلر (Cloudflare).
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل دسترسی به داده‌ها همواره نقطه حساس‌ترین بخش زنجیره است. در دنیای عامل‌های وب، این کنترل حالا به سطح «اثر انگشت مرورگر» منتقل شده است.
طبق گزارشی از dev.to که در ۲۰ اوت ۲۰۲۶ منتشر شد، صنعت به دو مجموعه‌ی مسئله تقسیم شده است. اول، مسئله‌ی استدلال است: سیستم باید با داشتن یک عکس از صفحه یا ساختار HTML (DOM snapshot) و یک هدف مشخص (مثلاً «یافتن ارزان‌ترین پرواز» یا «پر کردن این فرم پذیرش»)، تصمیم بگیرد که برای رسیدن به هدف، کجا کلیک کند، چه چیزی تایپ کند یا چقدر اسکرول کند. این یک حلقه‌ی مبتنی بر مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — است.
در این لایه، Browser Use به راهکار غالب تبدیل شده است. این چارچوب پایتونی با مجوز MIT، مدل‌های OpenAI، Gemini یا Claude را به مرورگر متصل می‌کند. مخزن گیت‌هاب این پروژه از ۱۰۰ هزار ستاره عبور کرده است. بر اساس محک Odysseys، این ابزار در ۲۰۰ وظیفه‌ی چندمرحله‌ای به نرخ موفقیت متوسط ۸۷ درصدی رسیده است، در حالی که در اجراهای دیگر، نرخ موفقیت آن در WebVoyager نزدیک به ۸۹ درصد گزارش شده است. با این حال، موفقیت فنی در بنچ‌مارک‌ها همیشه به معنای موفقیت در محیط واقعی نیست؛ چرا که شکاف میان مجوز فنی و قضاوت تجاری اغلب دلیل شکست عامل‌های AI در مقیاس سازمانی است.
مسئله دوم، زیرساخت است: یعنی اجرای یک نسخه‌ی Chromium در جایی که زنده بماند، در طول جلسات چندمرحله‌ای فعال بماند و انسانی به نظر برسد. اینجاست که Browserbase، Steel و Hyperbrowser وارد میدان می‌شوند. آن‌ها تصمیم نمی‌گیرند کجا کلیک شود، بلکه محیطی را فراهم می‌کنند که کلیک در آن اتفاق بیفتد. آن‌ها مدیریت چرخه حیات جلسه (Session)، ثبت داده‌ها برای عیب‌یابی (Debugging) و مدیریت هم‌زمانی (Concurrency) را بر عهده می‌گیرند.
Browserbase بر یک پلتفرم ابری متمرکز است که از جلسات Chromium از طریق پروتکل Chrome DevTools (CDP) استفاده می‌کند. این پلتفرم با Playwright، Puppeteer و Selenium سازگار است. ارزش اصلی این سرویس در «لایه‌ی مخفی‌ساز» (Stealth Layer) آن است که از اثر انگشت‌های اختصاصی Chromium برای جلوگیری از مسدود شدن‌های خاموش استفاده می‌کند. مکانیزم‌های کلیدی این پلتفرم عبارتند از:
- عامل‌های امضا شده (Signed Agents): مکانیزمی با هدف این است که ترافیک عامل‌ها به‌جای مسدود شدن خاموش توسط فروشندگانی مثل کلودفلر، شناسایی و پذیرفته شوند.
- حالت تأیید شده (Verified Mode): این قابلیت که در Stagehand در دسترس است، هویتی قابل بررسی به جلسه می‌دهد تا سایت‌هایی که ترافیک بات‌ها را به‌طور کامل می‌بندند، اجازه ورود دهند.
- قابلیت مشاهده (Observability): بازپخش کامل جلسات و ردیابی DOM را فراهم می‌کند. این به توسعه‌دهندگان اجازه می‌دهد دقیقاً ببینند چرا یک عامل در ساعت ۲ صبح شکست خورده است، به‌جای اینکه فقط به یک Stack Trace خالی خیره شوند.
در مقابل، Hyperbrowser رویکردی مشابه دارد اما بیشتر روی بسته‌بندی محیط‌های اجرای عامل (Agent Runtimes) روی جلسات خام تمرکز کرده است. این سرویس برای تیم‌هایی طراحی شده که حجم بسیار بالایی از استخراج داده (Scraping) و خزش (Crawling) دارند و در آن‌ها تخفیفات حجمی مهم‌تر از ابزارهای عمیق بازپخش جلسه است. هایپربراوزر شامل حل‌کننده داخلی کپچا (CAPTCHA) است و حالت مخفی‌ساز را به‌صورت پیش‌فرض ارائه می‌دهد، نه به‌عنوان یک افزونه در لایه‌های گران‌تر.
از سوی دیگر، Steel با ارائه یک API مرورگر متن‌باز تحت مجوز Apache 2.0 (موجود در گیت‌هاب در steel-dev/steel-browser با حدود ۷,۵۰۰ ستاره)، شرط متفاوتی را می‌بندد. این ابزار بر پایه Puppeteer و CDP ساخته شده و به‌سادگی از طریق دستور docker run -p 3000:3000 ghcr.io/steel-dev/steel-browser قابل میزبانی شخصی (Self-hosting) است.
استیل برای کسانی که می‌خواهند مالک زیرساخت خود باشند، مجموعه ویژگی‌های جامعی ارائه می‌دهد:
- مدیریت جلسه: تداوم کوکی‌ها و مدیریت زنجیره پروکسی.
- ابزارهای استخراج: تبدیل داخلی صفحه به Markdown، استخراج PDF و عکس.
- قابلیت گسترش: پشتیبانی از افزونه‌های مرورگر، ثبت درخواست‌ها (Request Logging) و پلاگین‌های مخفی‌ساز.
تفاوت اصلی این است که استیل ابزارهای مخفی‌سازی را فراهم می‌کند، اما سرمایه‌گذاری پژوهشی اختصاصی Browserbase روی اثر انگشت‌های ضد-تشخیص را ندارد. توازن در اینجا بین هزینه و کنترل است؛ میزبانی روی یک VPS می‌تواند هزینه را به حدود ۰.۰۵ تا ۰.۱۰ دلار به‌ازای هر ساعت مرورگر برساند، در حالی که مدل‌های SaaS هزینه‌های متفاوتی دارند.
مرز میان این دو لایه در Stagehand کمرنگ می‌شود. این SDK که محصول Browserbase است، مانند Browser Use عمل می‌کند و دستورات زبان طبیعی (مثلاً «روی دکمه ورود کلیک کن» یا «قیمت را استخراج کن») را با استفاده از یک LLM به اقدامات عینی Playwright تبدیل می‌کند.
با این حال، Stagehand به‌طور صریح برای اجرا روی جلسات مدیریت‌شده‌ی Browserbase طراحی شده است. اگرچه می‌تواند با Playwright یا Puppeteer معمولی هم کار کند، اما نماینده یک محصول بسته‌بندی شده است که در آن لایه‌ی استدلال، زیرساخت زیرین را پیش‌فرض می‌گیرد. این موضوع برای برخی راحتی ایجاد می‌کند و برای برخی دیگر خطر وابستگی به فروشنده (Vendor Lock-in).
در سال ۲۰۲۶، سه عامل این تصمیم را حیاتی کرده است. نخست، سیستم‌های تشخیص بات در شناسایی Chromiumهای بدون رابط گرافیکی (Headless) بسیار دقیق‌تر شده‌اند. فروشندگان اکنون ترتیب دست‌دادن TLS، ناهماهنگی‌های رندرینگ Canvas، اثر انگشت‌های WebGL و پرچم‌های اتوماسیون قابل تشخیص توسط CDP را بررسی می‌کنند. پرچم‌های ساده‌ای مثل --disable-blink-features=AutomationControlled دیگر کافی نیستند؛ مخفی‌سازی اکنون به یک دسته‌بندی محصول با قیمت‌گذاری مجزا تبدیل شده است.
دوم، عامل‌های هوش مصنوعی الگوهای ترافیک را تغییر داده‌اند. به‌جای اینکه یک اسکرپر یک میلیون بار به سه صفحه ضربه بزند، عامل‌ها هزاران جلسه کوتاه، غیرقابل‌پیش‌بینی و چندمرحله‌ای ایجاد می‌کنند. عامل از قبل نمی‌داند چند صفحه را بازدید خواهد کرد. این امر نیازمند زیرساخت‌های جدیدی برای مدیریت چرخه حیات جلسه و بازپخش در میانه اجرا است که با سرویس‌های کلاسیک پروکسی-اسکرپینگ متفاوت است.
سوم، ظهور فرهنگ محک (Benchmark). جدول‌های رده‌بندی مثل WebVoyager و Odysseys به بازار اجازه می‌دهند تا درباره کیفیت عامل‌ها با اعداد بحث کنند. این موضوع باعث جداسازی نحوه ارزیابی ابزارها شده است: استدلال با «نرخ موفقیت در وظیفه» سنجیده می‌شود، در حالی که زیرساخت با «زمان فعال بودن» (Uptime)، «تأخیر» (Latency) و «دوام مخفی‌ساز» ارزیابی می‌شود.
از نظر عملکرد، بنچ‌مارک‌های مصنوعی نشان می‌دهند که فروشندگان زیرساخت در حال نزدیک شدن به شروع جلسه در کمتر از یک ثانیه هستند. در یک مقایسه گزارش شده، Steel جلسات جدید را در حدود ۸۹۴ میلی‌ثانیه (میانه) و ۱,۰۹۰ میلی‌ثانیه (p95) شروع کرد. در آن اجرای خاص، Steel، Hyperbrowser و Kernel ۱۰۰٪ جلسات تست را به پایان رساندند، در حالی که Browserbase حدود ۹۹.۹۶٪ را تکمیل کرد.
اگرچه شکاف ۰.۰۴ درصدی نزدیک به نویز است، اما نشان می‌دهد که پایداری خام اکنون یک پیش‌نیاز است. تمایز واقعی به تجربه توسعه‌دهنده و دوام لایه‌ی مخفی‌ساز در برابر سیستم‌های تشخیص در حال تکامل منتقل شده است.
انتخاب پشته‌ی مناسب به اندازه تیم و بودجه بستگی دارد:
- توسعه‌دهندگان مستقل/استارتاپ‌های کوچک: بهتر است با کتابخانه متن‌باز Browser Use و مرورگر محلی شروع کنند. این سریع‌ترین راه برای اعتبارسنجی این است که آیا یک عامل اصلاً می‌تواند وظیفه‌ای را انجام دهد یا خیر، پیش از آنکه هزینه‌ای برای زیرساخت بپردازند.
- تیم‌های متوسط: معمولاً به سراغ Browserbase یا Hyperbrowser می‌روند. هزینه زمان یک مهندس که صرف عیب‌یابی یک شکست نامعلوم در مخفی‌سازی می‌شود، معمولاً از قیمت یک پلن مدیریت‌شده بیشتر است. Browserbase برای کسانی که نمی‌خواهند یک سطح زیرساختی دوم را مدیریت کنند، پیش‌فرض عمل‌گرایانه است.
- تیم‌های پلتفرم/داده: کسانی که ظرفیت Kubernetes یا DevOps دارند، اغلب Steel را ترجیح می‌دهند. آن‌ها می‌توانند «مالیات عملیاتی» نگهداری کانتینرها را بپذیرند تا از وابستگی به فروشنده دوری کرده و هزینه‌های بلندمدت را کاهش دهند.
در مورد توازن‌های عینی، مدل‌های هزینه متفاوت است. Browserbase بر اساس ساعت‌های مرورگر، فراخوانی‌های API و توکن‌های مدل صورت‌حساب می‌کند. پلن‌های آن شامل رایگان، Developer (۲۰ دلار در ماه)، Startup (۹۹ دلار در ماه) و Scale است. API Fetch آن به‌طور جداگانه محاسبه می‌شود (۱ تا ۷ دلار به‌ازای هر ۱,۰۰۰ فراخوانی بسته به فرمت خروجی). Steel در حالت ابری رایگان شروع می‌شود و مسیرهای میزبانی شخصی را می‌توان روی یک VPS ارزان اجرا کرد. کتابخانه Browser Use رایگان است، اما عامل ابری میزبانی‌شده آن از حدود ۳۰ دلار در ماه شروع می‌شود و شامل چرخش پروکسی و بیش از ۱,۰۰۰ ادغام است.
وابستگی و امنیت نیز موضوعات کلیدی هستند. مجوز Apache 2.0 استیل یک تمایز بزرگ است؛ چون قابل میزبانی شخصی است، تیم‌ها می‌توانند بدون بازنویسی کد، از ابر به زیرساخت خود منتقل شوند. Browserbase و Hyperbrowser فقط API-محور هستند و راه خروجی «خودت اجرا کن» ندارند. از نظر امنیتی، جلسات مدیریت‌شده کوکی‌های کاربر و توکن‌های احراز هویت را نگه می‌دارند. برای مشتریان تحت نظارت قانونی، تصمیم بین اعتماد به ایزولاسیون فروشنده یا میزبانی شخصی، یک تصمیم استراتژیک در مورد ریسک است، نه فقط هزینه.
توسعه‌دهندگان باید مراقب ادعاهای اثبات‌نشده درباره نرخ موفقیت باشند. مخفی‌سازی یک جنگ موش و گربه است؛ تنظیماتی که امروز کار می‌کند، ممکن است فردا با یک آپدیت در سیستم تشخیص فروشنده، شناسایی شود. این یک «مالیات نگهداری» است که فروشندگان مدیریت‌شده جذب می‌کنند؛ اگر روی Steel میزبانی کنید، این مالیات به‌صورت کار پژوهشی امنیتی به تیم شما بازمی‌گردد.
علاوه بر این، مدل‌های قیمت‌گذاری به‌شدت متفاوت است. چون یک اجرای عامل ممکن است شامل چندین تلاش مجدد و بارگذاری صفحه باشد، هزینه‌ها سریع‌تر از اسکرپینگ سنتی افزایش می‌یابند. تیمی که ده جلسه همزمان اجرا می‌کند از نظر هزینه با تیمی که یک جلسه طولانی برای نظارت بر یک داشبورد دارد، متفاوت است. Browserbase و Hyperbrowser تعداد جلسات همزمان را بر اساس پلن محدود می‌کنند که در صورت ویروسی شدن یک محصول، می‌تواند به یک دیوار سخت تبدیل شود.
در نهایت، چون اکثر این ابزارها از نقاط انتهایی سازگار با CDP استفاده می‌کنند، تغییر زیرساخت اغلب یک تغییر ساده در پیکربندی (یک wsEndpoint متفاوت) است. وابستگی واقعی زمانی رخ می‌دهد که تیم‌ها به ویژگی‌های اختصاصی مثل Signed Agents در Browserbase یا حل‌کننده داخلی کپچای Hyperbrowser متکی شوند.
برای جمع‌بندی این گزینه‌ها، تصمیم معمولاً به هدف اصلی بستگی دارد:
- برای عیب‌یابی (Debuggability): Browserbase به دلیل بازپخش جلسه و ردیابی DOM پیشرو است.
- برای هزینه/کنترل: Steel تنها راه viable برای کسانی است که می‌خواهند از طریق میزبانی Apache 2.0 از وابستگی به SaaS دوری کنند.
- برای توان عملیاتی (Throughput): Hyperbrowser برای خزش‌های حجیم و حل کپچا بهینه شده است.
- برای منطق (Logic): Browser Use استاندارد حلقه استدلال است، فارغ از اینکه مرورگر کجا میزبانی شود.
آنچه باید دید این است که آیا هیچ لایه مخفی‌سازی می‌تواند واقعاً در طول ماه‌ها استفاده تولیدی پایداری کند، یا اینکه بازی موش و گربه با کلودفلر نیازمند یک تغییر بنیادین در نحوه شناسایی عامل‌ها در وب خواهد بود.
گام بعدی شما
- اگر از Playwright استفاده می‌کنید، لایه‌ی Browser Use را برای مدیریت منطق استدلال امتحان کنید.
- برای کاهش هزینه‌های استنتاج در مقیاس بالا، استقرار Steel روی یک سرور شخصی را بررسی کنید.
- در صورت مواجهه با مسدود شدن‌های مکرر، از قابلیت Signed Agents در Browserbase برای شناسایی قانونی عامل خود استفاده کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو