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

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

الاشتراك كبنية تحتية

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

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

يتم تقديمه هنا كانتقال من نافذة ذكية واحدة إلى فريق كامل من الوكلاء، حيث يتعامل البعض مع البحث والبعض مع الكود والبعض يتحقق من الحل المقترح.

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

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

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

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

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

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

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

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

ماذا يعني هذا

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