Autogenesis: بروتوكول التطور الذاتي للعملاء الذين يُصلحون أنفسهم (arXiv:2604.15034)
⏱️ وقت القراءة المقدر: 7 دقائق
القيد المزمن للعملاء الحاليين
معظم العملاء المبنية على نماذج اللغة الكبيرة اليوم ثابتة في طبيعتها. يكتب البشر تعريفات المحثات والأدوات، وحتى حين تتكرر الأخطاء لا يتغير العامل من تلقاء نفسه. يتطلب الأمر أن يراجع شخص ما السجلات، ويعدّل المحثة، ثم يعيد النشر حتى تظهر النسخة التالية. هذه الدورة بطيئة، وهذا معروف للجميع. السؤال هو كيفية أتمتتها.
تعالج ورقة arXiv:2604.15034 بعنوان “Autogenesis: A Self-Evolving Agent Protocol” هذه المسألة مباشرة. الادعاء الجوهري بسيط: إذا عومِلت كل مكونات العامل، أي المحثات والأدوات والذاكرة والعامل ذاته، بوصفها “موارد بروتوكول” قابلة لإدارة الإصدارات، أصبح العامل قادراً على إغلاق حلقة التحسين من تلقاء نفسه.
طبقتان: الموارد والتطور الذاتي
يتألف AGP (Autogenesis Protocol) من طبقتين متمايزتين.
طبقة بروتوكول ركيزة الموارد
تُنمذج الطبقة الأولى كل مكون من مكونات العامل بوصفه “مورداً مسجلاً في البروتوكول” يحمل حالة صريحة ودورة حياة وواجهة إصدارات. حتى المحثة المفردة تصبح عنصراً يحمل رقم إصدار؛ يمكن تتبع أي نسخة من المحثة استُخدمت في أي تشغيل، ويمكن الرجوع إليها عند الحاجة.
التجريد مفيد عملياً لأن مكونات العامل تصبح قابلة للتبادل أثناء التشغيل. إذا توصل العامل إلى أن المحثة v2 أفضل من v1، استطاع استبدالها ذاتياً دون إعادة نشر.
طبقة بروتوكول التطور الذاتي
الطبقة الثانية هي التي تحقق التطور الذاتي الفعلي. تعمل هذه الطبقة بحلقة مغلقة من ثلاث مراحل:
- الاقتراح (Propose): توليد مرشحين للتحسين استناداً إلى بيانات الأداء الراهنة.
- التقييم (Assess): التحقق من أن التغيير المقترح يُحدث تحسناً فعلياً.
- الإيداع (Commit): تطبيق التغييرات التي اجتازت التحقق فحسب على بيئة الإنتاج.
الجدير بالملاحظة أن مرحلة الإيداع تضم بوابة تحقق صريحة. التغييرات التي لا تجتاز التحقق لا تُطبَّق. ليس تعديلاً ذاتياً مفتوحاً بلا حدود، بل تحسين ذاتي خاضع للسيطرة.
النتائج التجريبية
تُفيد الورقة بأن نظام Autogenesis المبني على AGP أبدى تحسيناً متسقاً في الأداء على المعيارات التي تستلزم تخطيطاً معقداً واستخدام أدوات. الأرقام التفصيلية لم تُنشر في الملخص وتستوجب مراجعة متن الورقة. ما تؤكد عليه الورقة ليس الأداء في تشغيل بعينه، بل المسار التراكمي الذي يرتفع فيه الأداء مع مرور الوقت.
ما الذي يميزه؟
معظم أبحاث التحسين الذاتي للعملاء تتمحور حول ضبط النموذج الدقيق: تحديث الأوزان ببيانات أعلى جودة. AGP يسلك مساراً مختلفاً: لا يلمس أوزان النموذج، بل يُحسِّن موارد البروتوكول المحيطة بالعامل، أي المحثات وتعريفات الأدوات وبنية الذاكرة. ميزة هذا النهج أنه أسرع؛ تُطبَّق التغييرات أثناء التشغيل دون دورات ضبط دقيق.
غير أنه ينطوي على قيد. التحسينات على مستوى موارد البروتوكول لا تستطيع تجاوز القدرات الأساسية للنموذج. لا يمكن لتحسين المحثة أن يحل مهمة يعجز النموذج عن معالجتها أصلاً.
منظور منصة ThakiCloud
المكان الذي تنطبق فيه أفكار AGP تطبيقاً مباشراً على المنصة التي تشغّلها ThakiCloud المبنية على Kubernetes هو نظام مهارات العملاء.
المهارات الموجودة حالياً تحت .claude/skills/ يكتبها البشر ويحدّثونها يدوياً. بتطبيق نموذج ركيزة الموارد في AGP، يصبح بالإمكان إدارة كل مهارة بوصفها عنصراً ذا إصدارات، وبناء خط أنابيب يولّد تلقائياً مرشحين لمراجعة المهارات استناداً إلى نتائج التشغيل. سير عمل selfharness-evolve يتحرك أصلاً في هذا الاتجاه خلال السعي الليلي لتطوير المهارات، وتوفر AGP الأساس النظري لذلك.
ثمة اعتبار خاص في بيئة متعددة المستأجرين: إذا كانت الموارد التي يُعدّلها العامل المتطور ذاتياً موارد مشتركة، فقد تؤثر التحسينات المستقاة من تشغيلات مستأجر واحد على مستأجرين آخرين. كيفية ربط بوابة الإيداع بعزل المستأجرين تستدعي قراراً تصميمياً صريحاً.
خلاصة
AGP يعامل منظومة العامل “كما يُعامَل الكود”. الكود يحمل إصدارات، ويخضع للاختبار، وله خط أنابيب نشر. تطبيق المبادئ ذاتها على محثات العامل وأدواته يتيح ارتفاع جودة العامل تدريجياً دون تدخل بشري.
تبقى تساؤلات مطروحة: ما الشروط التي تجعل حلقة التطور الذاتي تتقارب؟ وكيف تُمنع الانزياف أو التطور في اتجاه غير سليم؟ وكيف تعمل إدارة إصدارات الموارد في بيئات متعددة العملاء واسعة النطاق؟ نأمل أن تجيب عن هذه التساؤلات أبحاث لاحقة.
المصدر: https://arxiv.org/abs/2604.15034