تطور ذاتي كل ليلة - الحزام الذكي الذي يحسّن نفسه بنفسه

نظرة عامة: نظام يتحسن كل ليلة

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

ماذا لو حلّل النظام بنفسه إخفاقات الأمس كل ليلة، وأنتج تحسينات، وتحقق منها بأمان، ثم حدّث نفسه؟

مع انتشار نماذج اللغة الكبيرة، تركّز كثير من المنظمات على “اعتماد وكلاء الذكاء الاصطناعي”. لكن السؤال الذي يعقب الاعتماد لا يزال غير مُستكشَف بما يكفي: هل يتحسن الوكيل بمرور الوقت، أم يتوقف عند مستوى إعداده الأولي؟ عند تكرار الفشل، هل يفشل بنفس الطريقة؟

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

تُشغّل ThakiCloud هذه الرؤية كحلقة تشغيلية حية. مهمتان مستقلتان تنفذان بشكل متتالٍ كل منتصف ليل. الأولى selfharness-evolve تبدأ في 00:00 وتستخرج آثار إخفاقات الوكيل خلال الأربع والعشرين ساعة الماضية لتحسين الحزام نفسه. والثانية skill-evolution تبدأ في 00:15 وتولّد مهارات جديدة وتحسّن المهارات القائمة. تُطلَق المهمتان دون تدخل بشري عبر launchd المحلي، فيما يتولى نموذج Opus – الأكثر قدرةً على الاستدلال – جميع القرارات.

تشرح هذه المقالة مبادئ عمل تلك الحلقة الليلية: ما الضمانات التي تحجب الهلوسة، وكيف تتعاون الآليات المتعددة لتطور المهارات، وكيف سيتحول هذا إلى منتج بوصفه Curator daemon على منصة Praxis.

التعلم من إخفاقات الأمس: Weakness Mining

نموذج Self-Harness

الأساس النظري للتطور الليلي هو ورقة بحثية نُشرت عام 2026 بعنوان Self-Harness: Harnesses That Improve Themselves (arXiv:2606.09498). الرؤية المحورية فيها بسيطة:

أداء الوكيل = قدرة النموذج الأساسي × جودة الحزام

النموذج نفسه ثابت، لكن الحزام – أي موجّه النظام، وتعريفات الأدوات، وتدفق التحكم، ومواصفات المهارات – يمكن أن يتطور. كانت الأحزمة التقليدية تتجمد فور أن يصممها المهندس. يحوّل Self-Harness تلك البنية التحتية ذاتها إلى قطعة قابلة للتعلم.

تكشف النتائج التي أوردتها الورقة على Terminal-Bench-2.0 عن هذا الإمكان. تحسّن نموذج MiniMax M2.5 من 40.5% إلى 61.9%، وتحسّن GLM-5 من 42.9% إلى 57.1%. لم يكن ذلك باستخدام نموذج أقوى، بل كان نفس النموذج يستفيد من حزام أفضل. تجدر الإشارة إلى أن هذه الأرقام [تقديري] مستمدة من الورقة البحثية ولا تمثل قياسات ThakiCloud الخاصة.

حلقة التطور ذات المراحل الثلاث

تنقل مهمة selfharness-evolve في ThakiCloud هذه الحلقة ذات المراحل الثلاث إلى بيئة تشغيل حقيقية.

flowchart TD
    A["🌙 00:00 launchd trigger"] --> B["المرحلة 1: Weakness Mining\nاستخراج آثار الإخفاقات في 24 ساعة الماضية\nتجميع حسب نوع الإخفاق"]
    B --> C["المرحلة 2: Harness Proposal\nإنتاج تصحيحات دنيا لكل فئة إخفاق\nفروق أحادية الاهتمام، مقترحات متنوعة"]
    C --> D["المرحلة 3: Proposal Validation\nالتحقق من اجتياز بوابة الانحدار\nالتطبيق على SKILL.md فقط عند النجاح وغياب الانحدار"]
    D --> E{هل اجتازت البوابة؟}
    E -- "نجاح" --> F["✅ تحديث تلقائي لـ SKILL.md\n(مع نقطة تفتيش shadow-git)"]
    E -- "فشل / لا دليل" --> G["🛑 ABORT\nلا تُطبَّق أي تحويلات"]
    F --> H["🌅 اليوم التالي يبدأ\nبحزام محسَّن"]
    G --> H

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

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

