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

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

لماذا يواجه MCP صعوبات

Playwright و Puppeteer لن تختفيا: وهما أدوات قوية لاختبارات e2e و CI/CD والتحليل القابل للتنبؤ. تبدأ المشاكل في اللحظة التي يتم فيها تسليم المتصفح للتحكم بواسطة LLM عبر MCP. لكي يفهم النموذج أين ينقر، يحتاج إلى رؤية الصفحة.

عادة ما يتم إرسال HTML خام أو شجرة إمكانية الوصول إلى السياق. في تطبيقات SPA الحديثة، يتحول هذا بسرعة إلى آلاف الرموز الإضافية في كل خطوة ويستهلك ذاكرة الوكيل قبل أن يصل إلى الهدف. وفقاً للبيانات التي يشير إليها مؤلف التحليل، قد يكلف النقر الواحد والتقاط لقطة من صفحة معقدة ما بين 15 إلى 200 ألف رمز لكل خطوة.

هذا ليس غالياً فحسب، بل غير مستقر أيضاً: ينفق النموذج السياق في قراءة شجرة الصفحة، ويبدأ في الالتباس في محددات CSS، وغالباً ما يفقد الأزرار المطلوبة. بالنسبة للسيناريوهات الحتمية، يكون هذا النهج محتملاً، لكن بالنسبة لوكيل مستقل يجب أن يتنقل بسرعة عبر الويب، فهو ثقيل جداً.

ماذا فعلت فيرسيل

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

• ملف تنفيذي واحد في Rust
• اتصال مباشر مع CDP بدون طبقات إضافية
• صفر تبعيات لـ Docker والبيئات المحلية
• مراجع قصيرة بدلاً من DOM الكامل

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

واجهة جديدة للعملاء

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

«لا تستخدم MCP للمتصفح — احفظ نوافذ السياق والأموال في API الخاصة بك.»

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

ماذا يعني هذا

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