Yandex تقارن بين MCP وCLI+Skill لوكلاء الذكاء الاصطناعي: 400 طلب وعطل غير متوقع

أجرى فريق «الخدمات المدينية» في Yandex اختبار أداء قارن فيه بين طريقتين لربط وكيل الذكاء الاصطناعي بواجهات برمجة داخلية، واكتشف أن الاختيار المعماري يؤثر مباشرة في كفاءة استهلاك التوكنات.

المشكلة: التوكنات ليست بلا حدود

نافذة السياق محدودة، وهذا معروف للجميع. لكن قلّة هم من يحسبون عدد التوكنات التي لا تذهب إلى المهمة نفسها، بل إلى «الغلاف المحيط بها»: أوصاف الأدوات، وقوائم المعاملات، والنتائج الوسيطة لعمليات الاستدعاء. وفي السيناريوهات المعقدة قد تستحوذ هذه النفقات الإضافية على حصة كبيرة من السياق المتاح. عندها يبدأ الوكيل بالخطأ، لا لأن النموذج سيئ، بل لأن المساحة المفيدة نفدت.

وطرح دانييل ميخائيلوف من فريق المنتجات الشريكة في Yandex السؤال بشكل مباشر: كيف ننجز أكثر ونستهلك توكنات أقل عند العمل مع واجهات برمجة داخلية حقيقية؟

MCP مقابل CLI + Skill

قارن الفريق بين طريقتين لدمج الوكيل مع الأدوات.

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

CLI + Skill نهج بديل: يتعامل الوكيل مع سطر الأوامر، بينما تُضمَّن المعرفة بالأدوات في «مهارة» (Skill) مضغوطة، وهي تعليمات جاهزة مكتوبة مسبقاً على شكل موجِّه (prompt). الوصف هنا أكثر إيجازاً، لكن صيانته تتطلب جهداً يدوياً.

ولاختبار الفرضية المستمدة من أبحاث خارجية، بنى الفريق اختبار أداء يضم:

• 14 سيناريو واقعياً للعمل مع أدوات Yandex الداخلية
• 2 من النماذج اللغوية
• أكثر من 400 طلب
• قياسات للدقة واستهلاك التوكنات في كل سيناريو

اللحظة التي تعطّل فيها كل شيء

لم تقع أهم نتيجة في نهاية التجربة، بل في منتصفها: توقف فجأة ما كان يعمل بثبات. وبحسب ميخائيلوف، تبيّن أن هذا العطل أكثر إثارة للاهتمام من الأرقام النهائية، إذ اضطر الفريق إلى البحث في أسبابه.

«في لحظة ما تعطّل كل ما كان يعمل، وتبيّن أن هذا هو الأكثر إثارة

للاهتمام. اضطررنا إلى معرفة السبب».

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

الخلاصة: شجرة قرار

وبناءً على نتائج سلسلة التجارب، وضع الفريق شجرة قرار عملية تحدد متى يكون MCP أجدى ومتى يكون CLI + Skill أجدى. وهذه ليست توصية مجرّدة، بل استنتاج مستمد من بيانات حقيقية: أكثر من 400 طلب في بنية تحتية فعلية.

ماذا يعني ذلك

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