ميتا تطلق Muse Code، أول عميل برمجي للطرفية مع عوامل تعمل لفترات طويلة وخيارات خصم بنسبة 95%

في 5 أغسطس 2026، أطلقت ميتا أول عميل برمجي للواجهة النهائية — Muse Code، وطرح في نفس الوقت نموذج Muse Spark 1.2 المُحسّن خصيصًا للبرمجة. يمكن لـ Muse Code قراءة مكتبات كود ضخمة، ووضع خطط تعديل، وكتابة الكود، وتشغيل الاختبارات، والتحقق من النتائج، كما يسمح بتشغيل عدة عميل خلفي خلال الجلسة بأكملها دون الحاجة إلى إعادة فهم المشروع في كل مهمة جديدة. كما صممت ميتا سجل أحداث محليًا يسمح فقط بالAppending ولا يمكنه الكتابة فوق، مما يسمح بالاستعادة الدقيقة للموقع الذي انقطع فيه البرنامج حتى في حالة تعطله. ما أثار أيضًا نقاشات المطورين هو السعر: تبلغ التكلفة النموذجية 1.25 دولار لكل مليون توكين إدخال و4.25 دولار لكل مليون توكين إخراج؛ وإذا سمح المستخدم لميتا باستخدام الإدخالات والإخراجات لتحسين المنتج، فسينخفض السعر في "النسخة المساهمة" إلى 0.10 دولار و0.20 دولار. الشرط الخلفي لهذا السعر المنخفض ليس عرضًا ترويجيًا عاديًا، بل هو الكود وبيانات الاستخدام. أظهرت التقييمات الرسمية أن Muse Spark 1.2 تقترب من نماذج البرمجة الرائدة، لكنها لم تتفوق عليها بشكل شامل بعد، كما أن بعض النتائج لم تُعاد تجربتها بشكل مستقل. الإشارة التي أرسلتها ميتا هذه المرة هي أن وحدة المنافسة في البرمجة بالذكاء الاصطناعي تنتقل من النموذج الفردي إلى النظام الكامل المكون من النموذج وإطار عمل العميل والحالة الطويلة الأمد ودورة البيانات.

مؤلف المقال، المصدر: Meta AI Research

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

هذا يضع Muse Code مباشرة في السوق الذي تتنافس عليه منتجات مثل Claude Code و Codex و Gemini CLI. لم تعد النماذج تقتصر على الإجابة عن سؤال "كيف يجب كتابة هذا الكود؟"، بل تحصل على حق الوصول إلى الطرفية ونظام الملفات وأدوات التطوير، وتنفذ المهام باستمرار مع تدخل بشري أقل.

أشارت ميتا في مقالها إلى أن Muse Code وMuse Spark 1.2 يُعرضان كنظام واحد، وليس كمنتجين يمكن فصلهما بحرية. فـMuse Spark 1.2 مسؤولة عن الفهم والاستدلال والإنشاء، بينما تُعنى Muse Code بتنظيم السياق، وجدولة الوكلاء الفرعيين، واستدعاء الأدوات، وحفظ الحالة، والتحقق من النتائج. كما تم تحسين كليهما معًا خلال مرحلة التدريب، مما يعني أن نفس النموذج عند نقله إلى إطار وكلاء آخر قد لا يُعيد إنتاج النتائج التي عرضتها ميتا.

التصميم الأكثر تميزًا لمود كود هو مجموعة من الوكلاء الخلفيين التي تعمل بشكل غير متزامن.

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

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

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

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

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

أنشأ Muse Code سجل أحداث محلي لهذا الغرض. يتم كتابة كل استدعاء للنموذج، وتنفيذ الأداة، وموافقة المستخدم، وتعديل الملف بطريقة الإضافة إلى السجل، ولا يتم تغطية السجلات التاريخية السابقة مباشرة بواسطة الحالات اللاحقة.

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

