قسّمت OpenClaw العمل متعدد الوكلاء إلى ثلاثة أوضاع: وكلاء مستقلون، ووكلاء فرعيون، وACP

قدمت OpenClaw نموذج متعدد الوكلاء ليس كفكرة مجردة، بل كمجموعة من أنماط العمل للمهام الحقيقية في Telegram. يمكن للمستخدم إدارة وكيل رئيسي واحد ثم توزيع الأدوار على المنفذين الدائمين والوكلاء المؤقتين والأدوات الخارجية للتطوير عبر ACP.

ثلاثة أنماط تشغيل

يستند مخطط OpenClaw إلى ثلاث طرق مختلفة للتفويض. الأولى—وكلاء دائمون منفصلون لهم مجلدهم الخاص بالعمل والذاكرة والتعليمات. الثانية—وكلاء فرعيون يطلقهم الوكيل الرئيسي لمهمة محددة فريدة ويوفر فقط السياق اللازم. الثالثة—ACP، أي نمط يتم فيه تنفيذ العمل الهندسي ليس بواسطة OpenClaw نفسه، بل بواسطة أداة خارجية متصلة مثل Codex أو Claude Code أو Gemini CLI. النتيجة ليست مساعداً عاماً واحداً، بل موزّع يمكنه اختيار مستوى التنفيذ المناسب لنوع العمل.

• وكيل دائم—لدور مطلوب بشكل منتظم
• وكيل فرعي—لبحث فريد أو جزء من مهمة كبيرة
• ACP—لمهام التطوير في بيئة خارجية
• الوكيل الرئيسي—للتوجيه والتحكم وتجميع النتائج

"الوظيفة متعددة الوكلاء في

OpenClaw ليست زراً واحداً، بل عدة أنماط تشغيل للوكلاء."

متى يحتاج إلى كل واحد

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

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

للتطوير، توفر OpenClaw مسار منفصل عبر ACP. هنا يبقى الوكيل الرئيسي نقطة الدخول والمصحح، لكن الكود نفسه تكتبه أداة خارجية. تصف المقالة ثلاثة سيناريوهات: جلسة ACP فريدة لمهمة هندسية معزولة، جلسة ACP دائمة لمشروع طويل الأمد، وربط سياق ACP بموضوع Telegram منفصل، حيث يوجد خط النقاش التقني بشكل منفصل عن الدردشة الرئيسية. يكون هذا النمط ضرورياً عندما يتطلب المشروع سياقاً طويلاً وتكرارات متسلسلة ومزايا أدوات سطر الأوامر المتخصصة.

Telegram كلوحة تحكم

يؤكد المؤلف على Telegram كواجهة طبيعية لهذه البنية. يمكن ربط وكيل دائم بـ bot منفصل أو بالموضوع الحالي، والسياق التقني ACP—بفرع مخصص في الدردشة. نتيجة لذلك، لا تختلط الأدوار وخطوط العمل: يجري البحث في مكان واحد، والتطوير—في مكان آخر، بينما يبقى الوكيل الرئيسي نقطة الدخول المركزية لتعيين المهام. بالنسبة للمستخدم، هذا لا يبدو مثل بنية معقدة، بل كخريطة مفهومة للحوارات مع أنواع مختلفة من المنفذين.

من هنا يتبع السيناريو الرئيسي لـ OpenClaw: يتوقف الوكيل الرئيسي عن كونه محاوراً فحسب ويصبح منسقاً للنظام. يمكنه إرسال البحث إلى وكيل منفصل، مهمة فرعية فريدة—إلى وكيل فرعي، الجزء الهندسي—إلى ACP عبر Codex، ثم إرجاع إجابة واحدة مجمعة. أي أن المستخدم لا يدير كل إجراء يدوياً، بل منطق توزيع العمل. وبالضبط في هذا تكمن القيمة العملية للوظيفة متعددة الوكلاء: إدارة دقيقة أقل، تخصص مدار أكثر، وعمل متوازي أكثر.

ما الذي يعنيه هذا

تقدم OpenClaw فعلياً ليس "وكيل ذكاء اصطناعي سحري،" بل نموذج عملياتي للفرق والمطورين الفرديين الذين يريدون توزيع الأدوار والسياق والأدوات عبر قنوات مختلفة. إذا ترسخ هذا النهج، ستشبه دردشات Telegram مع الوكلاء بشكل متزايد IDE خفيف الوزن ومركز توزيع في نفس الوقت: نقطة دخول واحدة وعدة منفذين وفصل أنظف بين البحث والمحتوى والكود.