Browserbase

تُعد Browserbase منصة بنية تحتية سحابية للمتصفحات بدون واجهة رسومية (headless) مصممة خصيصاً لوكلاء الذكاء الاصطناعي. تأسست الشركة في عام 2023 على يد Paul Klein IV، وهو مهندس سابق في Twilio والمدير التقني لشركة StreamClub، وتقوم بتشغيل مثيلات Chromium معزولة (sandboxed) في السحابة يمكن لوكلاء الذكاء الاصطناعي المعتمدين على النماذج اللغوية الكبيرة (LLM) الوصول إليها عبر اتصالات Playwright أو Puppeteer أو Selenium القياسية. المشكلة الأساسية التي تحلها هي ما يسميه Paul Klein "الـ 85% التي لا يمكن لواجهات برمجة التطبيقات (APIs) الوصول إليها": صفحات الويب، والبوابات، والتطبيقات الموثقة التي لا تحتوي على نقطة نهاية API قابلة للقراءة آلياً وتم تصميمها خصيصاً للمتصفحات البشرية. تجعل Browserbase هذه العناصر قابلة للوصول للوكلاء على نطاق الإنتاج.

تتكون المنصة من ثلاث طبقات. توفر طبقة البنية التحتية جلسات متصفح سحابية تُفوتر بنظام ساعة-متصفح، مع حل مدمج لاختبارات CAPTCHA، وبصمة تخفي (stealth fingerprinting)، وإدارة الوكلاء (proxy)، وإعادة تشغيل الجلسات مع تشغيل الفيديو. أما Stagehand فهي طبقة حزمة تطوير البرمجيات (SDK) مفتوحة المصدر (بترخيص MIT، وتدعم TypeScript و Python، وتحظى بأكثر من 22,400 نجمة على GitHub) والتي تغلف التحكم في المتصفح بأربعة أوامر أساسية للذكاء الاصطناعي: act() لتنفيذ الإجراءات باللغة الطبيعية، و extract() لاستخراج البيانات المهيكلة، و observe() لمعاينة ما سيفعله الإجراء، و agent() لتفويض المهام المستقلة متعددة الخطوات. بينما Director هي طبقة واجهة المستخدم باللغة الطبيعية، التي أُطلقت في يونيو 2025، وتتيح للمستخدمين غير التقنيين وصف عمليات الأتمتة بلغة إنجليزية بسيطة وإنشاء نصوص برمجية قابلة للتشغيل دون كتابة أي كود. اعتباراً من مارس 2026، تعالج Browserbase حوالي 37 مليون جلسة متصفح فريدة شهرياً عبر أكثر من 10,000 شركة، مع تحقيق Stagehand لـ 800,000 عملية تنزيل أسبوعية لحزمة SDK.

ما الذي تفعله Browserbase فعلياً في أبريل 2026

تمنح البنية التحتية لـ Browserbase الوكلاء مثيل متصفح Chromium كاملاً يمكن الوصول إليه عبر WebSocket باستخدام بروتوكول Chrome DevTools. يمكنك ربط كود Playwright أو Puppeteer الحالي الخاص بك بتغيير نقطة نهاية (endpoint) واحدة فقط؛ لتعمل الجلسة في سحابة Browserbase بدلاً من خادمك. ومن هناك، يمكن للوكيل التنقل، والنقر، وملء النماذج، والتعامل مع الصفحات المليئة بـ JavaScript، وحل اختبارات CAPTCHA تلقائياً، والاحتفاظ بملفات تعريف الارتباط (cookies) عبر الطلبات. تتضمن الجلسات عرضاً مباشراً مدمجاً (لمشاهدة المتصفح في الوقت الفعلي)، وإعادة تشغيل الفيديو بعد الجلسة، ولقطات DOM، وسجلات الأوامر (prompt logs) لتصحيح أخطاء عمليات التشغيل الفاشلة.

يُعد الإصدار Stagehand v3، الذي أُطلق في 29 أكتوبر 2025، علامة فارقة معمارية مهمة. بُنيت الإصدارات السابقة من Stagehand فوق Playwright؛ بينما انتقل الإصدار v3 إلى CDP الأصلي، مما جعله متوافقاً مع Puppeteer و Bun ومحركات القيادة الأخرى المعتمدة على CDP. يعمل إطار العمل الآن بشكل أسرع بنسبة 44% في المتوسط مقارنة بالإصدار v2، مع مكاسب ملحوظة في إطارات iframes المتداخلة وتفاعلات shadow DOM، والتي كانت تمثل أنماط الفشل السائدة لنصوص الوكلاء السابقة على تطبيقات الويب الحديثة. أضاف Stagehand v3 أيضاً التخزين المؤقت التلقائي للعناصر (automatic element caching): بمجرد أن تكتشف عملية تشغيل act() أو extract() عناصر الصفحة، تعيد عمليات التشغيل اللاحقة استخدامها دون الحاجة إلى استنتاج إضافي من النماذج اللغوية الكبيرة (LLM)، مما يقلل من زمن الوصول وتكاليف واجهة برمجة التطبيقات (API) لسير العمل المتكرر.

