OpenClaw: تفكيك الإعدادات من أول بوت إلى نظام متعدد الوكلاء في Telegram

يسمح OpenClaw برفع وكيل ذكاء اصطناعي على Telegram حرفياً في مساء واحد: الأمر `openclaw onboard` يقوم بتكوين البوابة (Gateway) وتشغيل أول بوت لديك. توقف معظم الأدلة هنا تماماً. دليل تفصيلي جديد يغطي المستوى التالي: كيفية عمل كامل التكوين من الداخل، كيفية الانتقال من بوت توضيحي واحد إلى نظام إنتاج حقيقي مع عدة وكلاء وبدون هدر غير ضروري للرموز (tokens).

ما بداخل openclaw.json

ملف التكوين openclaw.json هو الملف المركزي للتحكم في النظام بأكمله. تغطي الوثائق الرسمية لـ OpenClaw محتوياته بشكل جزئي، لذلك فإن تحليل كل قسم مع أمثلة عملية قيّم بشكل خاص.

الأقسام الرئيسية للتكوين:

• gateway — العنوان والمنفذ (port) لطلبات الإدخال إلى الوكلاء
• agents — قائمة الوكلاء مع تعليمات النظام وربط النماذج اللغوية
• bindings — قواعد التوجيه: أي وكيل يجب أن يستقبل كل رسالة واردة
• session_policy — إدارة الذاكرة: متى يتم إعادة تعيين السياق ومدة الاحتفاظ بالسجل
• workspace — المسار إلى ملفات العمل التي يتم تحميلها في سياق الوكيل

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

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

نبض القلب بدون استهلاك خامل للرموز

Heartbeat هو آلية لإيقاظ الوكيل بشكل دوري. يسمح بتنفيذ المهام بشكل مستقل، بدون رسالة واردة: مراقبة الأحداث، إرسال التقارير، التحقق من حالة الخدمات الخارجية.

فخ نموذجي هو تفعيل heartbeat بفاصل زمني قصير بدون شروط تفعيل. يبدأ الوكيل في توليد مئات الطلبات الفارغة إلى نموذج اللغة ويهدر الرموز بدون فائدة.

يتضمن التكوين الفعال ثلاثة عناصر إلزامية:

• فاصل زمني معقول — عادة لا يقل عن 5–10 دقائق لمعظم السيناريوهات
• شرط التفعيل — فقط عندما تكون هناك أحداث جديدة أو بيانات للمعالجة
• تعليمة heartbeat منفصلة — غير مخلوطة مع تعليمة النظام الرئيسية للوكيل

« النبض بدون شروط الحراسة — هذا مولد استهلاك، وليس ميزة »، — من نقاشات مجتمع

OpenClaw.

يعمل نبض القلب المكوّن بشكل صحيح بصمت وينشط فقط عندما تكون هناك مهمة حقيقية.

الوكلاء المتعددون: الربط والمواضيع

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

يتحمل التوجيه مسؤولية القسم `bindings`. يربط مصدر الرسالة (chat_id + topic_id) بوكيل معين. إذا لم يتم تعيين الربط — تذهب الرسالة إلى الوكيل الافتراضي، مما يكسر منطق العمل في نظام متعدد الوكلاء في معظم الحالات.

يتطلب session_policy في التكوينات الجماعية تحديد النطاق بوضوح. بدون ذلك، قد تختلط سياقات مستخدمين مختلفين في نفس المحادثة — سيبدأ الوكيل في "تذكر" بيانات الأشخاص الخاطئين.

ماذا يعني هذا

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

مفيد لكل من يبني بنية تحتية للذكاء الاصطناعي على Telegram وتجاوز بوتاً توضيحياً واحداً.