Vercel تطلق agent-browser لوكلاء الذكاء الاصطناعي: وصول خفيف إلى المتصفح دون MCP

أطلقت Vercel أداة agent-browser التي تمنح وكلاء الذكاء الاصطناعي وصولاً إلى المتصفح دون طبقات MCP الثقيلة. والفكرة بسيطة: لا تُعرض على النموذج شجرة DOM الكاملة للصفحة، بل قائمة قصيرة بالعناصر التفاعلية التي يمكنه التعامل معها مباشرة.

لماذا يتعثر MCP

لن يختفي Playwright وPuppeteer؛ فهما أداتان قويتان لاختبارات e2e وCI/CD والاستخراج المتوقع للبيانات. تبدأ المشكلات عندما يُسلَّم المتصفح إلى LLM ليتحكم فيه عبر MCP. فلكي يفهم النموذج أين ينقر، عليه أن يرى الصفحة. وعادةً يُرسَل إلى السياق إما HTML الخام وإما شجرة إمكانية الوصول (accessibility tree). وفي تطبيقات الصفحة الواحدة (SPA) الحديثة، يتحول ذلك سريعاً إلى آلاف الرموز الإضافية في كل خطوة، ويستنزف ذاكرة الوكيل قبل أن يصل إلى هدفه أصلاً.

ووفقاً للبيانات التي يستند إليها كاتب التحليل، قد تكلّف نقرة واحدة مع لقطة لصفحة معقدة ما بين 15 و200 ألف رمز في الخطوة الواحدة. وهذا مكلف، وغير مستقر أيضاً: فالنموذج ينفق السياق في قراءة شجرة الصفحة، ثم يبدأ بالتخبط في محددات CSS، ويخطئ أكثر في إصابة الأزرار المطلوبة. أما في السيناريوهات الحتمية (deterministic) فهذا النهج لا يزال مقبولاً، لكنه ثقيل جداً على وكيل مستقل يُفترض أن يتنقل في الويب بسرعة.

ما الذي فعلته Vercel

كانت مهمة Vercel عملية: إذا كان الوكيل يكتب الواجهة بنفسه، فعليه أن يستطيع فتح الصفحة وفحص المكوّن وتنفيذ الإجراءات الأساسية في المتصفح. ولهذا بسّط الفريق agent-browser وأزال الارتباط السابق بخدمة Node الخلفية (daemon). والنسخة الحالية مبنية كأداة سطر أوامر خفيفة بلغة Rust تعمل مباشرة مع Chrome DevTools Protocol. ونتيجة لذلك، يسهل تشغيل الأداة محلياً، ويسهل وضعها في الحاويات، ولا حاجة إلى جلب بنية Node إضافية معها.

• ملف تنفيذي واحد بلغة Rust
• تواصل مباشر مع CDP دون طبقات وسيطة زائدة
• بلا أي اعتمادات (zero-dependency) لبيئات Docker والبيئات المحلية
• مراجع قصيرة بدلاً من DOM الكامل

الفكرة المحورية هي لقطة (snapshot) للعناصر التفاعلية. فبدلاً من الشجرة الضخمة، يحصل الوكيل على قائمة مدمجة مثل button "Sign In" [ref=e1] أو textbox "Email" [ref=e2]، ثم يعمل بأوامر قصيرة: افتح الصفحة، انقر على @e1، املأ الحقل @e2. وهذا الشكل لا يشغل عشرات الآلاف من الرموز، بل مئات منها. وهو يخفف العبء عن LLM بوضوح، ويقلل في الوقت نفسه احتمال تعطل الإجراء بسبب محدد هش.

واجهة جديدة للوكلاء

يظهر الفرق بوضوح في سيناريو بسيط: فتح موقع والنقر على أول مقال. في مخطط MCP التقليدي، يتلقى الوكيل أولاً شجرة إمكانية وصول ضخمة، ثم يبحث فيها عن العنوان المطلوب ويحاول بناء محدد CSS دقيق. وأي تغيير في التنسيق، أو نافذة منبثقة لملفات تعريف الارتباط (cookies)، أو حاوية زائدة، يجعل هذه النقرة هشة. أما في agent-browser فالمسار أقصر: open، ثم snapshot، ثم click على مرجع (ref) قصير. فالنموذج لا يعتمد على تخمين بنية DOM، بل على خريطة جاهزة للعناصر التفاعلية.

«لا تستخدموا MCP للمتصفح — وفّروا نوافذ السياق وأموالكم على API».

ومن اللافت أن Microsoft تروّج بدورها لفكرة مشابهة عبر @playwright/cli. فالوكيل هناك أيضاً يعمل بأوامر قصيرة، وتُحفظ حالة المتصفح خارج سياق النموذج. وهذا تحول مهم لفئة أدوات الوكلاء (agentic tooling) كلها: فالسوق يبتعد عن فكرة بث أحشاء المتصفح مباشرة إلى LLM، وينتقل إلى مخطط تحتفظ فيه الأداة المحلية بالحالة بنفسها، ولا تسلّم النموذج سوى الحد الأدنى اللازم من طبقة التحكم. والفرق بين الحلول اليوم يكمن في المنظومة المحيطة بها: Playwright يبقى أثقل، أما نهج Vercel القائم على Rust فهو أكثر تقشفاً.

ماذا يعني ذلك

تبدأ أتمتة المتصفح لوكلاء الذكاء الاصطناعي بالانقسام إلى فئتين. يبقى Playwright وPuppeteer التقليديان الأساس للاختبارات المعقدة واستخراج البيانات، لكن الطلب يزداد بوضوح على أغلفة سطر الأوامر الخفيفة في البرمجة بالوكلاء (agentic coding) والتحقق السريع من الواجهات. والخلاصة الرئيسية بسيطة: الأجدى لـ LLM ألا يُعطى المتصفح كاملاً، بل طبقة مدمجة من الأوامر والمراجع إلى العناصر. فهذا أرخص وأكثر استقراراً وأنفع في العمل الفعلي.