الانتقال إلى المحتوى الرئيسي
هذه الصفحة تقرير، وليست دليل استخدام. تصف تصميم حلقة التعافي الذاتي في الـ SDK المسمّى lousho، والأدلة المجموعة حتى 2026-11-09. ولمعرفة طريقة الاستخدام، اقرأ التعافي الذاتي والتحسين الذاتي وتحسين الـ agent. والملف docs/improve.md في مستودع الـ SDK هو المرجع الكامل للحلقة.

​
الملخّص

يعتمد سلوك الـ agent على نموذجه وعلى الـ harness الخاص به، أي التعليمات والمهارات التي تخبر النموذج كيف يعمل. ويستطيع Lousho تغيير هذا الـ harness انطلاقًا من الـ runs الفاشلة للـ agent نفسه. يتكوّن النظام من طبقتين. الأولى تستعيد الـ run بينما يخدم الـ agent الـ traffic، ولا تغيّر الـ agent أبدًا. والثانية، وهي حلقة التعافي الذاتي، تجعل نماذج تحرير تقترح تعديلات على التعليمات والمهارات. وتختبر بوابةٌ كلَّ تعديل على runs جديدة لحالات تدريب وحالات محجوزة (held-out)، وتفحص كلفته. ثم يختبره canary بإعادة التشغيل مرة أخرى. بعد ذلك تطبّق الحلقة التعديل (الوضع التلقائي، وهو الافتراضي) أو تضعه في قائمة انتظار ليقرّر فيه شخص (الوضع اليدوي). وبعد الكتابة، يتراجع حارس المجموعة (corpus guard) ومراقب تتابعي عن التعديل إذا أضرّ. ويُسجَّل كل تغيير في سجل تدقيق مسلسل بالـ hash. وتحدّ الميزانيات وعقد الإيجار (lease) ومفتاح الإيقاف من عمل الحلقة. نعرض أربع مجموعات من النتائج على benchmark برمجي اصطناعي. أفادت تسمية الفحص الفاشل للمحرّرين في مهمة، ولم تتفوّق على عدم التسمية في مهمة أخرى. وأبقى تشغيلٌ كامل من سطر الأوامر الـ harness الأساسي حين لم يُفِد أي تعديل. واجتاز تشغيلٌ حيّ لسيناريوهات الحلقة الأحد عشر كلَّ محاولة اختبرت شيئًا فعلًا. لكنه شغّل محاولة واحدة لكل سيناريو، بينما تتطلب معايير القرار من 5 إلى 10، لذا فحكمه غير مكتمل. ووجدت تجربة جانبية أن تخطيطًا متعدد الـ agents مكلف جدًا ليكون الافتراضي. يبقى الوضع التلقائي هو الافتراضي، وتبقى الحلقة تجريبية.

​
1. المقدمة

​
1.1 الدافع

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

​
1.2 المساهمات

  • طبقتان بحدّ واضح. استعادة الـ run تُنهي الـ runs أو توقفها ولا تعدّل الـ agent أبدًا. وحلقة التعافي الذاتي لا تعدّل إلا instructions.md وskills/<name>/SKILL.md.
  • بوابة تراعي الضوضاء. يُحكَم على كل تعديل لكل حالة تدريب على حدة، على runs جديدة، مع حالات محجوزة لا يراها المحرّرون أبدًا، ومع فحص للكلفة لا يقارن إلا الـ runs الناجحة في الجانبين.
  • فحوص قبل الكتابة وبعدها. يستخدم canary إعادة التشغيل runs لم يستخدمها أي قرار للبوابة. ويتراجع حارس المجموعة والمراقب التتابعي عن التعديل الضار.
  • وضعا موافقة. الوضع التلقائي يكتب بعد الـ canary، والوضع اليدوي يضع التعديل في قائمة انتظار لشخص. وكلاهما يشغّل الفحوص نفسها.
  • خيارات Harness². محرّرون متوازيون، وk من المقترِحين، وجولات متتابعة، ومحدِّد أعمى، وذاكرة مؤقتة للمحرّرين مع سجلّ حسابات (ledger)، ورفض التعديلات التي تقتبس فحصًا فاشلًا.
  • benchmark للضرر المزروع. أحد عشر سيناريو يجب فيها على الحلقة أن تصلح شيئًا أو ترفضه أو تتراجع عنه، مع معايير قرار (go/no-go).

