AWS تختصر ربط مجموعة بيانات جديدة بخادم MCP إلى ملف JSON واحد

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

وصف الفريق المسؤول عن شبكة مراكز الفرز التابعة لأمازون في أميركا الشمالية نهجا مختلفا: خادم MCP مشترك بين الوكلاء وبحيرة بيانات الشركة. يعمل الخادم على Amazon ECS Fargate، ويوفر نقطة النهاية القياسية /mcp، ويربط Athena وRedshift وBedrock Knowledge Bases باعتبارها أدوات قابلة للاكتشاف. أما الوعد العملي الأهم فهو أن إضافة مجموعة بيانات جديدة لا تتطلب موصلا جديدا، بل ملف JSON واحدا يحتوي على البيانات الوصفية.

كيف يحل ملف واحد محل تكامل مستقل

لنفترض وجود جدول للطلبات. يحدد ملف JSON قاعدة البيانات واسم الجدول والغرض من البيانات وأنواع الأعمدة وأوصافها ومعدل التحديث وأمثلة لقيم حقيقية. وتفيد الأمثلة خصوصا في تمكين الوكيل من إدراك أن معرف المستودع يأتي بصيغة مثل FC-EAST-07، وليس اسما اعتباطيا لمنطقة. ويمكن أيضا حفظ إرشادات خاصة بمحرك SQL، مثل كيفية مقارنة تاريخ مخزن كسلسلة نصية بعمود من نوع timestamp.

بعد المزامنة، يصبح الملف جزءا من كتالوج البحث في Bedrock Knowledge Bases. وعندما يسأل المستخدم عن أغلى عشرة طلبات خلال الشهر الماضي، يعثر الوكيل أولا على الجدول المناسب ووصفه، ثم ينشئ SQL ويتحقق من توافقه مع Athena، ولا ينفذ الاستعلام إلا بعد ذلك. ووفقا للمؤلفين، استغرقت الدورة الكاملة من 15 إلى 20 ثانية.

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

أين يوجد التحكم في الوصول

يستضاف خادم MCP في شبكة فرعية خاصة خلف موازن تحميل داخلي. وتمر طبقة العميل العامة عبر AWS WAF وCognito، بينما تحفظ حالة المحادثة في DynamoDB. ولا تقبل أدوات Athena سوى استعلامات SELECT، وتسجل استدعاءاتها في CloudWatch. وتطبق Bedrock Guardrails على التفاعلات مع النموذج، وتساعد على تصفية المحتوى الضار والتحقق من استناد الإجابة إلى المصادر ومنع بعض الهجمات التي تمرر تعليمات من خلال البيانات.

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

ما الذي ينبغي نقله إلى بنيتك الخاصة

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

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