كيف نبني وكلاء ذكاء اصطناعي فعالين؟ ثلاث قواعد لفهم AI Agents

أصبحت وكلاء الذكاء الاصطناعي AI Agents من أكثر الاتجاهات حضوراً في تطوير تطبيقات الذكاء الاصطناعي، لكن السؤال الأهم ليس كيف نبني Agent، بل متى نحتاج إليه فعلاً

من الاستدعاء الواحد إلى الوكيل

بدأت كثير من تطبيقات النماذج اللغوية باستدعاء واحد للنموذج لإنجاز مهام مثل التلخيص والتصنيف واستخراج المعلومات. ومع زيادة تعقيد المنتجات، أصبح من المفيد تنظيم عدة استدعاءات في مسارات محددة مسبقاً، وهو ما يمكن وصفه بالـ Workflow

أما الـ Agent فيمنح النموذج مساحة أكبر لاتخاذ القرار أثناء التنفيذ، واختيار الأدوات والخطوات التالية استناداً إلى النتائج التي يحصل عليها من البيئة

وهنا تظهر المفاضلة الأساسية: كلما زادت استقلالية النظام زادت قدرته على التعامل مع المهام المعقدة، لكن قد ترتفع أيضاً التكلفة وزمن التنفيذ واحتمالات الخطأ وصعوبة التنبؤ بالسلوك

القاعدة الأولى: لا تبنِ Agent لكل شيء

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

تزداد قيمة الـ Agent عندما تكون المهمة غامضة ومعقدة وذات قيمة كافية لتبرير تكلفة الاستكشاف، وعندما توجد طريقة عملية لاكتشاف الأخطاء والتحقق من النتائج

أربعة أسئلة قبل بناء Agent

• ما درجة تعقيد المهمة؟ هل يمكن تحديد مسارها مسبقاً أم أن المسار يتغير بحسب النتائج
• ما قيمة المهمة؟ هل تستحق التكلفة الإضافية في النماذج والأدوات والوقت
• هل القدرات الأساسية متوفرة؟ هل يستطيع النظام تنفيذ الأجزاء الحرجة من المهمة بصورة موثوقة
• ما تكلفة الخطأ؟ وهل يمكن اكتشاف الخطأ بسهولة قبل أن يسبب أثراً أكبر

لماذا تعد البرمجة مثالاً مناسباً للـ Agents؟

البرمجة تجمع بين التعقيد والغموض والحاجة إلى اتخاذ قرارات أثناء التنفيذ. كما أن نتائجها قابلة للتحقق بدرجة جيدة من خلال الاختبارات وعمليات التكامل المستمر CI

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

القاعدة الثانية: اجعل الـ Agent بسيطاً

في صورته الأساسية يمكن فهم الـ Agent باعتباره نموذجاً يعمل في حلقة، ويتفاعل مع بيئة عبر مجموعة من الأدوات، ويتلقى تعليمات تحدد الهدف والقيود والسلوك المتوقع

الفكرة ليست أن البساطة تعني أن النظام النهائي يجب أن يبقى بسيطاً دائماً، وإنما أن يبدأ المطور من أصغر بنية يمكنه فهم سلوكها ثم يضيف التعقيد عندما يثبت أنه ضروري

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

الأدوات جزء من الذكاء الوكيلي

الأداة ليست مجرد وظيفة برمجية يستدعيها النموذج، بل هي الواجهة التي يتعامل من خلالها الـ Agent مع البيئة

ولهذا يجب أن يكون وصف الأداة واضحاً في وظيفتها ومدخلاتها ومخرجاتها والقيود المفروضة عليها ومتى ينبغي استخدامها

ومن هنا تأتي أهمية Model Context Protocol — MCP الذي يهدف إلى توحيد طريقة ربط تطبيقات الذكاء الاصطناعي بالأدوات ومصادر البيانات والخدمات الخارجية

القاعدة الثالثة: فكر مثل الـ Agent

من أكثر الأفكار أهمية في الحديث أن المطور قد ينظر إلى النظام من منظوره هو، بينما يتخذ الـ Agent قراراته بناءً على المعلومات الموجودة فعلياً داخل سياقه في تلك اللحظة

لذلك، عندما يتخذ Agent قراراً يبدو غير منطقي، لا يكفي أن نسأل لماذا أخطأ، بل ينبغي أن نسأل أيضاً: ماذا كان يرى عندما اتخذ القرار؟

اختبار بسيط

ضع نفسك داخل السياق الذي يراه Agent وحاول تنفيذ المهمة بالمعلومات نفسها والأدوات نفسها

