الفصل 2 — كشف بروتوكول سياق النموذج (MCP)

المقالة الثانية من الجولة الفصلية لـ LLM Primer IV: تصميم الإدراك الاصطناعي بـ MCP. حيث نَبني النموذج الذهني — ثلاثة أدوار، صيغة سلكية JSON-RPC، سطح اكتشافٍ ديناميكي، ودورة حياة جلسة — بقدرٍ كافٍ من العناية ليستطيع بقية الكتاب الوقوف عليه.

لماذا يوجد هذا الفصل

سمَّى الفصل 1 المشكلة. ويبني هذا الفصل النموذج الذهني للإجابة. يُمكن تلخيص MCP في جملةٍ وسوء فهمه في فقرة، فيأخذ الفصل وقته: ما هو البروتوكول على المستوى السلكي، ماذا تعني الأدوار الثلاثة وماذا يَملك كلٌّ منها، كيف يَختلف عن REST في الحالات المُهمَّة إنتاجياً، وماذا يحدث خلال جلسةٍ من الاتصال إلى التفكيك. الهدف أن تَستطيع بنهاية الفصل — قبل قراءة التالي — أن تتنبَّأ ماذا يجب أن تكون أوّلية الخادم، وماذا يجب أن تكون أوّلية العميل، ولماذا يَكتسب MCP البنية التي يَملك.

2.1 ما هو MCP وماذا يعني «USB-C للذكاء الاصطناعي» فعلاً

بروتوكول سياق النموذج مواصفةٌ مفتوحةٌ لكيف تَكتشف تطبيقات النماذج اللغوية القدرات الخارجية وتَصفها وتَستدعيها. على السلك هو JSON-RPC 2.0 فوق واحدٍ من حِفنة نقولٍ صغيرة. على المستوى المعماري هو العقد الذي يُتيح لمُضيفٍ أن يعمل مع أيِّ خادمٍ مُطابِق دون شيفرة تكاملٍ تفصيلية. أداةٌ بُنيت مرةً مقابل البروتوكول تَعمل مع كل مُضيفٍ ينطق به. ومُضيفٌ بُني مرةً مقابل البروتوكول يَستطيع استخدام كل أداةٍ تَنطق به.

اختصارٌ علقَ هو «USB-C للذكاء الاصطناعي». الشكل البنيوي يَعكس USB-C فعلاً — معيار اتصالٍ واحدٌ يَتوسَّط بين مجتمعٍ مفتوحٍ من الأجهزة ومجتمعٍ مفتوحٍ من المُضيفين. حدود الاستعارة جديرةٌ بالتسمية: يُقَنِّن USB-C موصِّلاً وكومةً فوقه؛ يُقَنِّن MCP البروتوكول فقط. يَجري USB-C على نطاقاتٍ زمنيةٍ كهربيةٍ مع تأطيرٍ مفروضٍ بالعتاد؛ يَجري MCP على نطاقاتٍ زمنيةٍ شبكيةٍ مع تأطيرٍ مُعرَّف برمجياً، ما يَعني أن MCP أكثر مرونةً وعليه أيضاً معالجة الاتصالات المُنقطعة والأقران البطيئة التي لا يُعالجها USB-C.

مقارنةٌ أقرب، للمهندسين، هي LSP. عَرَّف بروتوكول خادم اللغة بروتوكولاً يَستطيع أيُّ محرِّرٍ وأيُّ خادم لغةٍ نطقه؛ ويُعرِّف MCP واحداً يَستطيع أيُّ مُضيف نموذجٍ لغوي وأيُّ مُقدِّم قدرات نطقه. شكل الفوز متطابق — العديد إلى العديد مَطوياً ببروتوكولٍ مشترك إلى ما يَتمدَّد جمعياً. قرار بناء MCP على JSON-RPC 2.0 بدلاً من اختراع صيغةٍ سلكيةٍ جديدة كان متعمَّداً: JSON-RPC صغيرٌ ناضجٌ مُحايد اللغة وغير لامع. الاختيارات المعمارية المُثيرة ليست على المستوى السلكي. إنها في كيف يَقتسم المُضيف والعميل والخادم المسؤولية.

