أمازون تكشف سر فشل أدوات MCP: العلة في التصميم لا في البروتوكول

نشرت أمازون (AWS) تحليلاً تقنياً مفصلاً يفنّد فكرة شائعة بين المطورين، وهي أن سوء تصرف الوكلاء الذكيين (AI Agents) المبنيين على بروتوكول سياق النموذج (Model Context Protocol - MCP) سببه عيب في البروتوكول نفسه. الحقيقة، كما جاء في مدونة أمازون لتعلّم الآلة (AWS Machine Learning Blog)، أبعد من ذلك: المشكلة تكمن في الطريقة التي يصمم بها المطورون الأدوات (Tools) التي يستدعيها هذا الوكيل.

حدّدت الشركة سببين متكررين وراء هذه الإخفاقات: "التضخم" (Bloat) و"الالتباس" (Confusion). يحدث التضخم لأن تعريفات الأدوات تُحمَّل بالكامل في نافذة السياق (Context Window) الخاصة بالنموذج اللغوي الكبير (LLM) مع كل استدعاء، حتى لو لم تُستخدم الأداة فعلياً في تلك المهمة. وعندما يكون هناك عدة خوادم MCP متصلة في الوقت نفسه، فإن تعريفات أدواتها المجمّعة قد تستهلك جزءاً كبيراً من السياق المتاح قبل أن يبدأ النموذج حتى بمعالجة سؤال المستخدم، مما يقلّص المساحة المتبقية للتفكير الفعلي ومعالجة المعلومات الخاصة بالمهمة.

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

هندسة السياق كحل جذري

تطرح أمازون الحل من منظور "هندسة السياق" (Context Engineering)، وهو تخصص يركّز على ضبط ما يراه النموذج اللغوي بالضبط، وفي أي لحظة من سياق العمل يراه. وبدلاً من التعامل مع التضخم والالتباس كعيبين منفصلين، تعاملهما المدونة كطرفي معادلة يجب على مصممي الأدوات ضبطها بعناية: فتقليص السياق بشكل مبالغ فيه قد يحرم النموذج من تفاصيل يحتاجها، في حين أن الإفراط في تركه مفتوحاً يفتح الباب للغموض الذي يولّد الالتباس.

من التوصيات العملية التي طرحتها أمازون ما يخص طريقة بناء استجابات الأدوات. فأداة تُعيد، مثلاً، 50 حقلاً (Field) في كل نتيجة ستُغرق نافذة السياق بسرعة، حتى لو احتاج الوكيل فعلياً إلى حقلين أو ثلاثة فقط لإنهاء مهمته. تقترح أمازون تصميم مخرجات الأدوات بحيث تعرض افتراضياً مجموعة محدودة من الحقول الأساسية فقط، على أن تكون التفاصيل الإضافية متاحة عبر معاملات اختيارية (Optional Parameters) تُستدعى فقط عندما تتطلبها المهمة. هذا التغيير الوحيد، بحسب الشركة، قادر على تقليص الهدر في السياق بشكل ملموس دون التضحية بأي وظيفة.

ولتجسيد هذه التوصيات عملياً، بنت أمازون نموذجاً محاكياً لواجهة برمجة تطبيقات (API) للبحث في محتوى تعليمي لمراحل ما قبل الجامعة (K-12)، طبّقت عليه عدة نسخ من نفس مجموعة أدوات MCP باتباع فلسفات تصميم مختلفة. الهدف من هذه المقارنة أن يرى المطورون جانباً إلى جانب كيف تترجم القرارات المتعلقة بالحقول الافتراضية، ودقة تقسيم الأدوات، وواضح التسمية، إلى فروقات قابلة للقياس في استهلاك السياق ودقة أداء النموذج.

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