تستحق طبقة المراقبة (observability) في المنصة ذكراً منفصلاً لأنها ميزة تنافسية حقيقية. تتضمن إعادة تشغيل الجلسة فيديو كاملاً، وفحص DOM في أي إطار، وسجلاً يوضح أوامر LLM التي تم إطلاقها وما أرجعته. عندما يفشل وكيل في الخطوة 7 من سير عمل مكون من 12 خطوة، يمكنك التمرير إلى تلك اللحظة ورؤية ما كان يعرضه المتصفح بالضبط وما استنتجه النموذج. يفتقر المنافسون إما إلى ميزة إعادة التشغيل بعد الجلسة تماماً أو يقصرونها على خطط المؤسسات (enterprise).

"جعلت تشغيل جلسات متصفح حقيقية لوكلاء الذكاء الاصطناعي لدينا أمراً سهلاً للغاية. بدونها، سيكون بناء النظام بأكمله وتوسيع نطاقه أصعب بـ 10 مرات.". Elijah Muraoka، مؤسس Soshi، على Product Hunt، يونيو 2025

"كانت واجهة برمجة التطبيقات (API) سهلة الدمج، وتوفر مجموعة ميزات بالغة الأهمية للعديد من حالات استخدام الأعمال.". Zach Tratar، مؤسس Embra، على Product Hunt، مايو 2025

موقع Browserbase مقارنة بـ Apify و Anchor Browser

يحتوي مجال المتصفحات بدون واجهة رسومية وأتمتة الوكلاء على ثلاث بنيات معمارية متميزة على الأقل، وتمثل كل من Browserbase و Apify و Anchor Browser بنية مختلفة منها.

Browserbase مقابل Apify: تُعد Apify سوقاً للأتمتة مبنياً حول "Actors"، وهي وظائف Node.js أو Python بدون خادم (serverless) تكتبها مرة واحدة وتنشرها على سحابتهم. الاختلاف الهيكلي الرئيسي هو أن نموذج Apify يعتمد على تنفيذ مهام مبرمجة مسبقاً من مكتبة (أكثر من 4,000 Actor جاهز لمواقع محددة مثل LinkedIn و Amazon و Google Maps)، بينما توفر Browserbase جلسات متصفح خام غير مبرمجة يعمل منطق وكيلك فوقها. إذا كنت بحاجة إلى استخراج بيانات من موقع يحتوي بالفعل على Apify Actor، فإن Apify أسرع في البدء. أما إذا كنت تبني وكيلاً يواجه صفحات جديدة غير متوقعة، أو أداة مبيعات برمجيات تتنقل في بوابات الموردين، أو وكيل أبحاث يصل إلى قواعد بيانات حكومية غامضة، فإن نموذج Actor الخاص بـ Apify لن يغطيك. يمكنك استدعاء Apify من منسق (orchestrator) كأداة معروفة؛ بينما Browserbase هي السطح الذي تعيش عليه حلقة المتصفح الكاملة لوكيلك. يختلف نموذج التكلفة أيضاً: تُفوتر Apify بناءً على وحدة الحوسبة لـ Actor وعرض النطاق الترددي للوكيل (proxy)، دون وجود طبقة تصحيح أخطاء لإعادة تشغيل الجلسة مصممة لحالات استخدام الوكلاء.

Browserbase مقابل Anchor Browser: تُعد Anchor أقرب فلسفياً إلى Browserbase: فكلاهما يوفر جلسات متصفح سحابية يمكن الوصول إليها عبر CDP. ما يميز Anchor هو تجريد نقطة نهاية "الأدوات الوكيلة" (agentic tools) الخاصة بها، فبدلاً من الوصول الخام إلى CDP، يمكنك استدعاء نقاط نهاية عالية المستوى مثل "perform web task" أو "navigate to". تعطي Anchor الأولوية للتنفيذ الحتمي (deterministic) من خلال البرمجة النصية الصريحة. في اختبار أداء عام 2025 يقارن سرعة إنشاء الجلسة، بلغ متوسط Anchor حوالي 13.1 ثانية مقابل 11.9 ثانية لـ Browserbase، على الرغم من أن Anchor تعاملت مع 3/3 جلسات متوازية في الفئة المجانية بينما قامت Browserbase بتشغيلها بالتسلسل. حيث تتخلف Anchor بوضوح هو النظام البيئي: لا يوجد مكافئ في Anchor لـ Stagehand، وهي حزمة SDK مفتوحة المصدر التي تضم أكثر من 22 ألف نجمة والتي اعتمدتها مئات فرق التطوير كمعيار. كما أن أدوات المراقبة في Browserbase (إعادة تشغيل الفيديو بعد الجلسة، ولقطات DOM) أكثر اكتمالاً؛ حيث تقدم Anchor عرضاً مباشراً أثناء التنفيذ ولكن ليس إعادة تشغيل بعد الجلسة. بالنسبة للفرق التي تريد وصولاً خاماً إلى المتصفح بالإضافة إلى إطار عمل مدعوم جيداً وذو رأي حوله، فإن Browserbase هي الإجابة الكاملة. أما بالنسبة للفرق التي تريد واجهات برمجة تطبيقات (APIs) لمهام حتمية عالية المستوى دون كتابة منطق الوكيل الخاص بها، فإن Anchor تستحق التقييم.