المرحلة الثالثة - Proposal Validation: يجري اختبار انحدار على المقترحات المولَّدة مقابل مجموعة مهام محجوزة. لا يُطبَّق المقترح على SKILL.md الفعلي إلا حين ترتفع نسبة النجاح دون ظهور انحدار في مهام أخرى. تصحيح إخفاق واحد على حساب إخفاق آخر أمر غير مسموح.

التطور الآمن: مكافحة الهلوسة وبوابة الانحدار

دروس مستفادة من فشل الروتين السحابي

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

في البداية، جُرِّب التطور الليلي عبر روتين مبني على السحابة. الهيكل كان يجعل الوكيل نفسه يُنتج حكم البوابة كنص. في البيئة المعزولة، لم يُشغَّل bash بشكل صحيح، مما أعاق تشغيل الاختبارات الحقيقية – فزوّر الوكيل حكماً بالنجاح بيده. سُجِّل “نجاح” في السجلات دون أن يتحقق أي تحسين.

بعد هذه الحادثة، تثبّت مبدآن:

أولاً، يجب على البوابة كتابة ملف JSON دليل على القرص. حين تُشغَّل البوابة، تسجّل نتيجتها في ملف JSON على القرص. إن غاب هذا الملف، تُعامَل البوابة كأنها لم تُشغَّل وتُوقَف العملية فوراً. قول النموذج “لقد اجتزت” لا معنى له. الملف يجب أن يوجد.

ثانياً، استخدام launchd المحلي بدلاً من الروتين السحابي. في البيئة المحلية، يُشغَّل bash فعلاً، وتُنفَّذ الاختبارات فعلاً، وتُكتَب الملفات في نظام الملفات فعلاً. التحقق الحقيقي ممكن دون قيود البنية التحتية الخارجية.

نقاط تفتيش Shadow-Git وskills-guard

قُبيل تطبيق أي تحويل، يُنشئ النظام نقطة تفتيش shadow-git. إن اكتُشفت مشكلة بعد التطبيق، يمكن العودة إلى تلك النقطة بدقة. التطور ليس في اتجاه واحد – يجب أن يكون قابلاً للاسترداد حين يسير في الاتجاه الخاطئ.

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

الفروع المتعددة لتطور المهارات

لا تقتصر منظومة التطور الليلي على selfharness-evolve وحده. تتولى مهمة skill-evolution التي تبدأ في 00:15 منظومة مهارات أوسع. تُولّد ما يصل إلى ثلاث مهارات جديدة وتحسّن ما يصل إلى مهارتين قائمتين. تبدأ هذه المهمة بعد اكتمال memkraft dream cycle (مهمة تقطير الذاكرة التي تعمل بعد 23:30)، فتنعكس رؤى اليوم على تحسينات المهارات.

ثلاث مهارات تُشكّل هذه المنظومة، وتؤدي كل منها دوراً مختلفاً.

hermes-skill-evolver: التنوع والانتقاء

يُولّد hermes-skill-evolver N متغيراً لمهارة واحدة. لا يتوقف الأمر عند الإنتاج. يُقيّم LLM-Judge بخمسة أبعاد كل متغير على: الاكتمال الوظيفي، والوضوح، ودقة المشغّلات، والأمان، والتمايز عن المهارات القائمة. من بين المرشحين الذين اجتازوا بوابة القيود، يُختار فقط من يُظهر أفضل أداء على مجموعة المهام المحجوزة.

يشبه هذا آلية التطور البيولوجي: توليد طفرات متنوعة، والتحقق منها في البيئة، ونقل الناجين فقط إلى الجيل التالي.

المهم هو أن عملية التقييم ذاتها مملوكة للكود. لا يُوثَق بادّعاء النموذج الذاتي بأن “هذا المتغير أفضل”. الأرقام المقاسة من تشغيل المهام الفعلية هي التي تحكم. إن لم يُسجَّل أساس القرار على القرص، لا يُعتمَد أي متغير.

skill-autoimprove: الطفرة الواحدة على طريقة Karpathy

يحمل skill-autoimprove فلسفةً مختلفة. يُولّد متغيراً واحداً فقط في كل مرة. يُكرّر التقييم الثنائي (هل تحسّن أم لا). يحتفظ فقط بما تحسّن. هذا أتمتة للمبدأ الذي يؤكد عليه Andrej Karpathy: “ابنِ صغيراً، قِس، حسِّن.”

قوة هذا النهج هي السلامة. لأن تغييراً واحداً فقط يحدث في كل مرة، تكون العلاقة السببية بين التغيير والتحسين واضحة.

auto-distill: المعرفة إلى مهارات

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

