Muse Wonder Full متاح باشتراك فقط: ماذا يعني ذلك لفرق الوكلاء؟

أقوى نموذج لدى Meta غير متاح عبر واجهة برمجة التطبيقات (API) الخاصة بها. يحقق Muse Wonder Full نتيجة 56 على مؤشر الذكاء الاصطناعي من Artificial Analysis، ويتعادل مع Claude Code المبني على Sonnet 5.5 بنتيجة 68 على مؤشر وكلاء البرمجة (Coding Agents Index)، كما يتصدر كافة النماذج في اختبارات قياس الأداء البرمجية طويلة المدى لدى Meta. ولا يمكنك استخدامه إلا عبر Muse Code، وهو وكيل الطرفية (terminal agent) التابع لشركة Meta، وذلك ضمن باقة Power بسعر 50 دولاراً أو باقة Maximum بسعر 200 دولار. بينما توفر واجهة برمجة التطبيقات نموذج Muse Wonder الأصغر بنتيجتي 52 و63. لا يوجد تسعير لكل رمز (per-token) لنموذج Full، ولا توجد بوابة مخصصة له، ولا موعد محدد لتوفيره.

بالنسبة للمطور الفرد، يُعد هذا مجرد خيار تسعير. أما بالنسبة لفريق يدير الوكلاء عبر لوحة مهام مشتركة، فالأمر يمثل عائقاً بنيوياً: إذ ينحصر أفضل نموذج لـ Meta داخل الطرفية لشخص واحد، وتحت اشتراك شخص واحد، وبإعدادات بيانات يتحكم فيها شخص واحد، ولا يمكن لأي مهمة مسندة (Task) أن تصل إليه. يوضح هذا المقال أثر ذلك على فريق العمل (Crew)، وكيفية التعامل مع هذا الوضع.

مقارنة بين نسختي Wonder من منظور الفريق

يمثل العمود الأيمن أداة شخصية، بينما يمثل العمود الأيسر مسار عمل مشتركاً (lane). وكل ما سيلي ينبع من هذا الاختلاف الجوهري.

ما يخسره الفريق عندما يكون النموذج الأفضل مقتصراً على الاستخدام الشخصي

خروج العمل عن مسار اللوحة المشتركة. تكمن قيمة Sharkly في جعل إسناد المهام، والتقدم، والمعوقات، والنتائج، والمراجعة مرئية للجميع من مرحلة الطلب وحتى الإطلاق. وجلسة Muse Code تفتقر تماماً إلى هذه المزايا. فإذا كان النموذج الأقوى يعمل هناك فقط، فإن أعقد المهام (Tasks) ستتجه تلقائياً نحو الشخص صاحب الاشتراك، لتسجل اللوحة مهمة أُنجزت (Done) دون سجل تشغيل، أو تتبع، أو مسار قابل للمراجعة.

تحول إعدادات شخص واحد إلى سياسة عامة للفريق. تعتمد اشتراكات Muse Code افتراضياً وضع "المساهم" (Contributor mode)، الذي يسمح لشركة Meta بتدريب نماذجها على الأوامر البرمجية والأكواد والمخرجات مقابل سعة استخدام إضافية. ويمكن للمشترك تعطيل هذا الخيار، لكن لا يمكن لأي شخص آخر في الفريق التأكد مما إذا كان قد فعل ذلك بالفعل. في المقابل، تستدعي بيئة التشغيل (Runtime) على جهاز العمل (Computer) واجهة برمجة التطبيقات بالوضع القياسي (Standard mode)، حيث لا تُستخدم البيانات في التدريب إطلاقاً، ويسري هذا المبدأ على كل وكيل (Agent) يعمل على الجهاز دون الحاجة إلى تدخل يدوي.

السعة مقيدة بفئة الاشتراك وليست بمفتاح الواجهة. يتم تجديد باقات Muse Code ضمن فترات تمتد لخمس ساعات أو أسبوعياً، وقد أظهر أسبوع الإطلاق ما يحدث عند مواجهة مشكلات: فقد استنفد Wonder وFull الحصص بمعدل سريع وغير طبيعي في اليوم الأول، ما اضطر Meta إلى إعادة ضبط الحصص للجميع، وأقر ألكسندر وانغ بأنه لا تزال هناك عقبات بحاجة إلى معالجة. بينما يخضع مسار العمل على واجهة برمجة التطبيقات لقيود مختلفة تماماً، بمعدل 3,000 طلب و4 ملايين رمز في الدقيقة يتقاسمها الفريق، وهو ما يمكن للوحة مهام الفريق قياسه والتحكم به بدقة، على عكس الأفراد.

أرقام الأداء الترويجية تختلف عما تحصل عليه فعلياً. ركزت المواد الترويجية لإطلاق Meta على أرقام نموذج Full. وأي شخص يخطط لسعة فريقه بناءً على هذه الأرقام، فهو يخطط لنموذج لا يستطيع الفريق (Crew) تشغيله أصلاً. فالصف المعني بفرق العمل هو الخاص بنموذج Wonder: حيث حقق 52 على المؤشر العام، و53.1 على SWE-Marathon، و25 في المعرفة العامة. وهو يظل نموذجاً ممتازاً للمهام طويلة المدى؛ وتستغرق عملية إعداده وفقاً لدليل كيفية تشغيله فترة بعد ظهيرة واحدة فقط.