​
2. صياغة المسألة

المقصود بالـ harness هنا ملف instructions.md في مجلد الـ agent وملفات skills/<name>/SKILL.md. أما الأدوات والصلاحيات والحدود والنماذج وagent.ts والسكربتات فهي خارج النطاق. ومجلد المهارة الذي يحوي أي ملف آخر يكون للقراءة فقط. ولا يجوز أن يترك التعديل أكثر من 8,000 حرف من التعليمات الدائمة. الحالة مُدخَل مسجَّل وفحص. والفحص دالة متزامنة تُرجع نجاحًا أو فشلًا أو “لا يمكن التقييم”. وعند الفشل قد تسمّي الفحص الذي أخفقت فيه الإجابة. وتأتي الحالات من الـ runs الفاشلة للـ agent نفسه في قاعدة بيانات المراقبة المحلية، ومن runs نسخة الـ harness الحيّة الآن فقط. لـ نموذج التهديد ثلاثة أجزاء:
  • الضوضاء. الـ runs عشوائية، وقد تُجيز بوابةٌ صغيرة تعديلًا عديم الفائدة بالصدفة.
  • الضرر الجانبي. التعديل الذي يصلح حالة قد يكسر أخرى.
  • الحقن. تحوي سجلات الـ runs نصًا قد يكون كتبه أي أحد، مثل مخرجات الأدوات أو محتوى الملفات. وقد يحاول هذا النص توجيه المحرّرين.

​
3. المنهج

​
3.1 الطبقة الأولى: استعادة الـ run

تستأنف agent.recover() الـ runs المنقطعة من آخر checkpoint. والـ run الفاشل ينتظر مهلة تراجع تتضاعف مع كل فشل، حتى 15 دقيقة. وبعد 10 حالات فشل متتالية يُعزَل ليقرّر فيه شخص. ومع retryWithDiagnosis يحصل الـ run الذي بلغ الحدّ على محاولة أخرى: نسخة متفرّعة باسم <id>.heal، تُستأنف من الخطوة نفسها، مع ملاحظة تقتبس الخطأ بوصفه بيانات. وبعد ثلاث حالات فشل متتالية من المزوّد، تتوقف الحلقة مؤقتًا وتجرّب run واحدًا في كل مرة. وتوقف createProgressGuard() الـ run الذي يكرر استدعاء الأداة الفاشل نفسه. ولا تغيّر هذه الطبقة الـ agent أبدًا.

​
3.2 الطبقة الثانية: خطوة تحسين واحدة

تشغّل improveAgent() خطوة واحدة وتُرجع اقتراحًا أو تُبقي الأساس. ولا تكتب شيئًا.
  1. تشغّل حالات التدريب على الـ harness الحالي. فإن نجحت كلها توقفت.
  2. يقترح محرّران تعديلات انطلاقًا من الـ runs الفاشلة. يصلح المحرّر الثابت (invariant) طريقة عمل الـ agent، عند أول نقطة انحرف فيها الـ run. ويصلح محرّر المجال (domain) ما يعرفه الـ agent. ويُجرَّب كل اقتراح على الحالات نفسها.
  3. يدمج المركِّب (composer) ما تدعمه التجارب، أو لا يغيّر شيئًا.
  4. تعيد البوابة تشغيل الـ harness الحالي على runs جديدة، فلا تقارن أبدًا بالـ runs سيئة الحظ التي استدعت التحرير. ويجب أن تنجح حالة تدريب واحدة على الأقل في عدد أكبر بـ 2 على الأقل من 3 runs، وألّا تسوء أي حالة تدريب. والحالة المحجوزة التي تتراجع تُعاد 3 مرات أخرى في الجانبين. ويُرفَض التعديل إذا كان التراجع المجمَّع 2 من 6 runs على الأقل (مع 3 تكرارات). ويجوز أن ترتفع الـ tokens لكل run ناجح بنسبة تصل إلى 50%، وتُقارَن فقط على الحالات الناجحة تحت كلا الـ harnesses.
  5. إذا فشل الـ harness المركَّب، يُجرَّب الـ harness الخاص بكل محرّر حسّن حالة، عبر الفحوص نفسها، بدءًا بالأرخص.
