كلودفلير يقيم موقعك في زمن وكلاء الذكاء الاصطناعي بدرجة جاهزية الوكيل

تعلمت مواقع الويب كيف تتحدث إلى المتصفحات، ثم إلى محركات البحث. ترى كلاودفلير أنها الآن بحاجة إلى تعلم كيفية التحدث إلى الوكلاء المدعومين بالذكاء الاصطناعي، فأطلقت أداة لمساعدتها على ذلك. مبادرة طموحة، لكنها تثير تساؤلات بقدر ما تحلّ من مشكلات.

أداة تقييم لمشكلة حقيقية

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

لقياس حجم المشكلة، قامت كلاودفلير بمسح 200,000 من أكثر النطاقات زيارة على الويب, مع تصفية معيدي التوجيه وخوادم الإعلانات وخدمات النفق للتركيز على المواقع التي يمكن للوكلاء التفاعل معها بشكل معقول.

الخلاصة مدهشة: 78% من المواقع لديها ملف robots.txt, لكن الغالبية العظمى منها كُتبت لزواحف محركات البحث التقليدية، وليس للوكلاء. فقط 3.9% من المواقع تقدّم محتوى بصيغة Markdown عندما يُطلب منها ذلك. ومعايير ناشئة مثل بطاقات خوادم MCP موجودة في أقل من 15 موقعًا في كامل مجموعة البيانات.

الحل الذي كشفت عنه كلاودفلير isitagentready.com يقترح إذن مؤشراً منظَّماً حول أربعة محاور.

• الـ قابلية الاكتشاف (discoverability) يتحقق من وجود وجودة الـ robots.txt، ومن sitemap.xml، ورؤوس الروابط.
• الـ محتوى (content) يقيم ما إذا كان الموقع يستطيع تقديم نسخة Markdown نظيفة عند طلب وكيل.
• الـ التحكم في وصول الروبوتات (bot access control) يفحص ما إذا كان الموقع يعبّر عن تفضيلات واضحة بشأن ما يمكن للذكاء الاصطناعي فعله بمحتواه.
• أخيرًا، القدرات يختبرون وجود معايير أكثر تقدماً مثل بطاقات خوادم MCP وAPI Catalog أو اكتشاف OAuth حتى يتمكن الوكلاء من المصادقة بشكل سليم.

معايير لا تزال بدائية وتبنٍّ شبه معدوم

هنا يجب ترويض حماس Cloudflare قليلاً. العديد من المعايير المذكورة في هذا المؤشر إما قيد الصياغة لدى IETF، أو اقتراحات غير رسمية دون ضمان اعتمادها على نطاق واسع. API Catalog (RFC 9727)، وMCP Server Cards، وWeb Bot Auth هي معايير حديثة لم يَبلغ بعضها بعد حالة RFC نهائية في وقت النشر.

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

حالة llms.txt توضّح ذلك. المقترَح في سبتمبر 2024، هذا الملف الموحد لعرض موقع أمام نموذج لغوي كبير ليس مضمناً افتراضياً في مؤشر Cloudflare، بل اختياري فقط. السبب؟ المعيار لا يزال موضع نقاشإنها قرار حكيم، لكنه يشير إلى أن حتى Cloudflare لا تعرف بعد بالضبط أي رهانات يجب أن تضعها.

التفاوض على المحتوى بـ Markdown: مكسب حقيقي وقابل للقياس

أحد الجوانب الأكثر واقعية للمبادرة، وربما الأكثر فائدة فوراً، يتعلق بـ قدرة الخادم على الرد بصيغة Markdown عندما يرسل وكيل ترويسة Accept: text/markdownتؤكد Cloudflare أنها قيّمت تقليلاً يصل إلى 80% في عدد التوكنات المطلوبة لقراءة صفحة، بالمقارنة مع نسختها الـ HTML.

هذا الرقم يستحق أن يُؤطَر. يحتوي HTML لصفحة توثيق تقنية غالبًا على كلام زائد: التنقل، القوائم، السكربتات، الوسوم المتداخلة… كل ذلك يمثل ضوضاء صافية بالنسبة لنموذج لغوي كبير. ملف Markdown مُنظّم جيّدًا، هذه هي جوهر المحتوى من دون التغليف. النتيجة المباشرة هي تقليل تكلفة استدعاءات واجهة برمجة التطبيقات للوكيلات، انخفاض في الكمون، واحتمال أفضل بأن يكون لدى الوكيل السياق الكامل دون اقتطاع.

لتوضيح ذلك، تشرح كلاودفلير أنها اختبرت موقع توثيقها الخاص (developers.cloudflare.com) عبر توجيه وكيل (Kimi-k2.5 عبر OpenCode) إلى عدة مواقع تقنية. النتيجة: استهلاك أقل للرموز بنسبة 31٪ واستجابات صحيحة أسرع بنسبة 66٪ مقارنة بمواقع أخرى غير محسّنة. لا بد من أخذ هذه الأرقام بحذر، لأنها ناتجة عن ظروف اختبار داخلية غير مدققة. لكن رتبة الحجم تتفق مع ما نعرفه عن الزيادة الهيكلية في HTML.

التنفيذ التقني على Cloudflare Docs: عملي وقابل للتكرار

