Ouroboros مقابل Claude Code: وكيل برمجي كتب نفسه بنفسه وحقق SOTA على Terminal-Bench 2.1

نشر باحث من AIRI في 3 أغسطس 2026 على موقع Habr تحليلاً مفصلاً للوكيل ذاتي التطور Ouroboros، وهو نظام مكتوب بلغة Python الخالصة أعاد كتابة شيفرته بنفسه على مدى أشهر. وحقق النظام نتائج SOTA على Terminal-Bench 2.1 وCL-Bench وOSWorld، وتساوى مع Claude Code وCodex على معياري GAIA وSWE-Pro.

كيف يكتب Ouroboros نفسه بنفسه؟

Ouroboros حلقة وكيلية (agentic loop) مكتوبة بلغة Python، تملك وصولاً مباشراً إلى git وصلاحية إعادة كتابة بيئة تشغيلها (runtime) أثناء العمل. وتجري الحلقة المغلقة على النحو التالي: يتلقى الوكيل مهمة وينفذها، ثم يحلل النتيجة ويُدخل تعديلات على شيفرته المصدرية، ثم يُعيد تشغيل نفسه بأمان على النسخة المحدّثة. وإذا تسببت النسخة الجديدة في عطل ما، يعود النظام تلقائياً إلى النسخة السابقة.

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

• اللغة: Python الخالصة دون أطر عمل وكيلية خارجية
• البيئة: Google Colab معزولة عن جهاز المطوّر المحلي
• الأدوات: git، وصلاحية إعادة كتابة بيئة التشغيل، وآلية رجوع آمن
• المهام الأولى: رسم القطط، والتعطل على YouTube، وتغيير خلفية سطح المكتب
• الميزانية: إنفاق مستقل للتوكنات دون رقابة مستمرة من المطوّر

ماذا تُظهر المعايير

حقق Ouroboros على ثلاثة معايير، هي Terminal-Bench 2.1 وCL-Bench وOSWorld، نتائج بمستوى SOTA. وتقيّس هذه المعايير الثلاثة جوانب مختلفة من قدرات الوكلاء: يقيس Terminal-Bench العمل في سطر الأوامر، ويقيس OSWorld التحكم بسطح المكتب وواجهات GUI، ويقيس CL-Bench المهام البرمجية المعقدة. أما على GAIA وSWE-Pro فسُجّل تكافؤ مع Claude Code من Anthropic وCodex من OpenAI.

«ما كنت لأبتكر هذا الهيكل (harness) بنفسي، أما التطور المستقل وكومة

الأموال المحروقة على التوكنات فنعم»، يقول مؤلف المشروع، الباحث في AIRI.

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

بماذا يختلف هذا النهج عن الوكلاء المعتادين

تتحسن معظم الأنظمة الوكيلية عبر هندسة المطالبات (prompt engineering) أو الضبط الدقيق (fine-tuning) على بيانات جديدة، بينما تبقى شيفرتها المصدرية دون تغيير. أما Ouroboros فيعمل بطريقة مختلفة: يعدّل الوكيل شيفرته المصدرية بنفسه ضمن حلقة إنتاجية (production)، وتطور البنية هو ما أوصل إلى نتائج SOTA، لا تجريب المطالبات.

وهذا يجعل Ouroboros من الأمثلة القليلة الموثقة علناً على تعديل ذاتي حقيقي للوكلاء مع نتائج رقمية قابلة للتحقق. فمعظم التجارب المشابهة إما تظل مغلقة، وإما لا ترافقها بيانات معايير مفتوحة. ووفق ما كتبه المؤلف في منشوره على Habr، يتضمن التحليل آثار التنفيذ (traces) وأرقاماً لإعادة الإنتاج و«عدداً من القصص المحرجة من التدقيق»، أي حالات اتخذ فيها الوكيل قرارات غير متوقعة خلال تطوره.

ويفيد المؤلف بأنه يُنجز الآن «كل شيء تقريباً من خلاله»، فقد تحول Ouroboros من مشروع بحثي إلى أداة العمل الرئيسية.

ماذا يعني ذلك

يقدّم Ouroboros دليلاً عملياً على أن التطور الذاتي للوكلاء قادر على تحقيق نتائج تنافسية دون ميزانيات حوسبة بملايين الدولارات. فقد حقق باحث واحد ببيئة Colab نتائج SOTA في ميدان تتنافس فيه مختبرات تملك فرقاً وبنية خوادم. والسؤال التالي هو كيفية إدارة هذا التطور عند التوسع، ومنع السلوك غير المرغوب من وكيل يكتب نفسه بنفسه.