OpenClaw v2026.10.1 يضم 2425 طلب دمج من 402 مطوّرًا، والمستخدمون يشعرون بالإرهاق

أصدر OpenClaw النسخة v2026.10.1. ووفق البيانات الرسمية للمشروع، تضم النسخة عمل 402 مساهمًا: 2425 pull request و3055 commit. وطالت التغييرات الرئيسية Skills وMCP Apps، وهما الطبقتان اللتان تقوم عليهما قابلية توسيع الوكيل. وأرفقت وسيلة الإعلام الصينية Jiqizhixin الخبر بتحفظ: يقول بعض المستخدمين إنهم تعبوا من هذه التحديثات.

حجم الإصدار بالأرقام

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

• عدد المساهمين: 402
• Pull request: 2425
• Commits: 3055
• بالمتوسط نحو 6 PR ونحو 7,6 commit لكل مؤلف
• نحو 1,26 commit لكل PR

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

Skills وMCP Apps: ما الذي جرى تحديثه بالتحديد

Skills هي حزم من التعليمات والسيناريوهات يستدعيها الوكيل لمهمة محددة. أما MCP Apps فهي امتداد لـ Model Context Protocol: فالأداة لا تعيد نصًا أو JSON فحسب، بل تعيد أيضًا واجهة تفاعلية يعمل معها المستخدم مباشرةً داخل الحوار مع الوكيل. وكلا النظامين الفرعيين يحدد مدى سهولة إضافة قدرات جديدة إلى الوكيل.

توجد القائمة التفصيلية للتغييرات في هذين القسمين ضمن سجل التغييرات (changelog) الرسمي على docs.openclaw.ai. ولم تَرِد هذه القائمة في المقتطف الذي وصلنا من المادة، ولذلك لا يمكن حتى الآن الحكم على عمق التعديلات بحسب كل بند على حدة. المعروف فقط أن الاتجاهين كليهما كانا من بين المحاور الرئيسية للإصدار.

لماذا تعب المستخدمون

يضع عنوان Jiqizhixin الخط الثاني في صلب الخبر: رغم ضخامة الإصدار، يتحدث المجتمع عن الإرهاق. والسبب مفهوم. فحين يُصدر مشروع آلاف التعديلات في نسخة واحدة، يتحول كل تحديث إلى ما يشبه ترحيلًا صغيرًا. إذ ينبغي إعادة قراءة changelog، والتحقق من أن Skills الخاصة بالمستخدم وخوادم MCP المتصلة والإعدادات لم تتعطل، والتأكد من أن سلوك الوكيل لم يتغير في التفاصيل الدقيقة.

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

هنا يكمن التوتر المألوف في كثير من المشاريع المفتوحة المصدر سريعة النمو. فالمجتمع النشط يمنح السرعة وتغطية أوسع للسيناريوهات. لكن كلما زادت التعديلات، ازداد العبء على من يريد ببساطة أن تعمل إعدادات الأمس غدًا.

ماذا يفعل المستخدمون والفرق

الخطوات العملية لا تتوقف على تفاصيل إصدار بعينه.

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

يُظهر الإصدار نفسه أن لدى OpenClaw مجتمعًا كبيرًا ونشطًا. أما السؤال التالي أمام المشروع فهو: هل سيتمكن من الجمع بين هذه الوتيرة والاستقرار الذي ينتظره من يستخدمون الوكيل في عملهم اليومي؟