MoEngage تتيح لوكلاء الذكاء الاصطناعي الوصول إلى 400 واجهة API مغلقة عبر AgentCore Gateway دون خوادم MCP خاصة بها

تطوّر شركة MoEngage منصة ترسل عبرها أكثر من 1350 علامة تجارية استهلاكية رسائل push والبريد الإلكتروني وSMS وWhatsApp وRCS المخصصة. وعندما بدأت الشركة العمل على وكلاء الذكاء الاصطناعي، تبيّن أن كل ما يلزم يعمل أصلاً: إنشاء الحملات، والاستعلام عن الشرائح، وإحصاءات التسليم. وهذه نحو 400 واجهة REST API داخلية، كتبتها 25 فريقاً، وتعمل داخل شبكات سحابية مغلقة (VPC) في سبع مناطق من AWS. ولا تُعرَض هذه الواجهات للإنترنت بسبب متطلبات تخزين البيانات داخل المنطقة. كانت المهمة السماح للوكلاء بالوصول إليها بأمان. والحل: بوابة مُدارة هي Amazon Bedrock AgentCore Gateway. وبحسب تقدير MoEngage، وفّرت البوابة نحو ستة أشهر من تطوير المنصة. وهذا تقدير داخلي من الشركة، ولم يتحقق منه أحد بشكل مستقل.

لماذا يُعدّ 20 خادم MCP فكرة سيئة

MCP (Model Context Protocol) معيار يعرف الوكيل بواسطته الأدوات المتاحة له ويستدعيها. والطريق البديهي أن تُنشئ كل فرقة خادم MCP خاصاً بها. وقد قدّرت MoEngage كلفة هذا المسار:

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

لذلك جاءت القاعدة هكذا: الفرق لا تكتب MCP. هي تبني واجهات REST API وتحدد العمليات التي تُعدّ أدوات. أما طبقة MCP كاملة فتديرها فرقة AI Platform. وتنتهي مسؤولية فرقة المنتج عند مواصفة OpenAPI مكتوبة جيداً.

وانطلاقاً من هذه القاعدة، صاغت الشركة أربعة شروط صارمة يجب أن تتحقق في وقت واحد:

• لا عناوين عامة: لا بوابات NAT ولا وكلاء (proxy) ولا VPN لكل عملية تكامل، وإلا تضاعف الأمر سبع مرات بعدد المناطق؛ • هوية الاستدعاء ليست قراراً للنموذج: لا يجوز أن تكون tenant والمستخدم والدور وسياق قاعدة البيانات معاملات يمكن للنموذج تغييرها خطأً، أو يمكن إقناعه بتغييرها؛ • يجب ألا يدخل كتالوج الأدوات الـ400 في السياق: فمع نحو 50 توكن لمخطط كل أداة، تتجاوز القائمة الكاملة 20 000 توكن عن كل اتصال؛ • الترشيح على جانب العميل لا يُعدّ حماية: فإذا سُلّم الكتالوج فعلاً، يكون الوكيل قد رأى ما لا ينبغي أن يراه.

كيف تحقق AgentCore Gateway هذه الشروط

تعمل البوابة بوصفها خادم MCP مُدارًا بالكامل. تسجّل مواصفات OpenAPI على أنها أهداف (targets)، فتولّد البوابة الأدوات بنفسها وتوجّه الاستدعاءات. وتحمل كل عملية اسماً بصيغة Target___operationId، مثل CampaignsAPI___searchCampaigns. إذا أُضيفت نقطة نهاية إلى المواصفة ظهرت الأداة، وإذا حُذفت اختفت. لا نشر ولا موافقات من فريق المنصة.

تُقيَّد الصلاحيات بسياسات مكتوبة بلغة Cedar. ويُصادَق على كل وكيل بدور IAM خاص به. ويختار محرك السياسات الأدوات قبل تكوين الرد على tools/list. فروبوت فحص الحملات، مثلاً، يحصل على مجموعة الأدوات campaigns-read ومنع صريح لمجموعة write-actions. وأدوات الكتابة غير موجودة في قائمته أصلاً: فهي لم تُرسَل إليه، ولم تُخفَ على جانب العميل.

