كيف تبني وكيل ذكاء اصطناعي للمتصفح بلغة Python: دليل خطوة بخطوة من Machine Learning Mastery

تتجاوز وكلاء الذكاء الاصطناعي للمتصفح حدود الدردشة وواجهات API. فبات بإمكان وكيل Python اليوم فتح المواقع والنقر على الأزرار وملء النماذج تماماً كما يفعل المستخدم الحقيقي.

لماذا المتصفح وليس API

تبدأ معظم الدروس التعليمية حول وكلاء الذكاء الاصطناعي باستدعاء API. غير أن الإنترنت الفعلي يعمل بطريقة مختلفة: فجزء كبير من البيانات والوظائف المطلوبة يختبئ خلف النماذج وأنظمة المصادقة والصفحات الديناميكية، أي في مواضع لا تصلها واجهة API الرسمية.

ماذا لو لم تكن هناك واجهة API عامة لموقع أحد المنافسين؟ وماذا لو تطلّب الأمر تسجيل الدخول واجتياز عدة خطوات من النماذج؟ في هذه الحالات لا تفيد أدوات الكشط (scraper) التقليدية.

نشر Machine Learning Mastery دليلاً عملياً مفصلاً لبناء وكيل متصفح بلغة Python. والفارق عن أداة الكشط التقليدية جوهري: فالوكيل لا يحلّل HTML ثابتاً، بل يرى الصفحة ويتصرف عليها. فهو يستجيب للتغييرات في الواجهة، ويتجاوز عناصر الحماية البسيطة، ويحاكي سلوك المستخدم الحقيقي. وهذا النهج تحديداً يجعل وكلاء المتصفح أداة أتمتة شاملة لا تعتمد على وجود API رسمي لدى موقع أو خدمة بعينها.

كيف يعمل وكيل المتصفح

تتكون البنية من ثلاثة مكونات. الأول نموذج لغوي (GPT-4o أو Claude أو LLM آخر) يقرأ وصف الصفحة ويقرر ما يجب فعله بعد ذلك. والثاني أداة للتحكم في المتصفح، وغالباً Playwright، وهي التي تفتح الصفحات فعلياً وتنقر على العناصر وتدخل النصوص وتمرّر الصفحة. والثالث طبقة orchestration: شيفرة تنقل المعلومات بين LLM والمتصفح وتدير حلقة التنفيذ.

تسير حلقة عمل الوكيل على النحو التالي: يتلقى المهمة في صورة نص، ويفتح المتصفح، ويقرأ بنية DOM للصفحة الحالية، ثم يضغطها ويصفّيها لتقتصر على العناصر الأساسية، ويمررها إلى LLM، ويتلقى الإجراء التالي (النقر على زر، أو إدخال نص، أو تمرير الصفحة للأسفل، أو الانتقال عبر رابط)، ثم يكرر الدورة. وتستمر الحلقة حتى تُنجز المهمة أو يُبلغ الحد الأقصى لعدد الخطوات.

والميزة الأساسية أن الوكيل غير مرتبط بمنطق صارم. فهل تغيّر موضع الزر؟ أو انتقل أحد عناصر الواجهة؟ أو أُضيفت خطوة جديدة؟ يتكيف LLM ويجد المطلوب من السياق، دون إعادة كتابة الشيفرة.

المهام النموذجية لوكيل المتصفح:

• ملء النماذج وإرسالها على مواقع عشوائية
• جمع البيانات من الصفحات التي تتطلب تسجيل الدخول
• مقارنة المنتجات والأسعار في الوقت الفعلي
• أتمتة المهام الروتينية في أنظمة CRM وخدمات SaaS دون API رسمي
• اختبار واجهات الويب من طرف إلى طرف (end-to-end) بمحاكاة سلوك المستخدم

الأدوات والمزالق

الحزمة الأكثر شيوعاً هي مكتبة `playwright` للتحكم في المتصفح، مع SDK الخاص بـ `openai` أو `anthropic` ليكون «عقل» الوكيل. ويلجأ المطورون بشكل متزايد إلى `browser-use`، وهي مكتبة تأتي بطبقة orchestration جاهزة فوق LangChain وPlaywright. وهي تقلل حجم الشيفرة المطلوبة وتتولى معظم الحالات غير القياسية.

والصعوبة الرئيسية في وكلاء المتصفح ليست تقنية، بل تصميمية. كيف تصوغ المهمة بشكل صحيح حتى لا يتعطل الوكيل عند صفحة غير متوقعة؟ وكيف تتعامل مع CAPTCHA أو نافذة منبثقة أو إعادة توجيه إلى صفحة بديلة؟ من الممارسات الجيدة إضافة تعليمات صريحة للحالات غير القياسية، وتحديد مهلة زمنية (timeout) لكل إجراء.

وثمة ملاحظة أخرى: قراءة بنية DOM للصفحات الكبيرة تستهلك الرموز (tokens) بسرعة. لذلك يقوم المطورون ذوو الخبرة بتصفية DOM قبل تمريرها إلى LLM، فيُبقون على العناصر التفاعلية والنص المرئي فقط، ويستبعدون السكربتات والأنماط والوسوم الخدمية.

ماذا يعني ذلك

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