ما يحتفظ به الفريق

كل هذا لا يعني أن نموذج Full عديم الفائدة، بل يعني أنه نمط مختلف من الأدوات. والواقع أنه يلائم المهام التي يؤديها حالياً Claude Code أو Codex في الطرفية الشخصية: مثل استكشافات المهندس المسؤول الأولية، أو التجارب الاستطلاعية (spikes) التي لم يُحدد نطاقها بعد، أو جلسات تصحيح الأخطاء المعقدة التي لا ترقى لتكون مهمة محددة حتى يفهم شخص أبعادها جيداً. يتفوق نموذج Full بأربع نقاط تحديداً في هذا النوع من المهام، لذا من الأفضل استخدامه هناك.

يكمن الالتزام الحقيقي في آلية تسليم المهام (handoff). فعندما تحول جلسة Muse Code مسألة غامضة إلى خطة عمل واضحة، تتحول تلك الخطة إلى مهمة (Task)، وتُنقل المهمة إلى مسار مرئي على اللوحة المشتركة. وعندها يقوم وكيل Wonder الخاص بالفريق، أو وكيل Opus 5.5، بتنفيذ العمل المحدد النطاق مع إرفاق سجل التشغيل وتعيين مراجع له. بهذه الطريقة، يحتفظ المشترك بحرية الاستكشاف، بينما يحتفظ الفريق بسجل العمل كاملاً.

وهناك ممارستان بسيطتان لضمان نجاح ذلك:

• تدوين اسم النموذج صراحةً داخل المهمة. لا يعرض Sharkly أسماء النماذج تلقائياً، لذا يجب أن تنص تعليمات الوكيل على تضمين معرّف النموذج في أعلى التقرير، كما ينبغي على الشخص الذي ينسخ النتائج من Muse Code الإشارة إلى ذلك في تعليقات المهمة. فالمراجع الذي لا يعرف ما إذا كان الفارق البرمجي (diff) ناتجاً عن Full في الطرفية أو Wonder عبر المسار المشترك لن يتمكن من تقييم العمل بشكل سليم.
• اتخاذ قرار تفعيل وضع المساهم (Contributor mode) كفريق. إذا كان أي شخص يمتلك اشتراكاً في Muse Code ويتعامل به مع مستودعات الفريق، فإن إلغاء مشاركة البيانات يجب أن يكون قراراً جماعياً ومكتوباً، وليس خياراً شخصياً متروكاً للصدفة. يشرح مقال حقن التعليمات البرمجية وحواجز حماية الوكلاء لماذا تُعد بوابة المراجعة البشرية هي أداة التحكم الحقيقية وليست النماذج نفسها.

سيناريو لأسبوع عمل كامل

تخيل فريقاً مكوناً من خمسة أفراد خلال الأسبوع الأول بعد الإطلاق. يشترك المهندس المسؤول في باقة Muse Code Power من اليوم الأول، ويقضي يوم الإثنين مستخدماً Full لإنجاز مهمة ترحيل برمجية صعبة تجنبها الجميع. وبحلول يوم الثلاثاء، أصبحت الخطة جاهزة: أربعة أجزاء واضحة النطاق، ولكل منها اختبارات يجب الحفاظ على نجاحها. تحولت هذه الأجزاء إلى أربع مهام (Tasks) على اللوحة، وأُسندت إلى وكيل Wonder على بيئة تشغيل Codex، لتعمل بالتوازي على جهاز الفريق (Computer)، بينما يتابع المهندس المسؤول المراجعة من صندوق الوارد (Inbox). أُنجزت مهمتان بنجاح تام، وجاءت الثالثة بطلب استفسار حول تعديل في بنية البيانات (schema) خارج المستودعات المرفقة، فأجاب المهندس المسؤول في تعليق على المهمة. أما المهمة الرابعة فرسبت في حزمة الاختبارات مرتين، ثم واصلت المحاولة حتى أغلقت بنجاح في المحاولة الثالثة مع سجل يوثق جميع المحاولات.

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

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

هل سيتوفر نموذج Full عبر واجهة برمجة التطبيقات؟

تشير مدونة مطوري Meta إلى أن نموذج Full متاح حصرياً عبر اشتراكات Muse Code دون تحديد جدول زمني لطرحه. والمنطق التجاري هنا جلي؛ فنموذج Full هو الدافع الرئيسي لدفع 50 دولاراً شهرياً، وتوفيره بتسعير مبني على الرموز سيعيق ذلك. ومع ذلك، وفرت Meta ثلاث نسخ برمجية مختلفة للواجهة، ووثقت تشغيل Claude Code وCodex على Wonder، وأتاحت Wonder على منصتي Vercel وCloudflare خلال أسبوع الإطلاق، ما يؤكد أن واجهة برمجة التطبيقات تحظى باهتمام بالغ. والمسار الأكثر ترجيحاً هو وصول Full إلى الواجهة فور ظهور النموذج التالي ليأخذ مكانه على قمة Muse Code. لذلك، صمم مسارات عملك الحالية بالاعتماد على Wonder، وأعد تقييم الخيارات عند تحديث صفحة النماذج.

دليل القرار في جدول واحد

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