بقلم: ليلى | محررة أدوات المطورين · صوت تحريري بإشراف بشري
الأسبوع القادم، يحصل بروتوكول Model Context Protocol على تحديث يبدو للوهلة الأولى تقنياً صرفاً، لكنه في الواقع يُزيل أحد أكثر العقبات إيلاماً أمام الشركات التي تحاول بناء تكاملات MCP على نطاق واسع — وقد كان هذا الاحتكاك تحديداً أحد الأسباب الرئيسية وراء ندرة النشر الحقيقي لوكلاء الذكاء الاصطناعي في بيئات الإنتاج على الرغم من كل الضجيج حول الـ agentic AI هذا العام.
MCP هو البروتوكول الذي يمنح نماذج الذكاء الاصطناعي وصولاً آمناً إلى مصادر بيانات خارجية وخدمات متنوعة — تقنياً، هو السباكة التي تسمح لنموذج مثل Claude بالوصول إلى تقويمك أو قاعدة بياناتك أو أدواتك الداخلية، دون أن يضطر المهندسون إلى بناء اتصالات مخصصة لكل حالة على حدة. المشكلة الآن؟ الطريقة التي يتعامل بها البروتوكول مع Session IDs.
الشرح الأوضح لهذا التحديث جاء من شركة Arcade، الناشئة التي أتمّت عامين من العمل وجمعت 60 مليون دولار في يونيو 2026 — بُنيت فكرتها الأساسية على أن وكلاء الذكاء الاصطناعي لا يفشلون بسبب ضعف النماذج، بل لأن البنية التحتية المحيطة بها غير جاهزة. Arcade تُتيح للوكلاء الاتصال بأدوات مثل Gmail وSlack وSalesforce بشكل آمن، وهي بالضبط البيئة التي يكشف فيها خلل Session IDs كل ثقله.
ليفهم المطوّر المشكلة، إليك كيف يعمل النظام الحالي كما يشرحه مؤسس Arcade Nate Barbettini: في المرة الأولى التي يتصل فيها عميل MCP كـ Claude بخادم، يُرسل رسالة تعارف — هويته وإمكاناته — فيرد الخادم بإمكاناته ويُعطي العميل Session ID. من تلك اللحظة، يُرفق العميل هذا الـ ID مع كل طلب لاحق حتى يعرف الخادم أن الطلب ينتمي للمحادثة ذاتها، وحين تنتهي صلاحيته، يضطر العميل إلى طلب معرّف جديد والمتابعة.
على الورق يبدو هذا منطقياً. لكن تخيّل بيئة إنتاج حقيقية: خادم يخدم ملايين المستخدمين خلف load balancer مهمته توزيع الطلبات على عشرات الأجهزة في مناطق مختلفة. كل طلب قد يصل إلى جهاز مختلف — لكن الـ Session ID أصدره جهاز آخر. النتيجة: كل آلة في المنظومة تحتاج إلى معرفة الـ ID الذي أصدره غيرها، وهو ما يستلزم طبقة مشاركة للحالة تُقاوم بطبيعتها المنطق الذي يقوم عليه الـ load balancer. ليس مستحيلاً، لكنه يُضيف تعقيداً وتكلفة حقيقيين.
الحل في النسخة الجديدة — التي نُشر مسودتها الرسمية منذ مايو 2026 — هو التحوّل نحو نهج “عديم الحالة” stateless في إدارة Session IDs على جانب الخادم، مماثل لما تتبعه معظم المواقع الإلكترونية العادية اليوم. بهذا النهج، لا يحتاج الخادم إلى تذكّر من أنت بين الطلبات عبر آلية مركزية مشتركة، مما يجعل التوزيع على خوادم متعددة أمراً طبيعياً بدلاً من أن يكون استثناءً يُعالَج بحلول مؤقتة.
التحديث يذكّرنا بحقيقة لا يحبّ الجميع الاعتراف بها: ليس كل شيء في عالم الذكاء الاصطناعي يتحرك بالسرعة ذاتها. تدريب النماذج يتقدم بوتيرة مذهلة، لكن البنية التحتية التي تحتاجها تلك النماذج لا تزال رهينة الإيقاع البطيء لتوافق لجان المعايير. (وفقاً لـ TechCrunch) هذا التحديث يُصحح معادلة اختلّت منذ البداية — حيث يبني المطوّرون قدرات وكلاء متقدمة على بروتوكول افترض بيئة خادم واحد، بينما الواقع يتطلب توزيعاً أفقياً فعلياً.
للمطوّرين الذين يبنون خوادم MCP اليوم، هذا التحديث لن يُلاحظه المستخدم النهائي، لكنه سيُلاحَظ في تكاليف التشغيل وسهولة الـ deployment وقدرتك على التوسع دون الحاجة إلى طبقة state management إضافية. إذا كنت تتساءل لماذا لم تبادر شركات كبيرة بعد إلى بناء تكاملات MCP من الدرجة الأولى على نطاق واسع على الرغم من توافر النماذج القادرة — فهذه كانت جزءاً من الإجابة.
