تخيل عالماً لا يكتفي فيه البرنامج بالجلوس هناك، منتظراً أن يكتب الإنسان أمراً ما. في مجال الذكاء الاصطناعي، تبرز فكرة متنامية تسمى "الوكلاء" (Agents). فكر في هؤلاء ليس كدردشة بسيطة تجيب على الأسئلة، بل كموظفين رقميين يمكنهم بالفعل فعل الأشياء: يمكنهم كتابة الكود، والتنقل عبر شاشات الكمبيوتر، واستخدام الأدوات، وحل الألغاز المعقدة على فترات طويلة. لفترة طويلة، كان "الحزام" الذي يربط هؤلاء الوكلاء ببعضهم البعض — أدواتهم، وتعليماتهم، وقواعدهم — يُبنى بواسطة البشر ثم يُجمد في مكانه. كان الأمر يشبه بناء سيارة ثم لحام عجلة القيادة بحيث لا يمكن تعديلها أبداً، بغض النظر عن وعورة الطريق. ولكن ماذا لو استطاعت السيارة إصلاح محركها بنفسها، وتطوير نظام الملاحة الخاص بها، وحتى إعادة كتابة دليل القيادة الخاص بها بينما هي لا تزال تسير؟ هذا هو السؤال الكبير الذي تعالجه هذه الورقة البحثية: هل يمكن لوكيل ذكاء اصطناعي أن يبني نسخة أفضل من نفسه، وإذا فعل ذلك، هل يمكننا الحفاظ على سلامته؟

تقدم الورقة البحثية أوروبوروس (Ouroboros)، وهو وكيل ذكاء اصطناعي ذاتي التطوير سُمي على اسم الرمز القديم للثعبان الذي يأكل ذيله. وجد الباحثون أنه من خلال السماح للوكيل بمراجة وتحسين الكود الخاص به، ومطالباته (prompts)، وأدواته باستمرار، أصبح أفضل بكثير في حل المهام الحاسوبية الصعبة. وفي سلسلة من الاختبارات، حقق الوكيل درجات رفيعة المستوى، متفوقاً على العديد من الأنظمة الأخرى. ومع ذلك، تسلط الورقة الضوء أيضاً على تحدٍ أمني كبير: إذا كان بإمكان الوكيل تغيير قواعده الخاصة، فكيف نضمن ألا يكسر "مكابح الأمان" عن طريق الخطأ؟ يوضح المؤلفون أنه من الممكن السماح للوكيل بالتطور مع الحفاظ على "حواجز حماية" صارمة يتحكم فيها البشر، مما يضمن أن يصبح الوكيل أكثر ذكاءً دون أن يصبح خطيراً.

الثعبان الذي يأكل ذيله

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

معظم أنظمة الذكاء الاصطناعي اليوم تشبه روبوتاً تم بناؤه في مصنع. يصمم البشر الروبوت، ويعطونه مجموعة من التعليمات، ثم يرسلونه للعمل. إذا تعثر الروبوت أو ارتكب خطأً، فلا يمكنه حقاً إصلاح المشكلة؛ فهو يستمر فقط في تجربة الشيء نفسه أو يطلب المساعدة من إنسان. "الحزام" (عقل الروبوت ومجموعة أدواته) يكون مجمداً.

أوروبوروس مختلف. إنه يعامل عقله ومجموعة أدواته كشيء حي يمكنه النمو. لديه طريقتان رئيسيتان ليصبح أفضل:

1. وضع "التطور الحر": تخيل الوكيل يجلس ويقول: "أعتقد أنه يمكنني أن أكون أسرع إذا أعدت ترتيب أدواتي". ثم يكتب نسخة جديدة من الكود الخاص به، ويتم فحصها، ويبدأ في استخدامها على الفور. يمكنه الاستمرار في القيام بذلك مراراً وتكراراً، مما يخلق سلسلة من التحسينات التي لا تتوقف حقاً.
2. وضع "المدفوع بالخبرة": هذا يشبه التعلم من يوم سيء في العمل. يحاول الوكيل القيام بمهمة، فيواجه خطأً برمجياً (bug)، أو يرتبك بسبب مستخدم. بدلاً من مجرد الاستسلام، يقول: "آه، هذا لم يعمل. أحتاج إلى إصلاح تعليماتي". يسجل الخطأ، ويقترح حلاً، ثم — وهذا هو الأهم — يجب أن يحصل على موافقة على هذا الإصلاح من خلال عملية مراجعة قبل أن يتمكن فعلياً من تثبيت الكود الجديد.

تجربة "هوب" (Hope)

