Agentgateway يجمع حركة LLM وMCP وA2A في وكيل مفتوح المصدر واحد

نشر إيفان، مهندس الأنظمة في RED Security، على Habr تحليلًا لـ Agentgateway، وهو بوابة مفتوحة المصدر يمكن أن تمرّ عبرها ثلاثة أنواع من حركة الذكاء الاصطناعي في آن واحد: طلبات النماذج اللغوية، واستدعاءات الأدوات عبر MCP، وتواصل الوكلاء فيما بينهم عبر A2A. الفكرة مفهومة لكل من رأى كيف ينتشر الذكاء الاصطناعي داخل الشركة بلا ضابط: فبدلًا من عشرات الاتصالات المباشرة التي توضع مفاتيحها في الشيفرة ولا يجمعها سجل واحد، تظهر نقطة واحدة قابلة للإدارة.

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

ما المشكلة التي تعالجها البوابة

حين تربط الفرق نماذج LLM واحدًا تلو الآخر، يبدو كل شيء بلا مخاطر. خدمة تتصل بـ OpenAI، وأخرى بـ Anthropic، وثالثة بـ Gemini. ثم تظهر وكلاء تستدعي واجهات API داخلية عبر خوادم MCP وعبر بعضها بعضًا. ولكل اتصال مفاتيحه وحدوده وسجلاته الخاصة. أو لا يملك شيئًا من ذلك أصلًا.

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

ما المعروف عن المشروع نفسه

أنشأت شركة Solo.io مشروع Agentgateway، ثم نُقل المشروع إلى Linux Foundation. هذا مهم لمن يخشى الارتهان لمورّد واحد: فالشيفرة مفتوحة، والإشراف عليها لا يقتصر على شركة واحدة. النواة مكتوبة بلغة Rust، وهذا يعني عادةً استهلاكًا قليلًا للذاكرة وزمن استجابة متوقعًا على المسار الساخن.

أبرز الإمكانات بحسب الوثائق:

• ثلاثة أنواع من الحركة في وكيل واحد: طلبات LLM وMCP وA2A؛
• التوجيه إلى عدة مزوّدي نماذج، بما فيها المنصات السحابية وواجهات API المتوافقة مع OpenAI؛
• المصادقة وسياسات الوصول، ومنها السياسات المبنية على JWT وتعبيرات CEL؛
• حدود الاستخدام ومحاسبة الاستهلاك المرتبطة بالتوكنات، لا بعدد الطلبات فحسب؛
• مرشحات حماية للمطالبات (prompts) والردود؛
• المقاييس والتتبع عبر OpenTelemetry؛
• التكامل مع Kubernetes Gateway API، وواجهة مدمجة لتصحيح الأخطاء.

أين المأخذ

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

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

من أين تبدأ في التطبيق

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

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