ألفا وكيل تعيد كتابة نفسها في أسبوعين: كيف نقل Prime Agent لغة TypeScript إلى Rust

جيش من ألفي عنصر، ولا واحد منهم بشر

وكيل البرمجة Prime Agent، الذي صدر رسميًا في أغسطس 2026 فقط، جمع خلال شهرين أكثر من 300 ألف عملية تنزيل وعالج أكثر من 8 تريليونات رمز. وفي 9 أكتوبر، أعلنت شركته المطوّرة Prime Intellect أمرًا أكثر جذبًا للانتباه: الأداة أعادت كتابة نفسها. تم الانتقال من TypeScript إلى Rust في أسبوعين، ومن قام بالعمل أكثر من ألفي وكيل مستقل.

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

الكلفة والحجم: نقل 200 مليار رمز دفعة واحدة

وفق ما ورد في المدونة الرسمية، جدولت إعادة الكتابة هذه أكثر من 2000 وكيل يعملون بالتوازي عبر أكثر من 10000 صندوق رمل من Prime، واستهلكت أكثر من 200 مليار رمز من نقطة نهاية GLM-5.3 على Prime Inference. أما مرحلة كتابة Rust فعليًا فقد أنجزها 1981 وكيلًا، باستهلاك نحو 192.99 مليار رمز؛ ثم أضافت مرحلة رفع الأداء التي استمرت ثلاثة أيام 228 وكيلًا آخرين ونحو 35.7 مليار رمز.

هذه الأرقام في حد ذاتها إشارة. أن يصبح النموذج المفتوح GLM-5.3 محرك الاستدلال الرئيسي لسرب وكلاء بمستوى الإنتاج ليس كقول «نموذج ما رفع نتيجته في الاختبار نقطة أخرى». إنه يبيّن أن كفاءة الكلفة للنماذج ذات الأوزان المفتوحة صارت مقبولة لمشروعات حقيقية في سياقات هندسية طويلة الأمد وضخمة الحجم وتحتاج إلى استدعاءات أدوات مستقرة.

التنظيم: الوكيل الجذر لا يكتب شيفرة المنتج

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

تمر كل مهمة بأربعة أدوار بالترتيب:

• المخطِّط: يكتب المواصفات وتصميم الوظيفة و«الإجابة المرجعية»، التي تُؤخذ مباشرة من السلوك القائم للنسخة المكتوبة بـ TypeScript.
• المنفِّذ: يكتب شيفرة Rust في worktree مستقل، حتى تتقدم الوظائف المختلفة بالتوازي.
• المراجع: يبدّل النموذج والسياق ليبحث بأسلوب تخاصمي عن عيوب هذا التغيير.
• المتحقق: يُصرّف الشيفرة ويشغّل اختبارات الاتساق في صندوق رمل جديد تمامًا.

إذا لم تنجح المراجعة أو لم ينجح التحقق، تعود المهمة إلى المنفِّذ مع النتائج. ولا يُسمح بدمج التغيير إلا إذا نجح الاثنان. وقد فصلت Prime Intellect عمدًا بين «التوليد» و«التقييم»، والسبب صريح: إذا تركت الوكيل الذي كتب الشيفرة يحكم على ناتجه، فسيميل بطبيعته إلى نفسه.

الحواجز الحقيقية: أربعة أنواع من فحوص الاتساق

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

• اختبارات TUI التفاضلية: تشغيل ثنائيي TypeScript وRust تحت النموذج النصي نفسه، ومقارنة شاشة الطرفية إطارًا بإطار، مع تغطية الإقلاع والقوائم واستدعاءات الأدوات واستئناف الجلسات والوكلاء الفرعيين والتعافي بعد الانهيار.
• اتساق الـ Harness: مقارنة سجلات الجلسات التي ينتجها كل طرف، والطلبات التي يرسلها كل منهما إلى مزوّد النموذج.
• اتساق البروتوكول: التحقق من كل نوع رسالة في بروتوكول الخفي مقابل تطبيق TypeScript.
• تدقيق الوظائف: في المواضع التي لا تصل إليها السكربتات، يتحقق الوكلاء مكوّنًا بمكوّن ويصنّفونه بـ «متسق» أو «متسق جزئيًا» أو «مفقود».

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

النتائج: إقلاع بارد أسرع 14 مرة، وذاكرة أقل بنسبة 80%

في بيانات المقارنة الرسمية، انخفض زمن الإقلاع البارد حتى إمكانية الكتابة من 737.8 مللي ثانية في نسخة TypeScript إلى 55.8 مللي ثانية، أي تسريع بنحو 14.18 مرة؛ وتحسّن الإقلاع الساخن 13.34 مرة؛ وانخفض استهلاك الذاكرة لشجرة العمليات كلها من 607.4 ميجابايت إلى 106 ميجابايت، أي توفير بنحو 80%؛ كذلك تقلص حجم التثبيت من 172.1 ميجابايت إلى 59.6 ميجابايت. ووصل أول إخراج مرئي عند 23.6 مللي ثانية. سجّلت مرحلة رفع الأداء 144 تجربة إجمالًا ودمجت 69 تغييرًا فعّالًا. لكن من المهم التنبيه إلى أن هذه المقارنة الجانبية استخدمت مجموعة التشغيل الخاصة بالفريق نفسه، وقد أوضح الفريق أيضًا غياب معيار مرجعي موحّد، لذا ينبغي قراءة الأرقام بحذر.

قد يدوم التغيير البنيوي أطول من السرعة. قُسّمت الشيفرة إلى تسع حِزم (crates)، بعلاقات اعتماد أحادية الاتجاه يفرضها Cargo؛ وتقلص أكبر ملف مصدري من نحو 15000 سطر إلى نحو 2500، ولم يعد أي ملف يتجاوز 5000 سطر. كل جلسة تعمل في عملية عاملة خاصة بها، فانهيار إحداها لا يؤثر في البقية. وجاء دعم Windows نتيجة جانبية لتجريد منصة أنظف، وانتقل كتالوج النماذج إلى الجلب وقت التشغيل، فلم يعد إطلاق نموذج جديد يعتمد على إصدار.

لماذا Rust

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

وحين تكون الشيفرة من كتابة الوكلاء أساسًا، تتضاعف قيمة «ضمانات وقت التصريف». فالتعدادات الشاملة، والملكية وأزمنة الحياة، إضافة إلى فحوص Clippy الصارمة، تستطيع استبعاد فئة كاملة من الأخطاء قبل أن تعمل الشيفرة أصلًا. بكلمات أخرى، يتحمّل المُصرّف جزءًا من الحكم الذي كان سيقع على عاتق مراجع بشري.

ماذا يعني هذا لأشخاص مختلفين

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

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