AWS تطلق نسخة المعاينة من Agent Registry: فهرس لوكلاء الذكاء الاصطناعي وأدواته للشركات

في 9 أبريل 2026 قدمت AWS خدمة AWS Agent Registry بحالة المعاينة (preview). وهي مكوّن من AgentCore يُفترض أن يجمع في مكان واحد وكلاء الذكاء الاصطناعي المؤسسيين والأدوات وخوادم MCP ومهارات الوكلاء (agent skills)، كي تتمكن الفرق من العثور عليها وإعادة استخدامها دون فوضى أو ازدواجية.

لماذا نحتاج إلى سجل؟

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

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

ما المتاح حاليًا

في نسخة المعاينة يخزّن السجل بيانات وصفية منظمة عن كل وكيل وأداة وخادم MCP ومهارة وكيل (agent skill) ومورد مخصص. ويمكن أن تتضمن السجلات اسم ناشرها، والبروتوكولات المدعومة، والإمكانات المتاحة، وطريقة الاستدعاء. وتعلن AWS أيضًا دعمًا أصليًا لمعياري MCP وA2A. يمكن إضافة البيانات يدويًا عبر وحدة التحكم (console) أو SDK أو API، أو الاكتفاء بتحديد نقطة وصول MCP أو A2A لتجلب الخدمة الوصف بنفسها. وهذا يتيح تحميل مشهد الوكلاء القائم في الفهرس بدلًا من البدء بقاعدة بيانات فارغة.

• تسجيل يدوي عبر وحدة التحكم وSDK وAPI
• استيراد تلقائي للبيانات الوصفية من نقاط وصول MCP وA2A
• الوصول إلى الفهرس عبر Console وAPI وMCP server
• بحث هجين: بالكلمات المفتاحية وبالمعنى
• وصول عبر OAuth لواجهات البحث الخاصة دون حسابات IAM

وتراهن AWS بشكل خاص على تسهيل العثور على المكوّنات الموجودة أصلًا. يجمع البحث في السجل بين المطابقة التقليدية بالكلمات المفتاحية (keyword matching) والمطابقة الدلالية للاستعلامات الطويلة بلغة طبيعية. ففي المثال الوارد في الإعلان، قد يعثر استعلام عن معالجة المدفوعات (payment processing) على أدوات موصوفة بأنها للفوترة (billing) أو إصدار الفواتير (invoicing)، حتى لو لم تتطابق الأسماء. والمنطق بسيط: يبحث المطوّر أولًا عمّا اعتُمد بالفعل داخل الشركة، ثم يكتب وكيلًا جديدًا من الصفر فقط عند الحاجة.

كيف تُدار الرقابة

الركيزة الثانية للخدمة هي الحوكمة (governance). تتيح AWS إدارة النشر والوصول عبر سياسات IAM: يستطيع المسؤولون أن يحدّدوا بشكل منفصل من يحق له تسجيل الوكلاء والأدوات، ومن يمكنه العثور عليها واستخدامها. يمر كل سجل بدورة حياة: يبدأ مسودة (draft)، ثم ينتقل إلى حالة بانتظار الموافقة (pending approval)، ولا يصبح مرئيًا لكامل المؤسسة إلا بعد اعتماده. كما تدعم الخدمة الإصدارات والسحب من الاستخدام، إضافة إلى بيانات وصفية مخصصة مثل الفريق المالك، وحالة الامتثال (compliance)، وبيئة النشر.

ويورد إعلان AWS أيضًا أولى الحالات المؤسسية. تستخدم شركة Zuora، التي نشرت بالفعل نحو 50 وكيلًا لفرق المبيعات (Sales) والمالية (Finance) والمنتج (Product) والمطورين (Developer)، هذا النهج لإنشاء فهرس مركزي وإعادة استخدام المكوّنات الجاهزة. أما Southwest Airlines فتركّز على نقطة أخرى: إذا لم تُرسَ قواعد موحدة للنشر والملكية منذ البداية، تتحول منظومة الوكلاء سريعًا إلى مجموعة خدمات متفرقة بلا رقابة. وهذه بالضبط هي الفجوة الإدارية التي يحاول Agent Registry سدّها.

ماذا يعني ذلك

يبدو أن AWS لا تبني مجرد خدمة ذكاء اصطناعي أخرى، بل طبقة بنية تحتية لمنظومة الوكلاء المؤسسية. وتتحدث الشركة منذ الآن عن الخطوة التالية: الفهرسة التلقائية للوكلاء عند النشر، واتحاد عدة سجلات (federation)، وفئات وتصنيفات (taxonomies) تلائم احتياجات الأعمال، وربط المقاييس التشغيلية من AgentCore Observability. وتتوفر نسخة المعاينة حاليًا في خمس مناطق فقط من AWS، لكن الاتجاه واضح: لا تحتاج الفرق المؤسسية إلى وسيلة لإنشاء الوكلاء فحسب، بل إلى سجل موحد يمكن فيه البحث عنهم وفحصهم واعتمادهم وسحبهم من الاستخدام وفق القواعد.