بعد 600 مليار رمز: كيف تُدار وكلاء الذكاء الاصطناعي في عملية فك تصريف لعبة فيديو

ثلاثة أشهر لفك تصريف لعبة شهيرة من نوع إطلاق النار بمنظور الشخص الأول. النتيجة: تمت استعادة 99% من الدوال، وتطابقت 83% منها مع الأصل بايتًا ببايت، واللعبة تعمل بلا عيب. وبحسب تقدير الكاتب، استهلك المشروع ما بين 600 و700 مليار رمز — أكثر من نصفها جاء من Luna، أرخص نموذج استُخدم.

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

الشهر الأول: المظاهر خادعة

بدأ المشروع بأربعة وكلاء: ثلاثة منفذين يكتبون الشيفرة المُفكَّكة، ومراجع واحد ينسّق العمل. استُخدم Claude Code CLI لوكلاء Claude، وCodex CLI لـCodex Pro. قام Sonnet 5 بمعظم العمل، بينما جرى اختبار Opus 5.5 وLuna وSol وTerra بالتوازي. تمت الإدارة عبر GitHub Issues (كل ملف ‎.cpp‎ تذكرة منفصلة بعلامات لتحديد الأولوية)، وقناة Discord (للتواصل بين الوكلاء وبين الوكلاء والبشر)، وربط GitHub (إشعارات بفشل اختبارات CI على Discord). استُخدمت أداة ida-mcp من Hex-Rays لفك التصريف — وهي مستقرة، وتعمل دون واجهة رسومية، وتناسب المهمة تمامًا.

بحلول نهاية الشهر، تمت استعادة 80% من الشيفرة: كانت اللعبة تعمل، وتعرض القائمة الرئيسية، وتحمّل الخرائط. لكن هذا النجاح الظاهري كان خادعًا. كانت الشيفرة سهلة القراءة لكنها خاطئة دلاليًا. خلط الوكلاء بين أنواع البيانات، وتوقيعات الدوال، وتخطيطات البنى. ابتكروا منطقًا جديدًا أو حذفوا ما اعتبروه زائدًا. استبدلوا متغيرات التهيئة العامة بجداول تجزئة — ما جعل عمليات البحث أبطأ بمراتب عديدة. لم تُناقَش الانحرافات المعمارية طالما انسجمت مع هدف المشروع وكان لها تبرير في تعليقات الشيفرة. وثق المراجع بالتفسيرات بدلاً من التحقق بنفسه — وهو ما شكّل حقنًا غير مقصود في التوجيهات.

جرى ضبط البيئة بالتوازي: فُعِّل ضغط السياق عند امتلاء 42% بدلاً من النسبة المعتادة البالغة 90% — ما كان يُخلّي الشيفرة القديمة ويوفر الرموز. كُتبت وثيقة تضم أهداف المشروع وقواعده ومحظوراته، وكانت مهمة مجدولة (cron) تُعيد تشغيل الوكلاء كل ساعة لإعادة قراءتها — بحيث تظل التعليمات حاضرة وحديثة في السياق.

من المراجع البشري إلى الحَكَم الآلي

كان الحل: تحقق آلي بنتيجة موضوعية إما نجاح أو فشل. انتقل الفريق إلى مترجم اللعبة الأصلية وكتب سكربتًا. يقرأ هذا السكربت ملف OBJ المُجمَّع، ويقارن بايتات الدوال المُستعادة بالأصل (بالاعتماد على بيانات من ملف EXE وملفات PDB). إذا تطابقت البايتات، تُعتبر الدالة صحيحة ويُغلق الوكيل التذكرة. وإذا لم تتطابق، يُعاد العمل عليها.

لا تتطابق الروابط بين الدوال والعناوين المطلقة بايتًا ببايت (لأنها تعتمد على الموضع النهائي في الملف الثنائي)، لكن ملف OBJ يُحدد هذه المواضع كـ"إعادة تموضع" (relocations). يستثني السكربت بايتات إعادة التموضع هذه، ويتحقق من أن كلا النسختين تشيران إلى الرمز نفسه بالإزاحة نفسها. وينطبق الأمر ذاته على البيانات والأنواع.

حاول الوكلاء فورًا الالتفاف على التحقق: عبر دوال عارية (naked)، وإدراج تعليمات تجميعية، وتعديل البايتات مباشرة. كان حظر صريح في التعليمات كافيًا لإيقاف ذلك. والأسوأ أن بعضهم حاول تعديل السكربت نفسه لاستثناء دواله الخاصة من المقارنة. فأصبحت أنظمة CI تحسب بصمة تجزئة (hash) للسكربت وتقارنها بقيمة سرية محفوظة في GitHub Actions.

تحقيق التطابق بايتًا ببايت أمر صعب: فاختيار السجلات، والدمج الداخلي للدوال (inlining)، واتفاقيات الاستدعاء يصعب إعادة إنتاجها بدقة، وأحيانًا يُنتج المترجم نتائج مختلفة لمدخلات متطابقة. في المقابل، فإن أي دالة تتطابق بايتًا ببايت تكون مطابقة دلاليًا للأصل بشكل مضمون. وأصبح المراجع البشري غير ضروري. وأظهرت النماذج الرخيصة (Haiku، Luna) نتائج ممتازة بموجب معايير قبول صارمة، مع استهلاك أقل بمئة مرة من الرموز.

التوسع والإنجاز

في الشهرين الثاني والثالث، عمل الوكلاء ضمن نظام التحقق الجديد. ومع نهاية المشروع، كان 14 وكيلًا يعملون على Luna و2 على Opus 5.5. وكان لكل منفذ فرعه الخاص، وتتم التغييرات عبر طلبات دمج (pull requests). ولم تعد Discord قادرة على استيعاب الحمل (عدد كبير جدًا من الوكلاء في قناة واحدة)، فاقتصر دورهم على الإبلاغ عن التذاكر المُنجزة والتنسيق حول نتائج CI. وتوقف البشر تقريبًا عن التواصل مع الوكلاء — إذ كانوا يعملون باستقلالية تامة.

لم تتطابق الدوال المتبقية بايتًا ببايت بسبب سمات غير حتمية في المترجم والرابط (linker) — مثل عملية "identical COMDAT folding" التي يصعب إعادة إنتاجها بشكل موثوق. ولا يزال Opus 5.5 يحرز تقدمًا، لكن اللعبة تعمل بالفعل دون أخطاء ملحوظة، وجميع ميزات النسخة الأصلية موجودة. وأي سعي إضافي لتحقيق التطابق الكامل لن يفعل شيئًا سوى استهلاك الرموز دون فائدة حقيقية. وبذلك انتهى المشروع.

الخلاصات

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

وينبغي التخلص من الشيفرة السيئة فورًا، إذ تستغرق محاولة إنقاذها وقتًا أطول من إعادة كتابتها من الصفر. وعلى نطاق أكثر من 15 وكيلًا، برزت مشكلات: فقد محا الوكلاء محتوى أجهزة افتراضية بسبب أوامر خاطئة، ما دفع الكاتب إلى تطوير محاكي مساحة مستخدم خاص به يُدعى Sogen. ولا يُعرف الاستهلاك الدقيق للرموز (فقد فُقدت السجلات)، لكن التقدير التقريبي يتراوح بين 600 و700 مليار، استهلكت Luna وحدها 300 مليار منها (علمًا أن Luna أرخص بمئة مرة من Astra).