Anthropic وMCP: لماذا يفقد وكلاء AI تركيزهم عندما يُمنحون أدوات أكثر من اللازم

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

عندما يكون الأكثر أسوأ

قبل سنة، بدا MCP وكأنه إجابة عالمية على فوضى التكاملات. كان بروتوكول واحد يعد بربط وكلاء الذكاء الاصطناعي بـ GitHub و Slack و Jira والقواعد البيانات الداخلية وأي نظام خارجي آخر بدون حديقة حيوان من الإضافات المخصصة. اعتنقت الصناعة هذا المنطق بسرعة: بحلول نهاية عام 2025، كان MCP مدعوماً بالفعل من قبل ChatGPT و Cursor و Gemini و VS Code، وتجاوز عدد الخوادم 10 آلاف، وفقاً للمؤلف. على الورق، بدا وكأنه نظام بيئي ناضج جاهز ليصبح الطبقة الأساسية لجيل جديد من منتجات الوكلاء.

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

"السياق محدود ولا يصبح أكثر فائدة ببساطة من حيث الحجم."

ثلاثة أنماط عملية

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

في الممارسة العملية، في عام 2026، استقرت ثلاثة أنماط تقلل من الحمل المعرفي دون التخلي عن MCP كطبقة تكامل.

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

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

سعر التكامل المريح

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

لذلك، فإن انحطاط الجودة هنا لا يرجع إلى البروتوكول نفسه، بل إلى البنية الهندسية المبنية فوقه. ومن هنا الاهتمام بمهارات الوكيل، التي تروج لها Anthropic. فهي ترفع مستوى التجريد: بدلاً من عمليات واجهة برمجية التطبيقات منخفضة المستوى، يتلقى الوكيل سير عمل معبأ بمنطق محدد مسبقاً. في هذا الوضع، لا يحل النموذج مجدداً كيفية التواصل مع Jira أو نظام آخر، بل يستخدم مسار جاهز لمهمة عمل محددة. هذا يقلل استهلاك الرموز ويقلل احتمالية الخطأ ويجعل سلوك الوكيل أكثر قابلية للتنبؤ. بالنسبة لفرق المنتج، هذا تحول مهم: لم تعد العالمية تعتبر ميزة مطلقة إذا كسرت الاستقرار.

ماذا يعني هذا

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