كيف يبدو واقع حلقة وكيل Stagehand

يقع سير عمل Stagehand بين نمطين من الفشل: Playwright الخالص (سريع ورخيص ولكنه يتعطل في كل مرة يتغير فيها اسم الفئة) وحلقات وكيل LLM الخالصة (مرنة ولكنها باهظة الثمن وبطيئة وغير حتمية). يجبرك تصميم Stagehand على اختيار مدى تدخل الذكاء الاصطناعي الذي تريده، خطوة بخطوة.

بالنسبة لوكيل تطوير المبيعات (SDR) النموذجي، سيكتب المطور كوداً حتمياً للأجزاء المستقرة (الانتقال إلى عنوان URL معروف، وتسجيل الدخول ببيانات اعتماد مخزنة) ويستخدم act() للأجزاء التي تتغير (النقر على زر نموذج الاتصال، والذي قد يُسمى بشكل مختلف عبر المواقع). تقوم extract() بسحب البيانات المهيكلة من الصفحة دون مطالبتك بكتابة محددات CSS التي تتعطل عند إعادة التصميم. تتيح لك observe() معاينة ما سيفعله Stagehand قبل التنفيذ، وهو أمر مفيد لبناء تغطية الاختبار أو تسجيل النوايا. تسلم أداة agent() الأهداف متعددة الخطوات بالكامل إلى نموذج LLM الأساسي، وهو مفيد للمهام الاستكشافية حيث يكون المسار غير معروف.

التحدي العملي الذي يواجهه المطورون هو التكلفة. كل استدعاء لـ act() أو extract() يطلق طلب LLM ما لم يتم تخزين العنصر مؤقتاً من عملية تشغيل سابقة. في وقت مبكر من التطوير، قبل ملء ذاكرة التخزين المؤقت، تتراكم التكاليف. أشار المطورون على Hacker News إلى أن Playwright المجرد قد يكون أرخص لسير العمل ذي هياكل الصفحات المستقرة والمعروفة. يعالج التخزين المؤقت التلقائي للعناصر في Stagehand v3 هذا الأمر مباشرة لسير العمل المتكرر، لكن الصفحات الجديدة لا تزال تتكبد تكاليف استنتاج LLM في كل مرة.

تصحيح الأخطاء هو المجال الذي تثبت فيه منصة Browserbase جدارتها مقارنة بـ Playwright المحلي. عندما يفشل وكيل عند حالة صفحة غير متوقعة، أو إعلان بيني، أو خطأ مقفل إقليمياً، أو متغير اختبار A/B لم يره الوكيل، تتيح لك إعادة تشغيل الجلسة التمرير إلى الإطار الدقيق وفهم حالة DOM التي كان النموذج يحللها. بدون ذلك، يكون تصحيح أخطاء عمليات تشغيل الوكيل الفاشلة بمثابة إعادة بناء انهيار من تتبع المكدس (stack trace). أما معها، فلديك فيديو.

لمن صُممت Browserbase

تُعد Browserbase الخيار الافتراضي للفرق التي تبني وكلاء ذكاء اصطناعي للإنتاج يحتاجون إلى التفاعل مع الويب المباشر على نطاق واسع. يغطي ذلك مجموعة واسعة من فئات المنتجات: ممثلو تطوير مبيعات الذكاء الاصطناعي (11x هي أحد العملاء البارزين)، ووكلاء الأبحاث الذين يجمعون البيانات من المواقع التي لا تحتوي على واجهات برمجة تطبيقات (APIs)، وبدائل أتمتة العمليات الآلية (RPA) التي تتعامل مع البوابات الحكومية والنماذج القديمة، وأدوات الاستخبارات التنافسية التي تراقب الأسعار وقوائم الوظائف، وأدوات المطورين التي تُجري اختبارات القبول المستندة إلى المتصفح عبر واجهات المستخدم المتغيرة.