ما المعلومات المتاحة؟ ما الذي ينقص؟ هل وصف الأداة واضح؟ هل القيود مفهومة؟ هل يعرف النظام نتيجة الإجراء الذي نفذه؟

هذه الطريقة تساعد على اكتشاف مشكلات لا تظهر عندما ننظر إلى النظام من خارج التجربة

مثال: Agents التي تتحكم في الكمبيوتر

عندما يعمل Agent في بيئة Computer Use قد يحصل على لقطة شاشة، ثم ينفذ إجراءً، ثم ينتظر حتى يحصل على حالة جديدة للبيئة. أثناء التنفيذ قد لا يملك معلومات كاملة عما حدث

ولهذا فإن وضوح وصف البيئة والأدوات، ومعرفة القيود، وتقديم المعلومات المناسبة في الوقت المناسب، كلها عناصر أساسية في تحسين السلوك

هندسة السياق Context Engineering

لم يعد تحسين Agent متعلقاً بالنموذج وحده. أصبح تصميم السياق الذي يصل إلى النموذج جزءاً أساسياً من هندسة النظام

ويشمل ذلك تعليمات النظام، ووصف الأدوات، ونتائج الأدوات، وحالة البيئة، والمعلومات السابقة، والقيود، والنتائج التي حصل عليها Agent في الخطوات السابقة

التقييم ليس مرحلة ثانوية

كلما أصبح Agent أكثر استقلالية أصبح تقييمه أكثر تعقيداً، لأنه لا ينتج إجابة واحدة فقط، بل ينفذ سلسلة من الخطوات ويستخدم أدوات ويغير حالة البيئة

ولهذا من المفيد تقييم النتيجة النهائية، وكذلك تتبع المسار الذي أدى إليها، ومراقبة التكلفة والزمن واستهلاك الرموز ومعدلات الخطأ

من Agent واحد إلى Multi-Agent Systems

أحد الاتجاهات التي يناقشها Barry Zhang هو التعاون بين عدة Agents، بحيث يمكن توزيع المهام بين وكلاء متخصصين أو تنفيذ بعض العمليات بالتوازي

لكن الانتقال إلى Multi-Agent لا يحل جميع المشكلات تلقائياً، بل يضيف سؤالاً جديداً: كيف تتواصل الوكلاء مع بعضهم، وكيف يشاركون النتائج والسياق، وكيف نمنع تضخم التعقيد بين الوكلاء

هل نحتاج إلى Agent أم Workflow؟

ليس الهدف استبدال Workflows بالـ Agents، بل اختيار البنية التي تناسب طبيعة المهمة

إذا كانت المهمة واضحة ومتكررة ويمكن تحديد خطواتها مسبقاً، فقد يكون Workflow أبسط وأكثر قابلية للتنبؤ والتحكم

أما إذا كانت المهمة غامضة وتتطلب استكشافاً واتخاذ قرارات أثناء التنفيذ، فقد يكون Agent أكثر ملاءمة

وفي بعض الأنظمة يمكن الجمع بين الاثنين: Workflow يحدد الهيكل العام، بينما يتولى Agent الجزء الذي يحتاج إلى مرونة واتخاذ قرار ديناميكي

أسئلة المستقبل

ينتهي الحديث بثلاثة أسئلة لافتة: كيف نجعل Agents أكثر وعياً بالميزانية من حيث الوقت والتكلفة والـ Tokens؟ كيف يمكن للأدوات أن تصبح أكثر قابلية للتحسين والتكيف؟ وكيف يمكن بناء تواصل أكثر مرونة بين الوكلاء في الأنظمة متعددة الوكلاء؟

الخلاصة

بناء Agent فعال لا يعني بناء النظام الأكثر تعقيداً

الفكرة الأهم هي أن نمنح النظام القدر المناسب من الاستقلالية للمهمة التي صُمم من أجلها

ابدأ بالسؤال: هل أحتاج Agent أصلاً؟

إذا كانت الإجابة نعم، فابدأ ببنية بسيطة: بيئة وأدوات وتعليمات واضحة

ثم راقب السلوك وقيّم النتائج وحسّن النظام تدريجياً

وأثناء كل ذلك حاول أن ترى العالم من داخل سياق الـ Agent نفسه، لأن فهم ما يراه النموذج قد يكون الخطوة الأولى لفهم سبب قراراته وتحسينها

مصادر للتعمق

• Building effective agents — Anthropic
• Demystifying evals for AI agents — Anthropic
• Model Context Protocol — Documentation