2.2 المُضيف والعميل والخادم — ماذا يَملك كلٌّ منها

يُعرِّف MCP ثلاثة أدوار، وأول ما يجب فهمه أن «العميل» و«الخادم» لا يَعنيان ما يَعنيانه في أماكن أخرى. يَعرض الخادم القدرات — أدوات، موارد، موجِّهات. والعميل اتصالٌ مفردٌ ناطقٌ بالبروتوكول لخادمٍ واحد، يُدار داخل تطبيقٍ أكبر. التطبيق الأكبر هو المُضيف. يَملك المُضيف النموذج وجلسة المستخدم والسياسة بشأن ما يُسمح للنموذج بفعله. والخوادم تَملك أسطح قدراتها. والعملاء أسلاكٌ بينهما، واحدٌ لكل خادم.

التقسيم يَهُمّ لأن لكل دورٍ مسؤوليةً مختلفةً ووضعية ثقةٍ مختلفة. المُضيف حدُّ الثقة المُهمّ من منظور المستخدم؛ وكل ما عداه شيءٌ قَرَّر المُضيف السماح به. مُضيفٌ يُكَلِّم خمسة خوادم لديه خمسة عملاء يَعملون داخله، كلٌّ بحالة جلسته وباشتراكاته ورؤيته لأيِّ القدرات تَفاوض عليها. إذا انهار خادم، ينهار العميل المُقابل؛ ويَستمرّ الباقون في العمل؛ ويَبقى المُضيف على قيد الحياة. العملاء عَزَلَة لكل اتصالٍ تَمنع خادماً سيئاً واحداً من تسميم الجلسة كلها.

وثمة حُجَّةٌ أمنية للتقسيم. كل خادمٍ، في حدِّه الأدنى، شيفرةٌ كتبها شخصٌ آخر. يَتوسَّط العميل كلَّ ما يَستطيع الخادم فعله مما يُؤثِّر في المُضيف — إشعارات، استنطاقات، طلبات معاينة، موارد منشورة — وهو حيث تَسكن السياسة لكل خادم. المُضيف والعميل والخادم أدوارٌ منطقية لا فيزيائيةٌ صارمة: في إعدادٍ محلي يكون الخادم عادةً عملية فرعية على stdio؛ في نشرٍ بعيد يكون خدمةً على نقلٍ قائمٍ على HTTP. لا يَكترث البروتوكول؛ تَكترث حدود الأدوار.

2.3 MCP مقابل REST — ماذا يَشتري لك الاكتشاف الديناميكي والأوصاف الدلالية

السؤال المعقول هو «أليس هذا مجرَّد REST؟». الفوارق ليست تجميلية. الأكثر تبعةً هي الاكتشاف الديناميكي، والأوصاف الدلالية المكتوبة لنموذجٍ لغوي، ونموذج الرسائل ثنائي الاتجاه.

يَنشر واجهةُ REST نقاطَ النهاية في توثيقٍ مكتوبٍ لمطوِّرين بشر. مجموعة نقاط النهاية التي يَستخدمها العميل ثابتةٌ وقت البناء؛ نقاط النهاية الجديدة تَتطلَّب إعادة نشر. يَقلب MCP هذا. عند بدء الجلسة، يَسأل العميل «ماذا تَعرض؟» ويُجيب الخادم بفهرسٍ مكتوبٍ — مخططات وأوصاف وبيانات وصفية — يَستخدمه المُضيف برمجياً. إذا أضاف الخادم لاحقاً أداةً، يُحدِّث إشعار listChanged العميلَ منتصف الجلسة دون إعادة تشغيل. الخادم هو المصدر الموثوق للحقيقة عن قدراته؛ ولا يَستطيع الوصف الانجراف عن التنفيذ لأنه لا توجد نسخةٌ منفصلةٌ على جانب العميل لتَنجرف عنها.

