Raft تحلل أين يضيف MCP و Thin MCP الكمون لوكلاء الذكاء الاصطناعي

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

حيث ينشأ التأخير

بدأ المؤلف بسؤال أساسي: ما مقدار التأخير الذي يضيفه MCP نفسه إذا أزلت الشبكة واحتفظت بكل شيء في عملية واحدة. للقيام بذلك، قارنوا أحادي البناء بدون MCP وأحادي البناء مع MCP داخل العملية. اتضح أن النمط نفسه يضيف حملاً نسبياً صغيراً — حوالي 10-11 ميلي ثانية في المتوسط، وأحياناً يصل إلى 35 ميلي ثانية. هذه نقطة مرجعية مهمة: إذا كان الوكيل يتباطأ بمئات الميلي ثانية، فعادة لا يكون السبب هو استخدام MCP نفسه، بل الطبقة الخارجية حوله.

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

ما أظهرته الاختبارات

يحلل المقال عدة سيناريوهات لفصل تأثيرات النقل والتسلسل والتنفيذ نفسه عن بعضها البعض.

• S1, MCP in-process: حوالي 10-11 ميلي ثانية من التأخير الإضافي، مما يعني أن وقت التنفيذ نفسه خفيف نسبياً.
• S2, MCP منفصل عبر شبكة Docker: حوالي 169 ميلي ثانية من الحمل الإضافي لكل استدعاء في المتوسط بسبب الشبكة والتسلسل والاتصال بين العمليات.
• S3a, Thin MCP عبر HTTP + JSON: في سلسلة قياسات واحدة، انخفض الحمل الإضافي إلى حوالي 128 ميلي ثانية، لكن النتيجة اتضحت غير مستقرة وقد تكون أسوأ بشكل ملحوظ في الجولات المتكررة.
• S3b, Thin MCP عبر HTTP + YAML: ارتفع التأخير إلى حوالي 274 ميلي ثانية، مما يشير إلى تكلفة إضافية من التسلسل وفك التسلسل.
• S4 و S5: أعطى ZeroMQ حوالي 200 ميلي ثانية، لكن مع سلوك أكثر قابلية للتنبؤ، بينما قلل وقت التنفيذ C++ الحمل الإضافي إلى حوالي 130-145 ميلي ثانية بدون تغيير جذري في الحجم.

الاستنتاج الرئيسي من هذه الأرقام هو أن التحسينات البديهية لا تعمل دائماً كما هو متوقع. لم يؤد استبدال JSON بـ YAML إلى تسريع النظام، بل أساء إليه بدلاً من ذلك. الانتقال من HTTP إلى IPC أيضاً لم يحقق انتصاراً تلقائياً: لم تُظهر تطبيق iceoryx2 الربح المتوقع، وكان فقط متغير ZeroMQ عملياً أكثر فائدة بسبب نموذجه غير المتزامن. حتى C++ ساعد باعتدال، وليس بشكل درامي.

لماذا thin لا ينقذ الموقف

لا يبدو Thin MCP في المقال وكأنه زر سحري للتسريع، بل كطريقة لتبسيط البنية المعمارية. في هذا المخطط، تبقى طبقة الوكيل الحد الأدنى وتقوم فقط بترجمة الاستدعاءات، بينما تنتقل المنطق التجاري إلى خدمات HTTP منفصلة. يوفر هذا النهج استقلالية اللغة ويبسط التوسع ويسمح بكتابة المنفذين في Go أو Rust أو C++، حتى لو كان SDK MCP كامل غير موجود لهم بعد.

Thin MCP هو أداة معمارية بدلاً من كونه طريقة لتحسين التأخير.

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

ماذا يعني هذا

بالنسبة للفرق التي تبني وكلاء الذكاء الاصطناعي، هذا ترياق جيد ضد التحسين السطحي. إذا كان النظام بطيئاً، يجب أن تبحث أولاً عن عدد الانتقالات بين المكونات والعمليات المحجوبة والنموذج الحسابي للتنفيذ والمراحل الثقيلة مثل التضمينات وإعادة الترتيب. يمكن لـ Thin MCP جعل النظام أنظف وأكثر مرونة، ويمكن لـ C++ أو IPC توفير مكاسب إضافية، لكن التأثير الحاسم يظهر فقط عندما تتوقف البنية المعمارية نفسها عن دفع الطلبات عبر طبقات غير ضرورية.