يحتوي Muse Code أيضًا على عدة مهارات قابلة للطلب:/planيُنشئ أولاً خطة تنفيذ تتطلب موافقة المستخدم؛/grillتهاجم وتشكك في هذه الخطة بشكل خاص للبحث عن الثغرات والمخاطر والافتراضات الخاطئة؛/goalثم تجعل الوكيل ينفذ بشكل مستمر حول الهدف المحدد حتى تتحقق شروط الإنجاز.

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

تم إطلاق Muse Spark 1.2 كإصدار مُحسّن للبرمجة بعد أقل من شهر من إصدار الإصدار 1.1. وتشير ميتا إلى أن هذا الإصدار زاد من تنوع قوة الحوسبة وبيئة التدريب المخصصة للمهام البرمجية، مع التركيز على تحسين توليد الكود، واستكشاف الأخطاء المعقدة، وفهم مكتبات الكود، وسير العمل الكامل للتطوير.

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

كما شاركت ميتا Muse Spark 1.1 في تدريب النموذج القادم. حيث يُستخدم النموذج القديم لإنشاء بيئات برمجة أكثر تعقيدًا وقوالب اتباع التعليمات، ثم تقييم ما إذا كانت الحلول المرشحة تلبي المتطلبات، مما يُنتج دفعات من البيانات لتعلم الإصدار 1.2.

ما يُشار إليه هنا بـ"التحسين الذاتي" لا يزال لا يعني قيام النموذج بتعديل الأوزان بنفسه بعد انفصاله عن التحكم البشري. التعبير الأكثر دقة هو أن النموذج من الجيل السابق يُستخدم كمُولّد للبيانات ومُقيّم، لمساعدة الفريق على توسيع بيانات التدريب للجيل التالي. تظل عملية تدفق البيانات وعمليات التدريب والإصدار النهائي للنموذج تحت سيطرة Meta.

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

حالة مقدمة من Meta، حيث يتم تحسين نواتي KDA وMLA على وحدات معالجة الرسومات NVIDIA Hopper ضمن بيئة Muse Code باستخدام Muse Spark 1.2. يجب على النظام كتابة الكود وترجمته وتحليل الأداء، ثم تعديله بشكل متكرر بناءً على النتائج.

أطول مدة تشغيل للاختبار هي 24 ساعة، مع أكثر من 1000 استدعاء لأداة. يُمنع الباحثون النموذج من استيراد مكتبات نواة طرف ثالث جاهزة، ويطالبونه بتنفيذ الخوارزمية في Triton والبحث عن تحسينات حقيقية في الأداء، وليس فقط تغليف تنفيذات موجودة كنتائج خاصة به.

في مهمة KDA، يجمع النموذج بين نوى الإعداد المتوازية داخل الكتلة ومسح عابر بين الكتل التسلسلي، مع إضافة تحسينات مخصصة للتخفيض المُحَكَم. وفي مهمة MLA، صمّم خط أنابيب Triton مكونًا من نواتين، وحاول إعادة استخدام التمثيل الكامن المشترك للـ KV.

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

تغطي تقييمات Meta Terminal-Bench 2.1 وDeepSWE 1.1 وGDPVal-AA v2 وMCP Atlas واختبارات البرمجة الداخلية. ويشمل Terminal-Bench 2.1 89 مهمة تتطلب إكمالها في بيئة طرفية؛ ويشمل DeepSWE 1.1 113 مهمة مستمدة من 91 مستودع كود، وتغطي خمس لغات برمجة.

وفقًا للرسوم البيانية التي نشرتها ميتا، حصل Muse Spark 1.2 مع Muse Code على 82.9% في Terminal-Bench 2.1، وهو أقل من 86.7% لـ Claude Opus 5، لكنه أعلى من Codex وGrok Build في تقييماتهما. على DeepSWE 1.1، حصل Muse Spark 1.2 على 59.3%، ولم يحقق المركز الأول. في 440 مهمة هندسية حقيقية داخل ميتا، حصل على 70.6%، وهو ما يزال أقل من Opus 5.

