يفتح أحد المهندسين Dawn ويطلب: "قم بعمل scrape لـ https://topstartups.io/ وزوّدني بأول 10 شركات ناشئة، متضمنة الأسماء، والأوصاف، والمقر الرئيسي، وسنة التأسيس، وعناوين URLs، وصفحات التواصل الاجتماعي، منسقة في جدول."
يفكر الـ agent للحظة، ويجلب الصفحة، ويحلل القوائم، ويتتبع الملف التعريفي لكل شركة ناشئة، ثم يعيد الجدول. عشرة صفوف. كل عمود ممتلئ بالبيانات. Pogo وAuctor وScalify وOmnea وRivan وListen Labs وDoppel وBlossom وAvoca وTraba. مقرات رئيسية موزعة عبر Brooklyn وNew York وLondon وSan Francisco وRemote. حسابات LinkedIn لمعظمها. سنوات التأسيس من 2020 إلى 2026.
كان هذا الجدول نتاج بضع استدعاءات عبر FourA.
أطلقت Dawn هذا الأسبوع أداة FourA كأداة من الدرجة الأولى (first-class tool) داخل منصة الـ agents الخاصة بها. حيث تتوفر في شبكة عمليات التكامل لديهم إلى جانب Notion وGitHub وGoogle Drive. يمكن للـ agents الممنوحة حق الوصول إلى FourA جلب صفحات الويب العامة أو HTTP endpoints، وتحليل الـ response (بما في ذلك JSON)، وإرسال النماذج، والتحقق من إمكانية الوصول، واستخراج نصوص أو روابط محددة مما يتم استرجاعه. يمتلك كل agent وصولا صريحا أو لا يمتلكه إطلاقا. حوكمة مخصصة لكل agent على حدة، دون الوقوع في خطأ منح الإنترنت بالكامل لكل الـ agents.
ليس المثير للاهتمام قدرة الـ agent على الوصول إلى URL، فالبحث على الويب متوفر في منصات الـ agent منذ عام. ما يثير الاهتمام حقا هو شكل الأداة الآخذ في التشكل الآن.
البحث على الويب واستخراج بيانات الـ URL مهمتان مختلفتان تماما. فالبحث مخصص لـ "ماذا يقول الإنترنت عن X؟"، أي معلومات عامة وتوليدية وتلخيصية. أما الاستخراج فمخصص لـ "إليك الـ URL أو الـ endpoint، اجلبه وأعطني إجابة مهيكلة". متطلبات موثوقية مختلفة، وتكاليف مختلفة، وأنماط فشل مختلفة. والجمع بينهما في أداة واحدة ينتج إجابة متواضعة لكليهما.
يتعامل تكامل Dawn معهما كأمرين منفصلين. لديهم إمكانية /web-research للمهمة العامة، وFourA مخصصة للمهمة المحددة بدقة. يختار الـ agent الأداة المناسبة بناء على ما يحتاجه فعليا. وهذا هو نمط النضج الذي بدأنا نشهده عبر منصات الـ agent في عام 2026: استخراج البيانات ينتقل من كونه مجرد "إضافة ملحقة بالبحث" ليصبح وحدة بناء أساسية قائمة بذاتها.
لمهندس المنصات الذي يقرأ هذا المقال
توفر Dawn خدمة FourA في هيئة ثماني أدوات محددة، ترتبط كل منها بنمط استخراج شائع:
foura_fetch_pageلصفحات الـ HTML والنصوصfoura_extract_textللمحتوى النظيف القابل للقراءةfoura_extract_linksللتنقل، والنماذج، والـ scripts، والأنماطfoura_fetch_jsonلنقاط نهاية الـ API endpointsfoura_head_urlللـ headers، والحالة، وإعادة التوجيهfoura_probe_siteلفحوصات الوصول السريعةfoura_submit_formلإرسال النماذج دون تسجيل دخولfoura_single_requestلطلبات HTTP العامة
يختار الـ agent الأداة بناء على متطلبات السؤال. استخدم استعلام topstartups أعلاه ثلاثا منها على التوالي: جلب، ثم استخراج، ثم متابعة.
عملية التكامل واضحة بما يكفي لإنجازها في يوم واحد. يعمل تحتها نمطان من الـ request: وضع مباشر ببصمة طلب مطابقة للمتصفح للمواقع التي لا تفرض قيودا مشددة، ووضع موجه عبر proxy لكل ما عدا ذلك. كلاهما يشتركان في نفس هيكل الـ request: وهو URL، وheaders وbody اختياريان، وتحليل اختياري للـ response. يختار الـ agent الوضع بناء على ما يفرضه الموقع المستهدف.
عادة ما يبدو العقد الذي تقدمه المنصة لعملائها من الـ agents على النحو التالي:
- مجموعة صغيرة من الإمكانات (fetch / extract / probe / submit)، لكل منها تعريف أداة محدد يمكن للـ agent استخدامه
- الاعتماد افتراضيا على وضع الـ proxy، والرجوع إلى الوضع المباشر عند أهمية زمن الاستجابة أو التكلفة
- أذونات مخصصة لكل agent حتى يحتفظ عملاء المنصة بالتحكم الكامل
- إتاحة تحليل الـ response المهيكل كمعامل للأداة، بدلا من دفنه داخل الـ system prompt
لكن الجزء الذي يقلل معظم مهندسي المنصات من تقديره هو ما يحدث في الحالات النادرة والحرجة. فحالة الـ 80% (نجاح الـ fetch في غضون 200ms مع إرجاع HTML نظيف) هي النصف السهل. أما نسبة الـ 20% الأخرى (المواقع التي تفرض قيودا على بصمة الـ request، أو تقحم اختبار JS challenge أثناء الـ response، أو ترجع خطأ 403 على نطاق عناوين IP السحابية) هي التي تحدد ما إذا كان الـ agent الخاص بك سيقدم إجابة صحيحة أم إجابة مفبركة. لقد أعدنا بناء مسار الـ request لدينا لتلك الحالات الدقيقة تحديدا، والفارق بين "يبدو موثوقا" و"موثوق بالفعل" هو جوهر العمل بأكمله.
لذا إذا كنت تدير منصة وكلاء ويستمر عملاؤك في السؤال عن كيفية قيام وكلائهم بـ "مجرد فحص هذا الـ URL"، فهذا هو النمط. التوثيق متاح في /docs. يسعدنا إرشادك خلال ذلك.
للجميع
لن ترى أيًا من هذا. ستلاحظ فقط أنه عندما تسأل مساعد ذكاء اصطناعي سؤالاً يتطلب الاطلاع على صفحة ويب حقيقية في الوقت الحالي، فإنه يجيب بشكل صحيح بدلاً من التخمين أو الاعتذار.
هذه هي النتيجة الموجهة للمستخدم لبنية استخراج أساسية موثوقة بما يكفي لتتواجد بجانب GitHub وGoogle Drive في شبكة عمليات الدمج. لم تعد مشروعًا بحثيًا. بل أصبحت بنية أساسية جاهزة.
لماذا يهم هذا
قبل ستة أشهر، كان الوكيل الذي يحتاج إلى قراءة صفحة ويب يتطلب بناءً مخصصًا. مطالبات مصممة خصيصًا، ومستخرجات بيانات هشة، وإعادات محاولة يدوية، ونسبة نجاح 60% في أفضل الأيام. كان الهيكل خاطئًا لأن الطبقة لم تكن موجودة بعد. وكانت المواقع التي يستهدفها الوكيل تتغير باستمرار. انتقل اكتشاف الروبوتات من الإشارات الثابتة إلى الفحوصات السلوكية، لذا تدهورت مستخرجات البيانات المؤقتة بسرعة أكبر من قدرة الفرق على إصلاحها.
الآن بدأت الطبقة في التشكل. اعتمدتها Dawn وأطلقت تكاملاً معها. نتوقع أن تتبعها المزيد من منصات الوكلاء هذا العام، ونتوقع أن يتقارب العقد التقني: أداة مخصصة للبحث، وأداة مخصصة للاستخراج، وحوكمة لكل وكيل، وتكلفة يمكن التنبؤ بها.
نحن في البداية. ولكن هكذا يبدو صعود التقنيات الجديدة. عندما تتوقف القدرة عن كونها مشروعًا وتصبح مكونًا جاهزًا للتوصيل.
إذا كنت تبني منصة وكلاء وترغب في تقديم نفس الهيكل، تواصل معنا. إذا كنت تبني وكلاء على Dawn، فإن FourA متوفرة بالفعل هناك. ما عليك سوى تفعيلها.