غوغل تتيح لـ Gemini API الجمع بين Search وMaps ووظائفها المخصصة في طلب واحد

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

ما الذي تغيّر

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

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

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

كيف يعمل الاستدعاء

الفكرة الأساسية أن Gemini باتت قادرة على أن تقرّر في مسار واحد متى تحتاج إلى بحث على الويب، ومتى إلى بيانات جغرافية من Maps، ومتى إلى وظيفة مخصصة في التطبيق. وإذا تطلّب السؤال عدة إجراءات، يستطيع النموذج الاحتفاظ بسياق مشترك ومقارنة نتائج الأدوات المختلفة ومواصلة السلسلة دون إعادة تشغيل السيناريو بالكامل.

وهناك تركيز خاص على parallel tool IDs وcontext circulation: فهما يساعدان على عدم الخلط بين ردود الأدوات ونقل البيانات اللازمة إلى الخطوة التالية.

• Google Search يجلب أحدث المعلومات حول موضوع الطلب
• Google Maps يضيف العناوين والسياق الجغرافي وبيانات الأماكن
• Custom functions تربط منطق الأعمال الداخلي للتطبيق
• Multi-step chains تتيح بناء سيناريوهات من عدة إجراءات متتابعة

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

لماذا يهم المطورين

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

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

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

ماذا يعني ذلك

تدفع غوغل Gemini API نحو واجهات وكيلية متكاملة، لا يكتفي فيها النموذج بتوليد النص، بل يدير مجموعة من الأدوات ضمن جلسة واحدة. وإذا أثبتت هذه الآلية استقرارها في سيناريوهات الإنتاج الفعلية، فسيتمكن المطورون من بناء مساعدات AI مفيدة بقدر أقل من التنسيق اليدوي، وإطلاقها في المنتج بوتيرة أسرع.