هذه النتائج تشير إلى أن Muse Code دخل نطاق المنافسة بين الوكلاء البرمجيين الرائدين، لكنها لا تدعم استنتاجًا مفاده أن "ميتا هزمت بشكل شامل Claude Code وCodex".

الرسميملف منهجية التقييمكما يوضح أن كل نموذج تم دمجه مع منتج Agent الخاص به: يستخدم Muse Spark Muse Code، وClaude يستخدم Claude Code، وGPT يستخدم Codex، وGemini يستخدم Antigravity، وKimi يستخدم Kimi Code. هذا النوع من المقارنة أقرب إلى مواجهة منتجات كاملة، لكنه لا يستطيع التمييز بين الأداء الناتج عن النموذج أو إطار العمل Agent.

كما أقرت ميتا بأن بيئة التقييم الداخلية وعبارات التوجيه الخاصة بها قد لا تكون مُحسّنة بشكل أمثل للنماذج المغلقة من طرف ثالث. كما أن نتائج Muse Spark 1.2 على Terminal-Bench لم تُدرج بعد في قوائم التحقق المستقل. لذلك، فإن أكثر التصريحات أمانًا في هذه المرحلة هي: تُظهر اختبارات ميتا الداخلية أنها قريبة من المستوى الرائد، لكن التحقق المستقل لا يزال مفقودًا.

يبلغ سعر إصدار Muse Spark 1.2 القياسي 1.25 دولار لكل مليون رمز إدخال، و0.15 دولار للإدخال المخزن مؤقتًا، و4.25 دولار للإخراج. لن تُستخدم الإدخالات والإخراجات في هذا الإصدار لتحسين منتجات Meta.

يتم تحديد النموذج الآخر على أنهmuse-spark-1.2-contributor. يبلغ سعر كل مليون وحدة إدخال 0.10 دولار، و0.002 دولار للإدخال المخزن مؤقتًا، و0.20 دولار للإخراج. مقارنة بالإصدار القياسي، يكون الإدخال أرخص بنسبة 92%، والإخراج أرخص بنسبة 95% تقريبًا.

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

لا يمكن للشركات أن تفترض أن مناسبًا لتسليم كامل قاعدة الكود للمساهمين فقط بناءً على سعر الرمز. ما إذا كان يُسمح باستخدام البيانات للتدريب يتطلب تقييمًا بناءً على شروط الخدمة الخاصة بـ Meta، وملكية الكود، وعقود العملاء، وسياسات الأمان الداخلية. الإصدار القياسي والإصدار المساهم تستخدمان قدرات متشابهة، لكنهما ترتبطان بعلاقتين مختلفتين تمامًا بالبيانات.

هذا يكشف أيضًا عن استراتيجية المنافسة الحقيقية لـ Meta: فهي لا ترغب فقط في جذب المطورين من خلال الأسعار المنخفضة، بل تهدف أيضًا إلى إنشاء حلقة مغلقة من بيانات التدريب البرمجي من خلال المهام والتعديلات والتعليقات والنتائج التي يولدُها المطورون أثناء استخدامهم لـ Muse Code. ويحصل المطورون على استدعاءات Agent شبه مجانية، بينما قد تحصل Meta على بيانات أكثر قيمة من كود GitHub العام — وهي كيفية تفكيك المهام وتعديلها والتحقق منها في الواقع.

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

كما أوضحت ميتا صراحةً أن هناك نماذج أكبر وميزات إضافية لإطارات الوكلاء ستُطلق في المستقبل. وهذا يعني أن Muse Spark 1.2 ليس المنتج الرائد النهائي، بل يُعد أكثر شبهاً بالبنية التحتية الكاملة الأولى لميتا في سوق وكلاء البرمجة.