أعلنت GitHub في 4 سبتمبر 2026 عن Project HydraFusion، وهو مشروع متاح كمعاينة بحثية داخل GitHub Copilot لتنسيق نماذج ذكاء اصطناعي من مزودين متعددين أثناء تنفيذ مهام البرمجة. وبدلاً من اختيار نموذج واحد مسبقاً، ينشئ HydraFusion خطة تنفيذ ويحدد ما إذا كانت المهمة تحتاج إلى حل مباشر، أو مراجعة مستقلة، أو تصعيد إلى نموذج أكثر قدرة.
تأتي الخطوة بعد ميزة Auto model selection التي أطلقتها GitHub في وقت سابق من العام لاختيار النموذج الأنسب لكل مهمة. لكن HydraFusion يوسع الفكرة من اختيار نموذج إلى بناء سير عمل كامل يوازن بين جودة النتيجة والتكلفة وزمن الاستجابة، بينما يظل التعقيد التشغيلي مخفياً عن المطور الذي يختار HydraFusion كما يختار أي نموذج آخر في Copilot.
ثلاثة مسارات لتنفيذ المهمة
يقيم النظام إشارات مرتبطة بالاستدلال وتوليد الشيفرة وتصحيح الأخطاء واستخدام الأدوات، ثم يختار واحداً من ثلاثة أنماط تنفيذ:
- Single: يتولى نموذج واحد حل المهمة مباشرة عندما تكون قدرته كافية.
- Cascade: يبدأ نموذج أكثر كفاءة بصياغة الحل، ثم تقرر بوابة جودة ما إذا كان سيُعتمد أو تُحال المهمة إلى نموذج أقوى.
- Critique: يصوغ نموذج حلاً أولياً، ثم يراجعه نموذج مستقل من عائلة مختلفة وفي سياق للقراءة فقط، قبل أن ينفذ النموذج الأول مراجعة واحدة للحل.
تقول GitHub إن الهدف من الانتقائية هو استخدام الاستدعاءات الإضافية فقط عندما يُتوقع أن تحسن النتيجة. وبذلك يحافظ المسار المباشر على السرعة والكفاءة، بينما يضيف المساران الآخران المراجعة أو التصعيد للمهام التي تستفيد منهما.
ما أظهرته الاختبارات
قيّمت GitHub سياسات ثابتة لـHydraFusion على ثلاثة اختبارات لوكلاء البرمجة: TerminalBench 2.1 وDeepSWE وCheckpointBench الداخلي المبني على جلسات حقيقية في GitHub Copilot. وقورنت النتائج بخطي أساس هما Claude Opus 5 وGPT-5.6 Sol، مع استخدام مدخلات وأدوات وحدود تنفيذ وافتراضات تسعير وظروف تقييم متطابقة.
في TerminalBench 2.1، حقق HydraFusion تحسناً قدره 4.9 نقاط مئوية في جودة المهام التي جرى التحقق منها، مع خفض التكلفة المقدرة لسير العمل بنسبة 67% مقارنة بـClaude Opus 5. وفي DeepSWE، الذي يركز على مهام هندسة برمجيات على مستوى المستودع وفهم الاعتماديات بين الملفات، اقترب النظام من Opus 5 بفارق 1.5 نقطة مئوية، مع تكلفة أقل بنسبة 36%. أما CheckpointBench، فكان الفارق في الجودة 0.1 نقطة مئوية فقط، مقابل خفض التكلفة بنسبة 65%.
وتشمل محاسبة التكلفة كل مراحل التنفيذ، بما في ذلك الصياغة والمراجعة والتعديل والتصعيد وإعادة المحاولة وخطط الرجوع. إلا أن GitHub تصف هذه النتائج بأنها اختبارات غير متصلة بالإنترنت، ومحددة بإصدارات الاختبارات وإعدادات سير العمل ومجموعة النماذج وافتراضات الأسعار المستخدمة.
ضوابط التشغيل وحدود المعاينة
صممت GitHub HydraFusion حول ضوابط تشمل تسجيل التكلفة والاستخدام لكل مرحلة، وتحديد مهلات الإلغاء والتنفيذ، وعزل خطوات المراجعة في سياقات لا تملك أدوات ولا تعدل المستودع. كما يتحقق النظام مسبقاً من تعريفات سير العمل وربط النماذج وسلوك البدائل وتوافر النماذج، ولا يطبق أي تصحيح إذا أُلغيت العملية أو فشلت عملية التحقق.
توصي GitHub حالياً ببدء التجربة بمهام برمجية كبيرة ومحددة جيداً، تُرسل في مطالبة واحدة إلى Copilot في وضع التشغيل التلقائي. وتركز الشركة لاحقاً على تحسين أداء الجلسات متعددة الأدوار والأطول زمناً. كما تنبه إلى أن النماذج وسير العمل والأسماء والتوافر وسلوك المنتج قد تتغير خلال فترة المعاينة.
القراءة التحريرية: التحول من اختيار النموذج إلى تصميم سير العمل
التغيير الأهم هنا ليس إضافة نموذج جديد، بل نقل قرار التنفيذ من المطور إلى طبقة تنسيق تقرر متى تكفي محاولة واحدة ومتى تستحق المهمة تكلفة المراجعة أو التصعيد. إذا انعكست نتائج الاختبارات على الاستخدام الفعلي، فقد يمنح ذلك المطورين جودة قريبة من النماذج الأقوى في بعض المهام دون دفع تكلفتها في كل طلب.
لكن الأرقام لا تثبت بعد تفوقاً عاماً في جميع أنماط البرمجة؛ فهي مرتبطة باختبارات محددة وسياسات مضبوطة ونتائج غير متصلة بالإنترنت. وتبقى أسئلة زمن الاستجابة والاعتمادية وسلوك النظام في الجلسات الطويلة وكفاءة التخزين المؤقت والسلامة مفتوحة، وهي جوانب قالت GitHub إنها ستقيسها خلال المعاينة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.