اتضح أن OpenClaw وكيل مستقل مكلف: 81 مليون توكن وتعارضات مع الخادم

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

وحش على الخادم

بدأ المؤلف بسيناريو نموذجي: أخذ خادماً افتراضياً يعمل حيث كانت هناك بالفعل مواقع على React و PostgreSQL و n8n وعدة روبوتات Telegram بسيطة، ونشر OpenClaw هناك. ظهرت المشكلة الأولى تقريباً بعد مباشرة خطأ في إعدادات رمز Telegram. بدلاً من إعادة تثبيت خالية من الألم، ترك النظام وراءه "بقايا" في systemd والتكوينات ومجلد `.openclaw`. استمرت المعاملات القديمة في التأثير على التشغيلات الجديدة، لذا فإن الطريقة المألوفة "حذفت وأعدت التثبيت" ببساطة لم تعمل.

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

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

لا يحب المصاحبات الموسيقية

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

حتى عندما وصل الطلب رسمياً، لم يتحول إلى استجابة عادية للسيناريو.

• احتاجت MCP إلى رمز ديناميكي لم يتمكن المصاحب من الحصول عليه
• قبلت Webhooks الطلبات لكنها لم تمررها للوكيل نفسه
• استدعاء نص Python المباشر أطلق الأمر لكنه لم يعد النتيجة
• أدى إنشاء مهارتك الخاصة إلى خطأ في المصادقة

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

بعبارة أخرى، أثبتت قوة الوكيل أنها قيدها الرئيسي.

"OpenClaw ليس مساعداً. إنه نينجا."

الأجهزة والرموز

ظهرت مفاجأة غير سارة أخرى عند توصيل نماذج محلية من خلال Ollama. لم تناسب الخيارات الخفيفة مثل `phi3:mini` و `gemma2:2b` و `gemma3:4b` لأنها لا تدعم الأدوات أو استدعاء الوظيفة، بدونه لا يمكن للوكيل أن يعمل بشكل صحيح.

تم العثور على نماذج متوافقة، لكن بالفعل بوزن مختلف: `qwen2.5:7b` و `llama3.1:8b` والحلول المماثلة تتطلب موارد أكثر بكثير. على VDS مع 32 GB من RAM، استغرقت الاستجابات من خمس إلى عشر دقائق لكل منها، والتنفيذ المتوازي للخدمات الأخرى أدى إلى أخطاء في الذاكرة.

من هذا نما المستوى الثاني من التكاليف. لتشغيل OpenClaw المستقر محلياً، وفقاً لتقييم المؤلف، تحتاج إلى خادم منفصل مع وحدة معالجة رسومات مثل V100 أو RTX 4090 وما لا يقل عن 12 GB من VRAM، وهذا هو بالفعل عشرات الآلاف من الروبلات شهرياً في الإيجار. لم تساعد محاولة الهروب من هذه المشكلة عبر API أيضاً.

تم استهلاك 5 ملايين رمز تم شراؤها من DeepSeek بواسطة الوكيل في ليلة واحدة دون أي مهام مفيدة تقريباً: فحص النماذج وتصفح الملفات الشخصية وارتكاب الأخطاء والضغط على API مرة أخرى. بعد الانتقال إلى OpenRouter، قامت ثلاث جلسات على مدار عدة ساعات بحرق 76 مليون رمز آخر.

في المجموع على مدار ثلاثة أيام، وصل الاستهلاك إلى حوالي 81 مليون رمز، مع ذهاب جزء كبير ليس إلى النص للمستخدم، بل إلى الفحوصات الداخلية واستدعاءات API المتكررة.

ماذا يعني هذا

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

لكن وعد "نشر وننسى" لا يعمل هنا: بدون بيئة مخصصة ونماذج متوافقة ومراقبة وميزانية واضحة، ينتقل المشروع بسرعة من فئة التجربة إلى بند دائم في النفقات.