أنور بآي
أرى REA من أكثر مهارات وكلاء الذكاء الاصطناعي إثارة للجدل. فهي تفتح بابًا كان موجودًا منذ زمن، لكنه احتاج إلى خبرة كبيرة وعمل يدوي طويل: فهم برنامج من نسخته الموزعة، ثم استخدام ذلك الفهم لبناء تنفيذ جديد. وإذا أصبحت هذه العملية أسهل، فقد تضع مطوري التطبيقات والألعاب أمام منافسة مختلفة عن التي اعتادوها.
هذه ليست بالنسبة إليّ فكرة نظرية فقط. استخدمت REA بنجاح لإعادة تنفيذ تطبيق بلغة Rust بالوظائف نفسها، ووجدت النسخة الجديدة أسرع في استخدامي. أكثر ما يلفتني هو إمكانية الجمع بين هذه الأدوات ووكيل مثل Hermes: لا تكتفي بالسؤال عن طريقة عمل ميزة، بل تعطي الوكيل وسائل يبحث بها عن الإجابة، ثم تساعده على كتابة تنفيذ آخر.
هذه ملاحظة أحمد، كاتب المقال، عن تجربته؛ لا تتضمن قياسات منشورة أو اسم التطبيق أو مقارنة أداء قابلة لإعادة الاختبار. لذلك لا نقدمها دليلًا على أن Rust أسرع دائمًا، أو أن REA تستطيع إعادة إنتاج أي تطبيق كاملًا. أما بقية المقال فمبنية على مراجعة توثيق المشروع ومصادره، دون تشغيل تحليل مستقل للتطبيق المذكور.
ما REA فعلًا؟ ليست Skill وحدها
اسم المشروع هو Reverse Engineer Anything. ووفق المستودع الرسمي، يربط REA وكيل الذكاء الاصطناعي بأدوات لفحص الملفات التنفيذية، والتطبيقات، وبعض سلوكيات التشغيل. يمكن الوصول إلى هذه القدرات عبر MCP أو من سطر الأوامر.
هناك ثلاثة أجزاء ينبغي تمييزها:
Skill: تعليمات تساعد الوكيل على اختيار مسار التحقيق، وقراءة الأدلة، وتسجيل ما يعرفه وما لم يعرفه بعد.
MCP وCLI: واجهتان لاستدعاء عمليات التحليل. قراءة ملف المهارة لا تضيف هذه الأدوات إلى جلسة الوكيل تلقائيًا.
محركات وأدوات خارجية: مثل Ghidra وHopper وIDA لتحليل الكود الأصلي، أو أدوات أخرى بحسب نوع الهدف.
هذا التفريق مهم. إذا ثبّتَّ المهارة وحدها، فلن يتحول نموذج اللغة إلى Decompiler. أما مع الأدوات المطلوبة، فيستطيع الوكيل أن يطلب فحصًا، ويقرأ النتائج، ويتابع سؤالًا محددًا بدل الاعتماد على التخمين.
من Decompilation إلى إعادة التنفيذ
الهندسة العكسية ليست جديدة. الجديد هنا هو إتاحة خطواتها لوكيل يستطيع تنسيق التحقيق وكتابة الكود والاختبارات.
Disassembly يحوّل تعليمات الآلة إلى تمثيل مقروء مثل Assembly. وDecompilation يحاول إنتاج تمثيل أعلى مستوى، غالبًا Pseudocode. هذا التمثيل ليس بالضرورة الكود الأصلي؛ قد تضيع أسماء المتغيرات، وتعليقات المطور، وبنية المشروع، وقد تكون بعض الأنواع أو المعاملات مستنتجة بصورة غير صحيحة.
بعد ذلك تأتي إعادة التنفيذ: تحويل السلوك الذي فهمته إلى برنامج جديد. يمكن أن تكون اللغة مختلفة، مثل الانتقال إلى Rust، لكن ذلك يتطلب قرارات هندسية واختبارات، لا مجرد ترجمة سطرية.
المسار العملي الذي تصفه REA هو:
يحدد الوكيل سؤالًا عن ميزة أو سلوك.
تستخرج الأدوات معلومات من الهدف المحلي.
يتابع الوكيل الاستدعاءات أو الموارد أو العلاقات التي تفسر السلوك.
يكتب مواصفات وتنفيذًا مستندًا إلى هذه الأدلة.
يختبر التنفيذ ويصرّح بالفجوات التي بقيت.
قد تنجح في إعادة بناء ميزة مهمة دون أن تستعيد التطبيق كله. وقد تحصل على واجهة مألوفة دون أن تتطابق تفاصيل التصدير أو الحسابات أو التوافق مع الملفات القديمة.
ما الذي يمكن تحليله؟
توضح وثائق المشروع في النسخة المراجعة مسارات متعددة، تختلف متطلباتها وحدودها:
Native binaries: دوال، وتعليمات، وسلاسل نصية، ومراجع واستدعاءات، باستخدام محرك مدعوم مثل Ghidra أو Hopper أو IDA.
JavaScript وElectron: وحدات واستيرادات وSource Maps، وعلاقات بين Renderer وPreload وIPC والإضافات الأصلية.
.NET assemblies: معلومات Metadata وتعليمات CIL وعلاقات معلنة، عبر تحليل ساكن.
Android APK: مسارات لتحليل Manifest والكود والموارد، مع متطلبات مثل JADX وJDK بحسب العملية.
المواقع والمتصفح: بنية الصفحات والسكربتات وملاحظات الشبكة ولقطات عند طلبها، مع متصفح مدعوم.
الحزم والموارد وبعض Firmware: جرد واستخراج وفحص يعتمد على نوع الملف والأدوات المتاحة.
هذه قائمة بمسارات يدعمها المشروع، وليست ضمانًا لنجاح كل مسار على كل منصة أو ملف. وقد تختلف قدرات فرع main عن إصدار npm المثبت لديك.
ولا يستخرج تحليل تطبيق محلي منطق خوادم الشركة تلقائيًا. إذا كان جزء من المنتج يعمل على Backend خاص، فلن تجد تنفيذ ذلك الجزء كاملًا داخل تطبيق سطح المكتب.
مثال الألعاب: استعادة دالة، لا إعلان اكتمال لعبة
يعرض المشروع دراسة حالة عن DX-Ball: كيف يمكن تتبع حساب موضع الصوت من تعليمات البرنامج إلى دالة C مفهومة.
المثال مفيد لأن أول مخرجات الـDecompiler لم تكن كافية. أظهر Pseudocode دالة دون مدخل واضح، بينما كشفت التعليمات عن مدخل على Stack وعمليات حسابية. تابع التحقيق الدالة المستدعية والثوابت المستخدمة قبل كتابة التنفيذ المستعاد.
تذكر الدراسة اختبارات لمقارنة سلوك الدالة وBytes الناتجة عن تجميعها. هذه نتائج نشرها أصحاب المشروع، وليست اختبارات أعدنا تنفيذها. كما توضح أن العمل على النسخة القابلة للعب ما زال مستمرًا؛ استعادة مجموعة من الدوال لا تعني اكتمال إعادة بناء اللعبة.
هنا يظهر سبب اهتمام صناعة الألعاب بهذه الأدوات: يمكنها تسهيل دراسة سلوك قديم أو استعادة حساب محدد. لكن اللعبة تشمل أصولًا فنية وصوتية، ومحركًا، وملفات حفظ، وأنظمة تشغيل وشبكات، وحقوقًا منفصلة عن الكود. نجاح تحليل جزء لا يحسم هذه الأجزاء الأخرى.
ArtCraft وAdobe: لماذا أصبح النقاش أكبر؟
المثال الذي يستحق النظر إليه هو Crafting Apps من ArtCraft. يعرض الموقع مجموعة تطبيقات مفتوحة المصدر مكتوبة بلغة Rust، تغطي تحرير الصور، والرسم المتجهي، والفيديو، والتصوير، وPDF، والمؤثرات، والنشر المكتبي.
وتصف صفحة PhotoCraft أدوات وواجهات مألوفة، وطبقات وأقنعة وتحريرًا غير هدّام، مع تنفيذ Native بلغة Rust. هذه أوصاف ينشرها الفريق، وليست نتائج اختبار أداء من طرفنا.
تربط تغطية Ars Technica هذه التطبيقات بمحاولة بناء بدائل لمنتجات Adobe باستخدام أدوات الذكاء الاصطناعي والهندسة العكسية. لكنها تؤكد أيضًا أن التطبيقات مبكرة وغير مكتملة، وتنقل طموحات المطور بشأن التكافؤ الوظيفي بوصفها وعودًا، لا نتيجة تحققت.
هناك فرق بين واجهة مألوفة وميزات مشابهة وبين نفس واجهة Adobe وكل وظائفها بالجودة والتوافق نفسيهما. التشابه الظاهر لا يثبت ذلك. كما أن المصادر التي راجعناها لا تثبت أن فريق ArtCraft استخدم REA تحديدًا؛ المثال يوضح الاتجاه الأوسع، وليس دراسة حالة موثقة لهذه الأداة.
لهذا أرى أن مصدر القلق المحتمل لمطوري التطبيقات هو انخفاض كلفة فهم السلوك وبناء بدائل. أما القول إن بديلًا مفتوح المصدر أصبح أسرع وأكمل من منتجات Adobe كلها، فيحتاج إلى اختبارات ومقارنات لا توفرها هذه المراجعة.
كيف تبدأ مع REA وHermes؟
هذه خطوات مستندة إلى التوثيق وليست تجربة تثبيت نفذناها هنا. استخدمها على جهاز تطوير تتحكم به، ومع تطبيق تملكه أو لديك إذن مناسب لتحليله.
1. تحقق من المتطلبات
بحسب دليل التثبيت، يدعم المشروع Node.js من فروع 22 و24 و26 وما بعدها، مع حدود دنيا محددة: 22.19 لفرع 22 و24.11 لفرع 24. لا تفترض أن كل إصدار فردي بين هذه الفروع مدعوم.
يمكنك فحص بيئتك وإصدار الحزمة المنشور:
node --version
npm --version
npm view rea-agents dist-tags.latest
تحليل JavaScript الساكن لا يحتاج إلى محرك Native. أما تحليل ملف تنفيذي أصلي فيحتاج إلى إعداد محرك مناسب. تثبيت REA لا يعني تثبيت جميع المتطلبات الخارجية.
2. راجع خطة الإعداد قبل تطبيقها
يذكر دليل REA أن Hermes من العملاء المدعومين. ابدأ بخطة محددة له بدل تغيير إعدادات كل الوكلاء المكتشفين:
npx rea-agents@latest setup --client hermes --dry-run --json
راجع الملفات والمسارات والتسجيل المقترح والنسخ الاحتياطية واستبدال تعليمات المهارة. تنزيل الحزمة عبر npm خطوة منفصلة عن الموافقة على تعديلات الإعداد.
بعد مراجعة الخطة والموافقة على نطاقها، يكون أمر الإعداد:
npx rea-agents@latest setup --client hermes
ثم أعد تشغيل الوكيل وفق تعليمات عميلك. هذه أوامر لجهاز تطوير محلي؛ البيئات المستضافة أو المُدارة قد تقيد تسجيل MCP أو الوصول إلى برامج سطح المكتب، فلا تفترض أن الأمر مناسب لكل نسخة من Hermes.
3. افحص التسجيل، ثم الاتصال الفعلي
npx -y rea-agents@latest doctor --client hermes --json
يفحص doctor المتطلبات وملفات التسجيل. نجاحه لا يثبت أن الأدوات ظهرت في الجلسة الحالية أو أن محرك التحليل يستطيع معالجة هدفك. تحقق من أدوات MCP التي يعرضها الوكيل، ثم ابدأ بسؤال صغير على هدف مصرح به.
4. أو ابدأ بتحليل JavaScript من CLI
يورد دليل CLI هذا المسار لتحليل مجلد تطبيق مستخرج أو ملف ASAR:
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json > app-evidence.json
استبدل المسار بهدفك المصرح به. الأمر ينفذ تحليلًا ساكنًا؛ لا تدّعِ من نتائجه أنك شاهدت التطبيق أثناء التشغيل. وقد تكون المخرجات كبيرة، لذلك حفظها ثم طلب ملخص أو جزء محدد أفضل من إدخالها كلها إلى Context Window.
اطلب تحقيقًا قابلًا للتحقق، لا «انسخ التطبيق»
بدل طلب إعادة بناء تطبيق كامل من البداية، استخدم طلبًا محددًا مثل:
حلّل ميزة البحث في التطبيق المحلي الذي أملكه ضمن المسار المحدد.
ابدأ بالتحليل الساكن، ولا تشغّل التطبيق أو تتصل بالشبكة دون موافقة منفصلة.
اشرح مصادر الأدلة، وما هو ملاحظة مباشرة وما هو استنتاج وما بقي مجهولًا.
اكتب مواصفات سلوكية للميزة واختبارات قبول، ثم اقترح تنفيذًا أصليًا بلغة Rust.
لا تنسخ كودًا أو أصولًا لا أملك حق استخدامها، ولا تعدّل التطبيق الأصلي.
هذا مثال مقترح، لا سجل تجربة أجريت هنا. والتعليمات النصية ليست Sandbox؛ استخدم صلاحيات وحسابات وبيئة معزولة تناسب الهدف.
قبل أن تقول إن النسخة الجديدة «أفضل»، اختبر ما يهمك: زمن البداية، والاستجابة على بيانات متساوية، واستهلاك الذاكرة، ودقة النتائج، وتوافق الملفات، ومعالجة الحالات الطرفية. استخدم النسخة نفسها من المدخلات والبيئة في المقارنة. اختيار Rust وحده لا يثبت تحسنًا.
التحليل المحلي لا يعني أن كل البيانات تبقى محلية
يذكر المشروع أن التحليل يجري محليًا، لكن الوكيل يستقبل نتائجه. إذا كان الوكيل يستخدم نموذجًا سحابيًا، فقد تتضمن الرسائل المرسلة إليه مقتطفات أو معلومات من التطبيق.
راجع سياسة مزود النموذج، واحذف الأسرار والبيانات الشخصية، ولا تستخدم عينات عملاء أو برامج داخلية حساسة دون إذن. كذلك، توجد عمليات Runtime تشغّل الهدف أو تتفاعل معه بصلاحيات المستخدم؛ وهي تختلف عن القراءة الساكنة للملفات.
أين تقف الحقوق؟
REA مرخصة تحت MIT. هذه الرخصة تخص الأداة، ولا تمنحك حقوق التطبيق الذي تحلله أو أصول اللعبة أو العلامات التجارية.
فهم سلوك برنامج، وكتابة تنفيذ مستقل، ونسخ كود مستخرج، وإعادة استخدام واجهة أو صور، إجراءات مختلفة. حتى وصف العمل بأنه Clean-room لا يضمن مشروعيته في كل حالة؛ قد تنطبق شروط ترخيص وقوانين وحقوق مرتبطة بالواجهة والتصميم. هذه المراجعة ليست استشارة قانونية.
ابدأ ببرنامج تملكه أو هدف مرخص للتحليل، ولا تتعامل مع REA كوسيلة لتجاوز DRM أو تراخيص البرامج أو أنظمة Anti-cheat أو قيود الوصول. إذا كان هدفك نشر بديل تجاري قريبًا جدًا من منتج قائم، فراجع الحدود القانونية قبل النشر.
رأيي: الوكيل أصبح قادرًا على البحث داخل المنتج
ما جذبني في REA هو الانتقال من سؤال النموذج عن تطبيق لا يعرف تفاصيله إلى إعطائه أدوات يبحث بها عن هذه التفاصيل. تجربتي مع إعادة التنفيذ في Rust جعلت هذا الاحتمال ملموسًا بالنسبة إليّ، لكن كل مشروع جديد يحتاج إلى إثباته الخاص.
يمكن لهذه الأدوات أن تقلل بعض العمل اليدوي في التحقيق، وأن تجعل بناء بدائل أو نقل ميزة إلى لغة أخرى أكثر قابلية للتجربة. لا تختزل العملية إلى «مجرد وقت حتى ينسخ الذكاء الاصطناعي أي تطبيق»: جودة الأدلة، والمنطق الموجود على الخادم، والاختبارات، والحقوق، كلها حدود حقيقية.
أفضل بداية هي ميزة واحدة، وهدف واضح، ومواصفات قابلة للاختبار. إذا استطعت إثبات سلوكها وإعادة تنفيذه، فوسّع النطاق من هناك.
لا تعليقات بعد. شارك سؤالك أو تجربتك مع هذا الدليل.