نسخ الاستعادة أدلةً مزدوجة. نسخة .heal التي نجحت تعطي زوجًا على المُدخَل نفسه: الـ run الفاشل، وإعادة محاولة نجحت بعد تشخيص. وتُرجع casesFromRecoveries() هذه الأزواج. ويقرأ المحرّرون إعادة المحاولة بوصفها دليلًا غير موثوق. ولا تكون الاستعادة أبدًا run للبوابة، ولا تجعل حالةً محمية، ولا يجوز أن تأتي من حالة محجوزة.

​
3.3 توسيع الخطوة: خيارات Harness²

تتبع الخطوة تصميم Harness² التبايني القائم على الاقتراح ثم التجربة ثم التركيب، وتوفّر خيارات توسيعه. وكلها معطّلة أو عند k = 1 افتراضيًا.

​
3.4 التعلّم عبر الدورات

بعد حسم الدورة (إبقاءً أو رفضًا أو تراجعًا)، تقرأ جلسة تأمّل (reflection) بطاقة المراجعة والفرق (diff) وأحكام الحالات والنتيجة، ولا تقرأ أي سجل خام أبدًا. وتكتب درسًا واحدًا على الأكثر في مكتبة خاصة بكل agent. ويُرفَض الدرس إذا أثار أساليب كشف الحقن، أو احتوى رابطًا أو HTML، أو كان طويلًا جدًا، أو اقتبس فحصًا فاشلًا. ويقرأ المحرّرون حتى 20 درسًا بوصفها بيانات غير موثوقة، ويذكرون الدروس التي استخدموها. وعندما يُبقى على التعديل، تحصل الدروس المذكورة على صوت “أفاد”. وعندما يُتراجَع عنه، تحصل على صوت “أضرّ”. ويُستبعَد الدرس نهائيًا حين تزيد أصوات “أضرّ” على أصوات “أفاد” باثنين.

​
4. تصميم النظام

​
4.1 الدورة

تعمل دورة واحدة لكل مجلد agent في كل مرة. ويشغّل lousho improve <dir> دورة واحدة، ويشغّلها --watch على مؤقّت. ويمكن أيضًا أن يبدأ دورةً تراجعٌ في الدرجة يرصده خادم المراقبة. يشغّل canary إعادة التشغيل كل حالة تدريب وكل حالة من المجموعة 6 مرات تحت الاقتراح، بأرقام تكرار لم تستخدمها البوابة أبدًا. ويجب أن تنجح كل حالة تدريب في 5 من 6 على الأقل. والكاتب هو الشيفرة الوحيدة التي تكتب ملفات الـ harness. يرفض الكتابة إذا تغيّر المجلد منذ أن قرأته الدورة، ويفحص التعديل بحثًا عن الحقن مرة أخرى، ويحفظ النسختين قبل التعديل وبعده، ويضيف قيد تدقيق من نوع apply.

​
4.2 الوضعان التلقائي واليدوي

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

​
4.3 الفحوص بعد الكتابة

  • حارس المجموعة. تُشغَّل كل حالة محمية أو مُصلَحة 3 مرات تحت النسخة الجديدة، مع إعادة عند الانخفاض. وعند التراجع في الأداء، أو إذا عجز الحارس عن الحكم، يُتراجَع عن التعديل. ويكرّر الـ watcher الحارس كل 24 ساعة.
  • المراقب. يقارن الـ runs الحقيقية تحت النسخة المطبَّقة بالـ runs تحت النسخة التي سبقتها. وينتظر 20 run في كل جانب، وينظر ثلاث مرات على الأكثر، بعد 20 و40 و60 run. والتراجع في الأداء هو انخفاض في نسبة النجاح يزيد على 0.05 ويكون دالًّا عند قيمة z تساوي 2.1 لكل نظرة، ما يُبقي معدل التراجع الخاطئ الكلي دون 5% من جانب واحد. وبعد 7 أيام دون runs كافية، يوسَم التعديل بـ kept-unverified.
  • التراجع. يستعيد نسخة محفوظة عبر الكاتب نفسه وينشئ نسخة جديدة، ولا يُعاد كتابة التاريخ أبدًا. وكل تراجع يبدأ فترة تهدئة مدتها 24 ساعة.

