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

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

ثلاثة أنماط عمل

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

والنتيجة ليست مساعدًا واحدًا شاملًا، بل منسّق يعرف كيف يختار مستوى التنفيذ المناسب لنوع العمل.

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

«تعدد الوكلاء في

OpenClaw ليس زرًّا واحدًا، بل عدة أنماط لعمل الوكلاء».

متى يلزم كل نمط

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

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

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

Telegram كلوحة تحكم

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

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

ماذا يعني ذلك

ما تقترحه OpenClaw عمليًا ليس «وكيل ذكاء اصطناعي سحريًا»، بل نموذج تشغيلي للفرق والمطورين المنفردين الذين يريدون توزيع الأدوار والسياق والأدوات على قنوات مختلفة. وإذا ترسّخ هذا النهج، فستزداد محادثات Telegram مع الوكلاء شبهًا ببيئة تطوير خفيفة (IDE) وغرفة تحكّم في آن واحد: نقطة دخول واحدة، وعدة منفّذين، وفصل أوضح بين البحث والمحتوى والبرمجة.