LangGraph وCrewAI وOpenAI وGoogle وMicrosoft وClaude: أي إطار لتنسيق الوكلاء تختار؟

ماذا يفعل إطار التنسيق فعلًا؟

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

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

ما المقاربات الست الرئيسية؟

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

CrewAI: فريق الأدوار. تعرّف الوكلاء بدورهم وهدفهم وخلفيتهم، ثم المهام التي توكلها إليهم. وينفذها الفريق بالتتابع أو بتنسيق وكيل مدير. والنموذج الذهني سهل القراءة جدًا لفرق الأعمال: تصف فريقًا كما تصف مؤسسة. وللأجزاء التي يجب أن تبقى حتمية، يقدم CrewAI أيضًا «Flows» تقودها الأحداث.

Microsoft Agent Framework: سير العمل المؤسسي. هو خليفة Semantic Kernel وAutoGen، وصدر بالإصدار 1.0 في أبريل 2026 لـ .NET وPython. ويفصل بوضوح بين الوكيل (نموذج يستدعي أدوات) وسير العمل: رسم بياني محدد النوع يربط الوكلاء والدوال، مع تفرعات وتوازٍ ونقاط حفظ وموافقة بشرية. ويستعيد أنماط التنسيق الموروثة من AutoGen (تتابعي، متزامن، تسليم، محادثة جماعية، Magentic-One) ويتصل بعدة مزودي نماذج وبـ MCP وA2A.

OpenAI Agents SDK: التفويض. تقوم الحزمة على عدد قليل من المكونات الأساسية: وكلاء وأدوات و«تسليمات» (handoffs) ينقل فيها وكيل المحادثة إلى وكيل أكثر تخصصًا، ووكلاء يُستخدمون كأدوات (يستدعي وكيل وكيلًا آخر ويحتفظ بالقيادة). وتضاف إليها ضوابط على المدخلات والمخرجات، وجلسات لذاكرة المحادثة، وتتبّع مدمج. إنها أخف مقاربة لفرز الطلب ثم تحويله إلى المتخصص المناسب.

Google ADK: وكلاء وسير عمل في تسلسل هرمي. يجمع Agent Development Kit بين وكلاء يقودهم النموذج ووكلاء «سير عمل» حتميين: تتابعي ومتوازٍ وحلقة. وتُدمج هذه الوكلاء في شجرة تحت وكيل جذر. وADK محسّن لـ Gemini وGoogle Cloud لكنه يبقى منفتحًا على نماذج أخرى، ويدعم بروتوكول A2A ليتحاور الوكلاء عبر الأنظمة.

Claude Agent SDK: حلقة الوكيل المزودة بالأدوات. تكشف الحزمة الحلقة التي يعمل بها Claude Code: يجمع النموذج السياق، ثم يتصرف بالأدوات (ملفات، أوامر، خوادم MCP)، ثم يتحقق من النتيجة ويعيد الكرّة حتى تنتهي المهمة. ويمر التنسيق عبر وكلاء فرعيين يعمل كل منهم في سياقه الخاص ولا يعيد إلا نتيجته، وعبر خطافات (hooks) يمكنها منع استدعاء أداة قبل تنفيذه. وهي مصممة للمهام الطويلة الكثيفة الأدوات التي لا يمكن رسم مسارها مسبقًا.

أيها تختار بحسب وضعك؟

الجدول أدناه قراءتي الخاصة، وليس مقارنة معيارية. وهو يقارن ما يهم عند اتخاذ القرار.

ما القواعد التي تساعد على الحسم؟

ثلاث قواعد بسيطة تجنبني معظم الخيارات السيئة:

• إن كنت تستطيع رسم العملية، فارسمها. فالرسم البياني أو سير العمل (LangGraph وMicrosoft Agent Framework وسير عمل ADK) أسهل في الاختبار والتدقيق والحصول على موافقة فرق الأعمال.
• إن كان المسار يتوقف على ما يكتشفه الوكيل، فدع النموذج يقود، لكن داخل صندوق. هذا ميدان حلقة الوكيل والتفويض (Claude Agent SDK وOpenAI Agents SDK)، مع حدود للخطوات والتكلفة والأدوات.
• اختر أولًا المنظومة التي تعرف فرقك تشغيلها. فإطار متوسط يُشغَّل جيدًا خير من إطار ممتاز لا يعرف أحد تصحيح أخطائه في الثانية فجرًا.

ما الفخاخ التي تظهر في الإنتاج؟

نادرًا ما يكون اختيار الإطار سبب فشل المشروع. فما يتعثر هو المواضيع نفسها أيًّا كان الشعار.

الحالة. الوكيل الذي يعمل عدة دقائق، أو ينتظر موافقة، يجب أن يستطيع التوقف والاستئناف دون البدء من الصفر. تحقق من مكان تخزين الحالة، وهل تصمد بعد إعادة التشغيل، ومن يستطيع قراءتها. نقاط الحفظ في LangGraph أو Microsoft Agent Framework تجيب عن هذا السؤال؛ أما في مقاربة أكثر حرية فالأمر متروك لك.

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

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

التكلفة. كل وكيل إضافي، وكل حلقة مراجعة، وكل تفويض يضيف استدعاءات للنموذج. حدد ميزانيات للخطوات والرموز لكل تنفيذ، وقِس التكلفة لكل مهمة ناجحة، ونبّه على التنفيذات المتطرفة. فالوكيل الذي يدور في حلقة لا يكلّف وقتًا فقط.

التبعية والسيادة. ثلاثة من الأطر الستة تأتي من مزودي نماذج، واثنان من مزودي سحابة. وكلها تعمل أفضل مع منظومتها الأصلية حتى حين تقبل نماذج أخرى. اطرح ثلاثة أسئلة قبل الالتزام: هل يمكن تغيير النموذج دون إعادة كتابة التنسيق؟ أين تُستضاف الآثار والحالة؟ ماذا يحدث إن اختفت ميزة مستضافة أو تغيّر سعرها؟ وللبيانات الحساسة، أبقِ منطق الأعمال (الأدوات والقواعد والتعليمات) في كودك الخاص، وتعامل مع الإطار كطبقة قابلة للاستبدال.

من أين تبدأ؟

نصيحتي واحدة أيًّا كان الإطار: ابدأ بوكيل واحد، مع أداتين أو ثلاث وتتبّع. قِس أين يفشل. ولا تضف وكيلًا ثانيًا أو رسمًا بيانيًا أو تفويضًا إلا حين يفرضه حدّ مقيس. فمعظم حالات الاستخدام في المؤسسات لا تحتاج إلى ستة وكلاء يتحاورون فيما بينهم، بل إلى عملية واضحة ووكيل موثوق وإنسان في المكان المناسب.