​
4.4 التشغيل

يُفحَص مفتاح الإيقاف قبل كل دورة، ثم قبل المحرّرين والـ canary والكتابة. وكل خطوة تغيّر شيئًا تضيف سطرًا إلى .lousho/audit.jsonl. ويحمل كل سطر قيمة SHA-256 للسطر الذي قبله، لذا يكشف lousho improve audit <dir> --verify أي سطر عُدِّل أو حُذِف.

​
4.5 الأمان والدفاع ضد الحقن

  • يبدأ كل سجل run يقرؤه المحرّرون بلافتة تقول إنه بيانات وليس تعليمات.
  • تقع نتائج الأدوات بين علامات “غير موثوق”، وتُزال العلامات المزوّرة داخل الـ run، المتداخلة منها والمفصولة بمسافات.
  • يُفحَص النص الذي يضيفه التعديل بحثًا عن حقن الموجّه عند كتابة المحرّر له، ثم مرة أخرى وقت الكتابة.
  • لا تصل الحالات المحجوزة إلى المحرّرين أبدًا. ولا تراها جلسة التأمّل إلا بأسماء مثل “الحالة المحجوزة 1” و”الحالة المحجوزة 2”، ولا يجوز أن تأتي استعادة من حالة محجوزة.
  • لدى المحرّرين أدوات ملفات على مساحة عمل في الذاكرة، دون shell ودون شبكة.
  • نص النموذج الذي يصل إلى بطاقة أو إشعار أو سجل التدقيق نص عادي: بلا روابط أو صور أو HTML.
هذه الفحوص تقديرية (heuristics) ويمكن خداعها، ولهذا توجد الفحوص التي تأتي بعد الكتابة.

​
5. إعداد التجارب

الـ benchmark. تستخدم كل التجارب examples/heal-benchmark في مستودع الـ SDK. يصلح الـ coding-agent فيه أخطاءً في مشروع JavaScript صغير، ويُقيَّم باختبارات مخفية. ويفشل الـ run إذا عدّل اختبارًا أو ملفًا لا تحتاجه المهمة. وكل المهام اصطناعية. النماذج. عمل الـ agent على qwen/qwen3.7-flash في التشغيل الحيّ للحلقة، وفي التشغيل الكامل من سطر الأوامر، وفي المرحلة الثانية من دراسة أسماء الفشل. وعمل المحرّرون على نموذج منفصل هو stealth/crouton-alpha. واستُخدم هذا النموذج أيضًا في المرحلة الأولى وفي التجربة الجانبية W0، ولم يعمل إلا على حالات اصطناعية. ويتحقّق سكربت الحلقة قبل كل محاولة وقبل كل استدعاء للمحرّر من أن كل run في قاعدة بياناته ينتمي إلى الـ benchmark، ويتوقف إن لم يكن كذلك. المقاييس. يكون الاقتراح مؤكَّدًا حين ينجح في 5 من 6 runs جديدة على الأقل. وpass^3 هو احتمال أن تنجح الحالة في ثلاثة runs متتالية، بمتوسط على الحالات. ونعرض كذلك عدد الطلبات والـ tokens.

​
6. النتائج

​
6.1 تسمية الفحص الفاشل

يستطيع الفحص أن يُرجع اسم المتطلب الذي أخفقت فيه الإجابة الفاشلة. قارنّا ثلاث حالات، 5 محاولات لكل منها: الاسم الحقيقي، وبلا اسم، وأسماء مخلوطة مأخوذة من فحوص أخرى. واشترطت الخطة أن تتفوّق الأسماء الحقيقية على المخلوطة بثلاثة اقتراحات على الأقل من خمسة. في المهمة الأسهل بلغت الأسماء الحقيقية وغياب الاسم كلاهما الحدّ الأعلى، ولم يضرّ إلا الاسم الخاطئ. وفي المهمة الأصعب أفاد الاسم الحقيقي، وأوقف الاسم الخاطئ كل الاقتراحات. والإرشاد المستفاد مذكور في توثيق الـ SDK: لا تسمِّ فحصًا إلا إذا كنت تعرفه.

