تنسب بعض المقارنات الصادرة عن جهات خارجية إلى Crawl4AI ميزة "الذكاء التكيفي" — أي محددات تتعلم بنية الموقع وتُصلح نفسها بعد تغييرات الـ markup. لكنني لم أجد هذا السلوك في واجهة الـ API التي اختبرتها. ما يوفّره Crawl4AI فعليًا هو توليد Markdown عبر متصفح، إلى جانب الاستخراج باستخدام CSS/XPath. أمّا Scrapling فيعرض ميزة منفصلة للمحددات التكيفية، ضمن الحدود الموضحة في مراجعته الخاصة.
اختبرت الإصدار Crawl4AI 0.9.0 على خمسة أنواع من الصفحات مع نتائج مرجعية معروفة: كتالوج ثابت، وكتالوج يُعرض بواسطة JavaScript، ومقال داخل عناصر boilerplate، وصفحة 500 مقصودة، ومخطط صفحات متعددة مترابطة. أعادت مسارات Markdown وschema المختبرة المحتوى المتوقع من ملفات الاختبار. لكن Markdown الخام أبقى على عناصر boilerplate، بينما احتاج الزحف العميق إلى انتظار خاص بكل صفحة، كما أن خطأ 500 العادي ظهر بتسمية توحي بمكافحة الروبوتات.
ما هو Crawl4AI فعليًا
ابدأ بأكثر نقطة يخطئ فيها الناس عند التثبيت. Crawl4AI ليس محلل Python صغيرًا. أول تشغيل لـ crawl4ai-setup يسحب بهدوء حزمتين كاملتين من المتصفحات — Playwright و Patchright — وعندما تدرك ذلك تتضح صورة الأداة بالكامل: هذا متصفح headless مُدار بعناية، مع محول Markdown في الأعلى، لكنه يرتدي قناع أداة scraping.
رسميًا، هي مكتبة مفتوحة المصدر بترخيص Apache-2.0 لتحويل صفحات الويب إلى Markdown من أجل مسارات RAG والوكلاء وتدفّقات البيانات. اختبرت v0.9.0. وتشمل اللبنات الأساسية فيها AsyncWebCrawler وBrowserConfig وCrawlerRunConfig وتوليد Markdown واستراتيجيات الاستخراج عبر CSS/XPath أو عبر LLM، وفقًا لـ الدليل السريع الرسمي.
وهنا النموذج الذهني المهم. أغلب مكتبات التحليل ترسل طلب HTTP ثم تعالج البايتات العائدة؛ أما Crawl4AI فيقود متصفحًا حقيقيًا. عرض الصفحة مدمج أصلًا، وهذا يجعل التثبيت أثقل من محلل HTTP خالص، بينما قد يتطلب الاستخراج الموثوق من العناصر التي تُعرض بشكل غير متزامن انتظارًا صريحًا. لا شيء في الاختبارات هنا أعاد كتابة المحددات بعد إعادة تصميم الصفحة. لذا اعتبر ادعاء "الإصلاح الذاتي" خطأً في مقارنة من طرف ثالث ما لم يكن هناك مصدر رسمي محدد وواجهة API قابلة لإعادة الإنتاج.
الميزات الأساسية، وكيف تعمل من الداخل
المسار أحادي الصفحة هو قلب الأداة. توجه AsyncWebCrawler إلى عنوان URL، فيحمّل الصفحة داخل متصفح، ثم يعيد لك Markdown. في المثال السريع الرسمي لـ example.com استغرقت هذه الدورة 1.81 ثانية وأعادت نتيجة 200 نظيفة. لا شيء استثنائي، لكنه يؤكد أن المسار الأدنى يعمل تقريبًا بلا إعدادات — لا schema، ولا waits، ولا إعداد للمتصفح.
فيديو تعليمي (1:02:38): Crawl4AI Official Tutorial, Full 1hr with Quickstart Examples.
الاستخراج المنظم هو الركن الثاني، وهو أقرب ما لدى Crawl4AI إلى "فهم" الصفحة — أي ليس استدلالًا، بل schema تكتبه أنت. بدلًا من تفريغ Markdown فقط، تمرر له مخطط CSS عبر JsonCssExtractionStrategy وتحصل على كائنات JSON تحتوي الحقول الدقيقة التي طلبتها. في الكتالوج الثابت المحلي أعاد 6 سجلات JSON نظيفة — اسم المنتج، الفئة، السعر، التقييم، ورابط التفاصيل — بما يطابق المنتجات الستة المتوقعة. هذا هو الفرق بين "هذه الصفحة كنص" و"هذه البيانات كسطور"، وCrawl4AI يقدم الاثنين من نفس عملية الزحف. لكن المحددات من صنعك أنت؛ الأداة تطابق ما تقدمه لها، ولا تستنتج schema بدلًا منك.
العرض الديناميكي هو المكان الذي تظهر فيه فائدة المتصفح. عندما توجهه إلى كتالوج يُعرض عبر JavaScript مع wait_for="css:.product-card" فإنه ينتظر حتى يكتمل العرض من جهة العميل قبل الاستخراج. ونتج عن ذلك استرجاع 8/8 للمنتجات في كل من Markdown وschema على الملف المحلي الخاص بي، خلال نحو 1.56 ثانية. وعلى صفحة Quotes to Scrape JS العامة التقط الاقتباسات المعروضة وحفظ لقطة شاشة مفيدة — وهو محتوى لن يراه طلب HTTP عادي، لأنه لا يوجد شيء في HTML الأولي يمكن تحليله.
ثم هناك التوسع والزحف. شغلت arun_many() ست صفحات تفاصيل محلية بالتوازي مع 6/6 استرجاع كامل خلال 3.76 ثانية. كما تأتي Crawl4AI باستراتيجيات deep crawl — مثل BFS وDFS وBestFirst — التي تتنقل في مخطط الروابط مع حدود للعمق وعدد الصفحات والفلاتر والتقييم. وقد جرى BFS deep crawl على مخطط الروابط للصفحة الرئيسية في ملف الاختبار وجلب خمس صفحات. وهنا تبدأ الفجوة بين التسويق والواقع، وسأعود لذلك أدناه.
الإعداد: الجزء الذي لا يضعه أحد في مقدمة README
كان التثبيت على جهازي أسلس مما توقعت من ناحية، وأثقل من ناحية أخرى. نجح pip install -U crawl4ai واختبار التشغيل السريع على Python 3.14.2 في macOS arm64. شرط PyPI من نوع >=3.10 يشمل أصلًا 3.14؛ وهذا النجاح يؤكد فقط التثبيت وسير العمل المختبرين، لا التوافق الأوسع.
أما مصدر الاحتكاك فهو خطوة الإعداد. فالأمر crawl4ai-setup يحمل ملفات المتصفح لكل من Playwright وPatchright — Chrome for Testing وFFmpeg وHeadless Shell. إذا كنت على حاسوب محمول بمساحة محدودة أو اتصال محدود البيانات، فهذه كلفة حقيقية، بينما تذكرها الوثائق على الهامش أكثر من عرضها بوضوح منذ البداية. بعد ذلك نجح crawl4ai-doctor وزحف إلى crawl4ai.com خلال 14.65 ثانية، وهو اختبار صحة جيد من النهاية للنهاية لكنه ليس معيار أداء لأي شيء — لا ينبغي أن تستنتج منه سرعة عامة.
الخلاصة في قسم الإعداد ضمن تقييمك الخاص: احسب كلفة تنزيل المتصفح، لا مجرد تثبيت الحزمة عبر pip. هذا أقرب إلى تجهيز بيئة متصفح headless منه إلى إضافة مكتبة داخل سكربت. حزمتا متصفح تهبطان على القرص قبل أن تزحف حتى إلى صفحة حقيقية واحدة، وهذه كلفة تدفعها مرة واحدة سواء احتجت فعلًا إلى طبقة التخفي الخاصة بـ Patchright أم لا.
تطبيق عملي: ما صمد، وما يجب الانتباه له
هناك أربع نتائج تستحق التوثيق بعناية، لأنها بالضبط من نوع التفاصيل التي تُسطحها صفحات التسويق — وفي حالة واحدة تُخطئ في توصيفها.
كما أن صفحتي العرض العامّتين اجتازتا المسار الناجح. في الصفحة الرئيسية لـ Books to Scrape أنتج Crawl4AI 13,476 حرفًا من Markdown خلال 2.43 ثانية. أما صفحة Quotes JS العامة فأعادت 1,666 حرفًا من Markdown المعروض خلال نحو 3.1 ثانية. لا واحدة من هاتين النتيجتين تثبت شيئًا عن النطاق، أو المواقع العدائية، أو الاستقرار طويل المدى، أو الجلسات، أو البروكسيات، أو إعادة المحاولة، أو سلوك الذاكرة.
ملف المقال يكشف ملاحظة مهمة حول جودة Markdown. التقط Crawl4AI العنوان وكل الفقرات 3/3 من جسم المقال — وهذا جيد. لكن Markdown الخام أبقى أيضًا على نصوص التنقل والروابط ذات الصلة وسطر الاشتراك ونص التذييل. هذا ليس خللًا؛ فبدون فلتر محتوى أو محدد هدف، فإن عبارة "حوّل هذه الصفحة إلى Markdown" تعني بصدق الصفحة كاملها. والعبرة هنا هي التفريق بين تحويل الصفحة الخام إلى Markdown وبين استخراج مقال نظيف. إذا كنت تريد الثاني، فستحتاج إلى فلتر محتوى مثل PruningContentFilter أو إلى محدد هدف — ولم أجرّبهما بما يكفي بعد، لذلك لن أزعم رقمًا للنظافة هنا.
الصفحة المعطلة كانت النتيجة الأكثر دلالة. قدّمتُ صفحة HTTP 500 مقصودة مع جسم صغير جدًا. أعاد Crawl4AI success=false والحالة 500 — وهذا صحيح — لكن رسالة الخطأ صاغت الأمر كأنه "Blocked by anti-bot protection: Structural: minimal_text on small page." لم تكن هناك أي طبقة مكافحة روبوتات. كانت مجرد صفحة خطأ صغيرة. خوارزمية Crawl4AI البنائية رأت نصًا مرئيًا قليلًا جدًا واستنتجت تفسيرًا متعلقًا بحظر الروبوتات. وهذا مهم جدًا لمن يبني فوق الأداة: لا تثق بوسم "anti-bot" كما هو. افحص رمز الحالة والمحتوى الفعلي قبل أن تستنتج أن الموقع يقاومك. النتيجة الخام موجودة في مستودع الاختبار عند results/local_failure_500.json.
الزحف العميق يحتاج إعدادًا مقصودًا. فزحف مباشر ديناميكي مع wait_for نجح بوضوح، بينما كشف deep crawl عبر BFS الكتالوج الديناميكي وأعاد فشلًا. التصنيف كـ minimal-text يتوافق مع قراءة الصفحة قبل أن تظهر البطاقات، كما أن deep crawl لم يطبّق الانتظار الموجود في الزحف المباشر. من أصل خمس صفحات، نجحت ثلاث وفشلت اثنتان. وبما أن إعادة التشغيل مع wait مضبوط لم تُعرض هنا، فهذه القراءة تبقى استنتاجًا لا سببًا مثبتًا.
أين استقرّت الأرقام
| الاختبار | النتيجة | زمن التنفيذ الملحوظ (تشغيل واحد موثق) |
|---|---|---|
البداية السريعة (example.com) | نجاح، 200 | 1.81ث |
| الكتالوج الثابت المحلي (Markdown) | استرجاع 6/6 للمنتجات | 0.731ث |
| استخراج CSS schema للكتالوج الثابت المحلي | 6 سجلات JSON | 0.740ث |
الكتالوج الديناميكي المحلي (wait_for) | استرجاع 8/8 للمنتجات | 1.559ث |
| استخراج CSS schema للكتالوج الديناميكي المحلي | 8 سجلات JSON | 1.561ث |
| Markdown المقال | 3/3 فقرات (+ boilerplate) | 0.752ث |
| الصفحة الرئيسية العامة لـ Books to Scrape | 13,476 حرفًا Markdown | 2.425ث |
| صفحة Quotes JS العامة | 1,666 حرف Markdown معروض | 3.111ث |
arun_many() (6 صفحات محلية) | استرجاع 6/6 | 3.760ث |
| deep crawl BFS المحلي | العثور على 5 صفحات، 3 نجاح / 2 فشل | 3.239ث |
| صفحة 500 المقصودة | فشل، 500 (موسومة خطأً كـ "anti-bot") | 0.745ث |
هذه أزمنة اختبار تشغيلي سريع، وليست معيار أداء: فالمقال لا يذكر العتاد، أو عدد مرات التكرار، أو حالة البداية الباردة/الدافئة، أو حالة التخزين المؤقت، أو ضوابط التوازي، أو مقدار التذبذب. لكنها تُظهر أن مسارات العمل المذكورة اكتملت على هذا الجهاز. توجد كل ملفات التشغيل في مجلد مستودع المقارنة.
ولكي تحصل على قياس يصلح لاتخاذ قرار، أعد كل مسار عمل في جلسات متصفح جديدة ومستخدمة سابقًا، واذكر التوزيعات بدل رقم عشري واحد، وثبّت نسخ المتصفحات، وسجل CPU والذاكرة وحالة الكاش والتوازي. بذلك يمكن فصل عبء المكتبة عن تشغيل المتصفح وعن تقلبات الشبكة.
| المتطلب | مدى الملاءمة في هذه المراجعة | الشرط الأساسي |
|---|---|---|
| عرض صفحة وإرجاع Markdown | مناسب جدًا | صفِّ عناصر boilerplate قبل اعتبار الناتج مقالًا نظيفًا |
| استخراج JSON بشكل schema | مناسب جدًا | ما زلت بحاجة إلى كتابة وصيانة CSS schema يدويًا |
| انتظار محتوى الصفحة غير المتزامن | مدعوم | عرّف شرط wait_for صريحًا ومحددًا للهدف |
| زحف الصفحات الديناميكية بعمق | مشروط | مرّر قواعد الجاهزية؛ الإعداد الافتراضي المختبر أعطى فشلًا جزئيًا |
| العمل كمحلل HTTP خفيف وعديم الاعتماديات تقريبًا | غير مناسب | ملفات المتصفح وصيانتها جزء من النشر |
| استخدام محددات ذاتية الإصلاح | غير مدعوم في هذا الاختبار | لا تستنتج ذلك من نصوص مقارنة غير مرتبطة |
الإيجابيات والسلبيات
الإيجابيات:
- مكتبة واحدة تقدم Markdown الخام و JSON منظمًا وفق CSS schema — فلا تحتاج إلى ربط أداتين معًا.
- عرض المتصفح مدمج؛ وقد تحتاج الوجهات المعروضة بشكل غير متزامن إلى
wait_forصريح. - مسارات الصفحة الواحدة المختبرة اكتملت ضمن الأوقات المذكورة أعلاه؛ ولا يوجد ادعاء عام بالسرعة مقارنةً بغيرها.
- ترخيص Apache-2.0 — مناسب تجاريًا ولا مفاجآت copyleft.
- مشروع نشط مع إصدار حديث ومجتمع كبير ومتفاعل.
السلبيات:
- إعداد أولي ثقيل (حزمتا متصفح) لا توضحه المقدمة بما يكفي.
- Markdown الخام يتضمن boilerplate ما لم تُفعّل فلاتر محتوى.
- الزحف العميق لا ينتظر الصفحات الديناميكية تلقائيًا — عليك ضبطه لكل عملية زحف وإلا ستظهر حالات فشل.
- رسائل الفشل قد تصف خطأً عاديًا بأنه "anti-bot"، وهو أمر مربك في السجلات.
- لا توجد محددات تتكيف ذاتيًا، رغم ما توحي به بعض المقارنات — الـ schemas تُكتب يدويًا وتبقى ثابتة.
- أنت من يدير بيئة المتصفح ويصونها بنفسه، بما في ذلك التحديثات وما قد ينتج عنها من أعطال.
لمن يناسب — ومن الأفضل أن يتجاوزه
يستحق Crawl4AI أن تقيّمه إذا كنت مطورًا تبني مسار RAG أو وكيلًا ذكيًا، وتشعر بالارتياح عند تشغيل بيئة متصفح headless، وتريد Markdown وJSON منظمًا من نفس عملية الزحف. الاختبارات لم تغطِّ مقاومة المواقع العدائية، أو الاستقرار طويل الأمد، أو الذاكرة، أو الجلسات، أو إعادة المحاولة، أو البروكسيات، أو النشر الإنتاجي، لذا فالتوصية هنا محصورة في مسارات العمل التي جرى اختبارها.
تجاوزه — أو على الأقل توقف قليلًا — إذا كنت تريد محلل HTTP صغيرًا قليل الاعتماديات (فهذا عكسه تمامًا)، أو لا تستطيع تحمل مساحة القرص وحجم التنزيل الخاص بالمتصفح، أو لا تريد امتلاك صيانة حزمة متصفح في الإنتاج. وتجاوزه تحديدًا إذا كنت تبحث عن محددات ذاتية الإصلاح: فهذه ليست وظيفة الأداة، وبناء سير عمل على ميزة لا تملكها سيؤذيك لاحقًا. وإذا كان هدفك هو استخراج نص مقال نظيف مع إزالة boilerplate، فقد تناسبك أداة أخف موجهة تحديدًا لهذه المهمة بشكل أفضل.
البدائل، بما فيها موقع Thunderbit
الإطار الصادق هنا: Crawl4AI مكتبة مفتوحة المصدر ومجانية تستضيفها وتُصينها بنفسك. تحصل على تحكم كامل وبدون رسوم استخدام لمزود الخدمة، لكنك ما تزال تدفع تكاليف الحوسبة والنطاق الترددي والتخزين وتحديثات المتصفح والـ schemas والعمل التشغيلي.
وفي الطرف الآخر توجد خدمة scraping مُدارة مثل Thunderbit، حيث يجري الجلب والاستخراج عبر API. لم يتم تشغيل Thunderbit على هذه الملفات الاختبارية، لذا لا يدعي هذا المقال وجود تطابق في النتائج فيما يخص العرض، أو التعامل مع anti-bot، أو CAPTCHA، أو الدقة، أو السرعة. المقارنة المهمة هنا هي ملكية التشغيل: إما أن تستضيف المكتبة المعتمدة على المتصفح بنفسك، أو تدفع خدمةً لتدير تلك الطبقة.
الفرق الحقيقي هو: من يدير المتصفح؟ مع Crawl4AI أنت تملك العرض والانتظار والـ schemas والصيانة. مع API مُدار تدفع لكل استدعاء وتنقل جزءًا من المسؤولية التشغيلية إلى المزوّد. هذا الاختبار لم يقارن المسارين من ناحية النتائج.
مراجعات مقارنة ذات صلة: المقارنة الكاملة لمستخرجات الويب مفتوحة المصدر، ومراجعة Firecrawl مع الاستضافة الذاتية، ومراجعة استخراج المقالات في trafilatura.
جرّب Thunderbit لاستخراج بيانات الويب
الحكم النهائي
يُعد Crawl4AI خيارًا معقولًا إذا كنت تريد استخراجًا مفتوح المصدر يعتمد على المتصفح ويُنتج Markdown وJSON منظمًا وفق schema، وأنت مستعد لتحمل مسؤولية بيئة المتصفح. لقد نجحت مسارات الصفحة الثابتة ومسارات الصفحات الديناميكية بعد انتظار مناسب في هذه الاختبارات. ترخيص Apache-2.0 مرن، مع بقاء مراجعة الاعتماديات والتوزيع أمرًا ضروريًا.
خصص ميزانية لملفات المتصفح. يحتاج Markdown الخام إلى فلترة قبل أن يصبح نص مقال نظيفًا. وتتطلب انتظارات الزحف العميق إعدادًا مقصودًا، وأي سجل يقول "anti-bot" يجب التحقق منه مقابل رمز الحالة ومحتوى الرد. أما محددات الـ schema فما زالت مسؤوليتك في الكتابة والصيانة. هذه هي الحدود التي أثبتها الاختبار؛ أما النطاق الإنتاجي وسلوك المواقع العدائية فهما ما يزالان سؤالين مفتوحين.
جرّب Thunderbit لاستخراج بيانات الويب Get Started Free
الأسئلة الشائعة
هل لدى Crawl4AI محددات تكيفية أو ذاتية الإصلاح؟ لا. رغم أن بعض المقارنات تنسب إليه "الذكاء التكيفي"، فإن Crawl4AI يطابق مخطط CSS/XPath الذي تكتبه أنت — ولا يقوم ببصمة العناصر أو إعادة اكتشافها بعد تغيير الـ markup. في الاختبار، حقق الاستخراج المنظم 6/6 و8/8 استرجاعًا باستخدام schemas كتبتها يدويًا. إذا غيّر موقعٌ ما classes الخاصة به، فسيتعطل schema حتى تحدّثه. تتبع العناصر ذاتية الإصلاح هي ميزة في مكتبة أخرى، وليست هنا.
لماذا يبدو التثبيت كبيرًا إلى هذا الحد؟
لأن crawl4ai-setup ينزل ملفات متصفح كاملة لكل من Playwright وPatchright — Chrome for Testing وFFmpeg وHeadless Shell. هذه هي كلفة شحن عرض متصفح حقيقي. احسب مساحة القرص وعرض النطاق المطلوبين، لأنه أثقل من محلل HTTP خالص، وستدفع هذه الكلفة حتى لو لم يستخدم حملك الفعلي طبقة التخفي قط.
هل يتعامل Crawl4AI مع الصفحات التي تُعرض عبر JavaScript؟
نعم، لأنه يقود متصفحًا headless حقيقيًا. في الاختبار، أعاد الكتالوج الديناميكي مع wait_for="css:.product-card" استرجاعًا كاملًا 8/8 للمنتجات، كما ظهرت صفحة Quotes JS العامة بشكل نظيف. لكن المشكلة أن الزحف العميق لا يطبّق هذا الانتظار تلقائيًا على الصفحات المكتشفة — فقد فشل BFS crawl على صفحة ديناميكية اكتشفها لأنه لم ينتظر. عليك ضبط الانتظار بنفسك، لكل عملية زحف.
هل يمنحني Crawl4AI نص مقال نظيفًا أم الصفحة كاملة؟
افتراضيًا، الصفحة كاملة. في الاختبار التقط كل فقرات الجسم، لكنه احتفظ أيضًا بالتنقل والروابط ذات الصلة ونص التذييل. لاستخراج مقال نظيف، استخدم فلتر محتوى (مثل PruningContentFilter) أو محدد هدف بدل الاعتماد على Markdown الخام.
هل يمكنني الوثوق برسائل خطأ Crawl4AI؟ اقرأها بنوع من التحفظ. فقد وُسمت صفحة خطأ 500 مقصودة بجسم صغير جدًا بأنها "Blocked by anti-bot protection" فقط بسبب heuristic يعتمد على قلة النص المرئي — ولم تكن هناك طبقة anti-bot أصلًا. والـ نتيجة الخام موجودة في مستودع المقارنة. تحقّق دائمًا من رمز HTTP الفعلي وجسم الرد قبل أن تحكم بأن الموقع يحجبك.
