الوكلاء يعملون بشكل مختلف عبر MCP وCLI، وطريقة DART تضيف حتى +9 نقاط

عندما يستخدم وكيل الذكاء الاصطناعي الأدوات، فهو لا يرى القدرات «الخام»، بل وصفها: إما كمجموعة دوال عبر بروتوكول MCP (Model Context Protocol، معيار لربط الأدوات بالنموذج اللغوي)، وإما كأوامر في الطرفية، أي CLI. طرح فريق الباحثين من ModalityDance (Zhenning Shi وLiang Pang وYongqi Li) سؤالًا مباشرًا: إذا كانت القدرات متطابقة تمامًا، وتغيّرت فقط طريقة عرضها على النموذج، فهل يتغير سلوك الوكيل؟ الجواب: نعم، وبشكل كبير. فقد اختلفت جودة حل المهام، واستهلاك الرموز (وحدات النص التي يُدفع ثمنها عند استخدام النموذج)، وحتى الطريقة التي يخطئ بها الوكيل ويتعافى من أخطائه. كما اقترح المؤلفون طريقة DART التي رفعت النتائج في جميع التكوينات الستة المختبَرة بما يصل إلى 9.0 نقاط.

كيف نجعل المقارنة عادلة

عادةً تُقارَن MCP وCLI «كما هما». لكن عندها يصعب معرفة ما الذي أثّر في النتيجة: الواجهة نفسها، أم أن أدوات إحداهما أغنى، أو أن تنفيذ الأخرى مختلف. ولإزالة هذا الالتباس، بنى المؤلفون منصة MICA (Matched Interface Comparison and Analysis، «مقارنة وتحليل الواجهات المتكافئة»).

وهي مبنية على النحو التالي:

• يوجد عقد موحّد للإجراءات الدلالية: قائمة بكل ما يستطيع الوكيل فعله أصلًا؛ • يُبنى من هذا العقد تلقائيًا إصداران: MCP وCLI؛ • مهما اختار الوكيل، يُفكَّك ترميز الإجراء ويُرسَل إلى الشيفرة التنفيذية نفسها.

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

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

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

ولتحديد مصدر هذه الحساسية، استخدم الباحثون أسلوبين.

• اختبارات بحالة متطابقة. وُضع الوكيل في الموقف نفسه، وغُيّرت ثلاثة أمور كلٌّ على حدة: طريقة عرض القدرات، وطريقة كتابة الإجراء، وطريقة إرجاع التغذية الراجعة. وهكذا أمكن معرفة أي الأجزاء الثلاثة يربك النموذج أكثر. • مسارات طبيعية مزدوجة. حلّ الوكيل المهمة نفسها عبر MCP وعبر CLI. ومن بين 2004 حلقات، وُجد تباعد بنيوي في 94.3%، أي في نحو 1890 حلقة. ولم تتلاشَ الفروق المبكرة، بل امتدت: فخطوة فاشلة واحدة في البداية غيّرت مجرى التفاعل كله بعدها.

خلاصة المؤلفين: الواجهة جزء من حلقة اتخاذ القرار المغلقة. يتصرف الوكيل، ويتلقى ردًا، ويقرر من جديد، وتؤثر صيغة الرد وصيغة الكتابة في كل خطوة لاحقة. فهي ليست غلافًا محايدًا حول النموذج.

DART: إصلاح كتابة الأمر لا القرار

ما دام التباعد ينشأ في مرحلة «تنفيذ» الإجراء، ففي هذه المرحلة تحديدًا يمكن إصلاحه. تقسّم طريقة DART (Decoupled Action Realization and Targeted Repair، «فصل تنفيذ الإجراء والإصلاح الموجَّه») العمل إلى جزأين. أولًا يحدد الوكيل ما الذي يريد فعله بالضبط. يُتحقَّق من هذا القرار الدلالي ويُحفظ. ثم تتولى خطوة منفصلة مسألة كيفية كتابة هذا القرار بلغة الواجهة المعنية، وعند وقوع أخطاء تُصلح هذه الكتابة فقط. أما معنى الإجراء المختار فلا يُعاد النظر فيه.

الأثر وفق الأرقام المعلنة:

• ارتفعت النتيجة في الاختبارات المعيارية في جميع التكوينات الستة المختبَرة (نموذج مع بيئة)، بحد أقصى 9.0 نقاط؛ • انخفضت كلفة MCP في جميع البيئات الثلاث، بحد أقصى 27.1 ألف رمز لكل مهمة.

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

ماذا يعني ذلك للمهندسين

يفقد الجدل «MCP مقابل CLI» معناه بهذه الصيغة: لا يمكن تحديد الفائز أصلًا دون التحكم في طريقة تنفيذ الواجهة. فالنموذج نفسه بالأدوات نفسها قد يبدو أقوى أو أضعف تبعًا لشكل العرض.

الاستنتاجات العملية:

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

القيود واضحة أيضًا: تشمل الدراسة ستة نماذج وثلاث بيئات، لذا ينبغي توخي الحذر عند تعميم الأرقام على أي مجموعة مهام أخرى. الشيفرة وصفحة المشروع متاحتان للجميع (مستودع ModalityDance/MICA على GitHub)، لذا يمكن التحقق من النتائج على وكلائكم الخاصين.