تناسب حزمة Stagehand SDK تحديداً مطوري TypeScript و Python الذين يشعرون بالراحة بالفعل مع Playwright ويريدون إضافة طبقة من أوامر الذكاء الاصطناعي الأساسية فوقه بدلاً من تبديل أطر العمل بالكامل. منحنى التعلم بسيط: تستمر نصوص Playwright الحالية في العمل؛ وتضيف استدعاءات act() حيث كانت المحددات الهشة موجودة.

تحصل فرق المؤسسات على قيمة مضافة من طبقة المراقبة. تعد القدرة على إعادة تشغيل ما رآه الوكيل وقرره بالضبط في كل خطوة أمراً مهماً للامتثال في الصناعات الخاضعة للوائح، وتصحيح الأخطاء التي يبلغ عنها العملاء، وتحسين أوامر الوكيل بمرور الوقت. يمكن للشركات التي لديها متطلبات HIPAA الحصول على تغطية اتفاقية شراكة الأعمال (BAA) في خطة Scale.

تُعد المنصة أيضاً مناسبة جداً للشركات الناشئة التي ترغب في تخطي بناء البنية التحتية بالكامل. يتضمن تشغيل متصفحات موثوقة بدون واجهة رسومية على نطاق واسع تدوير الوكلاء (proxy rotation)، وخدمات CAPTCHA، وبصمة المتصفح، وإدارة حالة الجلسة، والمراقبة. تقوم Browserbase بتجريد كل ذلك في واجهة برمجة تطبيقات (API) واحدة وفاتورة شهرية.

ما لا تقدمه Browserbase

ليست Browserbase الخيار الصحيح عندما تحتاج إلى العديد من جلسات المتصفح القصيرة جداً. الحد الأدنى للفوترة البالغ دقيقة واحدة يعني أن فحص نموذج يستغرق 10 ثوانٍ يُفوتر كدقيقة كاملة. إذا كان سير عملك يتضمن مئات التفاعلات السريعة والحتمية، أو فحوصات الأسعار، أو اختبارات الحالة (status pings)، أو عمليات التحقق من webhook، فإن نموذج التكلفة سيعمل ضدك. سيكون إعداد Playwright المستضاف ذاتياً أو واجهة برمجة تطبيقات (API) استخراج بيانات أخف وزناً أرخص.

كما أنها ليست بديلاً عن البنية التحتية التقليدية لاستخراج بيانات الويب (web scraping) عندما يكون للمواقع المستهدفة بنية معروفة ومستقرة وتوجد Actors مبنية مسبقاً بالفعل في سوق Apify. إذا كنت بحاجة إلى بيانات منتجات Amazon، أو ملفات تعريف LinkedIn من تصدير مهيكل، أو نتائج Google SERP على نطاق واسع، فإن أدوات استخراج البيانات المصممة لهذا الغرض تتمتع بتسعير أكثر كفاءة لتلك الأهداف المعروفة.

يجب على الفرق التي تبحث عن برمجة نصية حتمية بالكامل دون تدخل LLM في وقت التشغيل أن تبحث في مكان آخر، أو يجب أن تستخدم البنية التحتية لـ Browserbase مع كود Playwright العادي وتتخطى Stagehand تماماً. تعمل المنصة بدون Stagehand؛ فالوصول إلى المتصفح هو الأساس. لكن بنية LLM في وقت التشغيل الخاصة بـ Stagehand هي مقايضة حقيقية: فهي تضيف تكلفة وعدم حتمية إلى كل خطوة تستدعي فيها الذكاء الاصطناعي. بالنسبة للفرق التي تجد هذا مقبولاً، فإن مرونة Stagehand تجاه تغييرات واجهة المستخدم تستحق العناء. أما بالنسبة للفرق التي تبني مسارات عمل خاضعة لرقابة صارمة وعالية التردد حيث يهم كل سنت لكل عملية تشغيل، فإن الحسابات تختلف.

أخيراً، تظل تدفقات المصادقة (authentication flows) مصدر قلق حقيقي بشأن الموثوقية. أظهرت الاختبارات على مسارات العمل التي تعتمد بكثافة على تسجيل الدخول والتي تتضمن رموز OTP والتحقق من البريد الإلكتروني معدلات فشل تبلغ حوالي 60%. يتعامل حل CAPTCHA الخاص بـ Browserbase مع اختبارات CAPTCHA المرئية بشكل جيد؛ بينما تتطلب تدفقات OTP المستندة إلى البريد الإلكتروني والحساسة للوقت تنسيقاً إضافياً لا توفره المنصة حالياً بشكل أصلي.