الأوصاف الدلالية هي الفارق الثاني. توثيق نقطة نهاية REST مكتوبٌ لمطوِّرٍ سيقرأ ويُقرِّر. وصف أداة MCP مكتوبٌ لنموذجٍ لغوي سيقرأه جزءاً من موجِّهه ويُقرِّر تلقائياً. وصفٌ يقول «POST إلى /users/:id/orders» لا فائدة منه لنموذجٍ لغوي، يَحتاج معرفة ما العملية المفهومية التي تَفعلها الأداة، ومتى يُفضَّل اختيارها، وما آثارها الجانبية، وماذا تَعني مدخلاتها بمصطلحات المجال. دُفع عمل ترجمة الواجهة إلى مصطلحاتٍ مقروءةٍ للنموذج اللغوي مرةً واحدةً، إلى الخادم، حيث يَستطيع الأقرب إلى القدرة الاحتفاظ به.

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

2.4 التفاوض على القدرات ودورة حياة الجلسة

تبدأ الجلسة حين يَفتح العميل نقلاً ويُرسل طلب initialize يَحمل نسخة بروتوكوله وقدراته. يُجيب الخادم بقدراته الخاصة — هل يَعرض أدواتٍ، هل يَعرض موارد، هل يُقدِّم اشتراكات، هل يَدعم خصائص متقدمة. يُؤكِّد العميل بإشعار initialized. تَنتقل الجلسة إلى الحالة التشغيلية، وأنواع الرسائل المُتاحة هي بالضبط الفرع الفرعي الذي اتَّفق عليه الطرفان.

هذا التفاوض هو ما يُتيح لعميلٍ وخادمٍ بمجموعتَي خصائص مختلفتَين أن يَتعايشا منتجاً. وهو أيضاً حيث يُعالَج الإصدار: يَختار الخادم النسخة الأعلى التي يَدعمها الطرفان. تشغيلياً، لدورة الحياة عواقب. التهيئة ليست مجانية — ثمة كلفة ذهابٍ-وإياب، وللخوادم البعيدة، إعداد اتصالٍ فوقها. الجلسات الطويلة العمر هي النمط المُفضَّل؛ تَتدفَّق تغيُّرات القدرة كإشعارات لا كإعادة اتصال. المُضيفون الذين يَحترمون هذا — يُبقون الجلسات دافئة، يُعيدون الاتصال خلفياً بعد انقطاعات الشبكة — يَحصلون على كَمونٍ أفضل مادياً. والمُضيفون الذين يَفكِّكون ويُعيدون التهيئة لكل طلبٍ يَعملون صحيحاً لكن بكفاءةٍ متدنية.

عدم تماثلٍ يجدر تثبيته: للطلبات إجابات؛ وللإشعارات لا. أحداث list-changed إشعارات، فالعميل الذي يُفوِّت واحداً عليه أن يكون مستعداً لتحديث رؤيته بإعادة استدعاء list_tools. الإشعار تحسينٌ لا ضمان. شيفرة MCP المتينة تعامله تلميحاً، لا سجلاً.

ما يُمهِّد له الفصل 2

لديك الآن النموذج الذهني. MCP بروتوكول JSON-RPC بثلاثة أدوار، اكتشافٌ ديناميكي يَجعل الخادم موثوقاً لقدراته الخاصة، أوصافٌ مكتوبةٌ لجمهور نموذجٍ لغوي، نموذج رسائل ثنائي الاتجاه بإشعاراتٍ وطلباتٍ يَبدأها الخادم، ودورة حياةٍ تَفتتح بتفاوضٍ صريحٍ على القدرات وتَعمل داخل أيِّ فرعٍ فرعي يَتَّفق عليه الطرفان. هذا سَقَّالة كافية للحديث محدَّداً عن ما يَعرضه كلٌّ من الخوادم والعملاء، وهو ما يَفعله الفصلان التاليان.

التالي — الفصل 3: أوّليات الخادم — الموارد والموجِّهات والأدوات. الأسماء الثلاثة التي يَستطيع الخادم تقديمها، لماذا تَهُمّ كلٌّ منها، وانضباط اختيار الأوّلية الصحيحة بدلاً من تحميل واحدةٍ على أرض الأخرى.