​
6.2 تشغيل كامل من سطر الأوامر

عمل lousho improve من البداية إلى النهاية على agent يعمل بنموذج Qwen، مع حالات ملتقطة. ورأى المحرّرون الفحوص الحقيقية. وفشلت ثلاث حالات تدريب في 0 من 3 تحت الـ harness الأساسي والمركَّب كليهما، فأبقت البوابة الأساس. وهذه هي النتيجة المتوقعة حين لا يفيد أي تعديل.

​
6.3 الإثبات الحيّ للحلقة (S29)

في 2026-11-09 شغّلنا loop.ts --live على السيناريوهات الأحد عشر كلها. شُغِّل كل سيناريو مرة واحدة، وشُغِّل planted-editor ثلاث مرات. واستخدمت خمسة سيناريوهات تختبر آليات الحلقة نفسها agent مُبرمَجًا مسبقًا (scripted). وأجرى التشغيل 3,675 طلبًا و766 run ونحو 6.3 مليون token. ولم يُستبعَد أي run ولم يقع أي خطأ. تحقّقت سلسلة التدقيق في مجلدات المحاولات الثلاثة عشر كلها. ونجحت كل محاولة اختبرت شيئًا فعلًا. لكن المعايير تتطلب 10 محاولات (و5 لـ true-fix وhealthy وcanary-traffic)، لذا فكل معيار عدا معيار التدقيق يُقرأ “محاولات أقل من اللازم”. وحكم التقرير INCOMPLETE (غير مكتمل).

​
6.4 القراءة النهائية (S30)

كانت قاعدة الخطة: يُحوَّل الافتراضي إلى اليدوي إذا لم يتحقق أحد معياري الضرر المزروع (B: planted-editor، وC: planted-forced). ولم يُخفِق أيٌّ منهما، إذ نجحت كل محاولة محتسَبة. لكن أيًّا منهما لم يتحقق كذلك، لقلة المحاولات. وكان القرار إبقاء الوضع التلقائي افتراضيًا، وإبقاء وسم “تجريبي” حتى تُشغَّل المعايير بالعدد الكامل.

​
7. التحليل

​
7.1 ما تعزله دراسة أسماء الفشل

لا تختلف الحالات الثلاث إلا في نص اسم الفشل، لذا فالدراسة استبعاد (ablation) لمُدخَل واحد من مُدخلات المحرّرين. وهي تُظهر أن الإشارة مهمة في المهمة الصعبة، وأن الإشارة الخاطئة أسوأ من غيابها. لكنها لا تُظهر أن البوابة لا تقبل إلا التعديلات الجيدة، فقد رأت البوابة الأدلة نفسها في كل الحالات.

​
7.2 الآليات مقابل السلوك

استخدمت خمسة من السيناريوهات الحيّة الأحد عشر agent مُبرمَجًا مسبقًا. وتختبر هذه الصفوف آليات الحلقة، مثل مفتاح الإيقاف وقائمة الانتظار والميزانية والمراقب، ولا تختبر سلوك النموذج. أما صفوف النموذج الحيّ (true-fix وplanted-editor وplanted-forced وinjection وhealthy وcanary-traffic) فهي التي تقول شيئًا عن التعديلات الحقيقية، ولكل منها محاولة أو محاولتان محتسَبتان.

​
7.3 تجربة جانبية: تخطيط الـ agents (W0)

سألت تجربة W0 ما إذا كان التخطيط متعدد الـ agents ينبغي أن يكون الافتراضي للمنتجات. شغّلت 22 حالة برمجية اصطناعية، 3 runs لكل منها، باستخدام stealth/crouton-alpha، في ثلاثة أذرع: agent مسطّح واحد، وagent من نوع flat-plus يُستخدم لفصل التوجيه عن المحتوى، والمنتج متعدد الـ agents. كلّف المنتج 4.24 ضعف tokens الـ agent المسطّح، وهذا فوق حدّ 1.3 ضعف، فكان الحكم مقابل المسطّح NO-GO: لن يكون التخطيط متعدد الـ agents هو الافتراضي. وكان الحكم مقابل flat-plus هو GO، بكلفة 1.24 ضعف الـ tokens. ولم يفشل الـ agent المسطّح إلا في حالة واحدة هي add-months، أي أن النموذج كان قريبًا من الحدّ الأعلى.

