تم إطلاق بروتوكول سياق النموذج (Model Context Protocol - MCP) كمعيار ملموس لتحويل النماذج اللغوية الكبيرة (LLMs) إلى وكلاء (agents) يمكنهم استدعاء أدوات خارجية في حلقة قابلة للقياس وآمنة. ومن خلال تحديد "قابس" مشترك بين أي مضيف يدعم MCP وأي خادم MCP، يتيح البروتوكول للمطورين استبدال الأكواد البرمجية المخصصة (ad-hoc) بسير عمل يمكن التنبؤ به وتدقيقه.

لماذا تحتاج النماذج اللغوية الكبيرة (LLMs) إلى بروتوكول

يقوم النموذج اللغوي الكبير فقط بالتنبؤ بالرمز (token) التالي من النص بناءً على بيانات التدريب الخاصة به. ولا يمكنه جلب حقائق جديدة، أو الكتابة في قاعدة بيانات، أو تشغيل واجهة برمجة تطبيقات (API) خارجية دون منطق إضافي. وقد قام المطورون ببناء "وكلاء" يحيطون بالنموذج في حلقة: يطلب النموذج أداة، فتعمل الأداة، ثم يتم تغذية النتيجة مرة أخرى، ويقرر النموذج ما إذا كان سيستمر أو يجيب المستخدم.

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

يسد MCP هذه الفجوات من خلال تقنين هيكل الحلقة والبيانات التي يجب أن تمر من خلالها.

التشريح المكون من جزأين لوكيل MCP

يفصل MCP الوكيل إلى تعريف (definition) – وهو القالب الذي يصف ما يمكن للوكيل القيام به – ونسخة (instance) – وهي التنفيذ الملموس لطلب المستخدم.

تعريف الوكيل (القالب)

  • حلقة المضيف (Host loop) – المنسق الذي يقود دورة (اطلب-الأداة-اقرأ-قرر).
  • سياق النظام (System context) – الشخصية والتعليمات عالية المستوى التي تشكل سلوك النموذج.
  • مجموعة خوادم MCP – كتالوج لمصادر الأدوات المتاحة التي قد يستدعيها المضيف.
  • سياسة الأدوات (Tool policy) – قائمة صريحة بالأدوات المسموح بها لوكيل معين.
  • اختيار النموذج اللغوي الكبير (LLM selection) – النموذج المحدد الذي سيقوم بتوليد الاستنتاج النصي.
  • حدود الإنهاء (Termination limits) – الحد الأقصى لعدد التكرارات وميزانية الرموز (tokens) لمنع الحلقات اللانهائية.
  • عقد المهمة (Task contract) – وصف رسمي للمدخلات التي يقبلها الوكيل وتنسيق المخرجات التي يعيدها.
  • استراتيجية السياق (Context strategy) – قواعد لكيفية تقليم أو تلخيص سجل المحادثة للبقاء ضمن حدود الرموز.

نسخة الوكيل (المهمة الجارية)

  • الهدف (Goal) – طلب المستخدم الذي يبدأ الحلقة.
  • سياق العمل (Working context) – السجل المتراكم، بما في ذلك نتائج الأدوات السابقة.
  • بيانات الاعتماد (Credentials) – الرموز (tokens) أو مجموعات الأذونات المطلوبة لاستدعاء الأدوات المختارة.
  • الميزانية المستهلكة (Consumed budget) – إحصاء للرموز المستهلكة والخطوات المتخذة حتى الآن.

توضح هذه العناصر كلاً مما يُسمح للوكيل بفعله وما يفعله حالياً.

كيف يغير MCP تدفق عملية التطوير

قبل MCP، كان على المطور الذي يريد من نموذج لغوي كبير أن يستعلم من واجهة برمجة تطبيقات (API) للطقس، ويسحب صفاً من قاعدة بيانات، ثم يصيغ تقريراً، أن يكتب كود ربط (glue code) مخصصاً لكل نقطة نهاية (endpoint). وغالباً ما كان هذا الكود يخفي استدعاءات الأدوات داخل مطالبة (prompt) النموذج، مما يجعل من المستحيل معرفة أي طلب أدى إلى أي استجابة.

مع MCP، يرسل المضيف المحادثة إلى النموذج، ويفحص أي طلب أداة يولده النموذج، ويقوم بتشغيل الأداة بنفسه، ثم يغذي النتيجة مرة أخرى. الكود الإضافي ضئيل، لكن الرؤية كاملة: يتم تسجيل كل رحلة ذهاب وإياب وكل رمز (token).

توفر هذه الرؤية فائدتين عمليتين:

  1. قياس التكلفة – يمكن للمطورين مقارنة نموذج أرخص بنموذج أكبر في نفس المهمة، ورؤية عدد الرموز التي يستهلكها كل تكرار بالضبط.
  2. تدقيق الأمان – تتم عمليات التحقق من سياسة الأدوات وبيانات الاعتماد خارج النموذج، مما يمنع النموذج من استدعاء خدمات غير مصرح بها بصمت.

ما الذي لا يزال غير محدد

يحدد MCP شكل المحادثة والبيانات الوصفية (metadata) التي تنتقل معها، لكنه لا يملي كيفية تنفيذ الأداة داخلياً.

ما الذي يجب مراقبته لاحقًا

  • مجموعات المقاييس (Metric suites) – يعد المقال التالي في هذه السلسلة بقائمة مرجعية للأرقام التي يجب على المطورين تتبعها (إنفاق الرموز، عدد التكرارات، زمن الاستجابة لكل أداة). ستصبح هذه المقاييس بمثابة فحوصات الحالة الفعلية لأي وكيل يعتمد على MCP.

الخلاصة

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