Amazon Bedrock AgentCore Runtime يدعم الآن وكلاء MCP بلا خوادم

نشرت Amazon Web Services دليلاً مفصلاً لنشر وكلاء MCP مخصصين في Amazon Bedrock AgentCore Runtime. يتيح هذا النهج للشركات إضافة طبقة إدارة قابلة للبرمجة بين وكلاء الذكاء الاصطناعي والأدوات الخارجية، دون الحاجة إلى إنشاء بنية تحتية خاصة بها وصيانتها.

لماذا أصبح الوكيل ضرورياً

أصبح Model Context Protocol المعيار الرئيسي لربط وكلاء الذكاء الاصطناعي بالأنظمة الخارجية. فعبره يصل الوكلاء إلى أنظمة الملفات وقواعد البيانات وواجهات API المؤسسية وخدمات المراقبة وآلاف الأدوات الأخرى.

تكمن المشكلة في أن اتصال الوكيل المباشر بخادم MCP يشكّل نقطة عمياء أمنياً. فحين يتعامل الوكيل مع الأداة مباشرة، لا تملك المؤسسة:

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

هذا مقبول في المشاريع التجريبية، لكنه غير مقبول في عمليات النشر الإنتاجية داخل بيئة خاضعة للتنظيم.

يسدّ وكيل MCP هذه الفجوة. فهو يعترض جميع الاستدعاءات بين الوكيل والأدوات، ما يتيح تطبيق أي منطق عمل: مصادقة الطلبات، وتدقيق الاستدعاءات، وإخفاء بيانات PII، وتحديد معدل الطلبات (rate-limiting) بحسب الأدوار والفرق. ولا يعلم الوكيل بوجود الوكيل الوسيط، إذ تبقى واجهته MCP قياسية.

Amazon Bedrock AgentCore Runtime

يُعد AgentCore Runtime بيئة تشغيل مُدارة ضمن Amazon Bedrock، صُممت خصيصاً لأحمال عمل وكلاء الذكاء الاصطناعي. وعلى خلاف الخدمات العامة مثل Lambda أو ECS، يفهم AgentCore دورة حياة جلسات الوكلاء، ويستطيع إدارة السياق، ويوفر أدوات observability مباشرة ضمن منظومة AWS.

يضيف تشغيل وكيل MCP على AgentCore Runtime ما يلي:

• التوسع بنمط Serverless — يتوسع الوكيل تلقائياً بحسب الحمل، ولا حاجة إلى خوادم
• التكامل مع AWS IAM — إدارة صلاحيات الوصول عبر سياسات قياسية دون كود مخصص
• CloudWatch Logs وMetrics — سجلات ومقاييس مركزية جاهزة للاستخدام
• AWS X-Ray — تتبع موزّع (distributed tracing) لتشخيص سلاسل استدعاءات الوكلاء
• التكامل مع VPC — عزل الوكيل داخل الشبكة الخاصة بالمؤسسة

وبالنسبة لفرق المؤسسات، يعني هذا أن حزمة الامتثال الكاملة في AWS (التدقيق والتشفير وإدارة المفاتيح) تُطبَّق تلقائياً على تفاعل الوكلاء مع الأدوات.

كيف يعمل

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

«يوفّر هذا طبقة قابلة للبرمجة لتنفيذ حوكمة وضوابط وقابلية مراقبة سليمة، متوافقة مع سياسات الأمان في المؤسسة» — مدونة AWS

Machine Learning.

تتمثل الميزة المعمارية الأساسية في المركزية. فبدلاً من تضمين منطق الأمان في كل وكيل أو كل تطبيق على حدة، تضبط المؤسسة وكيلاً موحداً لكل وحدة أعمال أو للمؤسسة بأكملها. ويسري أي تغيير في السياسة فوراً على جميع الوكلاء العاملين عبره.

ماذا يعني ذلك

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

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