​
8. القيود

  • محاولات أقل من اللازم. شغّل الإثبات الحيّ محاولة واحدة لكل سيناريو (وثلاثًا لـ planted-editor)، وحكمه غير مكتمل. فهو يُظهر أن الحلقة قادرة على العمل من البداية إلى النهاية، لا أنها تعمل بموثوقية.
  • مهام اصطناعية فقط. تأتي كل النتائج من benchmark برمجي اصطناعي صغير، وقد تتصرف الـ agents الحقيقية والـ traffic الحقيقي بشكل مختلف.
  • نماذج قليلة. نموذج واحد للـ agent ونموذج واحد للتحرير، ولم يعمل نموذج التحرير إلا على حالات اصطناعية. وقد لا تنتقل النتائج إلى نماذج أخرى.
  • صفوف مُبرمَجة. استخدمت خمسة سيناريوهات حيّة agent مُبرمَجًا مسبقًا، فهي تختبر الآليات فقط.
  • قد تُجيز بوابة صغيرة تعديلًا عديم الفائدة. مع حالة إلى ثلاث حالات تدريب و3 تكرارات، يقع على الـ canary والحارس والمراقب أن يكشفوه. والضرر على traffic لا تغطيه المجموعة لا يظهر إلا بعد 20 run.
  • الـ agents قليلة الـ traffic. قد لا تحصل أبدًا على حكم من المراقب، فتبقى تعديلاتها kept-unverified.
  • انجراف النموذج. قد يبدو تغيير النموذج تراجعًا في الأداء، فيُتراجَع عن تعديل جيد.
  • دفاعات تقديرية. يمكن خداع فحوص الحقن.
  • لم يتحقق معيار المرحلة الأولى. في add-months لم تتفوّق أسماء الفشل الحقيقية على المخلوطة بالهامش المخطَّط.

​
9. الأعمال ذات الصلة

Harness². يحسّن Harness² (arXiv 2610.14224) الـ harness لكل مهمة بخطوة تباينية من الاقتراح ثم التجربة ثم التركيب، ويوسّعها بالتكرار المتوازي أو المتتابع. ويخزّن الـ harnesses المعتمَدة والدروس في مكتبة لكل مجال. ويستعير Lousho منه المحرّرين الثابت والمجال، والمركِّب، وk من المقترِحين، والجولات المتتابعة، والمحدِّد الأعمى، والمكتبة. وليس في Harness² canary ولا حارس مجموعة ولا درجة مستمرة ولا تراجع. Self-Healing Harness. تعامل ورقة Self-Healing Harness (arXiv 2609.24130) التعديلَ الذاتي بوصفه ضبطًا للقبول. وتشغّل حلقة من الرصد والانتباه والإصلاح والتحقق، مع بوابة وتجارب أمامية وحارس على مستوى المجموعة. ويتبع الـ canary وحارس المجموعة والدرجة المستمرة والتراجع في Lousho هذا الخط من العمل. ما يضيفه Lousho. وضع الموافقة، وكاتب واحد يرفض الكتابة القديمة، ومجدول بعقد إيجار، وميزانيات عبر الـ runs، ومفتاح إيقاف، وسجل تدقيق مسلسل بالـ hash، وcanary اختياري على حركة المرور الحيّة.

​
10. الخاتمة

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

​
ملحق: إعادة إنتاج التشغيلات

السكربتات موجودة في مستودع الـ SDK. وتحتاج التشغيلات الحيّة إلى مفتاح OpenRouter وإلى Node 25 أو بيئة معزولة (sandbox).
يطبع التقرير كل معيار مع أعداده وحكمًا واحدًا: GO، أو GO with misses، أو NO-GO، أو INCOMPLETE. وراجع README الخاص بالـ benchmark لمعرفة كل الخيارات.