لماذا نمط التصميم مهم؟
عندما نتحدث عن أنظمة الذكاء الاصطناعي الوكيلة (Agentic AI)، نحن لا نتحدث عن نموذج لغوي يرد على أسئلة — نتحدث عن نظام يتخذ قرارات، يستخدم أدوات، وينفذ مهام معقدة بشكل مستقل. الفرق بين نظام وكيل ناجح وآخر فاشل غالباً لا يكون في النموذج المستخدم، بل في نمط التصميم المعماري الذي تختاره.
نشرت Google Cloud دليلاً معمارياً شاملاً يحدد أنماط التصميم الرئيسية لبناء أنظمة AI وكيلة، وفي هذا المقال نلخص لك أهم ما جاء فيه بأسلوب عملي ومبسط.
قبل أن تختار: حدد متطلباتك أولاً
قبل القفز إلى اختيار نمط معين، عليك الإجابة على أربعة أسئلة جوهرية:
1. طبيعة المهمة: هل المهمة يمكن إنجازها بخطوات محددة مسبقاً؟ أم أنها مفتوحة وتحتاج تخطيطاً ديناميكياً من النموذج؟
2. زمن الاستجابة: هل الأولوية للسرعة أم للدقة؟ بعض الأنماط أسرع لكنها أقل مرونة، وبعضها يعطي نتائج أعمق لكنه أبطأ.
3. التكلفة: هل ميزانيتك تتحمل استدعاءات متعددة للنموذج في كل طلب واحد؟
4. التدخل البشري: هل المهمة تتضمن قرارات حساسة تحتاج موافقة بشرية؟
إذا كانت مهمتك بسيطة ومحددة — مثل تلخيص مستند أو تصنيف ملاحظات — فأنت غالباً لا تحتاج نظاماً وكيلاً أصلاً. الحلول غير الوكيلة مثل RAG أو الاستدعاء المباشر للنموذج قد تكون أكفأ وأرخص.
النمط الأول: الوكيل المفرد (Single Agent)
أبسط الأنماط وأهمها كنقطة انطلاق. وكيل واحد يستخدم نموذج AI مع مجموعة أدوات محددة و System Prompt شامل. الوكيل يفسر طلب المستخدم، يخطط الخطوات، ويقرر أي أداة يستخدم.
مثال عملي: وكيل دعم فني يستعلم من قاعدة بيانات عن حالة الطلب، أو مساعد بحثي يستدعي APIs لتلخيص الأخبار.
نصيحة Google: إذا كنت في بداية تطوير الوكلاء، ابدأ دائماً بوكيل مفرد. ركّز على تحسين المنطق والبرومبت وتعريفات الأدوات قبل إضافة تعقيد معماري.
لكن عندما يزداد عدد الأدوات أو تعقيد المهمة، قد تلاحظ بطئاً أو اختياراً خاطئاً للأدوات — وهنا تأتي الأنماط متعددة الوكلاء.
الأنماط متعددة الوكلاء: عندما وكيل واحد لا يكفي
الفكرة الأساسية: تقسيم المشكلة الكبيرة إلى مهام فرعية، وتعيين كل مهمة لوكيل متخصص. هذا يحسّن القابلية للتوسع والصيانة والموثوقية. لكنه يضيف تعقيداً في التنسيق والأمان والتكلفة.
Google حددت عدة أنماط رئيسية:
النمط التسلسلي (Sequential)
سلسلة خطية من الوكلاء: مخرج الأول يصبح مدخل الثاني، وهكذا. لا يحتاج نموذج AI للتنسيق — التسلسل محدد مسبقاً.
مثال: خط أنابيب بيانات — وكيل استخراج ← وكيل تنظيف ← وكيل تحميل.
الميزة: أقل تكلفة وأسرع من الأنماط التي تستخدم النموذج للتنسيق.
العيب: جامد. لا يتكيف مع الظروف المتغيرة ولا يتخطى خطوات غير ضرورية.
النمط المتوازي (Parallel)
عدة وكلاء يعملون في نفس الوقت على مهام مستقلة، ثم تُجمع النتائج. مفيد عندما تريد تقليل زمن الانتظار أو جمع وجهات نظر متعددة.
مثال: تحليل ملاحظات العملاء — وكيل تحليل المشاعر + وكيل استخراج الكلمات المفتاحية + وكيل التصنيف + وكيل كشف الأولوية، جميعهم يعملون معاً.
العيب: تكلفة أعلى فورياً ومنطق تجميع معقد عند وجود نتائج متناقضة.
النمط الحلقي (Loop)
تنفيذ متكرر لسلسلة وكلاء حتى تتحقق شروط إيقاف معينة (عدد أقصى من التكرارات أو حالة مخصصة). مثالي للمهام التي تحتاج تحسيناً تدريجياً.
التحذير الأهم: خطر الحلقة اللانهائية. إذا لم تُحدد شروط الإيقاف بدقة، قد يعمل النظام بلا توقف — وهذا يعني تكلفة تشغيلية كارثية.
نمط المراجعة والنقد (Review & Critique)
تطبيق عملي للنمط الحلقي: وكيل "مُولِّد" ينتج المخرج، ووكيل "ناقد" يقيّمه وفق معايير محددة (دقة، أمان، التزام بالقواعد). الناقد إما يوافق أو يرجع المخرج للمولد مع ملاحظات.
مثال: وكيل يكتب كوداً → وكيل أمني يفحصه ضد الثغرات → يرجعه للتعديل أو يوافق عليه.
المقايضة: جودة أعلى مقابل زمن وتكلفة أكبر مع كل دورة مراجعة.
نمط التحسين التكراري (Iterative Refinement)
شبيه بالمراجعة والنقد، لكن هنا الوكيل يحسّن مخرجه بنفسه عبر دورات متعددة حتى يصل لعتبة جودة محددة أو حد أقصى من التكرارات.
مثال: وكيل يكتب مسودة مقال → ينقدها ذاتياً → يعيد كتابتها → يكرر حتى تصبح جاهزة.
مثالي للمهام الإبداعية المعقدة التي يصعب إتمامها في محاولة واحدة.
نمط المنسق (Coordinator)
وكيل مركزي يستخدم نموذج AI لتحليل الطلب وتوجيهه ديناميكياً للوكيل المتخصص المناسب. هذا هو الفرق الجوهري عن النمط المتوازي — هنا التوجيه ذكي وليس مبرمجاً مسبقاً.
مثال: وكيل خدمة عملاء يحلل الطلب: هل هو استفسار عن طلب؟ إرجاع منتج؟ استرداد مبلغ؟ ثم يوجه لوكيل متخصص.
المقايضة: مرونة أكبر لكن استدعاءات نموذج أكثر = تكلفة وزمن أعلى.
التحليل الهرمي للمهام (Hierarchical Decomposition)
تطوير لنمط المنسق — هرم متعدد المستويات. وكيل "جذر" يستقبل المهمة المعقدة، يحللها لمهام فرعية، يفوّض كل واحدة لوكيل فرعي، وهذا بدوره قد يحلل مهمته لمهام أصغر... وهكذا نزولاً حتى تصبح المهام بسيطة بما يكفي للتنفيذ المباشر.
مثال: مشروع بحثي كامل: وكيل جذر ← وكيل جمع بيانات + وكيل تحليل + وكيل كتابة التقرير.
الأنسب لـ: المشاكل الغامضة والمفتوحة التي تحتاج استدلالاً متعدد الخطوات. لكنه الأعلى تكلفة وتعقيداً.
نمط السرب (Swarm)
الأكثر تعقيداً وإبداعاً: مجموعة وكلاء متخصصين يتواصلون فيما بينهم بحرية (all-to-all). كل وكيل يمكنه مشاركة نتائجه، نقد مقترحات الآخرين، والبناء على عمل زملائه. لا يوجد منسق مركزي يدير العملية — وكيل الإرسال يسهّل التواصل فقط.
مثال: تصميم منتج جديد: وكيل باحث سوق + وكيل هندسة + وكيل نمذجة مالية. يتناقشون ويتفاوضون حتى يتفقوا على تصميم يوازن جميع المتطلبات.
التحذير: بدون شروط إيقاف محكمة، قد يدور السرب في حلقات غير منتجة. الأعلى تكلفة وزمناً بين جميع الأنماط.
نمط ReAct: فكّر ثم نفّذ ثم لاحظ
هذا ليس نمط تنسيق بل طريقة تفكير للوكيل نفسه. الوكيل يعمل في حلقة تكرارية من ثلاث خطوات:
Thought (تفكير): يقيّم المعلومات ويقرر الخطوة التالية.
Action (فعل): إما يستخدم أداة لجمع معلومات، أو يصيغ الإجابة النهائية.
Observation (ملاحظة): يستقبل نتيجة الأداة ويحفظها في ذاكرته ليبني عليها.
يستمر حتى يجد إجابة حاسمة أو يصل لحد أقصى من التكرارات. مثالي للمهام الديناميكية التي تتغير ظروفها — مثل وكيل روبوت يحسب مساراً ويعدّله باستمرار حسب العوائق الجديدة.
نمط الإنسان في الحلقة (Human-in-the-Loop)
نقاط توقف إلزامية في سير العمل تنتظر تدخلاً بشرياً. الوكيل يوقف التنفيذ مؤقتاً عند نقطة محددة ويطلب مراجعة أو موافقة بشرية قبل المتابعة.
مثال: وكيل يخفي البيانات الشخصية من مجموعة بيانات طبية تلقائياً، لكنه يتوقف عند نقطة أخيرة لمسؤول الامتثال ليتحقق يدوياً قبل الإفراج عن البيانات.
ضروري للقرارات عالية المخاطر، السلامة، والامتثال التنظيمي.
نمط المنطق المخصص (Custom Logic)
عندما لا يناسبك أي نمط قياسي — تكتب منطق التنسيق بنفسك باستخدام كود مخصص (شروط، تفرعات، دمج أنماط متعددة). أقصى مرونة ممكنة.
مثال: وكيل استرداد أموال يجمع بين فحص متوازٍ (التحقق من المشتري + أهلية الاسترداد) ← شرط مخصص ← توجيه لمسار استرداد أو مسار رصيد متجر.
المقايضة: أنت مسؤول عن تصميم وتنقيح كل التنسيق — تعقيد تطوير وصيانة أعلى.
جدول المقارنة السريعة: أي نمط تختار؟
لسير العمل المحدد مسبقاً:
• مهام خطية بخطوات ثابتة → تسلسلي
• مهام مستقلة تُنفذ معاً → متوازٍ
• مهام تحتاج تحسيناً تدريجياً → تحسين تكراري
لسير العمل الديناميكي:
• مهام متعددة الخطوات مع أدوات خارجية → وكيل مفرد
• توجيه ديناميكي لمهام متنوعة → منسق
• مشاكل غامضة تحتاج تحليلاً هرمياً → تحليل هرمي
• مشاكل تحتاج نقاشاً وتعاوناً → سرب
لسير العمل التكراري:
• تخطيط وتكيف مستمر → ReAct
• تنفيذ متكرر حتى شرط معين → حلقي
• تحقق إلزامي قبل الإنهاء → مراجعة ونقد
لمتطلبات خاصة:
• قرارات حساسة تحتاج إشرافاً → إنسان في الحلقة
• منطق تفرعي معقد → منطق مخصص
الخلاصة
اختيار نمط التصميم ليس قراراً نهائياً تتخذه مرة واحدة — بل عملية مستمرة تراجعها مع تطور متطلباتك. ابدأ بسيطاً بوكيل مفرد، قيّم الأداء، ثم انتقل لأنماط أكثر تعقيداً عند الحاجة.
الأهم من النمط نفسه هو أن تسأل الأسئلة الصحيحة قبل البدء: ما طبيعة المهمة؟ ما هي أولوياتي؟ وما الذي أستطيع تحمل تكلفته؟
المرجع
هذا المقال ملخص لدليل Google Cloud الرسمي: Choose a design pattern for your agentic AI system — Google Cloud Architecture Center