كيفية تحديث OpenClaw (Moltbot/Clawdbot) إلى أحدث إصدار

OpenClaw (المعروف سابقًا باسم Moltbot/Clawdbot) يتحرك بسرعة. هذه السرعة رائعة للميزات، ولكنها تعني أيضًا تغييرات متكررة في:

• سلوك تنسيق الوكلاء
• منطق نبضات القلب (فحوصات رخيصة أولاً، استدعاءات النموذج فقط عند الحاجة)
• أسماء متغيرات البيئة
• مخطط الاستمرارية وتدفق الترحيل
• افتراضات عقود المكونات الإضافية والأدوات

إذا قمت بالتحديث بشكل عرضي (git pull && restart)، فإنك تخاطر بحدوث أعطال صامتة: تظهر العمال بصحة جيدة ولكنهم يتوقفون عن إكمال المهام، تفشل محولات الأدوات بسبب انحراف المخطط، أو تظهر زيادات في التكلفة لأن عتبات نبضات القلب/النموذج قد تغيرت.

يقدم لك هذا الدليل استراتيجية تحديث آمنة للإنتاج مع أوامر ملموسة وخطوات تحقق.

قبل التحديث: حدد بنية التثبيت الخاصة بك

تتناسب معظم عمليات نشر OpenClaw الحقيقية مع أحد هذه الأنماط:

1. تشغيل Docker بعقدة واحدة (استضافة ذاتية سريعة)
2. مكدس Docker Compose (OpenClaw + قاعدة بيانات + Redis + حاويات مساعدة)
3. Systemd + venv (تثبيت من المصدر على خادم افتراضي خاص VPS)
4. إعداد حافة هجين (EC2 + Tailscale + مستوى تحكم خاص)

يجب أن تتطابق خطة التحديث الخاصة بك مع بنية النظام الخاص بك لأن آليات التراجع تختلف.

• Docker/Compose: التراجع عبر إعادة تثبيت علامة الصورة.
• التثبيت من المصدر: التراجع عبر علامة git + قفل التبعيات.
• قاعدة بيانات مُدارة: قد لا يكون تراجع المخطط سهلاً.

إذا لم تكن قد وثقت بنية النظام الحالي لديك، فافعل ذلك أولاً.

الخطوة 1: تثبيت الإصدار الحالي والتقاط حالة وقت التشغيل

تعامل مع هذا كنقطة استعادة.

أ. تسجيل بيانات الإصدار/البناء الوصفية

صورة الحاوية

docker ps --format 'table {{.Names}}\t{{.Image}}'

إذا كان OpenClaw يكشف نقطة نهاية الإصدار

curl -s http://localhost:8080/version | jq

تثبيت يعتمد على Git

cd /opt/openclaw git rev-parse --short HEAD git describe --tags --always

ب. التقاط لقطة لمتغيرات البيئة والتكوين

cp /etc/openclaw/.env /backups/openclaw-env-$(date +%F).bak cp -r /etc/openclaw/config /backups/openclaw-config-$(date +%F)

قم أيضًا بتصدير مراجع الأسرار (وليس الأسرار الخام) وتأكيد موفري الرموز المميزة، وإعدادات توجيه النموذج، وعتبات نبضات القلب.

ج. نسخ البيانات المستمرة احتياطيًا

لقاعدة بيانات PostgreSQL:

bash pg_dump -Fc -h  -U   > /backups/openclaw-$(date +%F).dump
لقاعدة بيانات Redis (إذا كانت قوائم الانتظار/نقاط الفحص ذات الحالة تهم):
bash redis-cli -h  BGSAVE

إذا تخطيت هذه الخطوة، فلن يكون لديك خطة تراجع.

الخطوة 2: قراءة ملاحظات الإصدار بحثًا عن علامات الترحيل وتغييرات السلوك

نظرًا للتطور الأخير لـ OpenClaw (بما في ذلك إعادة الهيكلة في عصر إعادة التسمية)، غالبًا ما تتضمن ملاحظات الإصدار متطلبات لمرة واحدة مثل:

• إعادة تسمية متغير البيئة (أنماط CLAW_* إلى OPENCLAW_*)
• تغييرات أوامر الترحيل
• الإعدادات الافتراضية لمجدول نبضات القلب
• تحديثات تنسيق بيان الأداة/المكون الإضافي
• إهمال واجهات محولات النموذج الأقدم

أنشئ قائمة تحقق قصيرة من ملاحظات الإصدار:

• إعادة تسمية التكوين المطلوبة
• أمر الترحيل
• تغييرات قائمة الانتظار/الموضوع
• دلالات نقطة نهاية الصحة الجديدة
• تغييرات المهلة الافتراضية/حماية التكلفة

الخطوة 3: تجهيز التحديث في بيئة ما قبل الإنتاج

لا تختبر في الإنتاج أولاً أبدًا. استنسخ شكل نشرك.

الحد الأدنى لدقة التجهيز:

• نفس فجوة إصدار OpenClaw (الحالي -> الهدف)
• نفس الإصدار الرئيسي لمحرك قاعدة البيانات
• نفس الواجهة الخلفية لقائمة الانتظار
• نفس محولات موفر النموذج
• تدفقات عمل حقيقية ممثلة (5-10 على الأقل)

إذا كان فريقك لديه واجهات برمجة تطبيقات حول OpenClaw (أدوات مخصصة، webhooks، التحكم في المهام)، فهذا هو المكان الذي يساعد فيه Apidog على الفور.

استخدم Apidog لـ:

• استيراد/تحديث تعريفات OpenAPI الخاصة بك
• التحقق من عقود الطلب/الاستجابة لنقاط نهاية أدواتك
• تشغيل اختبارات الانحدار المستندة إلى السيناريو قبل النشر
• نشر وثائق تفاعلية لنقاط النهاية المتغيرة بحيث تتوافق فرق الواجهة الأمامية/ضمان الجودة بسرعة

هذا يمنع حوادث "تم تحديث OpenClaw بشكل جيد، ولكن التكاملات تعطلت".

الخطوة 4: التحديث حسب نوع النشر

الخيار أ: Docker Compose

ثبت العلامات الصريحة في docker-compose.yml (تجنب latest في الإنتاج).

yaml services: openclaw: image: ghcr.io/openclaw/openclaw:v1.14.2 env_file: - .env depends_on: - postgres - redis

عملية التحديث:

bash docker compose pull openclaw docker compose up -d openclaw

إذا كانت عمليات الترحيل منفصلة:

bash docker compose run --rm openclaw openclaw migrate

ثم أعد تشغيل العمال:

bash docker compose up -d worker scheduler

الخيار ب: Docker العادي

bash docker pull ghcr.io/openclaw/openclaw:v1.14.2 docker stop openclaw docker rm openclaw

docker run -d
 --name openclaw
 --env-file /etc/openclaw/.env
 -p 8080:8080
 ghcr.io/openclaw/openclaw:v1.14.2

قم بتشغيل أمر الترحيل إذا كان مطلوبًا.

الخيار ج: المصدر + systemd

bash cd /opt/openclaw git fetch --tags git checkout v1.14.2

إعادة بناء البيئة

source .venv/bin/activate pip install -r requirements.txt

الترحيل

openclaw migrate

إعادة التشغيل

sudo systemctl restart openclaw-api openclaw-worker openclaw-scheduler

تحقق من أن تجاوزات وحدة systemd لا تزال تتطابق مع وسيطات CLI الجديدة.

الخطوة 5: التحقق من الصحة بما يتجاوز "العملية قيد التشغيل"

العملية الجارية لا تعني نظام وكيل صحي.

فحوصات الصحة الواجب تشغيلها فوراً

جاهزية/نشاط واجهة برمجة التطبيقات (API)bash curl -f http://localhost:8080/health/livecurl -f http://localhost:8080/health/ready

إنتاجية قائمة الانتظار

• وضع مهمة اختبار في قائمة الانتظار
• تأكيد مطالبة العامل
• تأكيد زمن استجابة الإكمال

1. سلوك نبضات القلبنظرًا للاتجاهات الحديثة في تصميم نبضات القلب (الفحوصات الرخيصة أولاً)، تأكد من:

• الفحوصات الرخيصة تعمل في الموعد المحدد
• الفحوصات المدعومة بالنموذج لا يتم تشغيلها إلا عند العتبات المتوقعة
• لا توجد استدعاءات LLM عرضية دائمة التشغيل

ضوابط التكلفة وزمن الاستجابةتحقق من قياسات التوكن/التكلفة قبل/بعد التحديث لنفس حمل عمل الاختبار.

استدعاء المكون الإضافي/الأداةقم بإجراء استدعاء واحد على الأقل لكل محول أداة حاسم.

الخطوة 6: تشغيل اختبارات عقود API واختبارات الانحدار باستخدام Apidog

هنا يمكن للعديد من مشغلي OpenClaw زيادة الموثوقية بسرعة.

إذا كان OpenClaw يتفاعل مع واجهات برمجة التطبيقات الداخلية (واجهات برمجة تطبيقات المهام، واجهات برمجة تطبيقات الأدوات، نقاط نهاية رد الاتصال)، فاستخدم Apidog كبوابة جودة:

• التصميم: حافظ على مخططات نقطة النهاية متوافقة في سير عمل يعتمد على OpenAPI أولاً.
• الاختبار: بناء سيناريوهات اختبار آلية للنجاح، المهلة، إعادة المحاولة، وحمولات البيانات المشوهة.
• المحاكاة: استخدم نقاط نهاية محاكاة ذكية لاختبار سلوك OpenClaw حتى عندما تكون الأدوات النهائية غير متصلة بالإنترنت.
• التوثيق: أنشئ وثائق تلقائية للعقود المتغيرة حتى تتوقف الفرق عن استخدام الأمثلة القديمة.
• CI/CD: تشغيل مجموعة اختبارات الانحدار عند كل ترقية إصدار قبل ترقية النشر.

نموذج عملي:

1. استيراد المجموعة/المواصفات الحالية إلى Apidog.
2. أضف تأكيدات للحقول التي يعتمد عليها OpenClaw (task_id، status، tool_result، correlation_id).
3. أضف حالات سلبية (429، 500، مهلة).
4. شغل في CI على فرع الترقية.
5. حظر الإصدار إذا ظهرت اختلافات تكسر العقد.

هذا أكثر أمانًا بكثير من اختبار نقطتي نهاية يدويًا بعد إعادة التشغيل.

الخطوة 7: استراتيجية النشر للإنتاج

بالنسبة للإعدادات ذات العقدة الواحدة، خطط لفترة صيانة قصيرة.

بالنسبة للإعدادات متعددة النسخ، قم بنشر تدريجي/كناري:

1. تحديث نسخة API واحدة
2. تحديث جزء واحد من مجمع العمال
3. راقب معدل الخطأ، تأخر قائمة الانتظار، استهلاك الرمز المميز لمدة 15-30 دقيقة
4. استمر في النشر إذا كان مستقراً

راقب هذه المقاييس:

• معدل نجاح المهام
• حجم إعادة المحاولة
• نمو قائمة الرسائل المعطلة
• زمن إكمال المهمة في المئين 95
• معدل طلبات LLM/استخدام الرمز المميز

تغيير بسيط في التكوين يمكن أن يجتاز فحوصات الصحة ولكنه يقلل من الإنتاجية.

مشاكل الترقية الشائعة والإصلاحات

1) العمال في وضع الخمول بعد بدء تشغيل API بنجاح

السبب: تغيير مساحة اسم/موضوع قائمة الانتظار أو عدم ملاحظة إعادة تسمية متغير البيئة.

الإصلاح: قارن ملفات البيئة القديمة/الجديدة وتحقق من إعدادات بادئة قائمة الانتظار.

2) نبضات القلب تؤدي إلى استدعاءات نموذجية مفرطة

السبب: تغيرت الإعدادات الافتراضية؛ لم يتم تعيين عتبة الفحص الرخيص.

الإصلاح: اضبط مستويات نبضات القلب وحدود تصعيد النموذج بشكل صريح في التكوين.

3) فشل الأداة/المكون الإضافي مع أخطاء المخطط

السبب: انحراف عقد حمولة البيانات بعد الترقية.

الإصلاح: شغل اختبارات عقود Apidog؛ حدث محولات الأدوات لتتطابق مع الحقول المطلوبة الجديدة.

4) ارتفاع تكاليف الرمز المميز بعد الترقية

السبب: سياسة إعادة المحاولة + تغييرات نبضات القلب + نوافذ سياق أطول.

الإصلاح: حدد عدد مرات إعادة المحاولة، فرض سياسة الميزانية، قارن تتبع الطلبات بالإصدار السابق.

5) ارتباك إعادة التسمية (Moltbot/Clawdbot/OpenClaw)

السبب: أسماء حزم مختلطة، علامات حاوية، وثائق قديمة.

الإصلاح: توحيد أدلة التشغيل الداخلية على مصدر واحد موحد للتحف الفنية واتفاقية العلامات.

ملاحظات الأمان والشبكات للمستضيفين ذاتيًا

يقوم العديد من المطورين بنشر OpenClaw على EC2/VPS مع وصول شبكي خاص (مثل بنية شبكة Tailscale). أثناء التحديثات:

• تحقق من أن قواعد جدار الحماية لم تتراجع
• تأكد من أن نقاط نهاية المسؤول تظل خاصة
• قم بتدوير مفاتيح API إذا كان التحديث يتضمن تغييرات في معالجة الأسرار
• تحقق من إنهاء TLS بعد تبديل الحاوية/الصورة

تأكد أيضًا من أن قوائم السماح لردود الويب هوك لا تزال تتطابق مع عنوان IP الصادر أو هوية النفق.

قائمة التحقق الموصى بها لتحديث الإنتاج

استخدم هذا في كل مرة:

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

الاتساق أهم من السرعة.

أفكار أخيرة

تحديث OpenClaw بأمان هو تخصص هندسي، وليس أمرًا واحدًا. تعكس رحلة إعادة التسمية من Moltbot/Clawdbot إلى OpenClaw مشروعًا يتطور بسرعة، ويجب أن تتماشى عمليتك التشغيلية مع هذا التطور.

إذا قمت بدمج طريقة نشر/تراجع قوية مع اختبار عقود API، فسوف تتجنب معظم آلام الترقية. يتناسب Apidog بشكل طبيعي هنا: صمم وقم بتحديد إصدارات عقود API، وشغل فحوصات الانحدار الآلية، وقم بمحاكاة التبعيات أثناء التجهيز، وانشر وثائق دقيقة لكل واجهة يتفاعل معها OpenClaw.

إذا كان سير عمل التحديث الحالي لديك يدويًا في الغالب، فابدأ صغيرًا: أضف بوابة تجهيز واحدة ومجموعة اختبار Apidog آلية واحدة هذا الأسبوع. عادة ما يؤتي هذا التغيير الواحد ثماره بحلول الإصدار التالي.