وتتولى الاتصال عبر خروج مُدار (egress) عبر Amazon VPC Lattice. أما حركة الدخول فتمر فقط عبر نقطة نهاية واجهة VPC مع DNS خاص. ويضيف أي API جديد هدفاً في البوابة ولا يغيّر طوبولوجيا الشبكة. وتُضبط الشبكة مرة واحدة.

وثمة ثلاثة قرارات أخرى يستحق الأمر اقتباسها:

• SigV4 بدلاً من JWT: الوكلاء الداخليون هم أصلاً خدمات بأدوار IAM، فيوقّعون الطلبات بالمفاتيح الموجودة لديهم، ولا حاجة إلى إصدار أو تدوير أي شيء جديد. أما خادم MCP العام من MoEngage الموجّه للأشخاص عبر Claude وعملاء آخرين فيعمل بشكل منفصل على OIDC JWT؛ • الهوية في الترويسات: تحوّل مكتبة العميل كائن Identity صغيراً إلى ترويسات X-MOE-*، ولا يراها النموذج. ولأن SigV4 يشغل ترويسة Authorization، يُمرَّر bearer token الخاص بطرف آخر في ترويسة منفصلة ببادئة MoEngage؛ • البحث بدلاً من القائمة: يرى النموذج أداة وصفية واحدة هي search_tools. يصف الوكيل مهمته، فيعيد البحث الدلالي في البوابة مرشحين، ولا يصبح قابلاً للاستدعاء حتى نهاية الدور إلا هؤلاء. وإذا أُعيد تسمية get_segment_user_count إلى get_segment_size، فسيجده البحث بالمعنى رغم ذلك.

ربط API في ساعات وحصيلة ثلاثة أشهر في الإنتاج

تضيف الفرقة إلى مواصفتها كتلة x-moe-mcp. والكشف للخارج موافقة صريحة: لا كتلة يعني لا أداة، ولا يحذّر CI من ذلك. ولا يحتاج الوكلاء إلى تسخين ذاكرة التخزين المؤقت ولا إلى عمليات ترحيل. وتتيح العلامتان internal وexternal فتح العملية، كلٌّ على حدة، للوكلاء الداخليين أو لخادم MCP العام أو للطرفين معاً.

وثمة ملاحظة مستقلة: وصف API الموجّه للمطوّر لا يصلح وصفاً للأداة موجّهاً للنموذج. فعندما أدرجت MoEngage عبارة «Returns a paginated list» حرفياً، اختارت النماذج الأداة بحسب تفاصيل التنفيذ لا بحسب القصد. والآن توفر الحقلان tool_description وparam_overrides مساحة لنص مكتوب للنموذج، دون المساس بالوثائق الموجّهة للبشر. ويتولى CI الباقي: يتحقق من الكتلة، ويسجّل الهدف في البوابة، ويطبّق سياسة Cedar.

يعمل النظام اليوم في سبع مناطق ويخدم نحو 400 عملية لصالح 10 وكلاء داخليين. من بينهم وكيل فحص الحملات (قواعد الاستهداف والمحتوى قبل الإطلاق)، ووكيل سلامة التسليم (سرعة الإرسال وارتفاعات bounce بحسب القناة)، ومنشئ الشرائح (يحوّل وصف الجمهور بلغة طبيعية إلى استعلام). ولكل وكيل دوره ومجموعة أدواته. وتبدأ الوكلاء الجدد من دون أسماء أدوات مكتوبة بشكل صارم: تصف القصد، وتحصل على مرشحين، ثم تستدعي. وتُلتقط عمليات إعادة التسمية أو العمليات الجديدة دون تعديل الشيفرة. وبحسب الشركة، يستغرق ربط API جديد الآن ساعات بدلاً من أيام.

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