يفتح مهندس منصة Dawn ويسأل: "قم بعمل Scrape لـ https://topstartups.io/ وأعطني أول 10 شركات ناشئة، بما يشمل الأسماء، والأوصاف، والمقر الرئيسي (HQ)، وسنة التأسيس، وعناوين URL، والصفحات الاجتماعية، منسقة في جدول."
يفكر الـ 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 جلب صفحة ويب عامة أو endpoint لـ HTTP، وتحليل الـ response (بما في ذلك JSON)، وإرسال نموذج (form)، والتحقق من إمكانية الوصول، وسحب نصوص أو روابط معينة مما يتم استرجاعه. يمتلك كل agent صلاحية وصول صريحة أو لا يملكها على الإطلاق. حوكمة لكل agent على حدة، لتجنب الوقوع في فخ "منح كل agent حق الوصول إلى الإنترنت".
المثير للاهتمام ليس قدرة الـ agent على الوصول إلى URL. فالبحث في الويب موجود في منصات الـ agents منذ عام. المثير للاهتمام هو شكل الأداة التي بدأت تتبلور.
البحث في الويب واستخراج البيانات من الـ URL هما مهمتان مختلفتان. البحث مخصص للإجابة عن "ماذا يقول الإنترنت عن X؟" وهي معلومات عامة، توليدية، وبمستوى التلخيص. أما الاستخراج فمخصص لـ "إليك الـ URL أو الـ endpoint، اجلبه وأعطني إجابة مهيكلة". متطلبات موثوقية مختلفة، وتكلفة مختلفة، وأنماط فشل مختلفة. وخلطهما في أداة واحدة ينتج إجابة متواضعة لكليهما.
يتعامل تكامل Dawn معهما كأمرين منفصلين. لديهم ميزة /web-research للمهمة العامة. بينما FourA مخصصة للمهمة المحددة. يستعين الـ agent بالأداة المناسبة بناءً على ما يحتاجه بالفعل. وهذا هو نمط النضج الذي بدأنا نراه عبر منصات الـ agents في عام 2026: الاستخراج ينتقل من كونه مجرد "إضافة ملحقة بالبحث" ليصبح عنصراً أساسياً (primitive) قائماً بذاته.
لمهندس المنصات الذي يقرأ هذا
توفر Dawn أداة FourA في شكل ثماني أدوات مسمّاة، كل منها يتوافق مع نمط استخراج شائع:
foura_fetch_pageلصفحات HTML والنصوصfoura_extract_textللمحتوى النظيف المقروءfoura_extract_linksللتنقل، والنماذج (forms)، والبرمجيات النصية (scripts)، والأنماط (styles)foura_fetch_jsonلـ API endpointsfoura_head_urlلـ headers، والحالة (status)، وإعادة التوجيه (redirects)foura_probe_siteلفحوصات الوصول السريعةfoura_submit_formلإرسال النماذج دون تسجيل دخولfoura_single_requestلطلب HTTP عشوائي
يختار الـ agent الأداة بناءً على ما يتطلبه السؤال. استعلام topstartups أعلاه استخدم ثلاثة منها بالتتابع: جلب (fetch)، ثم استخراج (extract)، ثم متابعة (follow-up).
التكامل بسيط بما يكفي لإنجازه في يوم واحد. يعتمد في الخلفية على نوعين من الـ requests: وضع مباشر (direct mode) مع بصمة متصفح (browser-grade fingerprinting) للمواقع التي لا تفرض قيوداً صارمة، ووضع موجه عبر البروكسي (proxy-routed mode) لكل الحالات الأخرى. كلاهما يشتركان في نفس شكل الـ request: الـ URL، والـ headers والـ body الاختياريين، وتحليل الـ response الاختياري. يختار الـ agent بناءً على ما يتطلبه الموقع المستهدف.
يميل العقد (contract) الذي تقدمه المنصة للـ agents الخاصة بها إلى أن يبدو كالتالي:
- مجموعة صغيرة من القدرات (fetch / extract / probe / submit)، كل منها بتعريف أداة مركز ومحدد يمكن للـ agent الوصول إليه
- التعيين الافتراضي على وضع proxy، والرجوع إلى الوضع المباشر (direct) عندما يكون زمن الاستجابة (latency) أو التكلفة أمراً مهماً
- صلاحيات لكل agent على حدة حتى يحتفظ عملاء المنصة بالقدرة على الحوكمة
- إتاحة تحليل الـ response المهيكل كمعامل للأداة (tool param)، بدلاً من دفنه في توجيه النظام (system prompt)
لكن الجزء الذي يقلل معظم مهندسي المنصات من تقديره هو ما يحدث في الحالات الاستثنائية (the tail). حالة الـ 80% (نجاح الجلب في غضون 200 مللي ثانية، وإرجاع HTML نظيف) هي النصف السهل. أما الـ 20% المتبقية (المواقع التي تفرض قيوداً على بصمة TLS، أو تضع تحدي JS في الـ response، أو تعطي خطأ 403 بسبب حظر نطاق عناوين IP السحابية) هي ما يحدد ما إذا كان الـ agent الخاص بك سيقدم إجابة صحيحة أم إجابة مخترعة (hallucinated). لقد أعدنا بناء مسار الـ request لدينا خصيصاً لتلك الحالات الاستثنائية (the tail)، والفرق بين "يبدو موثوقاً" و"موثوق بالفعل" يمثل الجزء الأكبر من العمل.
لذا، إذا كنت تدير منصة agents ويستمر عملاؤك في السؤال عن كيفية تمكين الـ agents الخاصة بهم من "مجرد التحقق من هذا الـ URL"، فهذا هو النمط المناسب. المستندات متوفرة في /docs. ويسعدنا أن نأخذك في جولة لشرحها.
للجميع عدا ذلك
لن ترى أيًا من هذا. ستلاحظ فقط أنه عندما تسأل مساعد الذكاء الاصطناعي سؤالاً يتطلب الاطلاع على صفحة ويب حقيقية في الوقت الحالي، فإنه يجيب بشكل صحيح بدلاً من التخمين أو الاعتذار.
هذه هي النتيجة التي يراها المستخدم لعنصر استخراج أساسي (extraction primitive) موثوق بما يكفي ليتواجد بجانب GitHub وGoogle Drive في شبكة التكاملات. لم يعد الأمر مشروعاً بحثياً، بل أصبح بنية تحتية أساسية (plumbing).
لماذا يهم هذا الأمر
قبل ستة أشهر، كان الـ agent الذي يحتاج إلى قراءة صفحة ويب يتطلب بناءً مخصصاً. توجيهات (prompts) مخصصة، وأدوات كشط (scrapers) هشة، ومحاولات إعادة يدوية، ومعدل نجاح لا يتجاوز 60% في أفضل الأحوال. كان الشكل خاطئاً لأن هذه الطبقة لم تكن موجودة بعد. وكانت المواقع التي يحاول الـ agent الوصول إليها تتغير باستمرار. حيث انتقلت تقنيات مكافحة البوتات من الإشارات الثابتة إلى الفحوصات السلوكية، مما جعل أدوات الكشط المرقعة تتدهور بشكل أسرع مما يمكن للفرق إصلاحه.
الآن بدأت هذه الطبقة في التشكل. لقد تبنتها Dawn وأطلقت تكاملاً معها. ونتوقع أن تحذو المزيد من منصات الـ agents حذوها هذا العام، كما نتوقع أن يتقارب العقد (contract): أداة مخصصة للبحث، وأداة مخصصة للاستخراج، وحوكمة لكل agent، وتكلفة متوقعة.
نحن في البداية. ولكن هذا هو الشكل الذي يبدو عليه صعود شيء جديد. عندما تتوقف القدرة عن كونها مشروعاً وتبدأ في كونها مجرد مقبس للتوصيل (plug).
إذا كنت تبني منصة agents وتريد تقديم نفس الشكل، تواصل معنا. وإذا كنت تبني agents على Dawn، فإن FourA موجودة بالفعل هناك. ما عليك سوى تفعيلها.