تطرح Google Antigravity ميزة Orchestrator للتبديل الديناميكي بين النماذج

قالت Google Antigravity في 12 نوفمبر 2026 إن Orchestrator، وهو خيار في القائمة المنسدلة للنماذج يُطرح لمشتركي Google AI Ultra، حقق معدل نجاح في المهام يقترب من مستوى Carbon على Terminal-Bench 4.1، مع خفض استهلاك الحصة بنسبة 24% في المتوسط وإنجاز المهام بسرعة أكبر بنسبة 19%، وذلك عبر التبديل الديناميكي بين Gemini 4 Carbon وGemini 4 Hydrogen ضمن جلسة واحدة.

يُطرح نموذج Hydrogen الجديد بصورة منفصلة في Antigravity للمشتركين المدفوعين في Google AI Pro وUltra، بينما تستطيع المؤسسات الوصول إلى النموذجين عبر Gemini for business. وتقول Google إن Orchestrator سيدعم نماذج وخطط اشتراك إضافية مستقبلًا، وتصف Hydrogen بأنه نظير Carbon وArgon في التنفيذ السريع، في مقابل الاستدلال الأعمق والأطول أمدًا الذي يقدمانه.

التبديل الديناميكي بين النماذج خلال جلسة واحدة

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

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

تحديد أدوار النماذج صراحةً عبر SDK

يمكن للمطورين الذين يريدون إسناد المهام صراحةً بدلًا من التبديل التلقائي ربط Hydrogen وCarbon عبر Antigravity SDK. ويمنحهم ذلك تحكمًا برمجيًا في النموذج الذي يتولى كل دور ضمن سير عمل متعدد الوكلاء.

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

كيف يختلف Orchestrator عن /Swarm

يأتي Orchestrator بعد المعاينة التي أُتيحت في 10 نوفمبر 2026 لكل من Gemini 4 Carbon و/swarm، والتي استهدفت أعمالًا هندسية موزعة على ملفات كثيرة ومجموعات اختبارات متعددة. ووفقًا لـوثائق /swarm، يستطيع المنسق توزيع المهمة على عاملين محددي الأسماء، يتولى كل منهم ملفات أو حزمًا أو أسئلة منفصلة، فيما يراجع المدققون الفروق ويشغّلون الاختبارات؛ كما يمكن تزويد العاملين بنسخ عمل معزولة من المستودع. أما Orchestrator، فيعالج بنية مختلفة: إذ يغيّر النموذج المستخدم خلال جلسة واحدة متطورة، بدلًا من إنشاء فريق يعمل بالتوازي على أجزاء مستقلة.

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