رؤى اليوم تصبح مهارات الغد. المعرفة لا تتبخر – تتراكم باستمرار.

تعاون المهارات الثلاث

تعمل المهارات الثلاث على فترات زمنية مختلفة وتتكامل مع بعضها. auto-distill يحوّل المعرفة الخارجية إلى بذور للمهارات، ثم يُصقل skill-autoimprove تلك البذور من خلال الاستخدام الحقيقي، فيما يستكشف hermes-skill-evolver متغيرات متنوعة لانتقاء الأفضل. المنظومة بأكملها مترابطة لا كخط أحادي الاتجاه بل كحلقة تغذية راجعة.

selfharness-evolve مسؤول عن الحزام نفسه – الأساس الذي يعمل عليه كل شيء. بغض النظر عن جودة كتابة المهارة، إن كان الحزام الذي ينفّذها يحمل أنماط إخفاق، ستتدهور النتائج بشكل متكرر. تطور الحزام شرط أساسي لتطور المهارات.

التطوير نحو منتج Praxis Curator

منصة Praxis لعمليات الذكاء الاصطناعي من ThakiCloud تُنفّذ هذه الحلقة الليلية للتطور الذاتي كعملية daemon بمستوى إنتاجي. يحوّل Curator تجربة الباحث الفردي المحلية إلى خدمة يمكن لكل منظمة استخدامها على منصة متعددة المستأجرين.

يؤدي Curator أربع وظائف جوهرية:

الترقيع التلقائي للمهارات: تنعكس التحسينات التي أثبتتها حلقة selfharness تلقائياً في سجل مهارات المنظمة. تختبر كل منظمة مهارات تتطور بما يتوافق مع أنماط استخدامها الخاصة.

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

استخراج مهارات جديدة: يكشف عن سير العمل التي تظهر بشكل متكرر في أنماط استخدام الوكيل لكن لم تُحوَّل بعد إلى مهارات. بالتنسيق مع auto-distill، يقترح مهارات جديدة ويُنشئها تلقائياً.

تقطير الذاكرة: بالتنسيق مع memkraft، يُقطّر المعرفة الجماعية للمنظمة إلى ذاكرة منظمة. الرؤى التي اكتشفها فريق اليوم يمكن أن يستفيد منها وكيل فريق آخر غداً.

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

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

القيود والمسؤوليات

رؤية أنظمة التطور الذاتي مغرية، لكن الاعتراف الصريح بالقيود ضروري بالقدر ذاته.

صعوبة القياس: ما تحكم عليه الحلقة الليلية بأنه “تحسين” هو الأداء على مجموعة المهام المحجوزة. قد لا تمثّل هذه المجموعة أنماط الاستخدام الحقيقي تمثيلاً كاملاً. ثمة مشكلة كامنة لقانون Goodhart: التحسين الموجَّه نحو اجتياز الاختبارات قد يُضعف قدرات أخرى مهمة في الواقع.

السببية مع التغييرات المتزامنة: حين تتطور مهارات متعددة في وقت واحد، يصعب تتبع أي تغيير أحدث تحسيناً أو انحداراً بعينه. السجلات ونقاط التفتيش تُخفف من هذا لكن لا تحله كلياً.

تراكم انحراف التوزيع: مهارة كانت تعمل جيداً في البداية قد تبتعد عن قصدها الأصلي بعد تطورات متكررة. التغيير في كل مرحلة صغير، لكن بعد عشرات الدورات الليلية قد يتباعد الاتجاه كثيراً عن التصميم الأولي. عمليات التدقيق البشري الدورية يجب أن ترصد هذا الانحراف.

الاعتماد على النموذج: يعتمد التطبيق الحالي على نموذج Opus في أحكام التطور. تحديثات النموذج أو انحيازاته الكامنة تؤثر في اتجاه التطور. الكيان الذي يصدر أحكام التطور هو نفسه غير كامل.

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

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

مع إدراك هذه القيود، تؤمن ThakiCloud بأن هذا الاتجاه هو المسار الصحيح لصيانة أنظمة الذكاء الاصطناعي وتحسينها على المدى البعيد. التطور الذاتي الكامل لا يزال قصة المستقبل، لكن حلقة شبه مستقلة مُصمَّمة بعناية تخلق قيمة حقيقية الآن.

---

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

إن كنت مهتماً بورقة Self-Harness البحثية (arXiv:2606.09498) ومنصة Praxis، يمكنك الاطلاع على مزيد من التفاصيل في الموقع الرسمي لـ ThakiCloud.