الجزء الأكثر إفادة في التدوينة ربما هو الذي يصف كيف أعادت كلاودفلير صياغة توثيقها الخاص. النهج مُثير للاهتمام لأنه يتجاوز مشكلة حقيقية: في فبراير 2026، ثلاثة أدوات فقط من بين سبعة مختبرة (Claude Code وOpenCode وCursor) ترسل تلقائيًا الترويسة Accept: text/markdownبالنسبة للبقية، فهناك حاجة إلى بديل.

الحل المُعتمد يجمع بين قاعدتين من قواعد كلاودفلير:

• إعادة كتابة عنوان URL التي تحول طلبًا موجهًا إلى /r2/get-started/index.md إلى طلب موجه إلى /r2/get-started/,
• وتعديل في رأس الطلب يضيف تلقائيًا Accept: text/markdown لهذه الطلبات المعاد كتابتها.

النتيجة يمكن لأي وكيل الوصول إلى إصدار Markdown لأي صفحة ببساطة عن طريق إضافة /index.md إلى عنوان URL، دون الحاجة للتعامل مع ترويسة خاصة.

قرار آخر ملحوظ: بدلاً من ملف واحد llms.txt ضخم (توثيق كلاودفلير يضم أكثر من 5000 صفحة)، يمتلك كل دليل من المستوى الأول ملفه الخاص، ويشير ملف الجذر إلى هذه الدلائل الفرعية. هذا يتجنب ما وُصف في المقالة بـ«حلقة grep»: عندما يواجه الوكيل ملفًا طويلًا جدًا بحيث لا يتسع في نافذة السياق، يبدأ بالبحث بالكلمات المفتاحية، يفقد الرؤية الشاملة، يضاعف الاستدعاءات ويخفض جودة استجاباتِه.

وقد تم العناية أيضاً بدرجة التجزئة. : حوالي 450 صفحة كانت مجرد قوائم روابط (صفحات دليل) تم استبعادها من llms.txt, لأنها لا تضيف أي قيمة دلالية إلى نموذج لغوي كبير حيث تم إدراج صفحاتها الفرعية بالفعل بشكل منفصل.

جهة تقوم بالتقييم وتبيع خدمات التحضير للحصول على الدرجات

موقف كلاودفلير يستحق فحصاً دقيقاً. تنشر الشركة درجة مرجعية لـ«استعداد الوكلاء»، وتدمج هذه الدرجة في أداة فحص الروابط (URL Scanner)، وتقترح مطالبات جاهزة للاستخدام لتصحيح كل نقطة فشل… وتبيع المنتجات (Workers، Rules، Access) التي تتيح تنفيذ هذه التصحيحات. الـ isitagentready.com هو نفسه مخدوم بواسطة كلاودفلير ويعرض خادماً MCP.

هذا ليس بالضرورة مشكلة: فعلت جوجل الشيء نفسه مع لايتهاوس ومؤشرات الويب الأساسية., ليصبح في آن واحد حكم الأداء ومزود الأدوات لتحسينه (عبر جوجل كلاود، فايربيس، إلخ). لكن هذا يعني أن معايير الدرجة قد تتطور وفقاً للمصالح التجارية للشركة بقدر ما تتطور وفقاً للاحتياجات الفعلية للوكلاء. معيار تفرضه شركة واحدة، حتى وإن كانت بنوايا حسنة، يظل معياراً قد تنحرف توجهاته.

من الجدير بالذكر أيضاً أن كلاودفلير تدفع بنشاط معايير مرتبطة بالمدفوعات الوكلائية (x402، بروتوكول التجارة الشامل)، وبعضها ينطوي على شركاء مباشرين مثل كوينبيس. هذه المعايير لا تدخل حالياً ضمن الدرجة، لكن وجودها في الأداة يشير بالفعل إلى اتجاه.

ما الذي يمكن للمطوّرين فعله عمليًا اليوم

رغم هذه التحفظات، هناك عدة إجراءات تحقق عائداً استثمارياً واضحاً وفورياً، بغض النظر عن تطور المعايير:

• تقديم Markdown عند الطلب أمر بسيط تقنيًا، يقلل التكاليف بالنسبة لمستهلكي واجهة برمجة التطبيقات، ويحسّن جودة إجابات الوكلاء. هذه هي الأولوية.
• الاهتمام بـ robots.txt لوكلاء الذكاء الاصطناعي (بإضافة توجيهات لبرامج الزحف مثل GPTBot, ClaudeBot, CCBot, إلخ) هي ممارسة جيدة لا تكلف شيئًا وتوضّح حقوق الوصول.
• تنظيم llms.txt تنظيمه حسب الأقسام للمواقع ذات المحتوى الكبير هو ممارسة وثائقية جيدة تفيد كلًّا الوكلاء والبشر الذين يسعون لفهم سريع لهندسة الموقع.

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

التبني كمؤشر للسوق، لا كإلزام

قد تكمن القيمة الحقيقية لمبادرة كلاودفلير في الـ مجموعة بيانات Radar التي تُدخلها: متابعة أسبوعية لتبني كل معيار بين أكثر 200000 موقع زيارة، مصنفة حسب فئة النطاق. هذا النوع من البيانات سيمكن من قياس ما إذا كانت المعايير "تنتشر" فعلاً، أم أن معظم المواقع ستظل خاملة في انتظار أن تتكيف الوكلاء معها، كما تكيفت بالفعل مع HTML على مدار ثلاثين عاماً.

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

المقال «كلودفلير يقيم موقعك في زمن وكلاء الذكاء الاصطناعي بدرجة جاهزية الوكيل» نُشر على الموقع أبوندانس.