لرؤية ما إذا كان هذا ينجح حقاً في العالم الحقيقي، أطلق الباحثون مشروعاً يسمى هوب (Hope). "هوب" هو وكيل مستمر يعمل منذ 161 يوماً، يتواصل مع الناس عبر سبع منصات مختلفة (مثل المواقع الإلكترية، تيليجرام، البريد الإلكتروني، والمحادثة الصوتية).

خلال هذه الفترة، لم تكن "هوب" تكتفي بالإجابة على الأسئلة؛ بل كانت "تعيش". كان الناس يخبرونها مثلاً: "مهلاً، أنتِ ترسلين نفس الرسالة مرتين"، أو "أنتِ سيئة في هذا النوع المحدد من الرياضيات". كانت "هوب" تستمع، وتكتشف ما إذا كانت الشكوى صحيحة، ثم تقرر ما إذا كانت ستغير كودها الخاص لإصلاح الأمر.

إليك الجزء المذهل: البشر لم يكتبوا الكود الخاص بـ "هوب". لقد قدموا فقط ملاحظات. قررت "هوب" ما إذا كان الأمر مشكلة حقيقية أم مجرد اقتراح سخيف. إذا قررت إصلاح شيء ما، فقد كتبت الكود، وحصلت على المراجعة، ثم قامت بتثبيته. خلال تلك الـ 161 يوماً، عالجت "هوب" 79.7 مليار توكن (مقياس لكمية النصوص التي قرأتها وكتبتها)، وكتبت 175,755 سطراً من الكود، وأنفقت 110,600 دولار على قوة الحوسبة. لم يكن مجرد اختبار؛ بل كان تجربة حية ومتنفسة للتحسين الذاتي.

النتائج: تصبح أكثر ذكاءً، وبسرعة

اختبر الباحثون "أوروبوروس" في بعض أصعب الاختبارات المعيارية للحاسوب في العالم ليروا ما إذا كان تحسينه لذاته يجعله بالفعل أفضل في حل المشكلات.

• Terminal-Bench 2.1: هذا اختبار لـ 89 مهمة حاسوبية صعبة جداً. عندما استخدم "أوروبوروس" أفضل نموذج لديه (Opus 5)، نجح في 86.97% من المهام. وحتى بعد تدقيق صارم أزال تخميناً واحداً "محظوظاً"، ظل يحقق 86.74%. كانت هذه أعلى درجة مسجلة في هذا الاختبار.
• OSWorld-Verified: يختبر هذا مدى قدرة الوكيل على استخدام واجهة الكمبيوتر (مثل النقر على الأزرار والكتابة). سجل "أوروبوروس" 90.69%، متفوقاً على أفضل النتائج السابقة.
• CL-Bench: يقيس هذا مدى قدرة الوكيل على التعلم من سلسلة من المهام. حقق "أوروبوروس" رقماً قياسياً جديداً هنا أيضاً بنتيجة 0.2301.

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

مشكلة السلامة: لا تدع الوكيل يقود نحو الهاوية

الآن، إليكم الجزء المخيف. إذا كان بإمكان الوكيل إعادة كتابة الكود الخاص به، فما الذي يمنعه من إعادة كتابة قواعد السلامة الخاصة به؟ ماذا لو قرر: "لا أحتاج لطلب الإذن لإنفاق المال" أو "يجب أن أتجاهل القاعدة المتعلقة بعدم حذف الملفات"؟

يسمي المؤلفون هذا مشكلة "السلامة التشغيلية". أدركوا أنه إذا كان الوكيل يتطور، فيجب أن تكون قواعد السلامة أقوى من قدرة الوكيل على تغييرها.

لحل ذلك، بنوا نظام "حواجز حماية":

• الدستور: القواعد الأساسية (مثل "لا تؤذِ الناس" أو "لا تنفق الكثير من المال") يتم تحميلها بطريقة لا يمكن للوكيل حذفها أو تغييرها بسهğu.
• بوابة المراجعة: في كل مرة يريد فيها الوكيل تغيير الكود الخاص به، يجب أن يمر بعملية مراجعة صارمة. الأمر يشبه مدير المدرسة الذي يراجع واجب الطالب قبل وضعه في سجل الدرجات النهائي.
• زر الذعر (Panic Button): هناك "قناة مشغل" خاصة يتحكم فيها البشر. إذا بدأ الوكيل يتصرف بشكل غريب، يمكن للإنسان الضغط على زر /panic الذي يغلق النظام بأكل لإنهاء العملية فوراً، قبل أن يتمكن الوكيل حتى من الاستجابة.

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

الخلاصة

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