Google Just Put 200+ Models, Including Claude, Inside One Agent Platform. Single-Model Lock-In Is Over.

قبل عامين، كان شراء "منصة ذكاء اصطناعي للمؤسسات" يعني اختيار نموذج لمورد واحد والبناء خلف واجهة برمجة التطبيقات (API) الخاصة به. وكان الرهان الذي اتخذته في اليوم الأول هو الرهان الذي تظل ملتزماً به. لقد انهار هذا التعريف للتو. فشركة Google، ثالث أكبر مزود للخدمات السحابية في العالم، تقدم الآن منصة وكلاء تشتمل على أكثر من 200 نموذج متوفرة بشكل مباشر، كما يتواجد أحد النماذج الرائدة للمنافسين مباشرة في نفس الكتالوج بجانب نموذجها الخاص. ولم يعد حيادية النموذج موقفاً مخالفاً للرأي السائد، بل أصبح هو المنتج ذاته.

وقد تجلى هذا التحول في مؤتمر Google Cloud Next 2026، الذي عُقد في الفترة من 22 إلى 24 أبريل في فندق ماندالاي باي في لاس فيغاس، حيث أعلنت Google عن 260 منتجاً عبر ثلاثة كلمات رئيسية أمام حوالي 32 ألف شخص من الحاضرين. ولم يكن العنوان الرئيسي للمشترين من المؤسسات نموذجاً أكبر، بل كان طرحاً أكبر حول البنية الهندسية.

ما الذي قامت Google بدمجه فعلياً

قامت Google بدمج Vertex AI في عرض موحد يسمى Gemini Enterprise Agent Platform. ووفقاً لـ إعلان Google الخاص، فإن "جميع خدمات Vertex AI وتطورات خارطة الطريق سيتم تقديمها حصرياً من خلال منصة الوكلاء (Agent Platform)، بدلاً من كونها خدمة مستقلة." لقد انتهت واجهة برمجة التطبيقات المستقلة للنموذج، ويمر كل شيء الآن عبر طبقة الوكيل.

تمنح المنصة المطورين وصولاً من الدرجة الأولى إلى أكثر من 200 نموذج من خلال Model Garden. وتغطي هذه القائمة عائلات Gemini وGemma الخاصة بـ Google، والنماذج المفتوحة مثل Llama، ونماذج الجهات الخارجية الرائدة. وتذكر Google بوضوح أن العملاء يحصلون على "الدعم لنماذج الجهات الخارجية مثل Claude Opus وSonnet وHaiku من Anthropic." إذ تعمل عائلة Claude من Anthropic بشكل أصلي داخل نفس الكتالوج مثل Gemini، وتتم محاسبتها وإدارتها كواجهة برمجة تطبيقات بدون خادم (serverless API) دون الحاجة إلى توفير بنية تحتية منفصلة.

إليكم مقارنة قبل وبعد، بعبارات بسيطة.

تُعد العناصر المحيطة بالنماذج بنفس أهمية عددها. فهناك خادم MCP عن بعد مدار، متوفر الآن بشكل عام، بحيث يمكن للوكلاء الوصول إلى الأدوات والبيانات الخارجية دون الحاجة إلى تمديدات مخصصة. وهناك وكيل لتصفح الويب، Project Mariner، يعمل في بيئات سحابية معزولة (sandboxes). وهناك بروتوكول Agent2Agent، الذي تصفه Google وشركاؤها بأنه يعمل في بيئة الإنتاج الفعلي وليس كمشروع تجريبي، حيث تقوم 150 مؤسسة بتوجيه المهام الحقيقية بين وكلاء مبنيين على منصات مختلفة. (لقد قمنا بتغطية A2A وMCP بالتفصيل بشكل منفصل؛ والنقطة المستهدفة هنا أضيق من ذلك.)

النقطة المستهدفة هنا هي ما يوضحه هذا الكتالوج بشأن الإستراتيجية.

لماذا يعد وضع Claude في كتالوج Google هو المؤشر الحقيقي

إن قيام مورد سحابي بتقديم نموذج رائد لجهة خارجية داخل منصة الوكلاء المميزة لديه ليس مجرد ملاحظة هامشية. إنه اعتراف بكيفية قيام المؤسسات بالشراء فعلياً.

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

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

