ما هو سجل MCP؟ ولماذا لا يمكنك تشغيل الوكلاء بدونه؟

إذا كنت قد جربت منتجات Anthropic Model Context Protocol (MCP)، فمن المحتمل أنك واجهت "جدار المضيف المحلي".

تقوم باستنساخ مستودع، وتشغل npx @modelcontextprotocol/server-postgres، وتربطه بـ Claude Desktop، وتشعر وكأنه سحر. يمكن لنموذج اللغة الكبير الخاص بك فجأة التحدث إلى قاعدة بياناتك. ولكن في اللحظة التي تحاول فيها نقل تلك البنية إلى بيئة الإنتاج -- حيث لديك خمسون وكيلاً، وعشرون مصدر بيانات، وأدوار IAM صارمة -- يتحول "السحر" إلى كابوس أنظمة موزعة.

أنت لا تحتاج فقط إلى بروتوكول. أنت بحاجة إلى دليل هاتف. أنت بحاجة إلى وسيط يعرف مكان وجود كل أداة، ومن يُسمح له باستدعائها، وما إذا كانت تعمل بشكل سليم حاليًا.

في هذا المجال، يترسخ هذا المفهوم بصفته MCP Registry.

في TrueFoundry، لا نتعامل مع السجل كمجرد قائمة ثابتة من عناوين URL. بل نطبقه كطبقة بنية تحتية نشطة للتوجيه باستخدام ما نسميه Virtual MCP Servers. إليك نظرة متعمقة على لماذا يُعد السجل المكون الأكثر أهمية الذي ربما تتجاهله.

المشكلة: مصفوفة الاتصال "N x M"

بدون سجل مركزي، تكون بنية النظام الوكيلي فوضى.

لنقل أن لديك ثلاثة وكلاء (الدعم، المبيعات، DevOps) وثلاث أدوات (Jira، Salesforce، AWS). إذا قمت بربطها مباشرة، سيتعين عليك ترميز نقاط النهاية والمصادقة بشكل ثابت لكل أداة في إعدادات كل وكيل.

إذا قام فريق DevOps بنقل أداة Jira إلى مجموعة جديدة، سيتعطل كل وكيل. وإذا قمت بتغيير مفتاح API الخاص بـ Salesforce، سيتعين عليك إعادة نشر كل وكيل.

الـ MCP Registry يحل هذه المشكلة عن طريق فصل الـ مستهلك (الوكيل) من الـ مزوّد (الأداة). يتصل الوكيل بالسجل، ويقوم السجل بتوجيه الطلب إلى الأداة الصحيحة.

إليك الفرق في الهيكل الطوبولوجي.

الشكل 1: سير عمل الاتصالات المباشرة مقابل طوبولوجيا السجل

نهج TrueFoundry: السجل "الافتراضي"

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

بدلاً من بناء قاعدة بيانات "كتالوج" منفصلة يتعين على الوكلاء الاستعلام عنها، قمنا ببناء السجل مباشرة في مسار الشبكة. تعمل بوابة TrueFoundry للذكاء الاصطناعي كخادم MCP "افتراضي" يجلس أمام خدمات الواجهة الخلفية الفعلية الخاصة بك.

كما هو موضح في وثائق TrueFoundry حول خوادم MCP الافتراضية:

"يجمع خادم MCP الافتراضي عدة خوادم MCP في خادم MCP واحد. وهذا يسمح لعميل MCP بالاتصال بنقطة نهاية واحدة والوصول إلى الأدوات/المطالبات/الموارد من عدة خوادم MCP."

هذا تحول دقيق ولكنه ضخم. بالنسبة لوكيلك، تبدو البوابة كخادم MCP عملاق واحد بقدرات لا حصر لها. خلف الكواليس، تقوم البوابة بتوجيه حركة المرور إلى حاوية postgres-mcp في المجموعة A وحاوية slack-mcp في المجموعة B.

قدرات السجل النشط

السجل المناسب لا يقتصر على سرد الأدوات فحسب، بل يدير دورة حياة التفاعل.

1. الاكتشاف الديناميكي

عندما يتصل وكيل ببوابة TrueFoundry، لا يحتاج إلى معرفة الأدوات الموجودة مسبقًا. يستخدم الاتصال أحداثًا مرسلة من الخادم (SSE). عند المصافحة، تفحص البوابة هوية الوكيل وتنشئ ديناميكيًا قائمة بالأدوات المسموح له برؤيتها.

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

2. المصادقة المركزية (الـ حارس البوابة)

هذا هو الجزء الذي يرضي أمن المعلومات. إذا قمت بتشغيل MCP الخام، يحتاج وكيلك إلى بيانات اعتماد قاعدة البيانات. وهذا أمر غير مقبول أمنيًا.

باستخدام نهج قائم على السجل، نستفيد من مصادقة وأمان البوابة. الوكيل يحتفظ فقط بمفتاح API الخاص بـ TrueFoundry. تحتفظ البوابة بالأسرار للخدمات النهائية الفعلية.

"تتحقق البوابة من مفتاح API الخاص بالعميل... ثم تقوم بتوجيه الطلب إلى خادم MCP الخلفي باستخدام رؤوس آمنة."

3. المراقبة والحوكمة

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

الجدول 1: مقارنة بين أنواع السجلات

التكامل: كيف يبدو في الكود

جمال هذا التجريد يكمن في مدى نظافة كود العميل. تتوقف عن القلق بشأن البنية التحتية.

كما هو مفصل في الدليل حول استخدام بوابة MCP في وكيل، ما عليك سوى توجيه عميل MCP الخاص بك إلى نقطة النهاية الافتراضية.

لماذا هذا مهم

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

إن إتاحتها بأمان لنماذج اللغة الكبيرة (LLM) هي مشكلة بنية تحتية، وليست مشكلة نمذجة. هذا أحد الأسباب التي تجعل MCP مقابل RAG مهم عند تصميم سير عمل وكلاء المؤسسات.

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

إنه يحول فوضى نصوص بايثون البرمجية المتشابكة إلى بنية مؤسسية قابلة للتركيب.

‍

‍