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

لقد وسّعت Google واجهة برمجة التطبيقات Gemini: الآن يمكن دمج الأدوات المدمجة مثل Google Search و Google Maps مع الدوال المخصصة في طلب واحد. يؤدي هذا إلى إزالة بعض التنسيق اليدوي حول سيناريوهات الوكيل وتقريب واجهة برمجة التطبيقات من تنسيق حيث ينسق النموذج البحث واستدعاءات الكود والانتقالات بين الخطوات بنفسه.

ما الذي تغير

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

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

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

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

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

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

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

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

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

ما الذي يعنيه هذا

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