Google AI Ultra: كيف تحوّل الاشتراك إلى مجموعة وكلاء متوازين وإجماع بين النماذج

يمكن النظر إلى Google AI Ultra لا بوصفه اشتراكًا مكلفًا في Gemini، بل بوصفه أساسًا لبيئة متعددة الوكلاء خاصة بالمستخدم. الفكرة هي توزيع المهام الروتينية على عمّال يعملون في الخلفية، واستخدام الوكيل الرئيسي منسّقًا ومراجعًا للقرارات.

الاشتراك بوصفه بنية تحتية

الفكرة الأساسية في هذا العرض بسيطة: سعر Ultra يبدو مرتفعًا، لكن يمكن تعويضه ليس بعدد المحادثات، بل بهندسة العمل نفسها. فبدلًا من حصر نموذج واحد في إعادة هيكلة لا تنتهي، يُقترح الجمع بين Antigravity IDE، وClaude بدور الوكيل الرئيسي، وGemini CLI بدور مجموعة منفّذين شبه غير محدودة. وإذا استُنفد الحد اليومي لنموذج واحد، فلا ينهار السيناريو: يتحول المنسّق إلى نموذج آخر، وتواصل المهام الخلفية تنفيذها بشكل منفصل.

يعالج هذا النهج مشكلتين في آن واحد. الأولى كلفة الرموز (tokens) في سيناريوهات API التقليدية، حيث يستهلك كل وكيل مساعد جزءًا من الميزانية. والثانية عنق الزجاجة في جلسة IDE الواحدة: فحتى لو كانت البيئة قادرة على استدعاء وكلاء فرعيين، يصعب التحكم في ذلك وتحديد الأدوار وبناء عمليات قابلة للتكرار. ويُقدَّم الحل هنا على أنه انتقال من نافذة ذكية واحدة إلى فريق وكلاء متكامل، يتولى بعضه البحث، وبعضه كتابة الشيفرة، وبعضه فحص الحل المقترح.

كيف تعمل المجموعة

لهذا الغرض يُقترح خادم MCP خاص هو Agent-Pool-MCP. يعمل الخادم وفق نموذج pull: لا تنتظر الجلسة الرئيسية انتهاء المنفّذ الخلفي من مهمته، بل تحصل على task_id وتواصل عملها. وقبل أي تعديل معقد، يمكن أولًا إرسال مهمة بحث بوضع readonly، ثم سؤال نموذج ثانٍ بشكل منفصل عبر consult_peer، وبعد ذلك فقط يبدأ إعادة الهيكلة. أي أنه بدلًا من السيناريو الخطي «فكّر، نفّذ، تحقّق» ينشأ خط إنتاج تسير مراحله المختلفة بالتوازي ولا يعطّل بعضها بعضًا.

• يحدد وكيل IDE الرئيسي المهام ويجمع النتائج
• ينفّذ عمّال الخلفية على Gemini CLI التحليل والكتابة البرمجية والفحوصات
• يوفّر consult_peer رأيًا ثانيًا من نموذج آخر قبل تعديل الشيفرة
• يوزّع المجلد المشترك `.agent/delegation/` المخرجات بين الوكلاء
• تحدد skills وworkflows الأدوار وقوائم التحقق والمسارات النموذجية

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

لا أحد يلمس ملفات الآخر.

الإجماع والتحكم

أكثر الأجزاء إثارة للاهتمام هو الإجماع بين النماذج المختلفة. فبما أن مجموعة العمّال مبنية على Gemini CLI، يُسند دور وكيل IDE الرئيسي إلى نموذج آخر، بحيث يكون ما يُحصَّل تحققًا فعليًا من الفكرة من الخارج لا اتساقًا ذاتيًا. في المثال، يقترح Claude حلًا معماريًا، بينما يبحث Gemini عن النقاط العمياء ويعيد حكمًا مثل AGREE أو SUGGEST_CHANGES قبل أن يغيّر أي أحد قاعدة الشيفرة. ويُبنى فوق ذلك تنسيق كسوري (fractal orchestration)، إذ يمكن للمنسّق أن يولّد فرقًا جديدة وفرقًا فرعية متداخلة، تقريبًا كما يفعل قادة الفرق والمطورون في أي هيكل هندسي معتاد.

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

والتركيز الأخير على الأمان: ينبغي اعتبار أي خادم MCP نقطة محتملة لحقن الأوامر (prompt injection)، وتثبيت الإصدارات، وتقييد الوصول إلى نظام الملفات، وعدم تمرير الأسرار في الأوامر النصية (prompts).

ماذا يعني ذلك

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