من قرارات المعمارية إلى النشر في الإنتاج، يغطي هذا الدليل كل ما تحتاجه لبناء وكلاء ذكاء اصطناعي موثوقين وآمنين ومفيدين فعلاً. حلقات ReAct، وتنسيق multi-agent، وحواجز الأمان، والتقييم، والأنماط المكتسبة بشق الأنفس التي تفصل العروض التوضيحية عن أنظمة الإنتاج.
إن وكيل الذكاء الاصطناعي هو نظام يستخدم نموذجاً لغوياً كبيراً كمحرك استدلال له ليقرر الإجراءات التي يتخذها، وينفذ تلك الإجراءات عبر الأدوات، ويراقب النتائج، ويكرّر حتى يتحقق الهدف. وعلى عكس استدعاء LLM بسيط يأخذ مدخلاً ويعيد مخرجاً، يعمل الوكيل في حلقة مع القدرة على التأثير في بيئته.
التمييز الجوهري هو الاستقلالية واستخدام الأدوات. الـ chatbot يجيب عن الأسئلة. أما الوكيل فيحجز الاجتماع، ويفتح التذكرة، ويستعلم من قاعدة البيانات، ويكتب التقرير — متخذاً في كل خطوة قراراً بما سيفعله تالياً بناءً على ما تعلّمه حتى الآن.
ليس كل نظام يحتاج إلى استقلالية كاملة. إن فهم موقع حالة استخدامك على هذا الطيف يحدد معماريتك ومتطلبات الأمان والتعقيد التشغيلي.
موجّه يدخل، استجابة تخرج. لا أدوات، لا حلقة. التصنيف، التلخيص، الاستخراج.
يستدعي النموذج أداة واحدة أو أكثر ويركّب النتائج. معظم روبوتات المحادثة ذات function calling.
يستدل النموذج، ويتصرف، ويراقب، ويكرر. وهو يقرر متى ينتهي. وكلاء ReAct.
ينسّق عدة وكلاء متخصصين لحل المهام المعقدة. أنماط supervisor أو swarm.
يراقب الوكلاء ويخططون ويتصرفون على آفاق زمنية طويلة بإشراف بشري ضئيل. يتطلب حواجز أمان واسعة.
يضيف الوكلاء زمن استجابة وتكلفة وعدم قابلية للتنبؤ. إذا كان بإمكانك حل المشكلة باستخدام pipeline حتمي (استخراج، تصنيف، سير عمل ثابت)، فافعل ذلك. الجأ إلى الوكلاء عندما تتطلب المهمة اتخاذ قرار ديناميكياً: عندما لا يمكنك التنبؤ مسبقاً بالأدوات التي ستُستدعى، وبأي ترتيب، وكم مرة. إذا كان منطق التفرّع معروفاً وقت التصميم، فاستخدم سير عمل؛ وإذا كان يجب تحديده وقت التشغيل، فاستخدم وكيلاً.
تحدد المعمارية التي تختارها كيف يستدل وكيلك ويخطط وينسّق العمل. لكل نمط مقايضات مختلفة تتعلق بقابلية التحكم وزمن الاستجابة والتعقيد.
يتداخل الوكيل بين آثار الاستدلال واستدعاءات الأدوات في حلقة: فكرة، إجراء، ملاحظة، تكرار.
يقرر الـ LLM الأدوات التي يستدعيها وبأي وسائط، ثم يركّب النتائج في إجابة نهائية.
ينشئ LLM مخطِّط خطة متعددة الخطوات مسبقاً، ثم ينفّذ LLM منفِّذ كل خطوة بالتتابع.
يتعاون عدة وكلاء متخصصين، كلٌّ يمتلك مجالاً أو قدرة محددة، بتنسيق من supervisor.
وكيل مركزي يوجّه المهام إلى وكلاء فرعيين متخصصين ويجمع مخرجاتهم. فصل نظيف للاهتمامات، لكن الـ supervisor يمثّل عنق زجاجة ونقطة فشل وحيدة.
الأكثر شيوعاً في الإنتاجيسلّم الوكلاء أحدهم إلى الآخر مباشرة بناءً على السياق. لا منسّق مركزي. أكثر مرونة لكن أصعب في تتبع الأخطاء والفهم.
نمط ناشئشجرة من المشرفين، كلٌّ يدير فريقاً من الوكلاء الفرعيين. يتيح هياكل تنظيمية معقدة، لكنه يضيف عبء تنسيق كبيراً.
لحالات الاستخدام المعقدة فقطابدأ بأبسط معمارية يمكن أن تنجح. سيتفوق وكيل ReAct واحد بأدوات جيدة في كل مرة على نظام multi-agent سيئ التصميم. لا تضف تعقيداً إلا عندما يكون لديك دليل على أن نهجاً أبسط لا يمكنه تلبية متطلباتك. معظم أنظمة الوكلاء الإنتاجية التي نبنيها تستخدم وكيلاً واحداً مع 5-15 أداة مصممة جيداً.
يتطور مشهد أطر الوكلاء بسرعة. فيما يلي مقارنة صادقة للخيارات الرائدة استناداً إلى خبرتنا في بناء أنظمة الإنتاج بكلٍّ منها.
| الإطار | الأفضل لـ | المزايا | العيوب | النضج |
|---|---|---|---|---|
| LangGraph | سير عمل معقد ذو حالة، أنظمة الإنتاج | تحكم دقيق، human-in-the-loop، استمرارية، streaming | منحنى تعلّم أكثر انحداراً، نموذج ذهني قائم على الرسوم البيانية | عالٍ |
| CrewAI | تعاون multi-agent، مهام قائمة على الأدوار | واجهة API بسيطة، نموذج الدور/الهدف/الخلفية، تفويض مدمج | تحكم أقل في تدفق التنفيذ، أصعب في تتبع الأخطاء | متوسط |
| OpenAI Agents SDK | تطبيقات native لـ OpenAI، النماذج الأولية السريعة | tool-calling أصلي، عمليات تسليم، حواجز أمان، tracing مدمج | ارتباط بالمزود، خيارات نماذج محدودة | متوسط |
| AutoGen | البحث، أنماط multi-agent الحوارية | أنماط محادثة مرنة، تنفيذ كود، محادثات متداخلة | تهيئة معقدة، تجريد أثقل | متوسط |
| Custom (no framework) | تحكم كامل، تبعيات دنيا، قيود محددة | لا عبء تجريد، بالضبط ما تحتاجه، سهل التدقيق | المزيد من الكود المكرر، يجب أن تبني الاستمرارية/streaming بنفسك | غير متاح |
لمعظم حالات استخدام الإنتاج، نوصي بـ LangGraph للأنظمة المبنية على Python أو تنفيذ مخصص لـ TypeScript. يمنحك LangGraph تحكماً دقيقاً في رسم التنفيذ البياني، واستمرارية مدمجة، وأنماط human-in-the-loop دون تجريد مفرط. لحالات الاستخدام الأبسط، يوفر OpenAI Agents SDK مساراً أسرع إلى الإنتاج إذا كنت بالفعل ضمن منظومة OpenAI.
الأدوات هي يدا وكيلك وعيناه. جودة واجهات أدواتك هي العامل الأكبر الوحيد المحدِّد لأداء الوكيل. سيتفوق نموذج متوسط بأدوات ممتازة على نموذج متطور بأدوات سيئة التصميم.
يجب أن تكون أسماء الأدوات أزواجاً من فعل-اسم (search_documents، create_ticket). ويجب أن تشرح الأوصاف متى تُستخدم الأداة، لا ما تفعله فقط.
عرّف مخططات JSON صارمة مع enums وحدود min/max وحقول مطلوبة. ينشئ الـ LLM وسائط أفضل عندما يقيّد المخطط فضاء مخرجاته.
أعِد أخطاءً منظمة يمكن للوكيل الاستدلال بشأنها. بدلاً من فشل عام، أعِد ما الذي حدث خطأً وما الذي ينبغي للوكيل أن يجربه بشكل مختلف.
ينبغي أن تكون أدوات القراءة فقط قابلة للاستدعاء بحرية. وينبغي أن تكون أدوات الكتابة idempotent حيثما أمكن، وأن تتطلب الإجراءات التدميرية تأكيداً.
شغّل أدوات تنفيذ الكود في حاويات معزولة. قيّد الوصول إلى نظام الملفات واستدعاءات الشبكة ووقت التنفيذ. لا تمنح الوكلاء أبداً بيانات اعتماد root أو admin.
أعِد فقط ما يحتاجه الوكيل. إن إغراق استجابات API الكاملة يهدر tokens نافذة السياق ويربك النموذج. لخّص أو استخرج الحقول الرئيسية.
ينبغي أن يجيب كل وصف أداة عن ثلاثة أسئلة للـ LLM: ماذا تفعل هذه الأداة؟ متى ينبغي استخدامها؟ ما هي القيود؟
عملياً، تعود معظم إخفاقات الوكلاء إلى ثلاثة أسباب جذرية: (1) أوصاف أدوات غامضة تدفع النموذج إلى اختيار الأداة الخطأ، (2) مخرجات أدوات كبيرة جداً أو غير منظمة بما يكفي ليحللها النموذج، (3) معلومات أخطاء مفقودة تمنع الوكيل من التعافي. أصلِح هذه الأمور الثلاثة قبل اللجوء إلى نموذج أكثر قوة.
الوكيل بلا ذاكرة عديم الحالة — ينسى كل شيء بين الأدوار. تحتاج وكلاء الإنتاج إلى طبقات متعددة من الذاكرة للحفاظ على السياق، والتعلم من التجربة، وإدارة المهام طويلة الأمد.
سجل المحادثة الحالي المُمرَّر كرسائل إلى الـ LLM. هذا هو الشكل الأساسي للذاكرة ويُدار بواسطة إطار المحادثة.
حقائق وتفضيلات ومعرفة تُحفظ في vector store أو قاعدة بيانات منظمة عبر الجلسات. تُسترجَع عبر التشابه الدلالي وقت الاستدلال.
سجلات لمسارات الوكيل السابقة: ما جرّبه الوكيل، وما نجح، وما فشل. تتيح التعلم من التجربة دون إعادة تدريب.
مسودة منظمة يستخدمها الوكيل خلال مهمة واحدة لتتبّع الحالة الوسيطة والنتائج الجزئية والخطوات التالية.
من المفاهيم الخاطئة الشائعة أن نوافذ السياق الأكبر تلغي الحاجة إلى إدارة الذاكرة. وهي لا تفعل. حتى مع نوافذ تتجاوز 200k tokens، يتدهور الأداء بشأن المعلومات المدفونة في منتصف السياقات الطويلة. والأهم من ذلك، أن حشو كل شيء في نافذة السياق مكلف: بالأسعار الحالية، يكلّف سياق 100k tokens لكل استدعاء 10-50 ضعفاً أكثر من سياق 4k tokens مُدار جيداً مع استرجاع موجّه.
يمتلك الوكلاء القدرة على اتخاذ إجراءات حقيقية في العالم. وهذا يجعل حواجز الأمان غير قابلة للتفاوض. يمكن لوكيل سيئ التقييد أن يرسل رسائل بريد خاطئة، أو يحذف بيانات، أو ينفق ميزانية API بأكملها في دقائق. الأمان ليس ميزة تضيفها لاحقاً — بل هو قيد تصميمي منذ اليوم الأول.
أوقِف التنفيذ مؤقتاً قبل الإجراءات غير القابلة للعكس (إرسال رسائل بريد، تعديل قواعد البيانات، إجراء عمليات شراء). اعرض الإجراء المخطَّط وانتظر موافقة صريحة.
وجّه إلى إنسان عندما تكون ثقة الوكيل دون عتبة معينة. مفيد للحالات الحدية التي تقع خارج توزيع التدريب.
دع الوكيل يكمل المهام لكن علّم المخرجات لمراجعة بشرية غير متزامنة. جيد للمهام عالية الحجم ومنخفضة المخاطر حيث تهم السرعة.
بدون حدود تكرار صريحة، يمكن للوكلاء الدخول في حلقات لا نهائية — باستدعاء الأداة نفسها مراراً بوسائط مختلفة قليلاً، أو بالتذبذب بين حالتين. يجب أن يكون لكل وكيل إنتاج حد أقصى صارم للتكرارات (عادة 10-25 خطوة) ومهلة زمن ساعة الحائط. وعند بلوغ أيٍّ من الحدين، ينبغي للوكيل أن يعيد بأناقة نتيجة جزئية مع تفسير بدلاً من الفشل بصمت.
اختبار الوكلاء أصعب جوهرياً من اختبار البرمجيات التقليدية. الوكلاء غير حتميين؛ يعتمد سلوكهم على النموذج والأدوات والبيئة. تحتاج إلى استراتيجية تقييم متعددة الطبقات تغطي الصحة والكفاءة والأمان والتكلفة.
| البُعد | الوصف | الهدف | كيفية القياس |
|---|---|---|---|
| إنجاز المهمة | هل حقق الوكيل الهدف المعلن؟ | > 85% | نجاح/فشل ثنائي على مجموعة مهام محتجزة |
| كفاءة المسار | كم خطوة اتخذها الوكيل مقارنة بالأمثل؟ | < 1.5x الأمثل | مقارنة عدد الخطوات بالحلول المكتوبة بواسطة خبراء |
| دقة الأدوات | هل استُدعيت الأدوات الصحيحة بالوسائط الصحيحة؟ | > 90% | مقارنة المسار بتسلسلات استدعاء الأدوات المتوقعة |
| الامتثال للأمان | هل احترم الوكيل حواجز الأمان والحدود؟ | 100% | اختبار red-team بموجّهات عدائية |
| زمن الاستجابة (P95) | الزمن من طرف إلى طرف من مدخل المستخدم إلى الإجابة النهائية | < 30s | تتبّع المئينيات عبر حركة الإنتاج |
| التكلفة لكل مهمة | إجمالي تكلفة الـ LLM + استدعاء الأدوات لكل مهمة مكتملة | ضمن الميزانية | تتبّع tokens واستدعاءات API لكل مسار |
اختبر كل أداة بمعزل بمدخلات معروفة ومخرجات متوقعة. حاكِ التبعيات الخارجية. هذا اختبار برمجيات قياسي ويلتقط أخطاء التكامل قبل أن تتراكم في حلقة الوكيل.
سجّل التسلسل الكامل لاستدعاءات الأدوات والوسائط والملاحظات لمجموعة من مهام الاختبار. قارن بمسارات مرجعية مكتوبة بواسطة خبراء المجال. قيّم كلاً من النتيجة النهائية وكفاءة المسار المتّبع.
ابنِ مجموعة من 50-200 مهمة تمثيلية بنتائج صحيحة معروفة. شغّل الوكيل الكامل مقابل هذه المهام وقِس معدل إنجاز المهام. أعِد تشغيل المجموعة قبل كل نشر وبعد ترقيات النماذج.
اسبر الوكيل بشكل منهجي بـ prompt injections وطلبات خارج النطاق وحالات حدية ومدخلات عدائية. تحقق من صمود حواجز الأمان تحت الضغط. هذا مهم بشكل خاص للوكلاء الموجّهين للمستخدمين.
منصات tracing وتقييم للإنتاج. سجّل كل تشغيل وكيل، وعلّق على المسارات، وشغّل التقييمات على البيانات التاريخية، والتقط الانحدارات.
أطر تقييم للموجّهات والوكلاء. عرّف مجموعات الاختبار ككود، وقيّم المخرجات بمقيّمين مخصصين، وادمجها في pipelines الـ CI.
الفجوة بين عرض توضيحي يعمل ووكيل إنتاج هائلة. يجب أن يكون وكلاء الإنتاج قابلين للمراقبة، وفعّالين من حيث التكلفة، وصامدين أمام الإخفاقات، وقابلين للتوسع تحت الحمل.
بمجرد أن يكون لديك نظام وكيل واحد يعمل في الإنتاج، يمكن لهذه الأنماط أن تفتح قدرات جديدة. كلٌّ منها يضيف تعقيداً كبيراً، لذا تبنّها فقط عندما يكون لديك حاجة واضحة والنضج التشغيلي لدعمها.
بعد توليد مخرج، يقيّم استدعاء LLM منفصل (أو النموذج نفسه بموجّه ناقد) جودة النتيجة ويقترح تحسينات. ثم ينقّح الوكيل مخرجه بناءً على النقد. هذا فعّال بشكل خاص في توليد الكود والكتابة ومهام التحليل حيث تتحسن الجودة بالتكرار.
ملاحظة تنفيذ: حُدّ التأمل إلى 2-3 جولات. بعد ذلك، تستقر الجودة بينما تتوسع التكلفة خطياً. استخدم معايير تقييم منظمة للناقد لتجنب حلقات تغذية راجعة غامضة.
الأفضل للمخرجات الحساسة للجودةاعرض وكيلك كنقطة نهاية API يمكن للأنظمة الأخرى استدعاؤها. يصبح الوكيل خدمة مصغّرة تقبل أوصاف المهام وتعيد النتائج. يتيح هذا التركيب: يمكن لوكيل منسّق استدعاء خدمات وكلاء متخصصة، كلٌّ بأدواته ومعرفته بالمجال.
اعتبارات تصميم رئيسية: تنفيذ غير متزامن بـ webhooks للمهام الطويلة، مفاتيح idempotency لأمان إعادة المحاولة، عقود API مُصدّرة بإصدارات، وSLAs واضحة لزمن الاستجابة ومعدل النجاح.
الأفضل لفرق المنصات والأدوات الداخليةيفكّك وكيل ميتا المهام المعقدة إلى مهام فرعية، ويوجّه كلاً منها إلى الوكيل المتخصص الأنسب، ويجمع النتائج. هذا هو نمط supervisor متعدد الوكلاء على نطاق واسع، حيث قد يكون كل وكيل فرعي خدمة بذاتها بأدواتها وذاكرتها وحواجز أمانها.
يحتاج المنسّق إلى: استراتيجية تفكيك مهام (قائمة على LLM أو على قواعد)، سجل قدرات للوكلاء المتاحين، معالجة أخطاء للإخفاقات الجزئية، وخطوة تركيب تجمع النتائج الفرعية بتماسك.
الأفضل لسير عمل المؤسسات الممتدة عبر مجالات متعددةيسجّل الوكيل المسارات الناجحة والفاشلة، ثم يسترجع تجارب سابقة مشابهة وقت الاستدلال لتوجيه قراراته الحالية. مع مرور الوقت، يتعلم الوكيل فعلياً من سجل إنتاجه الخاص دون أي fine-tuning للنموذج. تُعلَّم المسارات الفاشلة بتحليل الأسباب الجذرية وتُحقَن كأمثلة سلبية.
يتطلب هذا: مخزن مسارات (vector DB مفهرسة حسب وصف المهمة)، عتبة تشابه للاسترجاع، تعليقاً بشرياً على أنماط الفشل، وقالب موجّه يدمج الأمثلة السابقة كسياق few-shot.
الأفضل للمهام المتكررة الخاصة بمجال معينلا يستجيب كل الوكلاء لموجّهات المستخدمين. بعضهم يعمل وفق جداول (شبيهة بـ cron) أو يُشغَّل عند الأحداث (بريد جديد، رسالة Slack، تغيّر في قاعدة البيانات). تراقب وكلاء الخلفية هؤلاء، وتلخّص، وتصعّد، وتؤتمت سير العمل الروتيني دون مبادرة بشرية.
أنماط التصميم: الاستقصاء + كشف التغيير، تنفيذ مُشغَّل بـ webhook، قوائم انتظار dead-letter للتشغيلات الفاشلة، ومعالجة idempotent للتعامل بأمان مع الأحداث المكررة.
الأفضل لأتمتة العملياتسواء كنت تصمم أول نظام وكلاء لك أو توسّع نظاماً قائماً، يمكننا مساعدتك في التنقّل بين قرارات المعمارية، وتجنّب المزالق الشائعة، وتسليم وكلاء موثوقين وآمنين وفعّالين من حيث التكلفة.