ويجدر بنا أن نكون دقيقين بشأن سبب كون هذا خطوة تراجعية وليس مجرد كرم. تتقاضى Google رسوماً مقابل استخدام Claude بنفس الطريقة التي تتقاضى بها رسوماً مقابل Gemini، لذا هناك منطق يتعلق بالإيرادات من استضافة نموذج منافس. لكن السبب الأعمق هو الحفاظ على العملاء. فالمؤسسة التي يتعين عليها مغادرة Google Cloud لتشغيل Claude هي مؤسسة قد تستمر في المغادرة وتتخلى عن كل الخدمات الأخرى أيضاً. إن الاحتفاظ بالنموذج المنافس داخل المنصة يحافظ على العميل داخل المنصة. وهذا لا يبدو منطقياً إلا إذا كان العميل سيطلب النموذج المنافس في كل الأحوال، وهو جوهر الموضوع.

ماذا يعني هذا إذا كنت تستخدم Vertex AI بالفعل

إذا كان فريقك قد بنى نظامه بالاعتماد على Vertex AI، فإن أول شيء يجب معرفته هو أنه لن يتم إيقافه، بل سيتم استيعابه ودمجه. وتوضح لغة Google أن خدمات Vertex مستمرة، ويتم تقديمها من خلال منصة الوكلاء (Agent Platform) بدلاً من كونها منتجاً منفصلاً. ولن تتوقف اتصالات النماذج الحالية لديك عن العمل بين عشية وضحاها.

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

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

الأرقام الكامنة وراء هذه الخطوة

يوضح سياق السوق سبب إعادة تنظيم Google لكامل بنيتها للذكاء الاصطناعي حول الوكلاء بدلاً من المحادثة (chat). حيث تتوقع Gartner أن تشتمل 40% من تطبيقات المؤسسات على وكلاء ذكاء اصطناعي مخصصين لمهام محددة بحلول نهاية عام 2026، ارتفاعاً من أقل من 5% في عام 2025. وتلك قفزة تعادل ثمانية أضعاف في غضون عام تقريباً، ويتم بناء المنصات حول اتجاه الطلب المستقبلي، وليس مكانه الحالي.

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

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

ما الذي يغيره هذا في طريقة شرائك

لقد انقلبت حسابات قيود الاحتجاز والارتباط بمورد واحد. فقبل عام، كان توحيد المعايير على نموذج واحد يبدو خطوة منظمة ومنضبطة. أما الآن فيبدو كأنه مخاطرة، لأن ريادة التكنولوجيا تتغير كل بضعة أشهر، والمورد الذي وحدت معاييرك عليه قد لا يتصدر الرهان القادم. فشركات Anthropic وOpenAI وGoogle تتبادل الصدارة بشكل متكرر، لدرجة أن المراهنة بكامل البنية التحتية لديك على أحدها هو رهان ضد مرونتك وخياراتك المستقلة.

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

طبقة التوجيه، في مثال ملموس واحد

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

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

ثلاثة نقاط جوهرية للأشخاص الذين يوقعون العقود:

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

• تعامل مع دعم النماذج من جهات خارجية كمتطلب أساسي. عندما تقدم Google نموذج Claude داخل منصتها الخاصة، فإن عبارة "نحن ندعم موردين متعددين" تتوقف عن كونها ميزة تنافسية وتصبح هي الحد الأدنى المقبول.

• أعطِ وزناً كبيراً لإمكانية التشغيل البيني في عملية التقييم. أصبحت بروتوكولات التواصل بين الوكلاء الجاهزة للإنتاج الفعلي تُقدم الآن من قِبل أكبر الموردين. قم بالشراء والتعاقد تطلعاً لعالم تتحدث فيه وكلاؤك مع أنظمة لا تملك سلطة السيطرة عليها.

هذا هو الإجماع السائد الآن، وليس رأياً مخالفاً للتيار

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

عندما بدأنا في طرح هذا الرأي، كان يبدو كوسيلة للتحوط ضد مخاطر الارتباط بمورد واحد. ولكن بعد مؤتمر Google Cloud Next 2026، أصبح هذا هو الاتجاه الذي يتحرك فيه السوق بأكمله. حيث قام أحد أكبر موردي الخدمات السحابية للتو بجعل تعدد النماذج وإمكانية التشغيل البيني بين الوكلاء هو الوضع الافتراضي لمنصة الوكلاء الرائدة لديه. لقد حُسم النقاش إلى حد كبير حول ما إذا كان ينبغي للمؤسسات الارتباط بنموذج واحد. وأصبحت الأسئلة المثيرة للاهتمام الآن تدور حول كيفية التوجيه والحوكمة والتنسيق بين نماذج متعددة ومتنوعة.

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