Category
وكلاء الذكاء الاصطناعي
Share the article
تُعد لغة Markdown اللغة العالمية للوكلاء الذكاء الاصطناعي. ولكنها أصبحت أيضاً، وبشكل متزايد، السبب وراء عدم قراءة أي شخص لما ينتجونه.
يقع هذا التوتر في صلب نقاش يتطور بهدوء بين مهندسي الذكاء الاصطناعي ويخرج الآن إلى العلن. في أوائل شهر مايو، نشر Andrej Karpathy توصية: اطلب من نموذجك اللغوي الكبير (LLM) هيكلة استجابته بتنسيق HTML، ثم اعرضها في المتصفح. وفي الوقت نفسه تقريباً، نشر Thariq Shihipar، وهو قائد هندسي في فريق Claude Code في Anthropic، حجة مفصلة بعنوان The Unreasonable Effectiveness of HTML (الفعالية غير المعقولة للغة HTML)، موضحاً أنه توقف تماماً عن استخدام markdown للمخرجات الناتجة عن الذكاء الاصطناعي.
تفكيرهم لا يتعلق بالجماليات؛ بل يتعلق بعدم توافق هيكلي بين ما يمكن لوكلاء الذكاء الاصطناعي إنتاجه وما يمكن للبشر استيعابه بالفعل.
كيف أصبحت لغة markdown الخيار الافتراضي
فازت لغة markdown في سباق تنسيق مخرجات الذكاء الاصطناعي لثلاثة أسباب عملية: فهي منخفضة التكلفة، وقابلة للقراءة بواسطة الآلات، وسهلة التعديل يدوياً.
من حيث التكلفة، فإن الفجوة كبيرة. يؤدي تحويل HTML إلى markdown إلى تقليل استخدام الرموز (tokens) بنسبة تقارب 68% للمحتوى النظيف وتصل إلى 87% لصفحات الويب الفعلية. وقد أطلقت Cloudflare ميزة "Markdown for Agents" خصيصاً لتبسيط لغة HTML إلى markdown قبل تغذيتها لأنظمة الذكاء الاصطناعي، مما يقلل من تكاليف الاستدلال بشكل كبير.
وفيما يتعلق بفهم الآلة، فإن markdown تتفوق بالفعل على HTML. في اختبارات قياس استخراج الجداول القائمة على GPT، حققت تمثيلات markdown دقة بلغت 60.7% مقارنة بـ 53.6% لجداول HTML. وتشهد خطوط أنابيب RAG تحسناً في الدقة يصل إلى 35% عند استيعاب markdown مقارنة بلغة HTML الخام.
أما بالنسبة لقابلية التعديل، فمن الصعب التغلب على markdown. يمكنك فتح ملف .md في أي محرر نصوص، وإجراء التغييرات، وحفظها في نظام التحكم في الإصدارات بفروق واضحة وقابلة للقراءة. بينما تكون فروق HTML مشوشة وصعبة المراجعة.
هذه المزايا حقيقية وتفسر سبب اعتماد كل أداة ترميز برمجي بالذكاء الاصطناعي، من Cursor إلى GitHub Copilot إلى Claude Code، لغة markdown كخيار افتراضي للخطط والمواصفات والوثائق. ولكنها تكشف أيضاً عن الافتراض الكامن في هذا التنسيق: وهو أن الإنسان في الطرف الآخر سيقوم بقراءة الملف وتعديله يدوياً.
هذا الافتراض بدأ ينهار.
مشكلة القراءة
نشرت مجلة Harvard Business Review دراسة في مارس 2026 صاغت فيها مصطلح "AI Brain Fry" (إرهاق الدماغ بالذكاء الاصطناعي). حيث أفاد الموظفون الذين يقومون بإشراف عالٍ على الذكاء الاصطناعي بزيادة قدرها 19% في العبء المعلوماتي الزائد، و14% جهد ذهني أكبر، و33% إرهاق أكثر في اتخاذ القرارات مقارنة بمن لديهم إشراف منخفض. ووجد تحليل منفصل من Fortune أن الوقت المستغرق في البريد الإلكتروني تضاعف بعد اعتماد أدوات الذكاء الاصطناعي، بينما انخفضت جلسات العمل المركزة بنسبة 9%.
المشكلة ليست في أن الذكاء الاصطناعي يكتب بشكل سيء، بل تكمن في أنه يكتب الكثير، ولا تقدم لغة markdown أي مساعدة للبشر في معالجة هذا الحجم الهائل.
وقد عبر Thariq Shihipar عن ذلك بصراحة قائلاً: "أنا شخصياً لا أقرأ فعلياً أكثر من ملف markdown يتكون من 100 سطر، وبالتأكيد لست قادراً على جعل أي شخص آخر في مؤسستي يقرأه". وهذا يتماشى مع ما تواجهه معظم الفرق؛ إذ ينتج وكلاء الذكاء الاصطناعي خطط تنفيذ من 200 سطر، ومواصفات تفصيلية، وتقارير متعددة الصفحات. المخرجات صحيحة تقنياً وسليمة هيكلياً، لكن معظمها يظل دون قراءة.
ويدعم علم الأعصاب هذا الرأي؛ حيث يخصص حوالي 30% من القشرة المخية البشرية للمعالجة البصرية، وفقاً لأبحاث رسم الخرائط القشرية التأسيسية التي أجراها Felleman وVan Essen. بينما يحصل السمع على 3%، واللمس على 8%. الرؤية هي، كما وصفها Karpathy، "الطريق السريع المكون من 10 حارات للمعلومات إلى الدماغ". ولغة markdown تكاد لا تستخدم هذه الميزة، فالنصوص العريضة، والعناوين الرئيسية، والنقاط النقطية هي كل ما تملكه في أدواتها البصرية.
أين تغير لغة HTML المعادلة
لا تجعل لغة HTML وكلاء الذكاء الاصطناعي أكثر ذكاءً، بل تجعل مخرجاتهم قابلة للاستهلاك الفعلي.
الفرق يكمن في كثافة المعلومات. يمكن لـ HTML تمثيل البيانات الجدولية، والتنسيقات المصممة بأسلوب أنيق، ورسومات SVG، والعناصر التفاعلية باستخدام JavaScript، والعلاقات المكانية مع تحديد المواقع المطلق، ومقتطفات التعليمات البرمجية المضمنة التي تعمل بالفعل. بينما تجبر لغة markdown وكلاء الذكاء الاصطناعي على تقريب كل هذا باستخدام رسومات ASCII ورموز unicode.
وقد صاغ Karpathy هذا الأمر كمرحلة من التطور الذي يعكس تطور واجهات الحوسبة دائماً: نصوص خام، ثم markdown، ثم HTML، وفي النهاية مقاطع الفيديو العصبية التفاعلية. وينطبق هذا النمط عبر تاريخ الحوسبة، من أسطر الأوامر إلى واجهات المستخدم الرسومية ثم شاشات اللمس؛ حيث قايضت كل خطوة الكفاءة بمزيد من الفهم والاستيعاب.
وتقدم أمثلة Thariq دليلاً عملياً على ذلك؛ فهو يستخدم HTML لخطط التنفيذ مع النماذج الأولية المضمنة ومقتطفات التعليمات البرمجية، ولمراجعة الأكواد البرمجية التي تعرض الفروق الفعلية مع التعليقات التوضيحية المضمنة والمصنفة بالألوان حسب الأهمية، وللنماذج الأولية التفاعلية حيث تتيح لك أشرطة التمرير ضبط المعلمات ويقوم زر "نسخ كـ JSON" بتصدير النتيجة مرة أخرى إلى جلسة الترميز، ولتقارير البحوث التي تحتوي على مخططات انسيابية بصيغة SVG وتصفح يعتمد على علامات التبويب.
وتعمل حركة vibe coding على تسريع هذا التوجه. عندما يصف المطورون بشكل متزايد ما يريدونه بلغة طبيعية ويتركون للوكلاء كتابة البرمجة، يصبح تنسيق المخرجات أهم من أي وقت مضى. أنت بحاجة إلى التحقق مما بناه الوكيل، وتوصيل ذلك من خلال معاينة HTML معروضة يكون أكثر كفاءة بكثير من التمرير عبر التعليمات البرمجية الخام في وحدة التحكم.
ميزة سهولة المشاركة لا تقل أهمية؛ إذ تتطلب ملفات markdown برنامج عرض أو مرفقاً، بينما تفتح HTML بشكل طبيعي في أي متصفح. وعندما يمكنك مشاركة مخرجات الوكيل كرابط URL، فإن احتمالية تفاعل أصحاب المصلحة تزداد بشكل كبير.
المنصات المؤسسية اتخذت قرارها بالفعل
بينما يتناقش مجتمع المطورين، تعمل منصات الذكاء الاصطناعي للمؤسسات بهدوء على بناء أنظمة مخرجات غنية لسنوات.
تعالج منصة Salesforce Agentforce أكثر من 4 ملايين جلسة عبر أكثر من 133,000 وكيل باستخدام تنسيقات الاستجابة التكيفية، وهو نظام يحول ردود النصوص من النماذج اللغوية الكبيرة إلى مكونات واجهة مستخدم مهيكلة مثل القوائم الدوارة، وأزرار الاختيار الغنية بالخيارات، وبطاقات الوسائط. وقد وثق فريقهم الهندسي مشكلة مثيرة للاهتمام أثناء التطوير: حيث كانت الإصدارات الأولى "تفرط في التنسيق"، مما يحول الإجابات البسيطة بنعم/لا إلى مكونات واجهة مستخدم كاملة. وكان الدرس المستفاد هو أن المخرجات الغنية يجب أن تتناسب مع تعقيد المعلومات.
تستخدم منصة Copilot Studio من Microsoft "الأوراق التكيفية" (Adaptive Cards)، وهي تنسيق مستقل عن المنصة لتقديم محتوى تفاعلي غني. وتعرض أداة Now Assist من ServiceNow نتائج الوكلاء كبطاقات قابلة للتفاعل مع روابط المصادر وتتبع التقدم خطوة بخطوة.
وقد ذهبت Google إلى أبعد من ذلك مع بروتوكول A2UI، وهو بروتوكول مفتوح يطلب فيه الوكلاء مكونات واجهة مستخدم معتمدة مسبقاً بدلاً من إنتاج HTML خام. هذا الاختلاف مهم جداً للأمان: فبدلاً من الثقة في الوكلاء لكتابة HTML آمنة، يتيح A2UI للوكلاء الإعلان عما يريدون عرضه وتتولى المنصة عملية العرض.
وقد استثمرت المختبرات الثلاثة الكبرى للذكاء الاصطناعي في المخرجات الغنية لمنتجاتها الاستهلاكية أيضاً. حيث أنتجت ميزة Claude Artifacts من Anthropic "عشرات الملايين" من مخرجات HTML التفاعلية، وأضافت OpenAI ميزات عرض HTML وReact إلى ChatGPT Canvas. هذه ليست تجارب، بل هي ميزات إنتاجية تعتمد على تبني واسع النطاق.
الإشارة الصادرة عن كل منصة رئيسية هي نفسها: عندما يتحدث الوكلاء إلى البشر، فإن النص وحده لا يكفي. والمنصات التي تدير وتنسق عمل الوكلاء عبر نماذج متعددة وسير عمل تحتاج إلى تنسيقات مخرجات تتناسب مع تعقيد ما ينتجه هؤلاء الوكلاء.
المقايضات حقيقية
HTML ليست ترقية مجانية، فالتكاليف ملموسة.
استهلاك الرموز (Tokens) هو الأكثر وضوحاً؛ إذ تستهلك HTML النظيفة ما بين ضعفين إلى ثلاثة أضعاف الرموز مقارنة بما يعادلها في markdown. ويمكن لملفات HTML الفعلية المزودة بـ CSS وJavaScript أن تتضخم إلى 8 أو 10 أضعاف. ومع اتساع نوافذ السياق الآن لتتجاوز مليون رمز، أصبح هذا الأمر أقل أهمية مما كان عليه في عام 2023، ولكنه لا يزال يتراكم على نطاق واسع.
الأمن يمثل مشكلة أكثر صعوبة؛ حيث يمكن أن تحتوي مخرجات HTML الخام من وكلاء الذكاء الاصطناعي على JavaScript، مما يفتح الباب أمام هجمات البرمجة العابرة للمواقع (XSS) وهجمات حقن الأكواد. بروتوكول A2UI من Google وجد خصيصاً لأن فرق أمن المعلومات في المؤسسات لا يمكنها قبول كتابة الوكلاء لرموز HTML عشوائية تعمل في بيئات الإنتاج الحية.
كما يتأثر التحكم في الإصدارات أيضاً؛ فمقارنات اختلافات الـ HTML تكون مشوشة ومليئة ببرمجة الإغلاق وتغييرات السمات التي تحجب التغيير الفعلي في المحتوى. وهذا أحد أكبر العيوب التي أقر بها Thariq نفسه.
وهناك حجة مضادة تستحق أخذها على محمل الجد. فقد نشر Kurtis Redux مقالاً بعنوان "The Unreasonable Ineffectiveness of HTML" كاستجابة مباشرة، جادل فيه بأن هذا التحول "يركض وراء المظهر البصري اللامع على حساب سهولة قراءة المصدر، والأمان، والتوافق مع النظام البيئي، وقابلية المراجعة". بالنسبة لقواعد الأكواد البرمجية التي يتعاون فيها الوكلاء مع البشر عبر ملفات مشتركة، تظل بساطة markdown ميزة حقيقية.
أي التنسيقين يصنع وكلاء أفضل؟
تعتمد الإجابة على من يتحدث إليه الوكيل.
بالنسبة للتواصل بين وكيل وآخر والمعالجة الآلية، تفوز لغة markdown بوضوح، فهي أقل تكلفة، وأكثر دقة في التحليل، وأسهل في تتبع الإصدارات. عندما ينتج وكيل Beam AI مخرجات سيستهلكها نظام آخر، فإن قيود markdown تصبح نقاط قوة.
أما للتواصل بين الوكيل والإنسان، فتفوز لغة HTML بوضوح تام. عندما يكون الهدف هو أن يفهم الشخص ما أنتجه الوكيل ويقيمه ويتخذ إجراءً بناءً عليه، فإن الوضوح البصري وكثافة المعلومات يتفوقان على كفاءة استهلاك الرموز. الزيادة البالغة 19% في العبء المعلوماتي الزائد التي وثقتها HBR لن تُحل بكتابة ملفات markdown أفضل، بل بتعريض المعلومات في التنسيقات التي يمكن للدماغ معالجتها بالفعل.
أفضل منصات الوكلاء ستدعم كلا التنسيقين؛ فسوف تستخدم markdown والبيانات المهيكلة داخلياً لعمليات تفكير الوكيل وذاكرته والتواصل بين الوكلاء وبعضهم، وستقوم بعرض مخرجات غنية، وبصرية، وتفاعلية للبشر الذين يحتاجون إلى مراجعة عمل الوكلاء والموافقة عليه واتخاذ القرارات بناءً عليه. طبقة المنصة هي المكان الذي تترجم فيه تفكير الوكيل لمخرجات قابلة للقراءة البصرية للبشر دون إجبار الوكيل على كتابة وتنسيق الأكواد المظهرية.
تطور Karpathy التدريجي، من النص إلى markdown ثم HTML وصولاً إلى الفيديو العصبي التفاعلي، ليس تنبؤاً بمستقبل بعيد، فالخطوات الثلاث الأولى تحدث الآن. والسؤال المطروح على المؤسسات هو ما إذا كانت البنية التحتية للوكلاء لديها تواكب هذا التطور، أم أنها لا تزال تطلب من الأشخاص قراءة ملفات markdown مكونة من 200 سطر لا يكملها أحد.
